Oracle7 Server Distributed Systems Volume II: Replicated Data

Propagating DDL Changes

When you use the procedures in the DBMS_REPCAT package to make changes to your replicated environment, these changes are not visible to a snapshot site until you refresh the snapshot replicated object group. Refreshing a snapshot site updates the objects contained in the replicated object group, whereas refreshing a snapshot updates the values of the rows of a snapshot object in the replicated object group.

Refreshing a Snapshot Site

To refresh a snapshot site with the most recent information from its associated master site, call the REFRESH_SNAPSHOT_REPGROUP procedure in the DBMS_REPCAT package at that snapshot site, as shown in the following example:

DBMS_REPCAT.REFRESH_SNAPSHOT_REPGROUP(
    gname                 => 'accts', 
    drop_missing_objects  => TRUE, 
    refresh_snapshots     => TRUE, 
    refresh_other_objects => TRUE
    execute_as_user       => FALSE);

In this example, all of the snapshots and other objects in the ACCTS object group of your current snapshot site will be refreshed, and any objects dropped at the associated master site will be dropped from the snapshot site. All snapshots in the replicated object group are consistently refreshed using the FORCE refresh option.

By default, only the RepGroup views for the given replicated object group are updated. Refreshing the RepGroup view implies that any changes made to the replicated environment, such as the addition of a new master site, or the removal of an object from the object group, are made visible to the snapshot site.

You can optionally choose to refresh the replicated snapshots and non-snapshot objects, such as views and procedures. Snapshots are refreshed as described . Oracle refreshes the non-snapshot objects, if necessary, by dropping and re-creating them using the definition of the object at the associated master site.

Additional Information: The parameters for the REFRESH_SNAPSHOT_REPGROUP procedure are described in Table 12 - 155, and the exceptions are listed in Table 12 - 156.

Attention: During a snapshot refresh, Oracle locks the base table of the snapshot in exclusive mode. Because other users are prevented from updating a snapshot during a refresh (queries are still available), you should schedule your refreshes to occur when the expected activity on the snapshot is low.

Altering a Replicated Snapshot

If you must alter the shape of a snapshot as the result of a change to its master, you must drop and recreate the snapshot by calling the DBMS_REPCAT.DROP_SNAPSHOT_REPOBJECT procedure and then the DBMS_REPCAT.CREATE_SNAPSHOT_REPOBJECT procedure.

Altering the Propagation Method of a Replicated Snapshot

To alter the method used to propagate changes from the snapshot site to its associated master site, use the DBMS_REPCAT.ALTER_SNAPSHOT_PROPAGATION procedure, as shown in the following example:

DBMS_REPCAT.ALTER_SNAPSHOT_PROPAGATION(
     gname             => 'accts',
     propagation_mode  => 'synchronous'
     execute_as_user   => 'REPADMIN');

In this example, all of the updatable snapshots in the ACCTS object group will now synchronously propagate their changes to their associated master tables.

When you call this procedure from the snapshot site, Oracle pushes the deferred transaction queue at the snapshot site, locks the snapshot base tables, and regenerates any triggers and their associated packages.

Additional Information: The parameters for the ALTER_SNAPSHOT_PROPAGATION procedure are described in Table 12 - 84, and the exceptions are listed in Table 12 - 85.

Forcing Ownership of a Transaction

You can change the ownership of a transaction, usually to the replication administrator who has full privileges at the remote site, by using EXECUTE_AS_USER.