Using the Subscription Re-Creation Procedure

Restore an RSSD that requires that lost subscriptions be re-created if you have created new subscriptions or other DDL since the last transaction dump, and you have not created new routes.

1. To prepare the failed RSSD for recovery, perform steps 1 through 4 of the basic RSSD recovery procedure.
2. To prepare the RSSDs of all upstream and downstream Replication Servers for recovery, perform step 2 through 3 of the subscription comparison procedure.
3. Shut down all upstream and downstream Replication Servers affected by the previous step. Use the shutdown command.
4. Restart all upstream and downstream Replication Servers in standalone mode, using the -M flag.

   All RepAgents connecting to these Replication Servers shut down automatically when you restart the Replication Servers in standalone mode.

5. To reconcile the failed RSSD with all upstream RSSDs, perform step 4 of the subscription comparison procedure.

   The failed RSSD should now be recovered.

6. To reconcile all downstream RSSDs with the RSSD for the current Replication Server, perform step 5 of the subscription comparison procedure.
7. If the recovering Replication Server is an ID Server, to restore the IDs in its RSSD, perform step 6 of the subscription comparison procedure.
8. 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, perform step 7 of the subscription comparison procedure.
9. Query the rs_subscriptions system table of the current Replication Server for the names of subscriptions and replication definitions or publications and their associated databases.

   • Also query all Replication Servers with subscriptions to primary data managed by the current Replication Server, or with primary data to which the current Replication Server has subscriptions.

   • You can query the rs_subscriptions system table by using the rs_helpsub stored procedure.

10. For each user subscription in the rs_subscriptions system table, execute the check subscription command using the information obtained in step 9.

    • Execute this command at the current Replication Server and at all Replication Servers with subscriptions to primary data managed by the current Replication Server, or with primary data to which the current Replication Server has subscriptions.

    • Subscriptions with a status other than VALID must be deleted or re-created, as described below.

11. For each Replication Server that has a non-VALID subscription with the current Replication Server as the primary:

    • Note its subid, and delete the appropriate row from the primary rs_subscriptions system table.

    • Use the subid from rs_subscriptions to find corresponding rows in the rs_rules system table, and also delete those rows.

    For each system table, rs_subscriptions and rs_rules:

    • If a subscription is in the primary table and not in the replicate table (because it was dropped), delete the subscription row from the primary table.

    • If a subscription is in the replicate table and not in the primary table, delete the subscription row from the replicate table. After completing the rest of this procedure, re-create the subscription, as described in steps 17 through 19.

    • If a subscription is in both the primary and replicate tables but is not VALID at one of the sites, delete the rows from both tables. After completing the rest of this procedure, re-create the subscription, as described in steps 17 through 19.

12. For each primary Replication Server for which the current Replication Server has a non-VALID user subscription:

    • Note its subid, and delete the appropriate row from the primary rs_subscriptions system table.

    • Use the subid from rs_subscriptions to find corresponding rows in the rs_rules system table, and also delete those rows.

    For each system table, rs_subscriptions and rs_rules:

    • If a subscription is in the primary table and not in the replicate table, delete the subscription row from the primary table. After completing the rest of this procedure, re-create the subscription, as described in steps 17 through 19.

    • If a subscription is in the replicate table and not in the primary table (because it was dropped), delete the subscription row from the replicate table.

    • If a subscription is in both the primary and replicate tables, but not VALID at one of the sites, delete the rows from both tables. After completing the rest of this procedure, re-create the subscription, as described in steps 17 through 19.

13. At both the primary and replicate Replication Server, execute the sysadmin drop_queue command for all existing materialization queues for subscriptions deleted in steps 17 through 19.
14. Restart in normal mode all Replication Servers, and their RepAgents, that had subscriptions to primary data managed by the current Replication Server or with primary data to which the current Replication Server had subscriptions.
15. Perform steps 5 through 13 of the basic RSSD recovery procedure.
16. Reexecute any DDL commands that executed at the current Replication Server since the last transaction dump.
17. Enable autocorrection for each replication definition.
18. Re-create the missing subscriptions using either the bulk materialization method or no materialization.

    Use the define subscription, activate subscription, validate subscription, and check subscription commands for bulk materialization.

19. For each re-created subscription, restore consistency between the primary and replicate data in either of two ways:

    • Drop a subscription using the drop subscription command and the with purge option. Then re-create the subscription.

    • Use the rs_subcmp program with the -r flag to reconcile replicate and primary subscription data.