在sql server 復制中，當在發(fā)布數(shù)據(jù)庫執(zhí)行1個大事務時，如一次性操作 十萬或百萬以上的數(shù)據(jù)。當操作數(shù)據(jù)在發(fā)布數(shù)據(jù)庫執(zhí)行完成后 ，日志讀取器代理將掃描事務日志，一次性傳遞到分發(fā)數(shù)據(jù)庫中。若上個事務未傳遞完成，連續(xù)執(zhí)行多個事務，日志讀取器代理將掃描日志中多個事務同時傳遞到分發(fā)數(shù)據(jù)庫中，默認最大掃描500個事務。如果執(zhí)行多次上百萬或千萬的數(shù)據(jù)將堵塞很久。
日志讀取器代理可配置將大事務劃分為多個小事務進行傳遞到分發(fā)數(shù)據(jù)庫中，分發(fā)隊列則按照小事務分發(fā)到訂閱數(shù)據(jù)庫中，這樣數(shù)據(jù)就很快同步！
在沒改代理參數(shù)之前，本人執(zhí)行1次插入30萬的數(shù)據(jù)到發(fā)布表中。插入完成后，監(jiān)控發(fā)布到分發(fā)的記錄如下：
可以看到，這1個事務的命令都得一次傳遞完才能分發(fā)，而分發(fā)又消耗時間，這里等待太久影響事務的實時性。
如果還有其他事務，默認500（參考參數(shù)：-ReadBatchSize），也將一起傳遞，耗時較長。
現(xiàn)在更改參數(shù)，掃描到 1000 左右的命令就即時分發(fā)，需要設(shè)置如下參數(shù)：
-MaxCmdsInTran number_of_commands
注：該參數(shù)只能添加到日志讀取器代理中，在代理配置文件沒有此參數(shù)的設(shè)置。
添加后重啟 日志讀取器代理。
再次插入 30 萬的數(shù)據(jù)！~到監(jiān)視器查看
可以看到，命令達到 1000 左右就進行分發(fā)了，此時查看訂閱數(shù)據(jù)庫，數(shù)據(jù)也同步過來了，這樣就省去了較多掃描命令的時間。
更詳細查看每個事務的命令數(shù)，如下：
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
這個參數(shù)雖好，但是也可能引起數(shù)據(jù)的一致性。
如：
在發(fā)布更新了一批數(shù)據(jù)，但是訂閱查詢時卻有不同。
分發(fā)事務遇到?jīng)_突或者死鎖，也導致這部分的數(shù)據(jù)不一致。
參考：復制日志讀取器代理
