After you create a subscription, Replication Server propagates transactions from the primary database to the replicate database. The replication system keeps the replicate copy of the table consistent with the primary copy.
The replicate data may become inconsistent with the primary version. For example, if you have not restricted update permissions on a replicate table to the maintenance user for the database, a client may update the replicate data directly, introducing inconsistencies.
Primary and replicate tables may be temporarily inconsistent because Replication Server takes some time to transfer updates from the primary table to the replicate table. However, as soon as the Replication Server applies the updates at the replicate database, inconsistency due to latency no longer exists.
There are three kinds of inconsistency that may occur between primary and replicate tables:
Missing rows in the primary table are missing from the replicate table.
Inconsistent rows in the primary table differ from the corresponding rows in the replicate table.
Orphaned rows in the replicate table do not exist in the primary table or do not match subscriptions for the replicate table.
You need to differentiate between temporary inconsistencies caused by delay and real inconsistencies caused by the incorrect use of the system or by system failures. The rs_subcmp program described in the following section helps you make this distinction. You can correct inconsistencies by dropping and recreating subscriptions or by using rs_subcmp.
