The arguments to these procedures contain the information necessary to apply the change at the remote site. The RPC is stored in the local deferred transaction queue. The local deferred transaction queue is stored in a database table, which can be viewed using the DefTran view.
As shown in Figure 1 - 6, when you commit an update to a table, Oracle inserts the necessary remote procedure calls into the deferred transaction queue. Oracle uses a second table, which can be viewed using the RepSites view, to store the destinations of each of the sites to which to push this queue. When you add another master site, its location is added to this destinations view. There is only one entry in the queue for each deferred transaction, regardless of how many destinations are listed in the replication sites view.
In separate transactions, the entries in the deferred transaction queue are propagated to each site listed in the replication site's destination view. Oracle does not remove a transaction from the local deferred transaction queue until it has been successfully propagated to all of the destinations listed in the replication sites view.
Figure 1 - 6. Propagating Data Level Changes
To propagate changes from the master tables to the associated read-only and updatable snapshots, Oracle uses the snapshot refresh mechanism,instead of the row-level replication mechanism. During a snapshot refresh,
For example, to preserve a master-detail relationship between a pair of snapshots, place the related snapshots in the same refresh group.
Synchronous replication uses the same row-level replication mechanism to propagate data-level changes as deferred transactions, but does not use a deferred transaction queue.
As shown in Figure 1 - 7, when you make a change to a replicated table, Oracle fires a trigger which calls a packaged procedure at each master site that applies the change.
Figure 1 - 7. Propagating Data-Level Changes Synchronously
Your change must be successfully applied at both the local table and at any replicated copies of the table, or rollback occurs. Synchronous replication is most useful in situations where you have a stable network and require that your replicated sites remain continuously synchronized.
You can choose to create a replicated environment in which some sites propagate changes synchronously while others use asynchronous propagation (deferred transactions).
Note: The advantages of synchronous propagation (no conflicting changes, never out of date) can only be fully realized if all sites are both sending and receiving changes synchronously.
Procedural replication only replicates the call to a stored procedure that is used to update a table. Procedural replication does not replicate the update itself.
After you replicate a procedure, you can generate a wrapper for this procedure at each site. When you call the procedure at the local site, the wrapper ensures that a call is ultimately made to the same procedure at all other sites in the replicated environment. This call can be made either synchronously or asynchronously (using the deferred transaction queue described ![[*]](jump.gif)
).
Note: Do not confuse this wrapper with the PL/SQL Wrapper.
Suggestion: Procedural replication is often used for large batch-oriented operations that can be run serially (such as purging data that was "logically" deleted), and can be used in conjunction with row-level replication. For more information on using procedural replication, refer to .