Re: Fast Refresh of Materialized View

CompDatabasesOracleServer wrote:
> Hi
> I'm using Oracle 10g (10.1.0.2.0) database.
>
> Our network contains one single Master, and several Replicated sites
> with updateable materialized view. All MV's are defined with fast
> refresh.
> When I add a row to a table at a replicated site (MV), it is pushed to
> the master site, and other replicated sites. My question is: does
> anyone know how the refresh of the materialized views are performed? Is
> is so that during the refresh, the new row is first deleted, and then
> inserted again at the replicated site that first inserted the new row?
> I've added some logging to the INSERT, UPDATE and DELETE tirggers, and
> according to the log, the INSERT trigger gets fired at both the Master
> and the replicated site where the row was inserted, but during the
> refresh of MV, the new row is first deleted, and then inserted again.
> Is this behaviour correct?
>

Yes - the master site cannot distinguish what site the update came from, and leave that out of the update loop. Or, it would be more trouble implementing that.
Besides, there's something like conflict resolution, and priorities. Master sites have higher priority than Slaves, in a M/S setup as yours.

> What will happen if the MV table is a parent of another table (not MV),
> and this relation is defined with CASCADE-DELETE constraint? Am I
> loosing the child records of the MV then? Can this be avoided?

Did you try? :)

Surely, you must be joking: a Parent/Child relation built on a view, with the child not being replicated?!? What design would that be?

-- 
Regards,
Frank van Bortel

Top-posting is one way to shut me up...