Bulk dematerialization

Bulk dematerialization is invoked using the without purge option of the drop subscription command. The subscription status becomes Dematerializing at the replicate Replication Server and a drop request is forwarded to the primary Replication Server.

When the primary Replication Server receives the drop request, it stops sending updates for the subscription to the replicate Replication Server. The subscription status becomes Dematerializing at the primary Replication Server and a drop request is returned to the replicate Replication Server.

When the replicate Replication Server receives the drop request, the subscription status is changed to Removing at the replicate. The replicate Replication Server logs in to the primary Replication Server and requests that it delete the subscription from its system tables. When that request has succeeded, the replicate Replication Server removes the subscription from its own system tables and the dematerialization is complete.

Table 5-9 describes solutions for bulk 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.

**Table 5-9: Materialization problems—without purge option**
Replicate Status	Primary Status	Subscription State	Suggested Actions
Dematerializing/ Pending		Waiting for other subscription requests for the same replication definition and replicate database.	Check for other subscription being created or dropped for the same replication definition and database. If there are no other subscriptions, wait for five minutes.
Dematerializing/ Recovering		Cannot connect to the primary Replication Server to drop the subscription.	Check the replicate Replication Server error log for messages. Make sure the user who created the subscription has the same login name and password at the primary Replication Server and the replicate Replication Server. The user should also have at least primary subscribe privileges.
Dematerializing		The primary Replication Server is waiting for the drop request.	Determine whether the primary Replication Server has run out of queue segments. Verify that the primary Replication Server is up and that the SQM, SQT, and DIST threads for the primary database are running.
Dematerializing	Dematerializing	The primary Replication Server processed the drop request and sent it to the replicate Replication Server. The replicate Replication Server is waiting for the drop request.	Check the route between the primary Replication Server and the replicate Replication Server. Check the DSI thread for the replicate database. Determine whether the replicate Replication Server ran out of queue segments.
Dematerializing/ Recovering	Dematerializing	The primary Replication Server processed the drop request and returned it to the replicate Replication Server. The replicate Replication Server abnormally terminated.	Wait for the subscription daemon to reset the recovering flag.
Removing/ Recovering	Dematerializing	The replicate Replication Server could not log in to the primary Replication Server to delete the subscription from the system tables.	Verify that the primary Replication Server is running.
Removing	Dematerializing	The primary Replication Server is deleting the subscription from the system tables. The replicate Replication Server is waiting for the primary Replication Server to finish.	Wait.
Removing	Invalid	The subscription is removed from the primary Replication Server. The replicate Replication Server will remove the subscription next.	Wait.
Invalid	Invalid	The subscription has been dropped.	None.