This section describes subscription materialization issues for a logical replicate database. It also describes what happens if you execute the switch active command for a logical replicate database during subscription materialization.
The following sections discuss each subscription materialization method.
When you use atomic materialization, Replication Server sets the save interval for the materialization queue to 'strict'. Transactions are not deleted from the materialization queue until the data has been applied to the active database and replicated into the standby database.
Replication Server executes a marker in the active replicate database when the materialization queue has been applied. The marker marks the start of transactions that execute after the materialization queue is applied.
When the marker is executed at the active replicate database, Replication Server writes an informational message like this in its log:
I. 95/10/03 18:00:15. REPLICATE RS: Created atomic subscription publishers_sub for replication definition publishers_rep at active replicate for <LDS.pubs2>
When the marker arrives at the standby replicate database, Replication Server writes an informational message like this in its log:
I. 95/10/03 18:00:15. REPLICATE RS: Created atomic subscription publishers_sub for replication definition publishers_rep at standby replicate for <LDS.pubs2>
Materialization is now complete and Replication Server drops the materialization queue. The subscription is considered VALID at both the active and the standby replicate database.
If you execute the switch active command while the materialization queue is being processed, Replication Server reapplies the materialization queue to the new active database. If you used the incrementally option to create the subscription, only the batches of materialization rows that were not already replicated into the new active database are reexecuted.
When you use nonatomic materialization, the save interval is set to 0, allowing Replication Server to delete rows from the materialization queue after they are applied to the active database.
If a subscription is materializing when you execute the switch active command, Replication Server finishes processing the materialization queue, but marks the subscription “suspect.” Use the check subscription command to find the subscription status in the active and replicate databases. You must drop and re-create suspect subscriptions.
If you use bulk materialization to create a subscription that replicates data into a warm standby application, you must ensure that the subscription data is loaded into the active and standby replicate databases.
If you load the data with a method that logs the inserted rows, such as logged bcp, Replication Server replicates the rows into the standby database. If you load the data with a non-logged method, you must also load it into the standby database because the active database log contains no insert records to replicate into the standby database.
During bulk materialization, you execute the activate subscription with suspension command before you load the subscription data into the replicate database. By default, activate subscription with suspension suspends the DSI threads for both the active database and the standby database. Suspending DSI threads allows you to load the data into both databases.
If you load the data using logged bcp or some other method that logs the rows, execute activate subscription with suspension at active replicate only so that Replication Server only suspends the DSI for the active database. This allows the inserted rows to be replicated from the active database into the standby database.
