检查点机制

圆满事务：日志中记录了事务的开始和commit提交事务，这说明日志已经完整地记录了事务的所有更新活动。

中止事务：日志中记录了事务的开始记录，但没有日志的提交记录，这说明日志记录的事务没有最后提交。

数据库的故障及恢复机制都离不开日志文件。每次恢复过程都需要从头到尾扫描日志文件以确定哪些事务是圆满事务，哪些事务是中止事务，才能分别进行Redo或Undo操作。

设想一下，如果日志文件的内容很大，这样的扫描和恢复操作将耗费大量的资源。而且尽管一些圆满事务的结果已经写入数据库（不需要Redo），但从头到尾的扫描仍然会Redo这些事务，尽管这样的操作并不会导致数据库一致性的改变，但无谓的Redo操作仍然显得多余。

有没有尽量减少在恢复时必须前滚的修改量的机制呢？这就是检查点机制。目前的主流数据库产品都支持日志的检查点机制。

SQL Server 系统按照设置在日志文件中设置一个一个的检查点（checkpoint），这里的检查点就好比是日志文件的一个一个驿站。检查点从当前数据库的内存的缓冲区中刷新脏数据和日志页面，以尽量减少在恢复时必须重做（Redo）的修改量。

1.检查点的操作

SQL Server 生成检查点的过程如下：

①将标记检查点起点的日志记录写入日志文件。

②将为检查点记录的信息存储在检查点日志记录链中，链起点的LSN将写入数据库根页面中。

③将最小恢复LSN（MinLSN）保存在检查点记录中。

④在检查点记录中记录所有的未完成的活动事务。

⑤如果数据库工作在【简单恢复模式】，删除新的MinLSN之前的所有日志记录。

⑥将所有修改后的日志写入磁盘。

⑦将所有修改后的数据写入磁盘。

⑧将标记检查点记录末端的记录写入日志文件。

2.检查点与恢复效率的关系

在日志文件中设置了检查点之后，为什么基于日志的恢复机制就可以提高效率了呢？如图所示为检查点发生时可能的事务的状态。

① 事务1

其start和commit日志记录都发生在检查点之前，这样的事务其结果已经反映到物理介质上去了（因为检查点会保证WAL协议，确保数据被写入），所以在恢复时无须对该事务做Redo操作。

② 事务2

其start日志记录在检查点之前发生，其commit记录在故障点之前发生，说明日志中事务已经完美提交，但数据不一定已经写入，所以属于圆满事务，需要Redo操作。

③ 事务3

其start日志记录在检查点之后发生，其commit记录在故障点之前发生，说明日志中事务已经完美提交，但数据不一定已经写入，所以属于圆满事务，需要Redo操作。

④ 事务4

其start日志记录在检查点之后发生，其commit记录在故障点之前尚未发生，说明日志中事务为中止事务，需要Undo操作。

⑤ 事务5

其start日志记录在检查点之前发生，其commit记录在故障点之前尚未发生，说明日志中事务为中止事务，需要Undo操作。

由于在检查点完成之前的所有事务不需要再执行Redo操作，所以可以大大提高数据库系统恢复的效率。

3.MinLSN的选择

MinLSN实际上代表了数据库从检查点恢复时，具体从哪个LSN号开始扫描并进行恢复。所以MinLSN的选择是检查点时的LSN和最早的活动事务起点LSN两者比较的最小值。

如图，事务2为检查点时的唯一活动事务，其起点的LSN1小于检查点发生时的LSN2，所以MinLSN取LSN1就可以。

本文转自UltraSQL51CTO博客，原文链接：/ultrasql/1591632 ，如需转载请自行联系原作者