Figure 3-6 illustrates a warm standby application for a primary database. In this example, one Replication Server manages three databases:
The active database for a logical primary database,
The standby database for a logical primary database, and
A replicate database that has subscriptions for the data in the logical primary database.
In this example, a single Replication Server manages both the primary and replicate databases. In other instances, different Replication Servers may manage the primary and replicate databases.
Figure 3-6: Warm standby application for a primary database
The numbers in Figure 3-6 indicate the flow of transactions from client applications through the replication system in a warm standby application for a primary database.
In Figure 3-6, numbers 1 through 3 trace transactions from clients to an inbound queue in the Replication Server:
Clients execute transactions in the active primary data server.
The active primary data server updates the active primary database.
The Replication Agent for the active primary database reads transactions for replicated data in the database log. It forwards the transactions to the Replication Server, which writes them into an inbound queue.
All transactions for replicated data, including those executed by the maintenance user, are sent to the Replication Server for application in the standby database.
In Figure 3-6, numbers 4 through 8 trace transactions from the inbound queue to the replicate database:
The Distributor thread reads transactions from the inbound queue.
The Distributor thread processes transactions against subscriptions and writes replicated transactions into an outbound queue.
Transactions executed by the maintenance user, which are always replicated into the standby database (because you set the send_warm_standby_xacts parameter when you configure RepAgent with sp_config_rep_agent), are not replicated to replicate databases unless you also set the send_maint_xacts_to_replicate parameter for RepAgent.
For Oracle, transactions executed by the maintenance
user, are always replicated to the replicate database because the filter_maint_userid configuration
parameter is invalid for Replication Agent for Oracle irrespective
of whether the parameter is set to “true” or “false”.
A DSI thread reads transactions from the outbound queue.
The DSI thread executes the transactions in the replicate data server.
The replicate data server updates the replicate database.
If the transactions are to be replicated to a database managed by a different Replication Server, they are written into an RSI outbound queue managed by an RSI thread instead of a DSI thread. The RSI thread delivers the transactions to the other Replication Server.
In Figure 3-6, numbers 9 through 11 trace transactions from the inbound queue to the standby database for the logical primary database:
The standby DSI thread reads transactions from the inbound queue.
The standby DSI thread executes transactions in the standby data server.
The standby data server updates the standby database.
The inbound queue is read by the standby DSI and the Distributor. The two threads do their work concurrently. Messages cannot be truncated from the inbound queue until both threads have read them and delivered them to their destination. The messages remain in the queue until the DSI has applied them to the standby database and, if there are subscriptions or replicated stored procedure executions, the Distributor has written them to the outbound queue.
Depending on your replication system, the transactions may be replicated into the standby database before the replicate database. However, Replication Server guarantees that the standby primary database and replicate databases will be kept in sync with the active primary database.
