複製到企業版和標準版訂閱者

我們有一個已定義且執行良好的事務複製過程。一個發布者，一個分發者（在不同的伺服器上）和幾個訂閱者（拉）。所有伺服器都有企業版。

使用金絲雀表檢查延遲。我在所有訂閱者上使用金絲雀表而不是跟踪令牌。看不到任何額外的延遲。Kendra Little 有一篇很棒的文章表明金絲雀表非常適合這種措施，因為跟踪令牌太耐心了。

複製不是針對整個數據庫，只有幾張表，但是表比較大，insert很多。

我使用標準版添加了一位訂閱者。它執行良好並且沒有任何問題，只是它顯示了更多的延遲問題，雖然不是很大，但它比所有其他訂閱者發出的警報要多得多。

問題

我該如何處理這個問題？有沒有可能改進？我應該檢查什麼？如果伺服器在插入方面表現出色，我應該如何改進它？

針對評論添加的資訊

標準版伺服器本身與其他訂閱者相同。所有伺服器都是由 DevOps 使用相同的配置創建的。我們在所有訂閱者上都有 12 個 CPU 核心。標準版訂閱者的執行通常與所有其他訂閱者（企業版）相同。只有幾次它開始顯示延遲增加（30 分鐘到 1 小時），並且需要一個多小時才能恢復。

PLE 是 55146（在企業訂戶上是 178775）。標準訂閱者的主要等待統計數據是：

• CXPACKET
• PAGEIOLATCH_EX
• PAGEIOLATCH_SH
• PREEMPTIVE_OS_AUTHENTICATIONOPS
• IO_COMPLETION
• LOGBUFFER

延遲在分發者和新訂閱者之間。它通常可以正常執行，並且與所有其他訂閱者一樣沒有延遲。但是一天一兩次，它會顯示出延遲，在其高峰期達到 30 分鐘到 1 小時。我發現當有成千上萬的更新到來時會發生這種情況。

表沒有分區。複製表中的所有內容都適合企業和標準。

取一個 1-2GB 的文件並將其從 Dist 複製到“好”訂閱者。注意速度/秒和經過的時間。然後對“潛在/新”訂閱者執行相同操作。如果差異很大，您有硬體/儲存/頻寬問題。如果做不到這一點，可能訂戶數據庫設置已關閉…小型自動增長等

引用自：https://dba.stackexchange.com/questions/153997