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.
Data Server Interface (DSI) thread is down.
Threads other than DSI are down.
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.
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.