共用方式為

加速資料庫復原

  • 發行項

適用於：Microsoft Fabric 中的 SQL Server 2019 （15.x） 和更新版本 Azure SQL 資料庫 Azure SQL 受控執行個體SQL Database

加速資料庫復原 （ADR） 藉由重新設計資料庫引擎復原程式，改善資料庫可用性，特別是在長時間執行的交易中。

ADR 於 SQL Server 2019 (15.x) 引進，並於 SQL Server 2022 (16.x) 獲得改善。 ADR 也適用於 Azure SQL Database、Azure SQL 受控實例、Azure Synapse Analytics（僅限專用 SQL 集區），以及 Microsoft Fabric 中的 SQL 資料庫。

注意事項

ADR 一律會在 Azure SQL Database、Azure SQL 受控實例和網狀架構中的 SQL 資料庫中啟用。

本文提供 ADR 的概觀。 若要使用 ADR，請檢閱＜管理加速資料庫復原＞。

如需事務歷史記錄和資料庫復原的詳細資訊，請參閱 SQL Server 事務歷史記錄架構和管理指南， 和 還原和復原概觀 （SQL Server）。

概觀

ADR 的主要優點為：

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

    長時間執行的交易不會影響整體復原時間，無論系統中作用中交易的數量或大小為何，資料庫仍能快速且穩定地復原。

  • 瞬間交易回復

    交易回滾是即時進行的，不論交易進行的時間或已更新的次數為何。

  • 積極性記錄截斷

    即使在有作用中的長時間執行交易的情況下，交易日誌也會被積極截斷，以防止其失控地增長。

傳統資料庫復原程式

如果沒有 ADR，資料庫復原會遵循 ARIES 恢復模式，並包含三個階段，如下圖所示並加以說明：

目前恢復流程的圖表。

  • 分析階段

    資料庫引擎會從最後一個成功檢查點（或最舊的髒頁面記錄序號（LSN））開始對交易記錄檔進行正向掃描，直到結束，以判斷引擎停止時每個交易的狀態。

  • 重做階段

    資料庫引擎會從最早的未提交交易順序掃描交易記錄直到結尾。 此程式會重做所有認可的作業，以在當機時將資料庫還原至其狀態。

  • 復原階段

    對於在當機時作用中的每個交易，資料庫引擎會向後回溯記錄，並復原此交易執行的操作。

  • 透過傳統的資料庫復原程式，如果長時間執行的交易處於作用中狀態，當機後復原可能需要很長的時間。

    資料庫引擎從非預期的重新啟動中復原的時間大約與當機時系統中最長使用中交易的大小成正比。 復原需要回復所有未完成的交易。 所需時間與交易執行的工作和其已使用時間成比例。

  • 取消或回退大型交易可能需要很長時間，因為它使用了之前所述的相同復原階段。

  • 資料庫引擎無法在有長時間執行的交易時截斷交易記錄檔，因為復原和回復過程需要其對應的記錄檔記錄。 因此，事務歷史記錄可能會成長非常龐大，並耗用大量的儲存空間。

加速資料庫復原處理序

ADR 藉由徹底重新設計資料庫引擎復原程式，解決傳統恢復模式先前的問題：

  • 將復原時間設為常數，因為不再需要從最舊的使用中交易開頭掃描事務歷史記錄。 使用 ADR 時，交易日志只會從最後一個成功的檢查點（或最舊的髒頁面 LSN）開始處理。 因此，復原時間不會受到長時間執行的交易影響，而且通常是即時的。

  • 將所需的事務歷史記錄空間降到最低，因為不再需要保留整個交易的記錄檔。 因此，可在進行檢查點和備份時積極地截斷交易記錄。

概括而言，ADR 可藉由為所有實體資料庫修改建立版本控制，並僅復原非版本化的操作，以達成快速的資料庫復原。這些非版本化的操作範圍有限，幾乎可以即時復原。 任何在當機時處於使用中狀態的交易都會標記為中止，且因此並行使用者查詢可以略過任何由這些交易產生的版本。

ADR 復原程式與傳統復原程式具有相同的三個階段。 下圖說明這些階段如何使用 ADR 運作：

ADR 恢復流程的圖表。

  • 分析階段

    此過程保持與傳統恢復模式相同，附加了重建次要記錄數據流 (SLOG) 並複製非版本化作業的記錄檔。

  • 重做階段

    分成兩個子階段

    • 子階段 1

      從 SLOG 重演（從最早的未提交交易起到最後一個檢查點）。 重做是快速的作業，因為它可能只需要處理 SLOG 中的一些記錄。

    • 子階段 2

      事務歷史記錄的重做會從最後一個成功的檢查點開始（而不是最舊的未認可交易）。

  • 復原階段

    ADR 的還原階段幾乎可以立即完成，方法是利用 SLOG 來還原非版本操作，並且使用邏輯還原結合持久性版本存放區（PVS）來執行列級版本型還原。

如需加速資料庫復原的說明，請觀看這段八分鐘的影片：

ADR 復原元件

ADR 的四個關鍵元件為：

  • 永續性版本存放區 （PVS）

    持續性版本存放區（PVS）是一種資料庫引擎機制，用於在資料庫本身儲存資料列版本，而不是在 tempdb 資料庫中的傳統版本存放區中儲存資料列版本。 PVS 可隔離資源並改善可讀取次要的可用性。

  • 邏輯還原

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

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

  • SLOG

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

    • 體積小並位於記憶體內部
    • 在檢查點過程中保存在磁碟上
    • 在交易認可時定期截斷
    • 只處理不涉及版本的操作來加速重做和復原
    • 透過只保留需要的記錄檔記錄來啟用積極性交易記錄截斷

  • 清除工具

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

