共用方式為

錯誤 9002：因為 SQL Server 中的 AVAILABILITY_REPLICA 錯誤訊息，資料庫交易記錄已滿

  • 發行項

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

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

徵兆

請參考下列案例：

  • 您已Microsoft安裝在伺服器上的 SQL Server 2012 或更新版本。
  • SQL Server 的實例是 AlwaysOn 可用性群組環境中的主要複本。
  • 事務 歷史記錄檔的自動成長 選項是在 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 行，以識別哪一個輔助資料庫延遲記錄截斷最多。

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

    欄位 描述
    log_send_queue_size 尚未抵達次要複本的記錄檔記錄數量
    log_send_rate 記錄檔記錄傳送至輔助資料庫的速率。
    redo_queue_size 尚未重做之次要複本記錄檔中的記錄記錄數量，以 KB 為單位。
    redo_rate 在指定的輔助資料庫上重做記錄檔記錄的速率，以 KB 為單位/秒。
    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

    更正措施可能包括，但不限於下列各項：

    • 請確定次要複本沒有資源或效能瓶頸。
    • 請確定重做線程不會在次要端遭到封鎖。 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