If you cannot recover the RSSD’s most recent database state, recovering from an RSSD failure is a complex process. In this case, you must load the RSSD from old database dumps and transaction log dumps.
It is not possible to migrate an RSSD database across
platforms using cross platform dump and load XPDL
or using bcp, and so on, the only way is to rebuild
the replication system on the new platform.
The procedure for recovering an RSSD is similar to that for recovering a primary database. However, it requires more steps, since the RSSD holds information about the replication system itself. RSSD system tables are closely associated with the state of the stable queues and of other RSSDs in the replication system.
If a Replication Server RSSD has failed, you first need to determine the extent of recovery required. To do this, perform one or more of the following actions:
When the RSSD becomes available, log in to the Replication Server and execute admin who_is_down. Some Replication Server threads may have shut down during the RSSD’s period of inactivity.
If an SQM thread for an inbound or outbound queue or an RSI outbound queue is down, restart the Replication Server.
If a DSI thread is down, resume the connection to the associated database.
If an RSI thread is down, resume the route to the destination database.
Check all connecting RepAgents to see if they are running with the sp_help_rep_agent system procedure. (RepAgents may have shut down in response to errors resulting from RSSD shutdown.) Restart them if necessary.
If you cannot recover the RSSD’s most recent database state, you must load it from old database dumps and transaction log dumps. See “Recovering an RSSD from dumps”.
