共用方式為

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

  • 發行項

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

什麼是復原佇列？

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

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

恢復 （重做） 佇列的癥狀和效果

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

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

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

如需詳細資訊，請參閱 的次要複 本上的數據延遲一節。

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

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

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

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

如何檢查復原 （重做） 佇列

復原佇列是每一資料庫測量，可使用主要複本上的 AlwaysOn 儀錶板或使用 主要或次要複本上的 sys.dm_hadr_database_replica_states 動態管理檢視 （DMV） 來檢查。 效能監視器 計數器會檢查復原佇列和復原率。 這些計數器必須針對次要複本進行檢查。

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

查詢sys.dm_hadr_database_replica_states

DMV 會 sys.dm_hadr_database_replica_states 報告每個可用性群組資料庫的數據列。 報表中的一個資料列是 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

以下是輸出的外觀。

查詢輸出的螢幕快照，其中redo_queue_size和redo_rate相關次要複本的數據。

在AlwaysOn儀錶板中檢閱復原佇列

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

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

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

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

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

  4. 若要新增 Redo 佇列大小 （KB） 和 重做速率 （KB/秒），請在下列螢幕快照中以紅色醒目提示的標頭上按下滑鼠右鍵。

    顯示新增重做佇列大小 （KB） 和重做速率 （KB/秒） 計數器的螢幕快照。

    根據預設，AlwaysOn 儀錶板會每隔 60 秒自動重新整理重做佇列大小 （KB） 和重做速率 （KB/秒）。

    顯示每 60 秒設定一次重新整理計數器的螢幕快照。

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

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

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

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

  3. 在 [可用的計數器] 下，選取 [SQLServer：Database Replica]，然後選取 [復原佇列] 和 [Redone Bytes/sec 計數器]。

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

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

    以下是增加復原佇列的外觀。

    顯示復原佇列增加的螢幕快照。

解譯復原佇列值

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

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

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

如果您發現隨著時間增加的復原佇列，需要進一步調查。 此額外活動表示某個項目已變更。 如果您在復原佇列中觀察到突然成長，下列量測對於疑難解答很有用：

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

取得重做率的基準費率

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

工作負載磁碟區很重要

當您有大型工作負載（例如針對1百萬個數據列的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 Queue 計數器。 下列螢幕快照顯示 ALTER TABLE ALTER COLUMN 針對主要複本執行的命令，而長時間執行的查詢則針對次要複本上的相同數據表執行。 Redo blocked/sec 計數器表示ALTER TABLE ALTER COLUMN命令正在執行。 雖然長時間執行的查詢是在次要複本上的相同數據表上執行，但主要復本上的任何後續變更都會導致復原佇列增加。

顯示架構修改鎖定等候類型的監視螢幕快照。

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

顯示增加LCK_M_SCH_M等候時間的螢幕快照。

單個線程重做

SQL Server 在 SQL Server 2016 Microsoft引進了次要復本資料庫的平行復原。 如果您在執行 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 現在會使用新的平行復原演算法，以便根據工作負載指派背景工作線程進行平行復原。 這可消除忙碌資料庫將保留在單個線程復原中的機會。 如需詳細資訊，請參閱 AlwaysOn 可用性群組 的一節。