Replication Problems

Replication problems occur when data changes at the primary database are not applied to the destination database.

Replication consists of copying data operations, such as updating or deleting data, from a primary database to the destination database. Replication begins after a subscription has been successfully materialized.

If you are monitoring the replication system, you might directly observe that data is not replicating to a destination database. Use rs_subcmp to determine which subscription is not being replicated.

If someone reports that their client application has retrieved incorrect data from a destination database consider that a replication problem may exist. Compare the primary and destination tables; if they are the same, then data is being replicated correctly, and it is likely that a problem with the client application that is causing incorrect data to appear in the client application. If data is not the same at the primary and destination databases, replication is failing, and you must troubleshoot the replication system.

Some symptoms of a replication problem directly identify the cause; other symptoms require more investigation to find the underlying cause. These symptoms are listed in order of most common to least common:

Data Server Interface (DSI) thread is down.
Threads other than DSI are down.
Use admin who_is_down to display information about threads that are down:
- DIST (Distributor) thread
- RepAgent user thread
- RSI (Replication Server Interface) thread
- RSI user thread
- RS (Replication Server) user thread
- SQM (Stable Queue Manager) thread
- SQT (Stable Queue Thread) thread
- NRM (Normalization) thread
- Major replication system component is down.
Use isql to check to see if a server is down by logging in to each server.
- RepAgent
- Replication Server
- Data server
A detecting loss message, which means that data replication messages were lost after queues were rebuilt. This message is shown in the Replication Server error log or in the rs_oqid system table.

See the Loss Status column in the output from admin health and admin who, sqm to monitor data consistency and check if there is the possibility of data loss in the queues.
Inbound or outbound stable queues are growing larger.

Use admin who, sqm and sysadmin dump_queue to display information about inbound and outbound stable queues.
Number of duplicate transactions is increasing.

Use admin who,sqt and sysadmin dump_queue to display information about inbound and outbound stable queues.
Transactions remain open for longer than is reasonable. These transactions might be orphans or a very long transaction. Orphan transactions do not have an ending commit or rollback statement.

Use admin who, sqt and sysadmin dump_queue to display information about inbound and outbound stable queues.
Primary and destination Replication Servers do not have the same locater.

Use isql to log in to the RSSD and view the rs_locater system table.
Replication is successful for other subscriptions on different data servers with connections to the same destination Replication Server.

Use rs_subcmp to compare a subscription’s tables in the primary and replicate databases to make sure the tables are the same.
Replication is successful for other subscriptions in the same or different tables on the same data server while replication for a particular subscription is failing.

Use rs_subcmp to compare a subscription’s tables in the primary and replicate databases to make sure the tables are the same.

Some symptoms appear as error messages in the Replication Server and Adaptive Server error logs. Use the diagnostic tools to identify replication problem symptoms.