SqlServer 復制中將大事務分紅大事務分發的辦法

SqlServer 復制中將大事務分紅大事務分發的辦法。本站提示廣大學習愛好者：（SqlServer 復制中將大事務分紅大事務分發的辦法）文章只能為提供參考，不一定能成為您想要的結果。以下是SqlServer 復制中將大事務分紅大事務分發的辦法正文

在sql server 復制中，當在發布數據庫執行1個大事務時，如一次性操作 十萬或百萬以上的數據。當操作數據在發布數據庫執行完成後 ，日志讀取器代理將掃描事務日志，一次性傳遞到分發數據庫中。若上個事務未傳遞完成，延續執行多個事務，日志讀取器代理將掃描日志中多個事務同時傳遞到分發數據庫中，默許最大掃描500個事務。假如執行屢次上百萬或千萬的數據將梗塞很久。

日志讀取器代理可配置將大事務劃分為多個大事務停止傳遞到分發數據庫中，分發隊列則依照大事務分發到訂閱數據庫中，這樣數據就很快同步！

在沒改代理參數之前，自己執行1次拔出30萬的數據到發布表中。拔出完成後，監控發布到分發的記載如下：

可以看到，這1個事務的命令都得一次傳遞完才干分發，而分發又耗費時間，這裡等候太久影響事務的實時性。
假如還有其他事務，默許500（參考參數：-ReadBatchSize），也將一同傳遞，耗時較長。

如今更改參數，掃描到 1000 左右的命令就即時分發，需求設置如下參數：
-MaxCmdsInTran number_of_commands

注：該參數只能添加到日志讀取器代理中，在代理配置文件沒有此參數的設置。

添加後重啟 日志讀取器代理。

再次拔出 30 萬的數據！~到監視器檢查

可以看到，命令到達 1000 左右就停止分發了，此時檢查訂閱數據庫，數據也同步過去了，這樣就省去了較多掃描命令的時間。
更詳細檢查每個事務的命令數，如下：

SELECT top 10 A.xact_seqno,A.entry_time,COUNT(*) AS cmds
FROM distribution.dbo.MSrepl_transactions A(NOLOCK) 
INNER JOIN distribution.dbo.MSrepl_commands B(NOLOCK) 
ON A.xact_seqno=B.xact_seqno
GROUP BY A.xact_seqno,A.entry_time
ORDER BY cmds DESC

這個參數雖好，但是也能夠惹起數據的分歧性。

如：

在發布更新了一批數據，但是訂閱查詢時卻有不同。

分發事務遇到抵觸或許死鎖，也招致這局部的數據不分歧。

參考：復制日志讀取器代理