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 deadlocks and these error messages are displayed 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 are known to occur when you are:

Creating 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.
Creating, activating, or validating subscriptions in one or more Replication Servers.
Dropping 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.”
Drop the “active/activating” subscriptions using the without purge option and re-create subscriptions.

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

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