数据库检查点 (SQL Server)

项目
10/13/2015

本主题概述了SQL Server数据库检查点。检查点创建了一个已知的正常点，SQL Server 数据库引擎可以在意外关闭或崩溃后的恢复过程中从该点开始应用日志中包含的更改。

检查点概述

出于性能原因，数据库引擎对缓冲区缓存中的内存中的数据库页执行修改，并且每次更改后都不会将这些页写入磁盘。相反，数据库引擎会定期在每个数据库上发布一个检查点。 “检查点”将当前内存中已修改的页（称为“脏页” ）和事务日志信息从内存写入磁盘，并记录有关事务日志的信息。

数据库引擎支持几种类型的检查点：自动、间接、手动和内部。下表总结了检查点类型。

名称	Transact-SQL 接口	说明
自动	EXEC sp_configure *“`recovery interval`，”`seconds`”*	在后台自动发出，以满足服务器配置选项建议的时间 `recovery interval` 上限。运行自动检查点直到完成。自动检查点根据未完成的写入次数以及数据库引擎是否检测到写入延迟超过 20 毫秒而受到限制。有关详细信息，请参阅 Configure the recovery interval Server Configuration Option。
间接	ALTER DATABASE...SET TARGET_RECOVERY_TIME =target_recovery_time { SECONDS \|MINUTES }	在后台发出，以满足给定数据库的用户指定的目标恢复时间要求。默认目标恢复时间为 0，这将导致对数据库使用自动检查点试探方法。如果使用 ALTER DATABASE 将 TARGET_RECOVERY_TIME 设置为 >0，则使用此值，而不是为服务器实例指定的恢复间隔。有关详细信息，请参阅更改数据库的目标恢复时间 (SQL Server)。
手动	CHECKPOINT [ checkpoint_duration ]	在执行 Transact-SQL CHECKPOINT 命令时发出。在连接的当前数据库中执行手动检查点操作。默认情况下，手动检查点运行至完成。调控方式与自动检查点的调控方式相同。（可选） checkpoint_duration 参数指定完成检查点所需的时间（秒）。有关详细信息，请参阅 CHECKPOINT (Transact-SQL)。
内部	无。	由各种服务器操作（如备份和数据库快照创建）发出，以确保磁盘映像与日志的当前状态匹配。

注意

SQL Server-k高级安装选项使数据库管理员可以根据某些类型的检查点的 I/O 子系统的吞吐量来限制检查点 I/O 行为。 -k 设置选项适用于自动检查点和任何未调控的手动和内部检查点。

对于自动、手动和内部检查点，在数据库恢复期间只有在最新检查点后所做的修改需要前滚。这将减少恢复数据库所需的时间。

重要

长时间运行的未提交的事务会增加所有类型的检查点的恢复时间。

TARGET_RECOVERY_TIME 和“recovery interval”选项的相互影响

下表总结了服务器范围sp_configure“”recovery interval设置与数据库特定的 ALTER DATABASE 之间的交互。TARGET_RECOVERY_TIME设置。

target_recovery_time	'recovery interval'	使用的检查点类型
0	0	目标恢复间隔为 1 分钟的自动检查点。
0	>0	自动检查点，其目标恢复间隔由 sp_configurerecovery interval 选项的用户定义的设置指定。
>0	不适用。	间接检查点，其目标恢复时间由 TARGET_RECOVERY_TIME 设置确定，以秒为单位。

自动检查点

每当日志记录数达到数据库引擎估计在服务器配置选项中指定的 recovery interval 时间内可以处理的数量时，就会发生自动检查点。在没有用户定义的目标恢复时间的每个数据库中，数据库引擎都会生成自动检查点。自动检查点的频率取决于 recovery interval 高级服务器配置选项，该选项指定给定服务器实例在系统重启期间应用于恢复数据库的最长时间。数据库引擎将估计它在恢复间隔内可以处理的最大日志记录数。当使用自动检查点的数据库达到此最大日志记录数时，数据库引擎将对数据库发出检查点。自动检查点之间的时间间隔可以变化很大。具有大量事务工作负荷的数据库的检查点生成频率将高于主要用于只读操作的数据库的检查点生成频率。

