加速数据库恢复

适用于: sql Server 2019 (15.x) 及更高版本Azure SQL 数据库 Azure SQL 托管实例 Microsoft Fabric 中的 SQL 数据库

通过重新设计 SQL 数据库引擎恢复过程,加速数据库恢复 (ADR) 可提高数据库可用性,尤其是存在长时间运行的事务时。

ADR 是 SQL Server 2019 (15.x) 中引入的新功能,并在 SQL Server 2022 (16.x) 中进行了改进。 ADR 也适用于 Azure SQL 数据库、Azure SQL 托管实例和 Azure Synapse SQL 中的数据库。 SQL 数据库和 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) 执行行级别基于版本的撤消。

还可以观看此 8 分钟的视频,了解加速数据库恢复:

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; 
    
  • 扩展事件

    添加了新的扩展事件 tx_mtvc2_sweep_stats,用于 ADR PVS 多线程版本清理器上的遥测。

最佳实践和指南

有关建议和不建议用于 ADR 的工作负载的指南,请参阅管理加速数据库恢复

重要

在 Azure SQL 数据库中,空闲事务(6 小时内未写入事务日志的事务)会自动终止,以释放资源。