錯誤 9002：資料庫的事務歷史記錄已滿，因為AVAILABILITY_REPLICA錯誤訊息 SQL Server

  • 發行項

本文可協助您解決事務歷史記錄檔變大或 SQL Server 空間不足時所發生的 9002 錯誤。

原始產品版本：SQL Server 2017、SQL Server 2016、SQL Server 2014 SQL Server 2012
原始 KB 編號： 2922898

徵狀

請試想下列案例：

  • 您已在伺服器上安裝 Microsoft SQL Server 2012 或更新版本。
  • SQL Server 的實例是 Always On 可用性群組環境中的主要複本。
  • 事務歷史記錄檔的自動成長選項是在 SQL Server 中設定。

在此案例中，事務歷史記錄可能會變得很大，而且磁碟空間不足，或超過主要復本上為事務歷史記錄設定的 MaxSize 選項，而且您會收到類似下列的錯誤訊息：

錯誤：9002，嚴重性：17，狀態：9。 資料庫 %.*ls' 的事務歷史記錄因 『AVAILABILITY_REPLICA』 而已滿

原因

當主要復本上的記錄變更尚未在次要複本上強化時，就會發生這種情況。 如需有關 Always On 環境中數據同步處理程式的詳細資訊，請參閱數據同步處理程式。

疑難排解

有兩種案例可能會導致可用性資料庫和 中的 'AVAILABILITY_REPLICA' log_reuse_wait_desc記錄檔成長：

  • 案例 1：將記錄的變更傳遞至次要複本的延遲

    當交易變更主要複本中的數據時，這些變更會封裝成記錄檔記錄區塊，而這些記錄的區塊會傳遞並強化至次要複本的資料庫記錄檔。 主要複本無法覆寫其本身記錄檔中的記錄區塊，直到這些記錄區塊已傳遞並強化至所有次要複本中的對應資料庫記錄檔為止。 將這些區塊傳遞或強化至可用性群組中任何複本的任何延遲，都會防止截斷主要復本資料庫中記錄的變更，並導致其記錄檔使用量增加。

    如需詳細資訊，請 參閱高網路等待時間或低網路輸送量會導致主要複本上的記錄檔建置。

  • 案例 2：重做延遲

    一旦強化至輔助資料庫記錄檔，次要復本實例中的專用重做線程會將包含的記錄檔記錄套用至對應的數據檔 (的) 。 在所有次要複本中的所有重做線程都套用了包含的記錄檔記錄之前，主要復本無法覆寫其本身記錄檔中的記錄區塊。

    如果任何次要復本上的重做作業都無法跟上在該次要複本強化記錄區塊的速度，則會導致主要復本的記錄檔成長。 主要復本只能截斷並重複使用它自己的事務歷史記錄，直至所有次要複本的重做線程都已套用為止。 如果有多個次要資料庫，請比較 truncation_lsn 多個次要複本的 sys.dm_hadr_database_replica_states 動態管理檢視數據行，以找出哪一個輔助資料庫最延遲記錄截斷。

    您可以使用 Always On 儀錶板和sys.dm_hadr_database_replica_states動態管理檢視來協助監視記錄傳送佇列和重做佇列。 主要欄位包括：

    欄位 描述
    log_send_queue_size 尚未抵達次要複本的記錄檔記錄數量
    log_send_rate 記錄檔記錄傳送至輔助資料庫的速率。
    redo_queue_size 次要復本記錄檔中尚未重做、以 KB 為單位 (KB) 的記錄記錄數量。
    redo_rate 在指定輔助資料庫上重做記錄檔記錄的速率，以 KB (KB) /second 為單位。
    last_redone_lsn 在輔助資料庫上重做之最後一筆記錄檔記錄的實際記錄序號。 last_redone_lsn 一律小於 last_hardened_lsn。
    last_received_lsn 記錄區塊標識碼，識別裝載此輔助資料庫的次要複本已接收到所有記錄區塊的點。 反映以零填補的記錄區塊標識碼。 它不是實際的記錄序號。

    例如，針對主要複本執行下列查詢，以最早報告 truncation_lsn 複本，並且是主要複本可在自己的事務歷史記錄中回收的上限：

    SELECT ag.name AS [availability_group_name]
, d.name AS [database_name]
, ar.replica_server_name AS [replica_instance_name]
, drs.truncation_lsn , drs.log_send_queue_size
, drs.redo_queue_size
FROM sys.availability_groups ag
INNER JOIN sys.availability_replicas ar
    ON ar.group_id = ag.group_id
INNER JOIN sys.dm_hadr_database_replica_states drs
    ON drs.replica_id = ar.replica_id
INNER JOIN sys.databases d
    ON d.database_id = drs.database_id
WHERE drs.is_local=0
ORDER BY ag.name ASC, d.name ASC, drs.truncation_lsn ASC, ar.replica_server_name ASC

    矯正措施可能包含但不限於下列各項：

    • 請確定次要沒有資源或效能瓶頸。
    • 請確定未在次要復本上封鎖 Redo 線程。 使用擴 lock_redo_blocked 充事件來識別何時發生這種情況，以及重做線程封鎖的物件。

因應措施

識別發生這種情況的輔助資料庫之後，請嘗試下列一或多個方法暫時解決此問題：

  • 將資料庫從違規輔助資料庫的可用性群組中取出。

    注意事項

    此方法會導致次要複本的高可用性/災害復原案例遺失。 您未來可能必須再次設定可用性群組。

  • 如果重做線程經常遭到封鎖，請將複本的 SECONDARY_ROLE 參數變更ALLOW_CONNECTIONS為 NO，以停Readable Secondary用此功能。

    注意事項

    這會防止使用者讀取次要複本中的數據，這是封鎖的根本原因。 重做佇列已降到可接受的大小之後，請考慮再次啟用此功能。

  • 如果已停用且有可用的磁碟空間，請啟用 自動成長 設定。

  • 如果已達到事務歷史記錄檔且有可用的磁碟空間，請增加該檔案的 MaxSize 值。

  • 如果目前的事務歷史記錄檔已達到系統最大值 2 TB，或另一個可用磁碟區上有額外的可用空間，請新增額外的事務歷史記錄檔。

其他相關資訊

適用於

  • SQL Server 2012 Enterprise
  • SQL Server 2014 Enterprise
  • SQL Server 2014 Business Intelligence
  • SQL Server 2014 Standard
  • SQL Server 2016 Enterprise
  • SQL Server 2016 Standard
  • SQL Server 2017 Enterprise
  • SQL Server 2017 Standard Windows