診斷緩慢的 Always On 送出

兩個節點 Always On 可用性組，一個同步副本。

我的同步副本經常不同步。我看到一種模式，當次要副本上發生日誌備份時，會出現短暫的延遲，在此期間 redo_queue_size 會迅速填滿，如下所示：

查看以下連結中的指導，似乎我的問題主要是由於嘗試強化事務時重做執行緒遇到的爭用：

https://technet.microsoft.com/en-us/library/dn135335(v=sql.110).aspx

當事務日誌備份執行時，副本會進一步不同步，並且在輔助副本上執行的報告也會加劇此問題。

一直以來，我的事務日誌備份都很大——平均為 1.2GB，但可能更大。

據我所知，我的日誌備份會很大，因為我在數據庫上啟用了 TDE，但我真的沒想到它們會這麼大。我懷疑這是導致次要副本上緩慢送出的最大原因。

是否有推薦的性能計數器來診斷同步副本上的慢速送出？我還能做些什麼來驗證我的理論？

我的問題似乎與此處描述的問題相同： https ://www.sqlservercentral.com/Forums/1871286/AlwaysOn-Missing-Redo-Thread

我可以僅在輔助副本上啟用此跟踪標誌還是需要將其應用於兩個節點？

編輯：我在早上 6 點檢查了重做隊列，發現了一個巨大的數字，恢復時間為 15-20 分鐘，並且一直在略微增加。然後我應用了 traceflagDBCC TRACEON (3459, -1)並在幾分鐘後發現，重做命令的數量下降得非常快。到目前為止，這個跟踪標誌似乎已經緩解了這個問題，但大概這會將所有事務強化到輔助副本的日誌中，例如 SQL Server 2014，因此，輔助副本仍有可能落後作為非並行執行緒的結果，當主要的寫入負載很重時。

我遇到的問題：

1. 同步二級副本半永久落後
2. 大量日誌備份

通過啟用跟踪標誌 3459 解決了這些問題。在我的情況下，很容易看到該標誌立即修復了等待類型，parallel_redo_flow_control dirty_page_table_lock parallel_drain_redo_worker並顯示重做隊列的大小迅速減小。

我想知道為什麼在錯誤報告中，微軟稱之為“斷言”： https: //support.microsoft.com/en-us/help/3200975/fix-assertion-occurs-when-you-use-parallel-redo-次要副本中

來自 SQLServerCentral.com 的 Jason AKA CirqueDeSQLeil https://www.sqlservercentral.com/Forums/1871286/AlwaysOn-Missing-Redo-Thread

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