SQL SERVER複寫拓撲結構中，訂閱端宕機後的處理…..（二）

接著上一章

 

當訂閱端長時間沒有連上，且同時在發布端有大量的insert語句，來看看：

 

USE mysales_normalGOINSERT INTO [mysales_normal].[myinventory].[Vendor]SELECT addressid,substring(addressline1,1,20),substring(city,1,10),substring(city,1,10),substring(city,1,5),substring(city,1,10) FROM AdventureWorks.person.ADDRESSWHERE AddressID>10000

 

這條語句插入了18510條語句，等待吧！可以從replication monitor可以得知未發送的命令：

 

SELECT count(*) FROM distribution.dbo.msrepl_commands (nolock) dmWHERE dm.publisher_database_id=7and article_id=8

 

 

如果運行 【Distribution clean up: distribution】job,是沒有任何效果的，因為命令沒有發送到訂閱端！

 

 

這時已經是第二天了，一直斷了10多個小時，插入insert tracer,會發現distributor to subscriber的狀態是pending,未發送命令多了一條，：

啟動具名執行個體後會發現distributor 把掛起的命令立即發送到subscriber，：

再來看看replication monitor中的undistributed comands選項：

只剩下最後一條insert tracer命令沒有被【Distribution clean up: distribution】這個job清理掉，看看相關msrepl_commmands中的命令：

SELECT count(*) FROM distribution.dbo.msrepl_commands (nolock) dm
WHERE dm.publisher_database_id=7
and dm.article_id=8

結果為0

再來看看未被清理掉的是什麼命令，使用如下的指令碼，這個時候不能使用@article_id這個參數

exec distribution..sp_browsereplcmds@publisher_database_id=7

 

 

 

 

 

訂閱端表vendor已經有相應的資料了！

 

總結：1：再一次的證明了undistributed commands 僅僅是顯示相應發布項在msrepl_commands中的命令，包括已發送的和未發送的命令，這個命令數字只能作為輔助判斷，

為了證明這一點，可以手動的暫停【Distribution clean up: distribution】job，會發現undistributed commands 會永遠不變。

         2： 【Distribution clean up: distribution】也只是清理掉已發送的命令，10分鐘運行一次，關鍵的判斷還是要通過[insert tracer]來確認，這個命令的詳細解釋點擊這

         3：在做這個測試尋找資料中，發現這個連結，在 FQA FOR Replication 中微軟給出了一個總結式的結論，抄錄如下：

Does replication resume if a connection is dropped

Yes. Replication processing resumes at the point at which it left off if a connection is dropped. If you are using merge replication over an unreliable network,

consider using logical records, which ensures related changes are processed as a unit.

       4：有關複製分發的資料，以下兩個網站非常不錯，可以常去看看！

a: REPLTalk covers Using and Tuning SQL Replication

b:replicationanswers