Replication Agent can automatically determine whether the truncation point has changed. You can send a resync marker using resume resync when:
There is no change to the truncation point and the expectation is that the Replication Agent should continue processing the transaction log from the last point that the Replication Agent processed. Each outbound DSI thread and queue receives and processes the resync database marker. DSI reports to the Replication Server system log when a resync marker has been received, satisfying the skip to resync marker request of DSI. Subsequently, DSI rejects committed transactions while it waits for a dump database marker. With this message and the change of behavior to one of waiting for the dump database marker, you can apply any dump to the replicate database at this time.
The truncation point of the primary database has been moved in time. This can occur when you manually change the truncation point.
In this situation, before sending the resync marker, execute ra_init force in Replication Agent, which reinitializes the Replication Agent repository. With this reinitialization, Replication Agent tracks any changes in the database that it might miss as a result of moving the truncation point and skipping the processing of some transaction log records.
Since the truncation point has changed, open transactions in the Replication Server inbound queue must be purged because these transactions do not match new activity sent from the new truncation point. Replication Server resets duplicates checking, since the changed truncation point could send a record with a previous origin queue ID (OQID). Since the prior data is purged from the queues, Replication Server does not treat any new activity from the Replication Agent as duplicate activity, and consequently does not reject the new activity. The purge option does not change DSI processing because Replication Server continues to reject outbound queue commands while waiting for the marker.
