加速資料庫復原
適用於：
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 運作的方式如下圖所示。
分析階段
該流程與目前的流程相同，但會另外重新建構 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 小時的交易) 會自動終止，以釋出資源。