通过

管理加速数据库恢复

  • 项目

适用于：SQL Server 2019 (15.x)

本文包含有关在 SQL Server 2019 (15.x) 及更高版本中管理和配置加速数据库恢复 (ADR) 的最佳实践的信息。 有关 Azure SQL 上的 ADR 的详细信息，请参阅 Azure SQL 中的加速数据库恢复。

注意

在 Azure SQL 数据库 和 Azure SQL 托管实例 中，加速数据库恢复 (ADR) 在所有数据库上都已启用，并且无法禁用。 如果发现有关存储使用情况、高中止事务和其他因素的问题，请查看排查加速数据库恢复 (ADR) 故障或联系 Azure 支持。

谁应考虑加速数据库恢复

许多客户发现加速数据库恢复 (ADR) 是一项可改善恢复时间的重要技术。 在确定哪些数据库应使用 ADR 之前，应综合考虑以下因素，并评估下面的因素，在权衡各项因素的累积之后决定是否适合使用 ADR。

  • 对于包含无法避免的长期运行事务的工作负载，建议使用 ADR。 例如，在长期运行的事务面临回滚风险的情况下，ADR 可以提供帮助。

  • 对于活动事务正在导致事务日志显著增大的工作负荷，建议使用 ADR。

  • 对于由于 SQL Server 长时间运行的恢复（如意外的 SQL Server 重启或手动事务回滚）而经历了数据库长时间不可用的工作负荷，建议使用 ADR。

  • 在数据库镜像中注册的数据库不支持 ADR。

  • 对于大于 100 TB 的数据库，由于单线程持久性版本存储 (PVS) 版本清理器，不建议使用 ADR。

  • 如果你的应用程序执行许多非批处理的增量更新（例如每当访问/插入行时更新记录），则你的工作负荷可能并不适合使用 ADR。 请考虑将应用程序查询重新编写为批处理更新（如果可能），直到命令结束，并减少大量小型更新事务。

评估工作负荷是否适合使用 ADR

在工作负荷中启用 ADR 后，请查找持久性版本存储 (PVS) 无法保持的征兆。 建议使用在加速数据库恢复故障排除中找到的方法来监视 ADR 健康状况。

对于更新/删除量较高（例如大容量 OLTP）并且 PVS 清理进程没有留出一段休息/恢复时间来回收空间的数据库环境，不建议使用 ADR。 通常情况下，业务操作周期会预留出此时间，但在某些情况下，你可能需要手动启动 PVS 清理进程，以利用应用程序活动情况。

  • 如果 PVS 清理进程运行了很长一段时间，你可能会发现中止的事务计数将增加，这也会导致 PVS 大小增加。 使用 sys.dm_tran_aborted_transactions DMV 报告中止的事务计数，并使用 sys.dm_tran_persistent_version_store_stats 报告清理开始/结束时间以及 PVS 大小。 有关详细信息，请参阅 sys.dm_tran_persistent_version_store_stats。

  • 若要在工作负荷之间或维护时段内手动激活 PVS 清理过程，请使用 sys.sp_persistent_version_cleanup。 有关详细信息，请参阅 sys.sp_persistent_version_cleanup。

  • 在 SNAPSHOT 或 READ COMMITTED SNAPSHOT 隔离模式下，具有长期运行查询的工作负载可能会延迟清理其他数据库中的 ADR PVS，从而导致 PVS 文件增长。 有关详细信息，请参阅排查加速数据库恢复故障中有关长期活动快照扫描的部分。 这适用于 SQL Server 和 Azure SQL 托管实例的实例，或者 Azure SQL 数据库弹性池中的实例。

加速数据库恢复的最佳做法

本部分包含有关 ADR 的指导和建议。

  • 对于 SQL Server，请将 PVS 版本存储隔离到更高层存储上的文件组，例如高端 SSD、高级 SSD 或永久性内存 (PMEM)，有时称为存储类内存 (SCM)。 有关详细信息，请参阅将 PVS 的位置更改为其他文件组。 此选项不适用于 Azure SQL 数据库和 Azure SQL 托管实例。

  • 请确保数据库中有足够的空间来使用 PVS。 如果数据库没有足够的空间供 PVS 增长，ADR 将无法生成版本。 与 tempdb 版本存储相比，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 显示了 SQL Server 实例上的所有中止事务。 nested_abort 列指示事务已提交，但存在中止的部分（保存点或嵌套事务），这可能会阻碍 PVS 清理进程。 有关详细信息，请参阅 sys.dm_tran_aborted_transactions (Transact-SQL)。

启用和控制 ADR

注意

