Using the Subscription Comparison Procedure

Follow this RSSD recovery procedure if you have executed some DDL commands since the last transaction dump but you have not created any new subscriptions or routes.

DDL commands in RCL include those for creating, altering, or deleting routes, replication definitions, subscriptions, function strings, functions, function-string classes, or error classes.

Warning! Do not execute any DDL commands until you have completed this recovery procedure.

Following this procedure makes the failed RSSD consistent with upstream RSSDs or consistent with the most recent database and transaction dumps (if there is no upstream Replication Server). It then makes downstream RSSDs consistent with the recovered RSSD.

If DDL commands have been executed at the current Replication Server since the last transaction dump, you may have to re-execute them.

Warning! This procedure may fail if you are operating in a mixed-version environment; that is, the Replication Servers in your replication system are not all at the same version level.

To prepare the failed RSSD for recovery, perform steps 1 through 4 of the basic RSSD recovery procedure.
To prepare all upstream RSSDs for recovery, execute the admin quiesce_force_rsi command at each upstream Replication Server.
- This step ensures that all committed transactions from the current Replication Server have been applied before you execute the rs_subcmp program.
- Execute this command sequentially, starting with the Replication Server that is furthest upstream from the current Replication Server.
- Make sure that RSSD changes have been applied, that is, that the RSSD DSI outbound queues are empty.
- The Replication Server that is directly upstream from the current Replication Server cannot be quiesced.
To prepare all downstream RSSDs for recovery, execute the admin quiesce_force_rsi command at each downstream Replication Server.
- This step ensures that all committed transactions bound for the current Replication Server have been applied before you execute the rs_subcmp program.
- Execute this command sequentially, starting with Replication Servers that are immediately downstream from the current Replication Server.
- Make sure that RSSD changes have been applied, that is, that the RSSD DSI outbound queues are empty.
Reconcile the failed RSSD with all upstream RSSDs, using the rs_subcmp program.
- First execute rs_subcmp without reconciliation to get an idea of what operations it will perform. When you are ready to reconcile, use the -r flag to reconcile the replicate data with the primary data.
- You must execute rs_subcmp as the maintenance user. See Replication Server Administration Guide Volume 1 > Manage Replication Server Security for more information on the maintenance user.
- In each instance, specify the failed RSSD as the replicate database.
- In each instance, specify the RSSD of each upstream Replication Server as the primary database.
- Start with the furthest upstream Replication Server, and proceed downstream for all other Replication Servers with routes (direct or indirect) to the current Replication Server.
- Reconcile each of the following RSSD system tables: rs_articles, rs_classes, rs_columns, rs_databases, rs_erroractions, rs_functions, rs_funcstrings, rs_objects, rs_publications, rs_systext, and rs_whereclauses.
- When you execute rs_subcmp on replicated RSSD tables, the where and order by clauses of the select statement must include all rows to be replicated.
  
  The failed RSSD should now be recovered.
Reconcile all downstream RSSDs with the RSSD for the current Replication Server, which was recovered in the previous step, using the rs_subcmp program.
- First execute rs_subcmp without reconciliation to get an idea of what operations it will perform. When you are ready to reconcile, use the -r flag to reconcile the replicate data with the primary data.
- You must execute rs_subcmp as the maintenance user. See Replication Server Administration Guide Volume 1 > Manage Replication Server Security for more information on the maintenance user.
- In each instance, specify as the primary database the recovered RSSD.
- In each instance, specify as the replicate database the RSSD of each downstream Replication Server.
- Start with the Replication Servers that are immediately downstream, then proceed downstream for all other Replication Servers with routes (direct or indirect) from the current Replication Server.
- Reconcile each of the following RSSD system tables: rs_articles, rs_classes, rs_columns, rs_databases, rs_erroractions, rs_functions, rs_funcstrings, rs_objects, rs_publications, rs_systext, and rs_whereclauses.
- When you execute rs_subcmp on replicated RSSD tables, the where and order by clauses of the select statement must select all rows to be replicated.
  
  All downstream RSSDs should now be fully recovered.
If the recovering Replication Server is an ID Server, you must restore the Replication Server and database IDs in its RSSD.
1. For every Replication Server, check the rs_databases and rs_sites system tables for their IDs.
2. Insert the appropriate rows in the recovering RSSD rs_idnames system table if they are missing.
3. Delete from the recovering RSSD rs_idnames system table any IDs of databases or Replication Servers that are no longer part of the replication system.
4. Ensure that the rs_ids system table is consistent.
  Execute in the RSSD of the current Replication Server this stored procedure:
```
rs_mk_rsids_consistent
```
If the recovering Replication Server is not an ID Server, and a database connection was created at the recovering Replication Server after the last transaction dump, delete the row corresponding to that database connection from the rs_idnames system table in the ID Server’s RSSD.
Perform steps 5 through 14 of the basic RSSD recovery procedure.
To complete RSSD recovery, re-execute any DDL commands executed at the current Replication Server since the last transaction dump.