此外，在简单恢复模式下，如果日志填充 70％，则自动检查点还将排队。

在简单恢复模式下，除非某些因素延迟了日志截断，否则自动检查点将截断事务日志中没有使用的部分。相反，在完整恢复模式或大容量日志恢复模式下，一旦建立了日志备份链，自动检查点将不导致日志截断。有关详细信息，请参阅事务日志 (SQL Server)。

在系统崩溃后恢复给定数据库所需的时间主要取决于重做崩溃时的脏页所需的随机 I/O 量。这意味着该 recovery interval 设置不可靠。它不能确定准确的恢复持续时间。此外，正在执行自动检查点操作时，数据的常规 I/O 活动显著增加并且无法预测。

恢复间隔对恢复性能的影响

对于使用短事务 (OLTP) 系统的联机事务处理， recovery interval 是决定恢复时间的主要因素。但是， recovery interval 选项不会影响撤消长时间运行的事务所需的时间。使用长时间运行的事务恢复数据库可能需要比选项中指定的 recovery interval 时间长得多。例如，如果长时间运行的事务在服务器实例被禁用之前需要两个小时来执行更新，则实际恢复所需的时间远远长于 recovery interval 恢复长事务的值。如需详细了解长时间运行的事务对恢复时间的影响，请参阅事务日志 (SQL Server)。

通常情况下，默认值提供了最佳恢复性能。但是，在以下情况下更改恢复间隔可能会提高性能：

如果例行恢复所需的时间在长时间运行的事务未回滚时超过 1 分钟。
如果您注意到频繁的检查点操作损害了数据库的性能。

如果您决定增大 recovery interval 设置，我们建议一点一点逐渐增大该值并评估每次增大对恢复性能的影响。此方法非常重要， recovery interval 因为随着设置的增加，数据库恢复需要花费很多倍的时间才能完成。例如，如果更改 recovery interval 10，则恢复完成所需的时间大约是设置为零时的 recovery interval 10 倍。

间接检查点

SQL Server 2012 中新增的间接检查点为自动检查点提供了可配置的数据库级替代方法。在系统崩溃时，间接检查点与自动检查点相比，恢复时间可能更短更可预测。间接检查点具有以下优点：

为间接检查点配置的数据库上的联机事务工作负荷可能导致性能下降。间接检查点确保损坏页的数量低于特定阙值，以便在目标恢复时间内完成数据库恢复。与利用损坏页数量的间接检查点相反，恢复间隔配置选项使用事务数量来确定恢复时间。当在接收大量 DML 操作的数据库上启用了间接检查点时，后台写入线程可以开始积极刷新磁盘的脏缓冲区，以确保执行恢复所需的时间在数据库所设目标恢复时间范围内。这可能造成某些系统上出现额外的 I/O 活动，如果磁盘子系统在 I/O 阙值之上或附近运行，则这会导致性能瓶颈。
间接检查点使您可以通过控制 REDO 期间随机 I/O 的开销来可靠控制数据库恢复时间。这使服务器实例不超过给定数据库的恢复时间上限（长时间运行的事务导致过多 UNDO 时间时除外）。
间接检查点通过在后台不断地将脏页写入磁盘来减小与检查点有关的 I/O 蜂值。

但是，为间接检查点配置的数据库上的联机事务工作负荷可能导致性能下降。这是因为间接检查点使用的后台写入线程有时增加了服务器实例的总写入负荷。

内部检查点

内部检查点由各种服务器组件生成，以确保磁盘映像与日志的当前状态匹配。生成内部检查点以响应下列事件：

已经使用 ALTER DATABASE 添加或删除了数据库文件。
进行了数据库备份。
创建了数据库快照，不管 DBCC CHECK 是显式还是内部执行。
执行了需要关闭数据库的活动。例如，AUTO_CLOSE 设置为 ON 并且关闭了数据库的最后一个用户连接，或者执行了需要重新启动数据库的数据库选项更改。
通过停止SQL Server (MSSQLSERVER) 服务来停止 SQL Server 实例。任一操作都会在 SQL Server 实例的每个数据库中生成一个检查点。
使 SQL Server 故障转移群集实例 (FCI) 脱机。