在 Azure SQL 数据库 和 Azure SQL 托管实例 中，加速数据库恢复 (ADR) 在所有数据库上都已启用，并且无法禁用或移动到不同的文件组。

ADR 在 SQL Server 2019 (15.x) 中默认处于禁用状态，并且可使用 DDL 语法进行控制：

ALTER DATABASE [DB] SET ACCELERATED_DATABASE_RECOVERY = {ON | OFF};

使用此语法控制该功能是启用还是禁用，并为永久版本存储 (PVS) 数据指定特定的文件组。 如果未指定文件组，则 PVS 将存储在 PRIMARY 文件组中。

需要在数据库上使用排他锁才能更改此状态。 这意味着 ALTER DATABASE 命令将停止，直到所有活动会话结束，并且任何新会话都将在 ALTER DATABASE 命令后等待。 如果完成操作并删除锁很重要，可以使用终止子句 WITH ROLLBACK [IMMEDIATE | AFTER {number} SECONDS | NO_WAIT] 中止数据库中的任何活动会话。 有关详细信息，请参阅 ALTER DATABASE set 选项。

管理永久版本存储文件组

ADR 功能的基础是使更改处于版本控制，不同版本的数据元素保存在 PVS 中。 查找 PVS 所在的位置时以及考虑如何管理 PVS 中数据的大小时，有一些注意事项。

在不指定文件组的情况下启用 ADR

此操作需要拥有对数据库的独占访问权限。

ALTER DATABASE [MyDatabase] SET ACCELERATED_DATABASE_RECOVERY = ON;
GO

在这种情况下，如果未指定 PVS 文件组，则 PRIMARY 文件组将保存 PVS 数据。

启用 ADR 并指定 PVS 应存储在文件组中

可以将 ADR 配置为使用除默认 PRIMARY 文件组之外的另一个文件组来保存 PVS 数据。

在 PRIMARY 之外的文件组中启用 ADR 之前，必须创建此文件组和数据文件。

创建 VersionStoreFG 文件组并在文件组中创建新的数据文件。 例如：

ALTER DATABASE [MyDatabase] ADD FILEGROUP [VersionStoreFG];
GO
ALTER DATABASE [MyDatabase] ADD FILE ( NAME = N'VersionStoreFG'
, FILENAME = N'E:\DATA\VersionStore.ndf'
, SIZE = 8192KB , FILEGROWTH = 65536KB )
TO FILEGROUP [VersionStoreFG];
GO

只有在创建文件组和辅助数据文件后，才能启用 ADR 并指定 PVS 应存储在特定文件组中。 此操作需要拥有对数据库的独占访问权限。

ALTER DATABASE [MyDatabase] SET ACCELERATED_DATABASE_RECOVERY = ON
(PERSISTENT_VERSION_STORE_FILEGROUP = [VersionStoreFG]);

禁用 ADR 功能

ALTER DATABASE [MyDatabase] SET ACCELERATED_DATABASE_RECOVERY = OFF;
GO

即使在禁用 ADR 功能后，也会在永久版本存储中存储版本，系统仍需要这些版本来进行逻辑还原。

将 PVS 的位置更改为其他文件组

在 SQL Server 中，出于各种原因，可能需要将 PVS 的位置移到其他文件组。 例如，PVS 可能需要更多的空间或更快的存储。

更改 PVS 位置的过程分为三步。

  1. 关闭 ADR 功能。

    ALTER DATABASE [MyDatabase] SET ACCELERATED_DATABASE_RECOVERY = OFF;
GO

  2. 等待，直到可释放 PVS 中存储的所有版本。

    为了能够打开具有永久版本存储新位置的 ADR，首先必须确保已从以前的 PVS 位置清除了所有版本信息。 若要强制执行清理操作，请运行以下命令：

    EXEC sys.sp_persistent_version_cleanup [database name];

    sys.sp_persistent_version_cleanup 存储过程是同步的，这意味着该过程将一直持续到当前 PVS 中的所有版本信息清除完成。 完成后，通过查询 DMV sys.dm_tran_persistent_version_store_stats 并检查 persistent_version_store_size_kb 的值，可验证版本信息是否确实已删除。

    SELECT DB_Name(database_id), persistent_version_store_size_kb 
FROM sys.dm_tran_persistent_version_store_stats where database_id = [MyDatabaseID];

    如果 persistent_version_store_size_kb 的值为 0，则可以重新启用 ADR 功能，将 PVS 配置到新文件组中。

  3. 打开 ADR，为 PVS 指定新位置：

    ALTER DATABASE [MyDatabase] SET ACCELERATED_DATABASE_RECOVERY = ON
(PERSISTENT_VERSION_STORE_FILEGROUP = [VersionStoreFG]);

后续步骤