首先說一下我們的環境
我們使用的是事務複制，複制是單向的，主伺服器和從伺服器都在同一個機房，當然不同機房也可以，隻需要改一下IP和端口
下面的腳本在我們的SQLServer2008上已經應用，暫時沒有發現問題，當然，如果大家使用過程中有發現問題歡迎向我回報o(∩_∩)o
首先，我們為什麽要校驗呢？
我們知道因為網絡延遲，或者從庫有寫入的情況（當然一般我們在訂閱端會設定為db_datareader，不允許寫）會造成主從資料不一緻的情況
無論是SQL Server還是MySQL，是以我們就需要進行資料校驗，以便大概知道我們的資料什麼時候開始不一緻
而校驗是不可能每時每刻都做校驗的，因為需要讀取全表資料，對性能會有影響
下面的過程隻需要遠端上去從伺服器，也就是訂閱伺服器上面做就可以了，完全不需要遠端主伺服器也就是釋出伺服器
線上我們做複制的表都比較小，資料量也不大
我們做複制的最大一個表是600MB的表
600MB的表 校驗時間是1 分鐘，那麼可以推算 50000MB（50GB）的表 大概80分鐘 ，至于這個時間根據不同的環境 硬體和軟體 所需的校驗時間可能會有所不同
我們使用的伺服器是DELL R720
這個腳本原理很簡單，就是利用SQL Server的job每天定時執行來擷取主從上面的資料，進而判斷主從資料是否一緻
廢話不說了，上腳本
1、在訂閱端執行檢視哪些表做了複制
首先你需要知道你現在哪些表是做了複制的，當然有些人會到釋出伺服器上去看，點選幾下按鈕，其實在訂閱端是有視圖可以看出
目前哪些表做了複制的
有9個表做了複制
2、建立linkedserver
View Code
建立linkedserver的目的是連接配接到釋出伺服器擷取資料，如果是不同機房，那麼隻需要改IP為公網IP和端口就可以了
3、在訂閱伺服器上建表
在訂閱端建立兩個表，這兩個表的作用是儲存校驗資料
我說一下Repl_NeedMonitor表的need_monitor 字段，如果你有一天不想監控某個表了，你需要将那個表的need_monitor 字段改為0就可以了
Repl_NeedMonitor表需要預先插入你要監控的表，在這裡第一步的“在訂閱端執行檢視哪些表做了複制”為了這一步做鋪墊的
執行完第一步，你知道有哪些表需要做監控，然後插入資料到Repl_NeedMonitor表就可以了
Repl_NeedMonitor表
4、建立執行資料一緻性校驗存儲過程
注意：腳本中凡是有--Do 的都是你需要結合自己情況去修改的變量
這個腳本的原理很簡單，是讀取主庫表的記錄數，然後讀取從庫表的記錄數，然後進行比較
當兩邊的記錄數是一緻的，那麼再用EXCEPT 減法歸零的方法比較兩邊表資料的内容是否一緻
如果也是一緻的，那麼兩邊表的資料就是一緻的，否則就是不一緻的，這裡有一個效率問題，就是首先判斷記錄數是否一緻
如果不一緻就沒有必要再去比較内容一緻了，最後把資料插入到表Repl_MonitorStatus
5、建立掃描要監控的表存儲過程
這裡用遊标檢查哪一個表需要進行校驗，然後調用usp_ReplConsistencyCheck存儲過程進行校驗
6、建立定時校驗複制主從資料一緻性JOB
每隔13個小時調用一次存儲過程，當然這個調用頻率可以結合實際情況進行修改
看一下執行結果
從作業曆史裡看一下總執行時間
從執行結果裡面也可以看到執行時間
腳本缺陷
這個腳本是有缺陷的，如果你是複制表裡面的幾個字段而不是整表複制的話，那麼他就不能比較兩邊的一緻性了
情況一：隻複制表裡的幾個字段，并隻需要監控一張表
解決辦法：在第一個存儲過程裡面《執行資料一緻性校驗》存儲過程 修改一下下面的代碼隻select複制的字段，而不是select *
情況二：隻複制表裡的幾個字段，并且需要監控幾張表，這些表中，有些表是整表複制，有些表隻複制幾個字段
由于腳本裡面沒有加入判斷複制項目，那麼對于這種情況，這個腳本無能為力
總結
線上上使用了事務複制這麽久不知道有多少人會定期的進行一下資料校驗，當主庫發生當機的時候，你的從庫的資料是否是一緻的
如果你的主庫因為硬體問題當機，并且不能在最短的時間之内修複好，那麼你這時再做主從資料的一緻性校驗已經沒有可能了
這時候你有兩個選擇
1、冒險使用從庫的資料，将從庫變為主庫
2、放棄使用從庫，全部資料不要（當然了，全部資料不要是沒有可能的！）
至于在SQL Server中比較兩張表的資料一緻性的方法和性能，可以參考下面這篇文章
<a href="http://www.cnblogs.com/lyhabc/p/4176269.html" target="_blank">SQLSERVER中如何快速比較兩張表的不一樣 </a>
如有任何問題，歡迎大家向我回報o(∩_∩)o