可用性組的卡住 REDO 執行緒
由於我們有可讀的輔助配置，我們正面臨 REDO 隊列波動的問題。
根據我對 SQL Server 較新版本的理解，重做執行緒是並行的。目前版本是在具有 64 個核心的 VM 上執行的 SQL Server 2017。
當在執行 AG 執行緒的同一個 cpu/調度程序上執行輔助選擇查詢時，我看到了問題。我假設 AG 執行緒產生它的調度程序並退居二線讓其他查詢執行。我相信這是問題所在，因為進來的查詢似乎在 AG 執行緒正在執行重做工作的地方遇到相同的 cpu_id。
下面的範例：spid 91 是對 cpu_id 6 的選擇查詢，同時 spid 123 和 144 正在為 AG 執行執行緒，如從 sys.dm_exec_requests dmv 中找到的。當 91 出現時，REDO 隊列開始建立。
我不知道是否有任何程序使您的查詢轉到不同的核心，而不是 AG 執行緒可能正在執行的核心。
- 我們可以控制它以使查詢命中其他調度程序而不是 AG 工作的調度程序嗎？
- 當 AG 執行緒掛起時在輔助節點上執行查詢時，我看到 PARALLEL_REDO_TRAN_TURN 上有很多等待。可以跟踪此處提到的標誌幫助
- 可能還有許多其他可用的調度程序。我無法理解為什麼某些程序卡在 Numa 的插槽中。我想較新的版本啟用了所有軟 numa，因此可以製作 8 個軟 numa 桶。8*8 調度器，64 可用。在這裡禁用軟 numa 是個好主意嗎？
數據庫隔離是 RCSI，但我認為這並不重要，因為在內部它已根據可讀輔助節點的設計更改為快照。
雖然這可能不是您正在尋找的答案，因為它最終需要遷移，但您可以嘗試在 SQL Server 2019 上執行您的工作負載，以便能夠使用“ SQL Server 2019 Intelligent Performance -Worker Migration ”或通常稱為 Worker偷竊。
Worker 遷移（也稱為“worker 竊取”）允許空閒的 SOS 調度程序從同一 NUMA 節點上另一個調度程序的可執行隊列中遷移一個 worker，並立即恢復遷移的 worker 的任務。此增強功能提供了更平衡的 CPU 使用率並減少了長時間執行的任務在可執行隊列中花費的時間。
為工作器遷移啟用的長時間執行的任務不再綁定到固定調度程序。相反，它會經常在同一個 NUMA 節點內的調度程序之間移動，這自然會導致調度程序的負載減少。與現有的負載因子機制一起，工作器遷移為 SQL Server 提供了平衡 CPU 使用的豐富解決方案。
如同一來源中所述，並行重做有資格進行工作人員遷移：
在 SQL Server 2019 中，啟用了與可用性組並行重做任務關聯的工作人員以進行工作人員遷移，以解決輔助副本上的重做任務之間常見的調度程序爭用問題。
遷移到 SQL Server 2019 時，此功能預設啟用。
添加
當 AG 執行緒掛起時在輔助節點上執行查詢時，我看到 PARALLEL_REDO_TRAN_TURN 上有很多等待。跟踪標誌 3459 有幫助嗎？
如果無法調整輔助節點上執行的查詢（例如，輔助節點上長時間執行的查詢時間減少），則該跟踪標誌可以提供好處。但可能還有其他原因，例如頻繁的頁面拆分。
查看執行重做執行緒序列是否對您的設置有益的一種方法是查看
PARALLEL_REDO_TRAN_TURN等待統計資訊，但您應該始終將這些資訊與其他資訊進行比較，例如輔助重做隊列大小的增加/減少。請注意啟用此跟踪標誌，因為重做性能可能會因串列而不是並行而受到影響。