針對處於還原狀態的可用性群組資料庫進行疑難解答

本文可協助您針對處於還原狀態的可用性群組資料庫進行疑難解答。

什麼是還原狀態？

當輔助伺服器必須復原已套用的變更，才能與主要伺服器同步處理時，就會發生還原狀態。

在正常作業期間，可用性群組主要和次要複本保持連線狀態，以便主要復本的變更與次要複本主動同步處理。

在故障轉移期間，此聯機狀態會遭到切斷。 新的主要復本上線后，主要複本與次要複本之間的連線就會重新建立。 在這個初始連線狀態期間，會交涉通用恢復點，讓新的次要複本應該開始復原，使其與主要複本同步。

如果在故障轉移時執行大型交易，新的輔助資料庫記錄會領先於主要複本資料庫。 交涉的新通用恢復點會要求次要復本接收主要複本的頁面，才能處於同步處理可以繼續的狀態。 還原程式也稱為「復原重做」。

還原程式原本就很慢，經常發生，而且通常很少注意到觸發還原狀態的小交易。 當故障轉移中斷大型交易時，通常會注意到還原狀態，導致許多頁面從主要復本傳送至次要複本資料庫，以將次要複本資料庫還原為可復原的狀態。

可用性群組資料庫處於還原狀態的徵兆和效果

當資料庫處於次要複本的還原狀態時，資料庫不會同步處理，因此不會接收來自主要復本的變更。 主要複本上的資料庫突然遺失可能會導致數據遺失。

AlwaysOn 儀錶板報表在主要複本上未同步處理

故障轉移可用性群組之後，您可能會發現次要複本在故障轉移成功時回報為未同步處理。 AlwaysOn 儀錶板會報告 主要複本上未同步處理 ，並在 次要復本上還原 。

AlwaysOn 儀錶板報表在主要複本上未同步處理	AlwaysOn 儀錶板報表在次要復本上還原

Always On DMV 會報告主要複本上的未同步處理

當您在主要複本上查詢下列 Always On 可用性群組 （AG） 動態管理檢視 （DMV） 時，資料庫會處於 NOT SYNCHRONIZING 狀態。

SELECT DISTINCT ar.replica_server_name, drcs.database_name, drs.database_id, drs.synchronization_state_desc, drs.database_state_desc
FROM sys.availability_replicas ar 
JOIN sys.dm_hadr_database_replica_states drs 
ON ar.replica_id=drs.replica_id 
JOIN sys.dm_hadr_database_replica_cluster_states drcs
ON drs.group_database_id=drcs.group_database_id

當您在次要資料庫上查詢 DMV 時，可用性群組資料庫處於 REVERTING 狀態。

只讀和報告工作負載無法存取輔助資料庫

還原輔助資料庫時，無法存取或查詢。 這些只讀工作負載脫機且中斷。 根據資料庫處於還原狀態的時間長度而定，如果這些工作負載是業務關鍵，可能需要將這些工作負載重新路由傳送至另一個次要複本或主要複本。

如果您有只讀工作負載，例如路由傳送至次要複本的報告工作負載，這些批次可能會失敗，訊息 922：

訊息 922，層級 14，狀態 1，第 2 行資料庫 'agdb' 正在復原。 請等候復原完成。

嘗試登入處於還原狀態之次要複本資料庫的應用程式無法連線並引發錯誤 18456：

2023-01-26 13：01：13.100 登入錯誤：18456，嚴重性：14，狀態：38。 2023-01-26 13：01：13.100 使用者 '<UserName>' 登入失敗。 原因：無法開啟明確指定的資料庫 'agdb'。 [CLIENT： <local machine>]

如果稽核失敗的登入，也可以在 SQL Server 錯誤記錄檔中報告此錯誤。

估計還原狀態剩餘的時間

使用下列其中一種方法來估計還原狀態剩餘的時間：

使用AlwaysOn_health XEvent 會話

AlwaysOn_health擴充事件診斷記錄檔具有hadr_trace_message事件，每五分鐘報告還原狀態進度。

使用 SQL Server Management Studio （SSMS） 連線到次要複本 物件總管 並鑽研管理、擴充事件，然後鑽研會話。 以滑鼠右鍵按兩下 AlwaysOn_health 事件，然後選取 [ 監看實時數據]。 您應該會取得新的索引標籤視窗，報告還原作業的目前狀態。 狀態會透過 hadr_trace_message 事件每隔五分鐘報告一次，並回報還原作業完成的百分比。

在估計還原完成時，次要復本上的 SQL Server 錯誤記錄檔沒有太大説明。 在下圖中，您可以在還原狀態時從 10：08 到 11：03 觀察，但回報很少。 次要復本收到主要復本的所有頁面之後，現在可以復原在觸發還原狀態的原始主要復本上執行的交易。 從 11：03 到 11：05 執行復原。 復原完成之後不久，資料庫應該會開始與主要複本同步處理，並在輔助資料庫處於還原狀態時趕上在主資料庫所做的所有變更。

使用 效能監視器 監視還原完成時間

使用性能計數器監視還原狀態進度 SQL Server：資料庫複本：需要復原的記錄總數和 SQL Server：資料庫複本：剩餘復原的記錄，然後選擇實例的可用性群組資料庫。 在下列螢幕快照的範例中， [需要復原 的記錄總數] 會回報為 56.3 mb，而 [復原 的記錄剩餘] 會慢慢降至 0 ，而報告還原進度。

除了等待之外，還有什麼其他選項？

Microsoft建議您預估還原狀態完成的時間。

將次要複本新增至可用性群組

如果可用性群組中只有兩個複本，可能的話，請新增另一個次要複本，以提供高可用性和備援，並在其他次要複本完成還原時主動與主要複本同步處理。

如何解決失敗的唯讀工作負載

由於還原中的次要復本資料庫無法存取，因此只讀工作負載會失敗。 更新讀取意圖路由表，將流量路由回到主要複本或另一個次要複本，直到受影響的次要複本資料庫完成還原程序為止。

避免還原狀態 - 監視大型交易

如果您在計劃性故障轉移期間經常觀察到此狀態，請實作在故障轉移之前檢查大型交易的程式。 下列查詢會報告系統上任何開啟交易的交易開始時間和目前時間，並提供交易的輸入緩衝區。

SELECT tat.transaction_begin_time, getdate() AS 'current time', es.program_name, es.login_time, es.session_id, tst.open_transaction_count, eib.event_info
FROM sys.dm_tran_active_transactions tat
JOIN sys.dm_tran_session_transactions tst ON tat.transaction_id=tst.transaction_id
JOIN sys.dm_exec_sessions es ON tst.session_id=es.session_id 
CROSS APPLY sys.dm_exec_input_buffer(es.session_id, NULL) eib WHERE es.is_user_process = 1
ORDER BY tat.transaction_begin_time ASC