Identify the data that is failing to replicate

Use this procedure to determine the specific subscription and columns that are failing to replicate. This procedure also checks to see if the primary and destination data servers and primary or destination Replication Server are running.

StepsIdentifying data that is failing to replicate

  1. To find out which data in a suspect subscription is failing to replicate, use isql to log in to the primary or destination Replication Server and run rs_subcmp.

    rs_subcmp logs in to the primary and destination data servers and compares the subscription’s data in the primary and destination tables. rs_subcmp can compare tables at Adaptive Server data servers only. To compare tables at a non-Adaptive Server data server, you can use a program equivalent to bcp out on the non-Adaptive Server data server and bcp out on the Adaptive Server data servers, and compare the output using the UNIX diff command

  2. If rs_subcmp successfully displays inconsistent rows, note the columns and rows that are not being replicated.

  3. If no data exists for subscribed columns, then the subscription has not materialized. Go to “Materialization”.

  4. If you cannot log in to a Replication Server, then that Replication Server is down. Go to “Replication Server is down”.

  5. If rs_subcmp fails, then one or both of the data servers are down:

  6. Use rs_subcmp to check if other subscriptions on the same data server are replicating:

  7. Use rs_subcmp to check if other subscriptions on databases controlled by the same destination Replication Server are replicating. If replication is working for other databases controlled by the destination Replication Server, then the problem is a specific database, database connection, or RepAgent. Take the following actions:

Once you have identified the data that is failing to replicate, go to the next procedure.