Replication problems

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. Replication problems occur when data is changed at a primary database but not at the destination database.

You can find that a replication problem exists by observing that data is not replicating to a destination database or by hearing from someone that their application is retrieving incorrect data from a destination database.

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.

You should consider that a replication problem may exist if someone reports that their client application retrieved incorrect data from a destination database. Compare the primary and destination tables; if they are the same, then data is being replicated correctly. There is probably a problem with the client application that is causing incorrect data to be displayed 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 can be organized into the following types in order of the most common first:

• Data Server Interface (DSI) thread is down.

• Threads other than DSI are down.

  You use admin who_is_down to display information about threads that are down.

• DIST thread

• RepAgent User thread

• RSI thread

• RSI User thread

• RS User thread

• SQM thread

• SQT 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.

• 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. Orphans are transactions that 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 login 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.