The atomic materialization method is invoked using the default version of the create subscription command. If there are no other subscriptions for the same replication definition and replicate database, the subscription is defined at the primary Replication Server. If the primary Replication Server is unavailable or any other problems occur, the recovering column in the rs_subscriptions system table is set to 1 to denote that the subscription requires recovery.
After the definition stage is complete, the replicate Replication Server builds the materialization queue for the subscription. You can monitor this activity with the admin who, sqm command.
Replication Server executes the rs_select_with_lock function to select subscription rows from the primary site. After the materialization queue is built, the replicate Replication Server sends an activation request to the primary Replication Server. This request is passed through the primary database via the rs_marker system function. When the primary Replication Server receives the activation request, the subscription is marked valid. All updates following the request are sent to the replicate database if they match the subscription.
The primary Replication Server sends the activation request back to the replicate Replication Server, where it is inserted into the DSI queue for the replicate database. When the DSI queue processes the request, the subscription status is changed to active.
The DSI thread also switches over to the materialization queue from its regular outbound queue for the site. The admin who, dsi command indicates which queue the DSI thread is processing. The materialization queue is applied to the replicate database. After the materialization queue is processed, the subscription is marked Valid and the materialization is complete.
If the replicate Replication Server runs out of stable queue segments:
Add a new partition to the replicate Replication Server.
If no partition is available, drop the subscription without purge.
Use nonatomic materialization.
To estimate how much space a subscription needs, refer
to the Replication Server Design Guide.
If the replicate database log cannot hold all of the data for the subscription in a single transaction:
Drop the subscription without purge.
Use the incremental version of atomic materialization.
Table 5-3 describes solutions for atomic materialization problems based on the status returned by check subscription. The Replicate Status column shows the subscription status returned by check subscription at the replicate Replication Server. The Primary Status column shows the subscription status returned by check subscription at the primary Replication Server. The Subscription State column provides a detailed description of the subscription status. The Suggested Actions column provides the solutions.
Replicate Status |
Primary Status |
Subscription State |
Suggested Actions |
|---|---|---|---|
Defined/ Pending |
Invalid |
Waiting for other subscriptions for the same replication definition and replicate database to be processed. |
Check for other subscriptions being created and dropped for the same replication definition and replicate database. If there are no other subscriptions, wait five minutes. |
Defined/ Recovering |
Invalid |
Cannot connect to the primary Replication Server to define the subscription. |
Check the replicate Replication Server error log for messages. Make sure the user creating the subscription has the same login name and password at the primary Replication Server and the replicate Replication Server. Make sure the user has at least primary subscribe permission at the primary Replication Server. |
Defined/ Recovering |
Defined |
Cannot build the materialization queue. |
Verify that the primary data server is running. Make sure the user creating the subscription has the same login name and password at the primary data server and replicate Replication Server, select permission on the primary table, and execute permission for rs_marker. Investigate whether the replicate Replication Server is out of stable queue segments. Use the admin disk_space command. Use admin who, dsi and admin who, sqm to monitor the queues. |
Defined |
Defined |
Building materialization queue. |
Building the queue may take some time. You may need to wait until this process is complete. Use admin who, sqm to monitor materialization. Investigate whether the primary Replication Server is out of stable queue segments. Use the admin disk_space command. Check if rows are being selected using a holdlock at the primary database. |
Qcomplete |
Defined |
Waiting for the activation request to get to the primary Replication Server. Materialization queue has been built. |
Verify that the RepAgent for the primary database is running. Investigate whether the primary Replication Server is out of stable queue segments. |
Qcomplete/ Recovering |
Defined/ Valid |
The replicate Replication Server stopped after the materialization queue was completed. |
Wait. The status should return to Qcomplete at the replicate Replication Server. |
Qcomplete |
Activating |
The activation request is being processed at the primary Replication Server. |
Wait. The status at the primary Replication Server should change to valid. |
Qcomplete |
Valid |
The subscription is complete at the primary Replication Server. Waiting for activation request or applying the materialization queue at the replicate Replication Server. |
Check the route between the primary and the replicate Replication Server. Check the replicate Replication Server DSI thread for the replicate database. Investigate whether the replicate Replication Server ran out of queue segments. Use admin who, dsi and admin who, sqm to monitor the queues. If admin who, dsi shows that the DSI is processing the materialization queue, wait until the queue has been processed. The length of the wait depends upon the size of the queue. |
Valid |
Valid |
Complete. |
None. |
