Oracle7 Server Distributed Systems Volume II: Replicated Data
Quiescing the Replicated Environment
Many of the procedures used to alter your replicated environment require that you resynchronize the replicated data at each master site. This is referred to as quiescing the system. You can quiesce the system by calling SUSPEND_MASTER_ACTIVITY. After making the necessary changes to your replicated environment, you can resume normal replication activity by calling RESUME_MASTER_ACTIVITY. Both of these procedures must be called at the master definition site.
During a Quiesce
The following steps describe how the symmetric replication facility resynchronizes the master sites in your replicated environment when you call DBMS_REPCAT.SUSPEND_MASTER_ACTIVITY. All master sites must be available to quiesce the replicated environment.
1. As shown in Figure 4 - 6, when you call SUSPEND_MASTER_ACTIVITY, Oracle synchronously broadcasts this request to each of the master sites, and this request is recorded in the RepCatLog view. Once the site begins to quiesce, its status in the Repgroup view changes from "normal" to "quiescing". This is true of the master definition site as well. At the master definition site, the RepCatLog view also indicates that the master definition site is awaiting a callback (a message indicating that the site has successfully quiesced) from each of the master sites. Each master site must report back to the master definition site when its status changes from "quiescing" to "quiesced". The master definition site cannot change its status to "quiesced" until all of the other master sites have reported back that they are now "quiesced".
Figure 4 - 6. Quiescing the Replicated Environment
Step 1: Calling SUSPEND_MASTER_ACTIVITY
2. Every few minutes a background process wakes up at each master site and checks the RepCatLog view to see if there are any actions that need to be performed. As shown in Figure 4 - 7, the quiesce request implies that Oracle must push any deferred transactions between the master sites. This is accomplished by forcing the NEXT_DATE value for the associated job to SYSDATE. The pushing of the deferred transaction queue can occur asynchronously at each master site.
Figure 4 - 7. Quiescing the Replicated Environment
Step 2: Pushing the Deferred Transaction Queue
3. As each master site successfully pushes its outstanding transactions, its status changes to "quiesced". As shown in Figure 4 - 8, ultimately, this status is sent to the master definition site, and the "await_callback" entry for that master site is removed from the RepCatLog view at the master definition site.
Figure 4 - 8. Quiescing the Replicated Environment
Step 3: Master Sites Return Status to Master Definition Site
4. When the master definition site has successfully quiesced, and is satisfied that all of its associated master sites are also "quiesced", it changes its status to "quiesced", as shown in Figure 4 - 9.
Figure 4 - 9. Quiescing the Replicated Environment
Step 4: Quiesce Completed
Suspending Replication Activity
To suspend replication activity for an object group, call the procedure SUSPEND_MASTER_ACTIVITY in the DBMS_REPCAT package, as shown in the following example:
DBMS_REPCAST.SUSPEND_MASTER_ACTIVITY(
gname => 'acct'
execute_as_user => 'FALSE'));
This example suspends all replication activity for the ACCT object group. You can continue to query objects in this object group, but any modifications that cause replication triggers to fire will not succeed.
Attention: The current implementation of SUSPEND_MASTER_ACTIVITY quiesces all replicated object groups at each master site. No updates can occur to replicated data if the status of any replicated object group at that site is "quiescing" or "quiesced".
You must call this procedure from the master definition site. The replicated object group must be in normal operation when you call this procedure. It suspends all activity at all master replication sites that invoke calls to generated replication procedures. All pending queued procedure calls are processed. Local updates that do not fire replication triggers will still succeed. Each master remains in this state until you invoke the procedure RESUME_MASTER_ACTIVITY.
This procedure typically operates asynchronously at the master definition and the master sites. The RepCatLog view contains interim status.
You must call DBMS_REPCAT.SUSPEND_MASTER_ACTIVITY before calling any of the procedures listed below:
- DBMS_REPCAT.ADD_MASTER_DATABASE
- DBMS_REPCAT.ALTER_MASTER_REPOBJECT
- DBMS_REPCAT.ALTER_MASTER_PROPAGATION
- DBMS_REPCAT.GENERATE_REPLICATION_SUPPORT
- DBMS_REPCAT.GENERATE_REPLICATION_TRIGGER
- DBMS_REPCAT.GENERATE_REPLICATION_PACKAGE
- DBMS_REPCAT.CREATE_MASTER_REPOBJECT
There may be additional situations in which you find it necessary to suspend replication activity. For example, administrators may wish to suspend activity and manually perform queries and updates on the replicas to restore equivalence if an unexpected conflict is detected, which was not resolved.
At a minimum, you must wait until the status field in the RepGroup view is "quiescing" at the master definition site. If the presence of a non-empty deferred transaction queue at a site could cause a problem, you should wait until this status is "quiesced" before proceeding. If an enabled replication trigger at a site could cause a problem, you should wait until the status is "quiesced" before proceeding.
Additional Information: The parameter for the SUSPEND_MASTER_ACTIVITY procedure is described in Table 12 - 169, and the exceptions are listed in Table 12 - 170.
Transaction Ownership
Under synchronous propagation, a transaction is owned by the owner of the trigger and will be propagated to the remote sit with that owner's privileges. You can change the ownership of the transaction, usually to the replication administrator who has full privileges at the remote site, by using GEN_OBJ_OWNER.
Resuming Replication Activity
After quiescing your replicated environment, you can resume normal replication activity by calling the RESUME_MASTER_ACTIVITY procedure in the DBMS_REPCAT package, as shown in the following example:
DBMS_REPCAT.RESUME_MASTER_ACTIVITY(gname => 'acct');
In this example, deferred remote procedure calls can once again be queued in master sites containing the ACCT replicated object group. You must call this procedure from the master definition site. When you call this procedure, the request is synchronously broadcast to all other master sites in the replicated environment, and the status for the replicate object group is updated to "normal" in the RepCatLog view.
Additional Information: The parameters for the RESUME_MASTER_ACTIVITY procedure are described in Table 12 - 165, and the exceptions are listed in Table 12 - 166.