昨天一臺SQL Server 2008R2的資料庫在凌晨5點多拋出下麵告警信息： The log scan number (620023:3702:1) passed to log scan in database 'xxxx' is not valid. This error may indica... ...
昨天一臺SQL Server 2008R2的資料庫在凌晨5點多拋出下麵告警信息：
The log scan number (620023:3702:1) passed to log scan in database 'xxxx' is not valid. This error may indicate data corruption or that the log file (.ldf) does not match the data file (.mdf). If this error occurred during replication, re-create the publication. Otherwise, restore from backup if the problem results in a failure during startup.
乍一看，還以為資料庫損壞了（data corruption），但是在做完DBCC CHECKDB後，發現其實資料庫其實是完好無損的。那麼肯定是跟Replication有關。但是在搜索了相關資料，僅僅在The process could not execute ‘sp_repldone/sp_replcounters” 這篇博客中找到了類似錯誤的資料：
Common Causes
- The last LSN in Transaction Log is less than what the LSN Log Reader is trying to find. An old backup may have been restored on top of Published Database. After the restore, the new Transaction Log doesn't contain the data now distributor & subscriber(s) have.
- Database corruption.
How to fix this
- Ensure database consistency by running DBCC CHECKDB on the database.
- If an old backup was restored on top of published database then use sp_replrestart
- If going back to the most recent transaction log backup is not an option then execute sp_replrestart on publisher in published database. This stored procedure is used when the highest log sequence number (LSN) value at the Distributor does match the highest LSN value at the Publisher.
- This stored procedure will insert compensating LSNs (No Operation) in the publisher database log file till one the compensating LSN becomes more than the highest distributed LSN in distribution database for this published database. After this it inserts this new high LSN in the msrepl_transactions table in the distribution database and executes sp_repldone on published database to update the internal structures to mark a new starting point for log reader agent.
- Ensure that the log reader agent is stopped and there is no incoming transactions on the published database, when this SP is executed.
- Since transactions may have been lost, we recommend to reinitialize the subscriber(s) and/or recreate publication/subscription(s). For large databases consider using “Initialize from Backup” as discussed in SQL Book Online.
但是在這個案例當中， 資料庫既沒有損壞，也沒有還原過。 只能是Replication出現了錯誤，但是在SQL Server的Replication中又沒有找到相關錯誤信息，本身這個是AWS的DMS自動生成的Replication，很多內部信息不太清楚（例如，是否出現異常），官方也沒有找到很詳細的介紹這個錯誤的相關資料。在此記錄一下。
參考資料：
https://blogs.msdn.microsoft.com/repltalk/2010/02/19/the-process-could-not-execute-sp_repldonesp_replcounters/
