《Replication的犄角旮旯》系列導讀

Replication的犄角旮旯（一）--變更訂閱端表名的應用場景

Replication的犄角旮旯（二）--尋找訂閱端丟失的記錄

Replication的犄角旮旯（三）--聊聊@bitmap

Replication的犄角旮旯（四）--關于事務復制的監控

Replication的犄角旮旯（五）--關于復制identity列

Replication的犄角旮旯（六）-- 一個DDL引發的血案(上)（如何近似估算DDL操作進度）

Replication的犄角旮旯（七）-- 一個DDL引發的血案(下)（聊聊logreader的延遲）

Replication的犄角旮旯（八）-- 訂閱與發布異構的問題

Replication的犄角旮旯（九）-- sp_setsubscriptionxactseqno，賦予訂閱活力的工具

---------------------------------------華麗麗的分割線--------------------------------------------

接觸Replication時間長了，遇到“應用復制的命令時在訂閱服務器上找不到該行。”這樣錯誤的幾率大大增加，而如何定位并手動填補數據成了DBA的必修課；本文將介紹一種暴力方法來追蹤已丟失的熱點數據，尤其是對于同表多條記錄丟失的問題，提高DBA的工作效率；

本文設計思路由陳璟童鞋提供，本人只是加以整理，如有侵權，烤鴨伺候……

本方法雖多次經受驗證無誤，但多次被MS supporter們建議不要嘗試使用此方法，還望各位DBA三思！

一般來說，定位“訂閱端丟失的記錄”分成以下幾步：

1、通過xact_seqno、command_id定位到具體命令

2、解析commands，確定命令類型（insert、update、delete）、對象名稱、主鍵

3、根據上述獲取的條件補數（insert或DTS），這是我們的關鍵，也是我們需要簡化的步驟

關于定位失敗的命令，可以參考微軟官方博客

http://blogs.msdn.com/b/apgcdsd/archive/2012/01/10/10254809.aspx

沒錯，我也是這樣操作，但如果你發現，剛剛補過一條記錄后，msrepl_errors又出現新的記錄，咋辦？再1、2、3的執行一遍？關鍵的問題是我們也不知道到底丟失了多少命令。如果這是發生在夜里，幾分鐘報一次警，持續1、2個小時，相信所有的DBA們都會瘋掉……so，自己動手豐衣足食吧；

先來分析一下可能造成“找不到行”的復制命令的類型；

1、insert

　　這類操作對DBA絕對是個blackhole；試想一下，如果一個insert操作丟失了，如果這個丟失的記錄后續沒有通過復制進行過update、delete，你是絕對發現不了的；沒辦法，這樣的工作只能交給驗證訂閱或者定期進行tablediff這類第三方工具搞定了，不過我相信大部分DBA都是在業務方發現數據不一致以后才后知后覺的……

2、update

　　update是三個DML操作里面比較復雜的，一個update命令傳到訂閱端但發現沒有這條記錄的時候就會報錯，由于在發現命令丟失時發布端已經完成更新，所以直接手動從發布庫里導入這條記錄到訂閱端即可；

3、delete

　　delete是最簡單的無需關心的操作，如果一個delete的復制命令傳到訂閱端發現沒有記錄，你會像處理update那樣重新從發布庫導入這條記錄到訂閱端？那你一定是大腦掉線了……帥鍋，這時候發布庫已經沒有這條記錄了，然后你會瘋了一樣的問自己腫木辦，腫木辦么？

　　有人說，在訂閱端insert一條只有主鍵的偽記錄，然后delete就可以正常下去了。沒錯，這確實是個辦法，但不是個好辦法，畢竟一個insert你也是要敲上十幾個甚至幾十個字符的……其實處理方法很簡單，已經刪了的記錄就沒必要再找回來了，關掉監控就行了；當然我指的是MS errors的報警監控。

處理方法：

1、定位具體命令

　　你還在通過復制監視器查看出錯信息？那補上一條數估計要幾分鐘（等待出錯信息刷新的時間），要是丟了幾十條記錄，那你這一天就不用干別的事情了；

　　直接從distribution.dbo.msrepl_errors里查吧；　　

SELECT * FROM distribution.dbo.MSrepl_errorsORDER BY time DESC

2、解析commands

　　根據上面查詢的結果，取出xact_seqno（出錯的命令的事務號）、command_id（命令id），在根據下面的系統存儲過程定位到具體的語句

USE distributiongosp_browsereplcmds '0x00026BBC000A3DDE000400000000','0x00026BBC000A3DDE000400000000' --兩個字符串均是上一步獲取的xact_seqno

　　在結果集中使用上一步的command_id定位到具體的行，取出command，就是出錯的命令

3、分析命令

　　[sp_MSupd_dbotest4]　　這是調用訂閱端的存儲過程名，upd說明是update操作，test4是訂閱端的對象名；

　　‘abc’　　這個是update操作的value，具體對應的哪一個column，那就數數逗號吧（自己測試一下就會發現規律）；實際上我們并不需要知道要更新哪一列；

　　10002 這個是主鍵的value，復制命令到訂閱端執行都是按照主鍵去操作的，這個看一下訂閱端的存儲過程就清楚了；

　　0x02　 這個是8進制的bitmap，簡單說就是這一類操作的位圖值，在這一章不會用到這個，后續的文章里會涉及到；