受益於 ADR 的工作負載

ADR 對於特別有利於具有以下特徵的工作負載：

  • 長時間執行的交易。
  • 導致交易日志大幅增長的作用中交易。
  • 資料庫因長時間執行恢復而無法使用（例如因非預期的服務重新啟動或手動交易回復）。

ADR 的最佳做法

  • 避免不必要的長時間執行交易。 雖然 ADR 即使在長時間執行的交易中也會加速資料庫復原，但這類交易可能會延遲版本清除，並增加 PVS 的大小。

  • 避免包含 DDL 作業的大型交易。 ADR 使用第二日誌流（SLOG）機制來追蹤復原中使用的 DDL 作業。 只有在交易進行時才會使用 SLOG。 SLOG 會進行檢查點，因此避免進行使用 SLOG 的大型交易可協助提升整體效能。 這些情況可能會導致 SLOG 佔用更多空間：

    • 許多資料定義語言（DDL）指令會在一個交易中執行。 例如，在一個交易中，快速建立和刪除臨時表。
    • 資料表具有數量非常多的已修改分割和索引。 例如，這類數據表上的 DROP TABLE 作業需要大量的 SLOG 記憶體保留，這會延遲截斷交易日誌並延遲撤銷/重做操作。 因應措施是逐一且逐步刪除索引，然後刪除數據表。

    如需 SLOG 的詳細資訊，請參閱 ADR 復原元件。

  • 防止或減少不必要的中止交易。 高交易中止率會對 PVS 清理程序施加壓力，導致影響 ADR 效能。 中止可能來自高比率的死結、重複鍵值、約束條件違反或查詢逾時。 sys.dm_tran_aborted_transactions DMV 會顯示資料庫引擎實例上所有中止的交易。 nested_abort 欄位表示交易已提交，但有部分中止（如儲存點或巢狀交易），這些也可能延遲 PVS 清理程序。

  • 請確定資料庫中有足夠的空間來考慮 PVS 使用量。 如果資料庫沒有足夠的空間讓 PVS 成長，ADR 可能無法產生版本，導致 DML 語句失敗。

  • 當在使用大量寫入的工作負載情況下啟用 ADR，交易記錄檔的生成速率可能會大幅增加，因為寫入 PVS 的列版本都會被記錄下來。 這可能會增加事務歷史記錄備份的大小。

  • 當您使用 事務複製、快照式複寫或 異動數據擷取 （CDC）時，ADR 的主動式記錄截斷行為會停用，讓記錄讀取器能夠從事務歷史記錄收集變更。 請確認交易日誌足夠大。

    在 Azure SQL Database 中，您可能需要增加服務層級或計算大小，以確保有足夠的事務歷史記錄空間可供您所有工作負載的需求使用。 同樣地，在 Azure SQL 受控實例中，您可能需要增加實例記憶體大小上限。

  • 針對 SQL Server，隔離較高層記憶體上檔案群組上的 PVS 版本存放區，例如高端 SSD 或進階 SSD 或持續性記憶體 （PMEM），有時稱為記憶體類別記憶體 （SCM）。 如需詳細資訊，請參閱 將 PVS 的位置變更為不同的檔案群組。

  • 針對 SQL Server，監視 PreallocatePVS 項目的錯誤記錄檔。 如果 PreallocatePVS 條目存在，您可能需要增加 ADR 的能力，以使用背景任務預先配置頁面。 在背景中預先分配 PVS 頁面，可透過減少前景 PVS 配置的高昂成本來提升 ADR 效能。 您可以使用 ADR Preallocation Factor 伺服器組態來增加此數量。 如需詳細資訊，請參閱 伺服器組態：ADR 預先設定因數。

  • 針對 SQL Server 2022 （16.x） 和更新版本，如果單個線程清除器效能不足，請考慮啟用多線程 PVS 清除。 如需詳細資訊，請參閱 伺服器組態：ADR 清除器線程計數。

  • 如果您觀察到 PVS 資料庫空間使用量偏高或 PVS 清除速度緩慢等問題，請參考 針對加速資料庫復原進行疑難解答。

SQL Server 2022 中的 ADR 改善

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

Azure SQL Database、Azure SQL 受控實例、Azure Synapse Analytics（僅限專用 SQL 集區）和 Microsoft Fabric 中的 SQL 資料庫也提供相同的改善。

  • 使用者交易清除

    由於鎖定擷取失敗，無法以一般過程清理的頁面。

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

  • 減少 PVS 頁面追蹤器的記憶體使用量

    這項改進會追蹤範圍層級的 PVS 頁面，以減少維護已建立版本頁面所需的記憶體使用量。

  • PVS 清理器改進

    PVS 清除工具已改善版本清除效率，以改善資料庫引擎如何追蹤和記錄中止交易的數據列版本。 這會導致記憶體和記憶體使用量的改善。

  • 交易層級持續性版本存放區 （PVS）

    這項改進可讓 ADR 清除屬於認可交易的版本，而不論系統中是否有中止的交易。 即使清除過程無法成功掃描並修剪終止的交易地圖，PVS 頁面仍可以解除分配。

    即使 PVS 清除速度緩慢或失敗，這項改善的結果也會降低 PVS 成長。

  • 多執行緒版本清除

    在 SQL Server 2019（15.x），清理過程是在資料庫引擎實例內單一執行緒運行。

    從 SQL Server 2022 （16.x） 開始，支援多線程版本清除。 這可讓相同資料庫引擎實例上的多個資料庫平行清除，或更快速地清除單一資料庫。 如需詳細資訊，請參閱 伺服器組態：ADR 清除器執行緒計數。

    已新增擴充事件 tx_mtvc2_sweep_stats，以監控 ADR PVS 多執行緒版本清除器。

相關內容