Determine the specific subscriptions
and columns that are failing to replicate.
This also verifies that the primary and destination data servers, and the primary or
destination Replication Server are running.
- Use isql to log in to
the primary or destination Replication Server.
If you cannot log in to a Replication Server,
then it is down.
- Run rs_subcmp to find out which data in a suspect subscription
is failing to replicate.
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, then use the
UNIX diff command to compare the output.
- If rs_subcmp
displays inconsistent rows, note the columns and rows that are not
being replicated.
- If
only text, unitext, and image columns
are not being replicated, these columns
may have inconsistent replication status.
- If no data exists for subscribed columns,
the subscription has not materialized.
- If rs_subcmp fails, one or both of the data servers are down:
If the primary data server is down, the Adaptive
Server log may be corrupt or full. The data server may also have
an operating system or hardware error.
If the destination data server is down, there may be a Data Server Interface (DSI) problem, or an operating system or hardware
error.
- Use rs_subcmp to
check if other subscriptions on the same data server are replicating:
If no other subscriptions
are replicating, it is likely that a problem exists with that data
server rather than with a particular subscription.
If all other subscriptions are replicating, then
a problem may exist with that particular subscription.
- 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.
Perform these:
- Look
for orphaned transactions in the primary Replication Server inbound
queue for the database.
- Troubleshoot RepAgents.
- Troubleshoot database connections.
Next
Once you have identified the data that is failing to replicate,
verify that the Replication Server threads are up.