数据库检查点（SQL Server）

2015-10-13

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

检查点概述

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

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

名称	Transact-SQL 接口	DESCRIPTION
自动	EXEC sp_configure *“`recovery interval`，”`seconds`”*	在后台自动发布，以满足服务器配置选项建议的时间上限。自动检查点已完成运行。根据未完成的写入次数以及数据库引擎是否检测到写入延迟超过 20 毫秒增加，自动检查点会受到限制。有关详细信息，请参阅 “配置恢复间隔服务器配置选项”。
间接	ALTER DATABASE ... SET TARGET_RECOVERY_TIME =target_recovery_time { 秒 \| 分钟 }	在后台执行以实现用户为某个数据库指定的目标恢复时间。默认目标恢复时间为 0，这会导致自动检查点启发式算法被用于数据库。如果使用 ALTER DATABASE 将TARGET_RECOVERY_TIME设置为 >0，则使用此值，而不是为服务器实例指定的恢复间隔。有关详细信息，请参阅更改数据库的目标恢复时间 (SQL Server)。
手动	CHECKPOINT [ checkpoint_duration ]	执行 Transact-SQL CHECKPOINT 命令时发出。手动检查点发生在连接的当前数据库中。默认情况下，手动检查点将运行直至完成。限流的工作方式与自动检查点的工作方式相同。（可选） checkpoint_duration 参数指定请求的时间量（以秒为单位）完成检查点。有关详细信息，请参阅 CHECKPOINT（Transact-SQL）。
内部	没有。	由各种服务器操作（例如备份和数据库快照创建）发出，以保障磁盘映像与日志的当前状态保持一致。

注释

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

对于自动、手动和内部检查点，在进行数据库恢复时，只需向前应用在最新检查点之后所做的修改。这减少了恢复数据库所需的时间。

重要

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

TARGET_RECOVERY_TIME和“恢复间隔”选项的交互

下表汇总了服务器范围sp_configure“recovery interval设置与数据库特定的 ALTER DATABASE ...TARGET_RECOVERY_TIME设置。

目标恢复时间	“恢复间隔”	使用的检查点类型
0	0	目标恢复间隔为 1 分钟的自动检查点。
0	>0	由用户定义设置的 sp_configure 恢复间隔选项指定的自动检查点。
>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，那么恢复完成的时间大约需要设置为零时的 10 倍。

间接检查点

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

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

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

内部检查点

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

已使用 ALTER DATABASE 添加或删除数据库文件。
数据库备份已完成。
无论是显式创建还是为了 DBCC CHECK 内部创建，都会创建一个数据库快照。
执行需要数据库关闭的活动。例如，当 AUTO_CLOSE 为开启状态且最后一个用户连接到数据库被关闭时，或者进行更改需要重启数据库的选项时。
通过停止 SQL Server (MSSQLSERVER) 服务来停止 SQL Server 实例。任何一个动作都会在 SQL Server 实例中的每个数据库中创建一个检查点。
使 SQL Server 故障转移群集实例（FCI）离线。

另请参阅

事务日志 (SQL Server)

通过

数据库检查点 （SQL Server）