針對 Always On 可用性群組中的復原佇列進行疑難解答

本文提供復原佇列相關問題的解決方法。

什麼是復原佇列？

對可用性群組資料庫中的主要複本所做的變更，會傳送至相同可用性群組中定義的所有次要複本。 這些變更到達次要複本之後，會先寫入可用性群組資料庫的事務歷史記錄檔。 然後，Microsoft SQL Server 使用復原或重做作業來更新資料庫檔案。

如果可用性群組的變更抵達並強化資料庫事務歷史記錄檔的速度比復原快，則會形成 復原佇列 。 此佇列是由未復原並還原至資料庫的強化事務歷史記錄交易所組成。

復原 (重做佇列) 徵兆和效果

查詢主要和次要複本會傳回不同的結果

查詢次要複本的唯讀工作負載可能會查詢過時的數據。 如果發生復原佇列，當您查詢相同的數據時，主要復本資料庫上的數據變更可能不會反映在輔助資料庫中。

雖然變更會抵達輔助資料庫並寫入資料庫記錄檔，但在復原並還原至資料庫檔案之前，將不會查詢變更。 復原作業可讓這些變更可供讀取。

For more information, see the Data latency on secondary replica section of "Differences between availability modes for an Always On availability group."

故障轉移時間較長或超過 RTO

復原時間目標 (RTO) 是組織可以處理的最大資料庫停機時間。 RTO 也會說明組織在中斷后重新取得數據庫存取權的速度。 如果發生故障轉移時，次要復本上存在大量復原佇列，復原可能需要較長的時間。 復原之後，資料庫會轉換成主要角色，並代表故障轉移之前存在的資料庫狀態。 較長的復原時間可能會延遲故障轉移後繼續生產環境的速度。

各種診斷功能報告可用性群組復原佇列

在復原佇列的情況下，SQL Server Management Studio (SSMS) 中的 Always On 儀錶板可能會報告狀況不良的可用性群組。

如何檢查復原 (重做) 佇列

復原佇列是每個資料庫的度量，可以使用主要複本上的 Always On 儀錶板，或在主要或次要複本上使用sys.dm_hadr_database_replica_states動態管理檢視 (DMV) 來檢查。 效能監視器 計數器會檢查復原佇列和復原速率。 這些計數器必須針對次要複本進行檢查。

接下來的幾個區段提供方法來主動監視可用性群組資料庫復原佇列。

查詢sys.dm_hadr_database_replica_states

sys.dm_hadr_database_replica_states DMV 會報告每個可用性群組資料庫的數據列。 報表中的一個資料列是 redo_queue_size。 此值是以 KB 為單位測量的復原佇列大小。 您可以設定類似下列查詢的查詢，每隔 30 秒監視復原佇列大小中的任何趨勢。 查詢會在主要複本上執行。 它會使用 is_local=0 述詞來報告次要複本的數據，其中 redo_queue_size 和 redo_rate 是相關的。

WHILE 1=1
BEGIN
SELECT drcs.database_name, ars.role_desc, drs.redo_queue_size, drs.redo_rate,
ars.recovery_health_desc, ars.connected_state_desc, ars.operational_state_desc, ars.synchronization_health_desc, *
FROM sys.dm_hadr_availability_replica_states ars JOIN sys.dm_hadr_database_replica_cluster_states drcs ON ars.replica_id=drcs.replica_id
JOIN sys.dm_hadr_database_replica_states drs ON drcs.group_database_id=drs.group_database_id
WHERE ars.role_desc='SECONDARY' AND drs.is_local=0
waitfor delay '00:00:30'
END

輸出如下所示。

在儀錶板 Always On 檢閱復原佇列

若要檢閱復原佇列，請遵循下列步驟：

1. 以滑鼠右鍵按下 SSMS 物件總管 中的可用性群組，以在 SSMS 中開啟 Always On 儀錶板。

2. 選 取 [顯示儀錶板]。

   可用性群組資料庫會最後列出，而且資料庫上有一些報告的數據。 雖然預設不會列出 重做佇列大小 (KB) 和 Redo Rate (KB/秒) ，但您可以將它們新增至此檢視，如下一個步驟中的螢幕快照所示。

