The dematerialize with purge method is invoked by using the with purge option of the drop subscription command. The subscription status is set to Dematerializing at the replicate Replication Server, and a drop request is forwarded to the primary Replication Server.
When the replicate Replication Server receives the drop request, it creates a dematerialization queue and starts a dematerialization thread to fill the queue. The dematerialization thread selects subscription data from the replicate database and puts a row delete operation into the dematerialization queue for each row that does not belong to any other active subscription.
While the dematerialization thread is writing to the dematerialization queue, the Data Server Interface (DSI) thread switches to the dematerialization queue and begins applying the deletes to the replicate database.
If the dematerialization thread encounters an error, the entire dematerialization process restarts and the same error may recur. To avoid this problem, suspend the connection to the replicate database. Then resume it using the skip transaction option. This resumes the connection with the second transaction in the queue. The first transaction is written to the exceptions log.
When dematerialization has completed, the subscription status at the replicate Replication Server is changed to Removing. The replicate Replication Server logs in to the primary Replication Server and requests the deletion of the subscription from its system tables. When that request succeeds, the replicate Replication Server removes the subscription from its own system tables and the dematerialization process is complete.
Add a new partition to the replicate Replication Server. If no partition is available, consider using bulk dematerialization.
If you have difficulty deleting subscription data, drop the subscription using the without purge option.
If you have difficulties because of permissions, a user with the appropriate permission should issue the drop subscription command.