在多數據庫 AG 中，是什麼決定了哪些數據庫將擁有超過 1 個重做執行緒？
我們有一個大型物理伺服器，上面有 50 多個 dbs；有些人很忙，有些人很安靜。
當 AG 中有多個 DB 時，只有其中一些 DB 具有多個重做執行緒。我們希望具有這些執行緒的數據庫成為繁忙的數據庫。在最近的一次遷移中，我們決定注意恢復數據庫的順序，因為我們理解這是根據數據庫創建日期決定的。但是，檢查遷移後，這是不正確的。
SELECT databases.database_id, databases.create_date, dm_hadr_db_threads.name, dm_hadr_db_threads.num_redo_threads, dm_hadr_db_threads.num_parallel_redo_threads FROM sys.dm_hadr_db_threads INNER JOIN sys.databases ON dm_hadr_db_threads.name = databases.name ORDER BY dm_hadr_db_threads.num_redo_threads DESC OPTION (RECOMPILE)
它不是創建日期或數據庫 ID。它不是按字母順序排列的。它不是添加到 ag 的順序。有誰知道這是什麼決定的？
這是 SQL Server 2019；查詢來自二級。
這是我們發現它基於 database_id 的地方：https ://www.brentozar.com/archive/2018/06/first-responder-kit-release-just-when-you-think-theres-nothing-new-left -去做/
並行重做執行緒按數據庫恢復順序分配，該順序確實遵循
sys.databases創建日期。也就是說，單獨的並行數據庫恢復 功能意味著可以將每個數據庫恢復任務分配給不同的 SOS 調度程序（當有足夠多的調度程序可用時）。
假設您有 8 個數據庫和 32 個處理器。8 個單獨的恢復任務可能會分配給 8 個不同的調度程序（CPU 的 SOS抽象）。8 個任務的創建（按創建日期順序）和調度程序分配可以很快發生。
每個調度程序多快（以及以何種順序）開始執行其分配的恢復任務取決於每個調度程序當時還有哪些其他工作（其可執行隊列），以及任何其他目前活動任務通過目前時間片的距離。
在每個獨立的恢復任務開始在其分配的調度程序上執行後不久，就會分配並行重做執行緒（直至全域限制）。由於上述問題，這是不確定的。
Microsoft 支持有一些未記錄的跟踪標誌，可以幫助促進在復雜場景中並行重做執行緒的良好分佈。您應該就您的情況與他們聯繫。