[Deprecated] The specified LSN for repldone log scan occurs before the current start of replication in the log

Summary

The specified Log Sequence Number for repldone log scan occurs before the current start of replication in the log.

Causes

There are unreplicated transactions in the transaction log that are marked for replication, but there are no current Log Reader Agents that can read those unreplicated transactions. The Log Reader Agent delivers replicated commands and transactions to the distribution database within transactions. After each transaction commits, the Log Reader Agent calls sp_repldone in the Publisher database to mark information such as the sequence number of the last distributed transaction and the commit record of the next transaction to scan for, if any. Since sp_repldone is called on the Publisher database, after the transaction is committed at the distribution database, it is possible for the Publisher database tracking data to have incorrect tracking data.

For example, after the log reader successfully commits a transaction (we will call it T1) in the distribution database, and sp_repldone was called to update the Publisher database tracking data to remember T1 has been sent and transaction T2 is the next one to scan, now the Log Reader Agent moves on to transaction T2. If the Publisher is shut down immediately after the Log Reader Agent commits transaction T2 in the distribution database but before sp_repldone is called to update the Publisher database tracking information, then when the Publisher comes back up, the tracking data still indicates that T1 was just sent and T2 is the next to scan. However, this is inconsistant with the fact that T2 has been committed in the distribution database already. The Log Reader Agent handles this situation internally. The next time the Log Reader Agent starts, it will query the distribution database to find out the sequence number of the last distributed transaction (LSN). After that it calls sp_repldone to reset the Publisher database tracking data so that the set of commands and transactions that had been delivered are not sent again.

This error may be raised if the transaction sequence number the Log Reader Agent retrieved from the distribution database is smaller than the last delivered transaction's sequence number as indicated by its tracking data. This condition implies the distribution database is missing some commands and transactions that the Log Reader Agent had previously sent. For example, if sync with backup was not enabled on the distribution database when the distribution database was restored to an earlier version while the Log Reader Agent had been delivering commands and transactions to the distribution database. Another possible cause is for user to manually delete some records from the MSrepl_transactions table in the distribution database.

The error might also occur, if replication was incompletely removed or if there is an inconsistency in the database.

Resolutions

To resolve this issue try the following:

• Use DBCC CHECKDB to verify the consistency of the database.

• If there is no other way to clear out the transaction log, execute sp_repldone and choose @xactid to be NULL, @xact_seqno to be NULL, and @reset to be 1 so that all replicated transactions in the log are marked as distributed. This is useful when there are replicated transactions in the transaction log that are no longer valid and you want to truncate the log. Caution This procedure can be used in emergency situations to allow truncation of the transaction log when transactions pending replication are present. This will cause existing log records to be skipped, therefore resulting in inconsistencies between the Publisher and the Subscriber.

• EXEC sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0, @time = 0, @reset = 1

To ensure consistency, drop and recreate all publications and subscriptions if possible.

Overrideable Parameters