Nonatomic Materialization

Execute the create subscription command with the without holdlock option at the replicate Replication Server to create a subscription using the nonatomic materialization method. The subscription is saved in the replicate Replication Server System Database (RSSD). If there are no other subscription requests for the same replication definition and replicate database, the subscription is defined at the primary Replication Server.

Note: Nonatomic materialization is supported only for primary Adaptive Server.

After the definition stage is complete, the replicate Replication Server sends an activation request to the primary Replication Server. The replicate Replication Server immediately starts to build the materialization queue for the subscription. After the materialization queue is built, the subscription status becomes “Qcomplete”. The replicate Replication Server sends a validation request to the primary Replication Server through the primary database. Use admin who to monitor this queue.

When the activation request arrives at the primary Replication Server, the subscription status becomes Active. All updates following the request are sent to the subscription.

The primary Replication Server returns the activation request to the replicate Replication Server. When the Data Server Interface (DSI) at the replicate Replication Server receives the request, the subscription status becomes Active and the transactions in the materialization queue are applied to the replicate database. If the materialization queue has not been built yet, the status returned by check subscription is Active, and not Qcomplete. If the materialization queue has been built, the status is Qcomplete and Active. The DSI thread switches over to the materialization queue from its regular outbound queue for the site. admin who, dsi shows which queue the DSI thread is processing.

After the contents of the materialization queue are applied to the replicate database, the subscription status becomes Materialized.

While the replicate Replication Server is applying inserts from the materialization queue, the validation request is moving from the primary database log, through the RepAgent, to the primary Replication Server.

Once the validation request arrives at the primary Replication Server, the subscription status becomes Valid at the primary Replication Server and the request is forwarded to the replicate Replication Server. The subscription status becomes Valid at the replicate Replication Server after the materialization queue is applied and the validation request reaches the beginning of the DSI queue.

Warning! The subscription data may be inconsistent at the replicate database from the time the DSI thread starts applying the materialization queue until the subscription is validated at the replicate Replication Server. This is the result of not using a holdlock while selecting the subscription data from the primary database. Once the subscription status becomes valid, however, the replicate data is consistent with the primary data.