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 SAP 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 SAP Replication Server with only direct routes to other destination SAP Replication Servers, and each destination SAP Replication Server has only one direct route back to the primary SAP Replication Server.
Create, activate, or validate subscriptions in one or more SAP Replication Servers.
Drop replication definitions in parallel in different SAP Replication Servers.

Note: In a production environment, deadlock situations on the replicate database are automatically handled by the SAP 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 SAP Replication Server. In extreme situations, avoid loading scripts simultaneously in different SAP Replication Servers; instead run scripts sequentially.