在sql server 復(fù)制中，當(dāng)在發(fā)布數(shù)據(jù)庫(kù)執(zhí)行1個(gè)大事務(wù)時(shí)，如一次性操作 十萬(wàn)或百萬(wàn)以上的數(shù)據(jù)。當(dāng)操作數(shù)據(jù)在發(fā)布數(shù)據(jù)庫(kù)執(zhí)行完成后 ，日志讀取器代理將掃描事務(wù)日志，一次性傳遞到分發(fā)數(shù)據(jù)庫(kù)中。若上個(gè)事務(wù)未傳遞完成，連續(xù)執(zhí)行多個(gè)事務(wù)，日志讀取器代理將掃描日志中多個(gè)事務(wù)同時(shí)傳遞到分發(fā)數(shù)據(jù)庫(kù)中，默認(rèn)最大掃描500個(gè)事務(wù)。如果執(zhí)行多次上百萬(wàn)或千萬(wàn)的數(shù)據(jù)將堵塞很久。

日志讀取器代理可配置將大事務(wù)劃分為多個(gè)小事務(wù)進(jìn)行傳遞到分發(fā)數(shù)據(jù)庫(kù)中，分發(fā)隊(duì)列則按照小事務(wù)分發(fā)到訂閱數(shù)據(jù)庫(kù)中，這樣數(shù)據(jù)就很快同步！

在沒(méi)改代理參數(shù)之前，本人執(zhí)行1次插入30萬(wàn)的數(shù)據(jù)到發(fā)布表中。插入完成后，監(jiān)控發(fā)布到分發(fā)的記錄如下：

可以看到，這1個(gè)事務(wù)的命令都得一次傳遞完才能分發(fā)，而分發(fā)又消耗時(shí)間，這里等待太久影響事務(wù)的實(shí)時(shí)性。
如果還有其他事務(wù)，默認(rèn)500（參考參數(shù)：-ReadBatchSize），也將一起傳遞，耗時(shí)較長(zhǎng)。

現(xiàn)在更改參數(shù)，掃描到 1000 左右的命令就即時(shí)分發(fā)，需要設(shè)置如下參數(shù)：
-MaxCmdsInTran number_of_commands

注：該參數(shù)只能添加到日志讀取器代理中，在代理配置文件沒(méi)有此參數(shù)的設(shè)置。

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

再次插入 30 萬(wàn)的數(shù)據(jù)！~到監(jiān)視器查看

可以看到，命令達(dá)到 1000 左右就進(jìn)行分發(fā)了，此時(shí)查看訂閱數(shù)據(jù)庫(kù)，數(shù)據(jù)也同步過(guò)來(lái)了，這樣就省去了較多掃描命令的時(shí)間。
更詳細(xì)查看每個(gè)事務(wù)的命令數(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

這個(gè)參數(shù)雖好，但是也可能引起數(shù)據(jù)的一致性。

如：

在發(fā)布更新了一批數(shù)據(jù)，但是訂閱查詢時(shí)卻有不同。

分發(fā)事務(wù)遇到?jīng)_突或者死鎖，也導(dǎo)致這部分的數(shù)據(jù)不一致。

參考：復(fù)制日志讀取器代理

版權(quán)聲明：本站文章來(lái)源標(biāo)注為YINGSOO的內(nèi)容版權(quán)均為本站所有，歡迎引用、轉(zhuǎn)載，請(qǐng)保持原文完整并注明來(lái)源及原文鏈接。禁止復(fù)制或仿造本網(wǎng)站，禁止在非maisonbaluchon.cn所屬的服務(wù)器上建立鏡像，否則將依法追究法律責(zé)任。本站部分內(nèi)容來(lái)源于網(wǎng)友推薦、互聯(lián)網(wǎng)收集整理而來(lái)，僅供學(xué)習(xí)參考，不代表本站立場(chǎng)，如有內(nèi)容涉嫌侵權(quán)，請(qǐng)聯(lián)系alex-e#qq.com處理。