RSSD deadlocks

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 usually occur when commands for the RSSD are issued faster than the server can process them. For example, RSSD deadlocks may occur even on a fast machine and network when you run scripts that create, alter, or delete many subscriptions or replication objects.

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

RSSD deadlocks are known to occur when you are:

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:

  1. 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.”

  2. 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.