Atomic materialization is the default materialization method, and 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. Use admin who, sqm to monitor this activity.
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 Data Server Interface (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.