共用方式為


加速資料庫復原

適用於:SQL Server 2019 (15.x) 和更新版本 Azure SQL Database Azure SQL 受控執行個體 Azure Synapse Analytics

加速資料庫復原 (ADR) 藉由重新設計 SQL 資料庫引擎復原流程來提升資料庫可用性,尤其是針對長時間執行的交易。

ADR 於 SQL Server 2019 (15.x) 引進,並於 SQL Server 2022 (16.x) 獲得改善。 ADR 也適用於 Azure SQL Database、Azure SQL 受控執行個體和 Azure Synapse SQL 中的資料庫。 SQL Database 和 SQL 受控執行個體預設會啟用 ADR,而且無法停用。 如需 Azure SQL 中 ADR 的詳細資訊,請參閱 Azure SQL 中的加速資料庫復原

本文提供 ADR 功能的概觀。 若要使用 ADR,請檢閱<管理加速資料庫復原>。

概觀

ADR 的主要優點為:

  • 快速且一致的資料庫復原

    使用 ADR,長時間執行的交易便不會影響整體復原時間,可快速且一致地進行資料庫復原,不論系統內使用中的交易數或其大小為何。

  • 瞬間交易回復

    使用 ADR,交易回復會在瞬間完成,不論交易處於使用中狀態的時間長度,或是已執行的更新數為何。

  • 積極性記錄截斷

    使用 ADR,交易記錄會積極地進行截斷,即使有使用中的長時間執行交易,它也能防止其失去控制。

目前的資料庫復原處理序

若沒有 ADR,SQL Server 中的資料庫復原會遵循 ARIES 復原模型且由三個階段組成,如下圖所示,並會在圖表之後會有更詳細的說明。

目前恢復流程的圖表。

  • 分析階段

    SQL Server 會從最後一次成功檢查點 (或是最舊的中途分頁 LSN) 的開頭順向掃描交易記錄至結尾,以判斷 SQL Server 停止時每個交易的狀態。

  • 重做階段

    SQL Server 會從最舊的未認可交易開始,執行交易記錄的順向掃描到結尾,藉由重做所有已認可的作業,讓資料庫回到當機時的狀態。

  • 復原階段

    針對當機時每一個使用中的交易,SQL Server 會向後周遊記錄,復原此交易所執行的作業。

根據這項設計,資料庫引擎從未預期重新啟動進行復原所需時間 (大約) 會和當機時系統中使用時間最長交易的大小成比例。 復原需要回復所有未完成的交易。 所需時間與交易執行的工作和其已使用時間成比例。 因此,SQL Server 復原處理序在有長時間執行的交易 (例如大量插入作業或針對大型資料表的索引建置作業) 時,可能需要相當長的時間。

此外,根據此設計,取消或復原大型交易也可能會耗費相當長的時間,因為它會使用與之前相同的復原復原階段。

此外,資料庫引擎在有長時間執行交易時無法截斷交易記錄,因為復原和回復處理序需要它們對應的記錄檔記錄。 因此,有些交易記錄會變得相當龐大並耗用大量的磁碟機空間。

加速資料庫復原處理序

ADR 藉由完全重新設計資料庫引擎的復原處理序來解決之前的問題:

  • 透過避免從最舊使用中交易的開頭進行掃描,或是掃描至開頭,來固定時間或使其能夠立即完成。 使用 ADR,只會從最後一次成功的檢查點 (或是最舊的中途分頁記錄序號 (LSN)) 開始處理交易記錄。 因此,復原時間不會受到長時間執行的交易影響。
  • 將所需的交易記錄空間減至最小,因為不再需要處理整個交易的記錄。 因此,可在進行檢查點和備份時積極地截斷交易記錄。

從高層級而言,ADR 會透過對所有實體資料庫修改建立版本,並只復原邏輯作業 (其數量有限且可以立即進行復原) 來快速地進行資料庫復原。 任何在當機時處於使用中狀態的交易都會標記為中止,且因此並行使用者查詢可以略過任何由這些交易產生的版本。

ADR 復原處理序與目前復原處理序具有相同的三個階段。 這些階段與 ADR 運作的方式如下圖所示。

ADR 恢復流程的圖表。

  • 分析階段

    該流程與目前的流程相同,但會另外重新建構 SLOG (系統記錄檔資料流) 並複製未建立版本作業的記錄檔記錄。

  • 重做階段

    分成兩個子階段

    • 子階段 1

      從 SLOG 重做 (最舊的未認可交易至最後一個檢查點)。 重做是快速的作業,因為只需要處理來自 SLOG 的幾個記錄。

    • 子階段 2

      從最後一個檢查點開始 (而非最舊的未認可交易),從交易記錄進行重做。

  • 復原階段

    使用 ADR 的復原階段會搭配邏輯還原來使用 SLOG 以復原未建立版本的作業及持續版本存放區 (PVS),以幾乎立即的方式來完成執行資料列版本式復原。

