AlwaysOn AG 輔助副本具有高重做隊列大小和估計恢復時間以及良好重做率的原因是什麼？
SQL14 是主伺服器，SQL16 是輔助副本，它們使用同步送出可用性模式進行設置：
截至昨天，數據似乎停止從主數據庫同步到副本。今天早上，我們暫停了可用性數據庫，然後又恢復了它。這似乎再次啟動了同步，因為我現在看到了新數據，但儀表板中的重做隊列大小和估計恢復時間仍然很大，並且還在繼續增長。
我可以檢查/做些什麼來解決這個問題？
附加資訊：伺服器版本：SQL Server 2016 Enterprise - SP1（主要和次要）
此外，早上早些時候，我們有一些長期執行的索引重組/重建作業在主數據庫上失敗。（那是大約 4 小時前的事，但現在這可能仍然是這個問題的潛在原因嗎？）
我注意到輔助伺服器上有以下伺服器日誌（從最舊到最新）：
不知道裡面有沒有線索？
輔助節點上的 DBCC OPENTRAN 返回以下內容：
擴展事件會話以跟踪輔助節點上的等待：
所以這裡有很多事情……（例如，這將是一個很長的答案，可能會經歷多次迭代）：
首先，該 AG 是否經歷了故障轉移？如果沒有，那麼我建議您在主節點上檢查 ERRORLOGs 開始您的故障排除過程；如果確實發生了故障轉移，請檢查正式稱為主節點的節點上的錯誤日誌以查看發生了什麼。您可以在 SSMS 中使用笨重的 UI，也可以使用未記錄的擴展過程
xp_readerrorlog，這是我的建議，因為這樣可以更快地過濾掉噪音。例如，我建議開始尋找對 AG 名稱的任何引用，如下所示並從那裡探勘：xp_readerrorlog 0, 1, N'>>YOUR AG NAME HERE<<', NULL, '2019-11-18 12:00:00.000', '2019-11-19 15:00:00.000', NULL, NULL檢查上面的連結以了解該命令周圍的語法。
根據您找到的內容，展開搜尋，檢查您的 Windows 事件日誌 (eventvwr.msc)、集群日誌 (cluadmin.msc)、應用程序日誌等，必要時使用錯誤時間作為參考點。我高度懷疑這些日誌會確定導致同步停止的原因，無論是與集群相關的問題，還是由於維護導致的打嗝等。基於此，如果您難以解釋結果，我建議發布一個新問題.
其次，在 AG 中執行 Index Maintenance 會導致 AG 同步延遲。無論 SQL Server 的版本（包括 SQL 2019）如何，都無法繞過它，儘管新版本往往恢復得更快。如果您覺得必須執行索引維護並且您有能力使應用程序離線，我建議您執行離線索引維護。
REBUILD將其作為已定義的離線執行MAXDOP，因為離線索引重建操作不會在您的 AG 內造成嚴重的延遲。顯然這種做法會導致停電，所以不能掉以輕心。我確實支持我們這樣做的環境，因為忽略索引維護會導致不必要的增長（並且在導致其他問題的多 TB 系統中）說白了，SQL Server 社區中的一個常見誤解是索引維護對數據庫的性能至關重要。通常情況並非如此，因為索引碎片對執行計劃行為的影響很小。只有當每頁的平均空白接近驚人的水平時，碎片才開始變得重要。老實說，在大多數情況下，索引維護基本上是一項非常昂貴的統計更新操作，這意味著**處於統計更新之上，**這通常不會導致阻塞，也不會備份 AG。
最後，如果您想查看輔助節點落後多遠並估計它們需要多長時間才能趕上，請嘗試此查詢，它是來自 Jonathan Kehayias 的此程式碼的變體：
SELECT ar.replica_server_name, adc.database_name, ag.name AS ag_name, drs.is_local, drs.synchronization_state_desc, drs.synchronization_health_desc, drs.last_redone_time, drs.redo_queue_size, drs.redo_rate, (drs.redo_queue_size / drs.redo_rate) / 60.0 AS est_redo_completion_time_min, drs.last_commit_lsn, drs.last_commit_time FROM sys.dm_hadr_database_replica_states AS drs INNER JOIN sys.availability_databases_cluster AS adc ON drs.group_id = adc.group_id AND drs.group_database_id = adc.group_database_id INNER JOIN sys.availability_groups AS ag ON ag.group_id = drs.group_id INNER JOIN sys.availability_replicas AS ar ON drs.group_id = ar.group_id AND drs.replica_id = ar.replica_id ORDER BY ag.name, ar.replica_server_name, adc.database_name;