Oracle7 Server Distributed Systems Volume II: Replicated Data

Recovery

Databases using symmetric replication are distributed databases. Follow the guidelines for distributed database backups outlined in the Oracle7 Server Administrator's Guide when creating backups of symmetric replication databases. Follow the guidelines for coordinated distributed recovery in the Oracle7 Server Administrator's Guide when recovering a symmetric replication database.

If you fail to follow the coordinated distributed recovery guidelines, there is no guarantee that your symmetric replication databases will be consistent. For example, a restored master site may have propagated different transactions to different masters. You may need to perform extra steps to correct for an incorrect recovery operation. One such method is as to drop and recreate all replicated objects in the recovered database.

You should consider removing pending deferred transactions and deferred error records from the restored database, and resolve any outstanding distributed transactions before dropping and recreating replicated objects. If the restored database was a master definition site for some replicated environments, you should designate a new master definition site (as described below) before dropping and creating objects. Any snapshots mastered at the restored database should be fully refreshed, as well as any snapshots in the restored database.

To provide continued access to your data, you may need to change master definition sites (assuming the database being recovered was the master definition site), or remaster snapshot sites (assuming their master site is being recovered). These techniques are described in the following sections.

Changing Master Definition Sites

To change your master definition site to another master site in your replicated environment, call the RELOCATE_MASTERDEF procedure in the DBMS_REPCAT package, as shown in the following example:

DBMS_REPCAT.RELOCATE_MASTERDEF(
	gname	=>	'acct', 
	old_masterdef	=>	'acct_hq.hq.com', 
	new_masterdef	=>	'acct_ny.ny.com',
	notify_masters	=>	TRUE,
	include_old_masterdef	=>	TRUE);

In this example, the master definition site for the ACCT replicated object group is changed from ACCT_HQ to ACCT_NY. The former master definition site remains as a master site in the replicated environment. By default, all master sites, including the former master definition site, are notified of this change.

Additional Information: The parameters for the RELOCATE_MASTERDEF procedure are described in Table 12 - 159, and the exceptions are listed in Table 12 - 160.

Usage Notes

It is not necessary for either the old or new master definition site to be available when you call RELOCATE_MASTERDEF. In a planned reconfiguration, you should invoke RELOCATE_MASTERDEF with NOTIFY_MASTERS TRUE and INCLUDE_OLD_MASTERDEF TRUE. If just the master definition site fails, you should invoke RELOCATE_MASTERDEF with NOTIFY_MASTERS TRUE and INCLUDE_OLD_MASTERDEF FALSE. If several master sites and the master definition site fail, the replication administrator should invoke RELOCATE_MASTERDEF at each operational master with NOTIFY_MASTERS FALSE.

Changing a Snapshot Site's Master

To change the master database of a snapshot replicated object group to another master site, call the SWITCH_SNAPSHOT_MASTER procedure in the DBMS_REPCAT package, as shown in the following example:

DBMS_REPCAT.SWITCH_SNAPSHOT_MASTER(
	gname	=>        'acct', 
	master	=>        'acct_ny.ny.com'
	execute_as_user => 'FALSE');

In this example, the master site for the ACCT object group is changed to the ACCT_NY database.

You must call this procedure at the snapshot site whose master site you want to change. The new database must be a master site in the replicated environment.

When you call this procedure, Oracle uses the new master to perform a full refresh of each snapshot in the local object group.

The entries in the SYS.SLOG$ table at the old master site for the switched snapshot are not removed. As a result, the MLOG$ table of the switched updatable snapshot at the old master site has the potential to grow indefinitely, unless you purge it by calling DBMS_SNAPSHOT.PURGE_LOG.

Additional Information: The parameters for the SWITCH_SNAPSHOT_MASTER procedure are described in Table 12 - 171, and the exceptions are listed in Table 12 - 172.