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

?

?

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

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

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

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

Replication的犄角旮旯（四）--關于事務復制的監(jiān)控

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

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

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

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

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

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

?

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

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

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

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

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

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

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

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

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

?

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

?

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

1、insert

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

2、update

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

3、delete

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

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

?

處理方法：

1、定位具體命令

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

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

2、解析commands

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

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

3、分析命令

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

　　‘a(chǎn)bc’　　這個是update操作的value，具體對應的哪一個column，那就數(shù)數(shù)逗號吧（自己測試一下就會發(fā)現(xiàn)規(guī)律）；實際上我們并不需要知道要更新哪一列；

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

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

　　至此，distribution的任務完成了，下面就是本文的關鍵——修改訂閱端存儲過程

4、修改訂閱端存儲過程

　　到訂閱數(shù)據(jù)庫里找到對應的存儲過程“sp_MSupd_dbotest4”，并生成腳本；

　　@pkc1　　這個就是test4的主鍵值；看到了吧，復制命令到訂閱端都是按照主鍵操作的，即便你在發(fā)布端傳入的是update table set a='abc'這樣的全表操作；

　　而下面的兩個if + 一個exec sp_MSreplraiserror 20598，就是判斷當更新數(shù)量為0時（@@rowcount=0）報一個20598的錯誤；

　　改造原則：鑒于可能出現(xiàn)同一個表中多條記錄丟失，我們可以先記錄那些丟失記錄的主鍵，然后批量的根據(jù)主鍵值去一次性導入到訂閱端，這才是簡化的關鍵；

　　創(chuàng)建log表;

　　對于update命令，我們需要的信息包括表名(test4)、操作類型(U)、主鍵名及鍵值(id=@pkc1)；參照下圖，在存儲過程中的相應位置添加insert語句，同時注釋掉報警語句；

?　　再查詢一下記錄表，我們要的信息就都在這里了。同時，由于關閉了報警，分發(fā)代理在下一次重試后可以正常繼續(xù)執(zhí)行下面復制命令，如果遇到多個記錄丟失的情況，只要去記錄表中查詢即可；

　　對于delete命令，正如之前所說，已經(jīng)刪除的命令就沒有必要再找回了，打算留一個日志的童鞋可以參照update的處理方法，修改訂閱端對應的del存儲過程，insert到記錄表中，或者干脆直接注釋掉報警語句，忽略掉delete操作即可；

5、手動補數(shù)

　　根據(jù)記錄表中的記錄，可以查看截止到當前時間點，之前所有的丟失記錄情況，拼一下sql，用DTS就可以完成批量導入；

?

注意：

　　1、此方法不建議長期使用，建議手動補數(shù)后注釋掉insert語句，并打開報警語句；

　　2、手動補數(shù)后，請將記錄表中已操作的記錄set yn=1，作為標記，以免重復insert時主鍵沖突；

　　3、對于聯(lián)合主鍵，存儲過程中默認以@pkc1~@pkcn表示，請注意記錄表中pkey字段的長度，以免溢出；

　　4、示例中僅列出了int型主鍵，對于varchar型主鍵，請自行調(diào)整insert語句中pkey列的值；

?

最后再次強調(diào)，修改訂閱端存儲過程存在風險，請謹慎操作~

?

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