RSSD Deadlocks

Replication Server System Database (RSSD) deadlocks usually occur when commands for the RSSD are issued faster than the server can process them. Deadlocks may occur even on a fast machine and network when you run scripts that create, alter, or delete many subscriptions or replication objects.

Symptom

The RSSD stops responding and you see these messages in the Replication Server error log:

E. 2006/06/13 11:14:12. ERROR #11061 USER(rho_dbo) - s/stscol.c(1717) Check
the log for error messages from RSSD.
E. 2006/06/13 11:18:22. ERROR #1028 USER(rho_dbo) - s/stscol.c(1717) Message
from server: Message: 1205, State: 2, Severity: 13 -- ‘Your server command
(process id #14) was deadlocked with another process and has been chosen as
deadlock victim. Re-run your command.’.

Explanation

RSSD deadlocks may occur when you:

Create routes in parallel within a star configuration. A star configuration has one primary Replication Server with only direct routes to other destination Replication Servers, and each destination Replication Server has only one direct route back to the primary Replication Server.
Create, activate, or validate subscriptions in one or more Replication Servers.
Drop replication definitions in parallel in different Replication Servers.

Note: In a production environment, deadlock situations on the replicate database are automatically handled by the Replication Server.

Solution

If routes are deadlocked, drop the routes and re-create them sequentially, allowing one minute between each creation.

If an RSSD deadlock occurs during the activation or validation of subscriptions:

Use rs_helpsub in the RSSD or check subscription in the Replication Server to check for subscriptions with status “Active/Activating” instead of “Active/Unknown.”
Use the without purge option to drop the “Active/Activating” subscriptions, then recreate the subcriptions.

If deadlocks occur while you are dropping subscriptions, drop them again.

To prevent a large number of deadlocks, do not simultaneously load several scripts into Replication Server. In extreme situations, avoid loading scripts simultaneously in different Replication Servers; instead run scripts sequentially.