3. 若要新增這些計數器，請以滑鼠右鍵按兩下資料庫報表上方的標頭，然後從可用的數據列清單中選取。

4. 若 要新增 Redo Queue Size (KB) 和 Redo Rate (KB/秒) ，請在下列螢幕快照中以紅色醒目提示的方式，以滑鼠右鍵按兩下標頭。

   

   根據預設，Always On 儀錶板會每隔 60 秒自動重新整理 Redo Queue Size (KB) 和 Redo Rate (KB/秒) 。

   

檢閱 效能監視器 中的復原佇列

每個次要復本和資料庫的復原佇列大小都是唯一的。 因此，若要檢閱可用性群組資料庫的復原佇列，請遵循下列步驟：

1. 在次要復本上開啟 效能監視器。

2. 選取 [ 新增 (計數器) ] 按鈕。

3. 在 [可用的計數器] 下，選取 [SQLServer：Database Replica]，然後選取 [ 復原佇列 ] 和 [重做位元組/秒 計數器]。

4. 在 [ 實例] 列表框中，選取您要監視復原佇列的可用性群組資料庫。

5. 選 取 [新增>確定]。

   以下是增加復原佇列看起來的樣子。

   

解譯復原佇列值

本節說明如何解譯與您在上一節中決定的復原佇列相關的值。

復原佇列問題何時發生？ 您應該容許多少復原佇列？

您可能會假設復原佇列的值為 0，這表示在報告時不會發生復原佇列。 不過，當生產環境忙碌時，您應該會預期復原佇列經常報告零以外的值，即使在狀況良好的 AlwaysOn 環境中也一樣。 在一般生產期間，您應該會看到此值在 0 與非零值之間變動。

如果您觀察到復原佇列會隨著時間增加，則需要進一步調查。 這個額外的活動表示某些項目已變更。 如果您觀察到復原佇列突然成長，下列度量有助於進行疑難解答：

• Log Redo Rate (KB/sec) (AlwaysOn 儀錶板)
• DMV sys.dm_hadr_database_replica_states中的Redo_rate

取得重做率的基準費率

在狀況良好的 AlwaysOn 效能期間，監視忙碌可用性群組資料庫上的重做速率。 在通常忙碌的上班時間，它們看起來會像什麼？ 在維護期間，當大型交易 (索引重建時，ETL進程) 在系統上提高交易輸送量時，這些速率為何？ 您可以在觀察復原佇列成長時比較這些值，以協助判斷已變更的專案。 工作負載可能大於平常。 如果重做率較低，可能需要進一步調查才能判斷原因。

工作負載磁碟區很重要

當您有大型工作負載 (例如針對一百萬個數據列的 UPDATE 語句、在 1 TB 數據表上重建索引，或甚至是將數百萬個數據列插入) 的 ETL 批次時，您應該會預期會立即或隨著時間而出現一些復原佇列成長。 當可用性群組資料庫中突然發生大量變更時，這是預期的。

如何診斷復原 (重做) 佇列

識別特定次要復本可用性群組資料庫的復原佇列之後，請連線到次要複本，然後查詢 sys.dm_exec_requests 以判斷復原線程的 wait_type 和 wait_time 。 以下是可在迴圈中執行的查詢。 您要尋找一或多個等候類型的高頻率，甚至是這些等候類型的等候時間。 以下是每秒執行一次的範例查詢，並報告可用性群組 「agdb」 的等候類型和等候時間：

WHILE (1=1)
BEGIN
SELECT db_name(database_id) AS dbname, command, session_id, database_id, wait_type, wait_time,
os.runnable_tasks_count, os.pending_disk_io_count FROM sys.dm_exec_requests der JOIN sys.dm_os_schedulers os
ON der.scheduler_id=os.scheduler_id
WHERE command IN('PARALLEL REDO HELP TASK', 'PARALLEL REDO TASK', 'DB STARTUP')
AND database_id= db_id('agdb')
waitfor delay '00:00:05.000'
END

重要事項

對於有意義的等候類型輸出，當您使用稍早所述的其中一種方法來監視此情況時，應該觀察復原佇列正在增加。

在此範例中，某些 I/O 相關的等候類型會 (PAGEIOLATCH_UP報告， PAGEIOATCH_EX) 。 監視以檢查這些等候類型是否繼續具有最大 wait_times 值，如下一欄所述。