您也可以觀看這段說明加速資料庫復原的八分鐘影片:

ADR 復原元件

ADR 的四個關鍵元件為:

  • 持續版本存放區 (PVS)

    持續版本存放區是一種資料庫引擎機制,用於保存資料庫本身產生的資料列版本,而非傳統的 tempdb 版本存放區。 PVS 可隔離資源並改善可讀取次要的可用性。 SQL Server 2019 (15.x) 中的每個執行個體都有一個 PVS 執行緒。 從 SQL Server 2022 (16.x) 開始,SQL Server 內每個資料庫都有一個 PVS 清除工具執行緒。

  • 邏輯還原

    邏輯還原是非同步的處理序,負責執行資料列層級版本式復原,為所有建立版本的作業提供交易立即回復和復原。

    • 追蹤所有中止的交易
    • 針對所有使用者交易,使用 PVS 來執行復原
    • 在交易中止後立即釋出所有鎖定
  • SLOG

    SLOG 是一種次要的記憶體內部記錄資料流,可儲存未建立版本作業的記錄檔記錄 (例如中繼資料快取無效判定、取得鎖定等)。 SLOG 是:

    • 體積小並位於記憶體內部
    • 透過在檢查點處理序期間進行序列化來保存在磁碟上
    • 在交易認可時定期截斷
    • 透過只處理未建立版本的作業來加速重做和復原
    • 透過只保留需要的記錄檔記錄來啟用積極性交易記錄截斷
  • 清除工具

    清除工具是一種非同步處理序,會定期喚醒並清理 PVS 中已淘汰的資料列版本。

SQL Server 2022 (16.x) 中的 ADR 改進

我們提供了幾項改進,以解決持續版本存放區 (PVS) 儲存體的問題,並改善整體可擴縮性。 如需 SQL Server 2022 (16.x) 新功能的詳細資訊,請參閱 SQL Server 2022 (16.x) 的新功能

  • 使用者交易清除

    清除因鎖定失敗而無法透過一般流程清除的頁面。

    若頁面因資料表層級鎖定衝突而無法透過一般清除流程解決,此功能可讓使用者交易在該類頁面上執行清除。 使用者工作負載無法取得資料表層級鎖定,因此這項改進可確保 ADR 清除流程不會無限期失敗。

  • 減少 PVS 頁面追蹤器的磁碟使用量

    這項改進會在範圍層級內追蹤持續版本存放區 (PVS),以減少維護版本分頁所需的磁碟使用量。

  • 加速資料復原 (ADR) 清除工具的改進項目

    加速資料復原 (ADR) 清除工具已提升版本清除效率,可改善 SQL Server 追蹤和記錄中止版本頁面的方式,進而改善記憶體和容量。

  • 交易層級持續版本存放區 (PVS)

    這項改進可讓 ADR 清除屬於已認可交易的版本,無論系統中是否有已中止的交易皆不影響其結果。 您可以透過這項改進解除配置持續版本存放區 (PVS) 頁面,即便清除無法成功完成掃掠並修剪中止的交易對應,亦不影響。

    即使 ADR 清除速度緩慢或失敗,這項改進還是能降低持續版本存放區 (PVS) 的增長。

  • 多執行緒版本清除

    在 SQL Server 2019 (15.x) 中,清除流程是 SQL Server 執行個體內的單一執行緒。

    從 SQL Server 2022 (16.x) 開始,此流程會使用多執行緒版本清除。 這可同時清除相同 SQL Server 執行個體中的多個資料庫。 當您有多個大型資料庫時,這項改進就相當重要。

    若要調整版本清除可擴縮性的執行緒數目,請使用 sp_configure 來設定 ADR Cleaner Thread Count。 執行緒計數的上限是執行個體的核心數目。

    我們建議您使用與資料庫數目相同的 ADR 清除工具執行緒數目,這才是最佳做法。 例如,如果您在具有兩個資料庫的 SQL Server 執行個體上將 ADR Cleaner Thread Count 設定為 4,ADR 清除工具仍然只會為每個資料庫配置一個執行緒,讓其餘兩個執行緒保持閒置狀態。

    下列範例會將執行緒計數變更為 4

    EXEC sp_configure 'ADR Cleaner Thread Count', '4';
    RECONFIGURE WITH OVERRIDE; 
    
  • 新的擴充事件

    已針對 ADR PVS 多執行緒版本清除工具上的遙測新增擴充事件 tx_mtvc2_sweep_stats

最佳做法和指引

如需 ADR 不建議使用的工作負載指引,請參閱<管理加速資料庫復原>。

重要

在 Azure SQL 資料庫中,閑置的交易 (尚未寫入交易記錄 6 小時的交易) 會自動終止,以釋出資源。