SQL Server 重做等候類型

識別等候類型時，請檢閱下列文章 SQL Server 2016/2017：可用性群組次要複本重做模型和效能 - Microsoft Tech Community 作為造成復原佇列之常見等候類型的交叉參考，並取得解決問題的協助。

次要報表伺服器上封鎖的重做線程

如果您的解決方案會針對次要複本上的可用性群組資料庫指示報告 (查詢) ，這些只讀查詢會取得架構穩定性 (Sch-S) 鎖定。 這些 Sch-S 鎖定可以防止重做線程取得架構修改 (Sch-M) 鎖定 (也稱為「架構修改鎖定」，或 LCK_M_SCH_M) 讓任何資料定義語言 (DDL) 變更，例如 ALTER TABLE 或 ALTER INDEX。 封鎖的重做線程無法套用記錄檔記錄，直到解除封鎖為止。 這可能會導致復原佇列。

若要檢查封鎖重做的歷史證據，請使用 SSMS 在次要復本上開 啟AlwaysOn_health Xevent 追蹤檔案。 lock_redo_blocked尋找事件。

使用 效能監視器 主動監視已封鎖的復原對復原佇列的影響。 新增 SQL Server：:D atabase Replica：：Redo blocked/sec 和 SQL Server：:D atabase Replica：：Recovery 佇列計數器。 下列螢幕快照顯示在 ALTER TABLE ALTER COLUMN 針對次要複本上的相同數據表執行長時間執行查詢時，針對主要複本執行的命令。 Redo blocked/sec 計數器表示ALTER TABLE ALTER COLUMN命令正在執行。 當長時間執行的查詢在次要複本的相同數據表上執行時，主要複本上的任何後續變更都會導致復原佇列增加。

監視重做線程嘗試取得的架構修改鎖定等候類型。 若要這樣做，請使用稍早所述的查詢來檢查針對 取消復原作業 sys.dm_exec_requests所報告的等候類型。 您可以在進行中的重做封鎖中觀察到 的等候時間 LCK_M_SCH_M 增加。

單個線程重做

SQL Server 在 Microsoft SQL Server 2016 中導入了次要復本資料庫的平行復原。 如果您在執行 SQL Microsoft Server 2012 或 Microsoft SQL Server 2014 時遇到復原佇列，您可以升級至更新版本的程式，以改善生產環境中的重做效能。

在使用平行復原架構的較新進階 SQL Server 版本中，可能會發生單個線程重做。 在這些版本中，SQL Server 實例最多可以使用100個線程進行平行重做。 視處理器和可用性群組資料庫的數目而定，平行重做線程最多會配置 100 個總線程。 如果達到 100 個線程重做限制，可用性群組中的某些資料庫會獲指派單一重做線程。

若要判斷可用性群組資料庫是否使用平行復原，請聯機到次要複本，並使用下列查詢來判斷套用可用性群組資料庫復原) (線程的數據列數目。 在下列範例中，如果 「agdb」 資料庫是單一線程，且其命令為 DB STARTUP，則復原工作負載可能會受益於平行復原。

SELECT db_name(database_id) AS dbname, command, session_id, database_id, wait_type, wait_time,
os.runnable_tasks_count, os.pending_disk_io_count FROM sys.dm_exec_requests der JOIN sys.dm_os_schedulers os
ON der.scheduler_id=os.scheduler_id
WHERE command IN ('PARALLEL REDO HELP TASK', 'PARALLEL REDO TASK', 'DB STARTUP')
AND database_id= db_id('agdb')

如果您確認您的資料庫使用單個線程重做，請檢閱稍早所述的演算法，以判斷 SQL Server 是否超過平行復原專用的 100 個背景工作線程數目。 這類條件可能是 「agdb」 資料庫只使用單一線程進行復原的原因。

SQL Server 2022 現在會使用新的平行復原演算法，以便根據工作負載指派背景工作線程進行平行復原。 這可消除忙碌資料庫在單個線程復原中保留的機會。 For more information, see the Thread Usage by Availability Groups section of "Prerequisites, Restrictions, and Recommendations for Always On availability groups."