深入理解检查点（checkpoint）的工作机制

本文结合Eygle大师的力作《深入解析oracle》一书中有关Checkpoint一节内容以及网上其它同学的相关知识，加上自己的理解，并配上实例深入的去理解Checkpoint的机制，如有不对的地方还请高手指点，希望与各位共同学习。欢迎转载，转载请注明出处。

1、坚持点的基础知识

检查点是数据库的一个事件，它存在的根本意义在于减少崩溃恢复（Crash recover）时间。检查点事件有CKPT进程触发，当检查点发生时，CKPT进程负责通知DBWR进程将脏数据（Dirty buffer）写出到数据文件上。CKPT还有一个职责就是负责更新数据文件头和控制文件上的检查点信息。

2、坚持点的工作原理

  在oracle数据库中，当进行数据修改时，需要首先将数据读入内存中（Buffer cache），修改数据的同时，oracle会记录重做（redo）信息用于恢复。因为有了重做的存在，oracle不需要在事务提交时（commit）立即将变化的数据写回磁盘（立即写可能太频繁导致性能大大降低），重做的存在正是为了在数据库崩溃之后，数据可以恢复。

  最常见的情况，数据库可能因为断电而crash，那么内存中修改过的、尚未写入数据文件的数据将会丢失。在下一次数据库启动之后，oracle需要通过redo日志进行数据库事务重演（也就是进行前滚），将数据库恢复到崩溃之前的状态，然后数据库可以打开提供服务，之后oracle将未提交的事务进行回滚。

  在启动的过程中需要多久才能打开数据库呢？我们希望这个时间越短越好，检查点的存在也正是为了缩短这个恢复时间。当检查点发生时（此时SCN被称为Checkpoint SCN）oracle通知DBWR进程，把修改过的数据，也就是此时Checkpoint SCN之前的脏数据（Dirty data）从buffer cache写入磁盘，当写完之后CKPT进程则会相应地更新数据文件头和控制文件，记录坚持点信息，变更标识。在坚持点完成之后，此检查点之前的被修改过的数据都已经写回磁盘，重做日志中的相应记录对于崩溃后实例恢复已经不再有用。

如下图所示，假定在T1时间点，数据库完成并记录了最后一次checkpoint，在T2时刻数据库crash，那么在下次启动数据库的时候，T1时刻之前的redo不再需要进行恢复，oracle只需要应用T1到T2之间的redo日志就可以把数据库恢复到实例crash之前的状态。

3、常规坚持点和增量检查点

为了理解常规坚持点和增量坚持点的概念，首先需要了解脏缓冲队列（Dirty list）。当数据在Buffer cache被修改之后，Dirty buffer就会被移动到Dirty list上，以便将来执行的检查点可以将这些修改过的Buffer写到数据文件上。但是Dirty buffer上的buffer并没有有顺序，有的buffer反复被修改，在链表上的位置就可能发生变化，当检查点发生时oracle需要将脏缓冲队列上的全部数据写出到数据文件。为了区分，在oracle8之前，oracle实施的这类坚持点通常被称为常规检查点（Conventional Checkpoint），由于常规检查点时需要写出全部脏数据，所以也被称为完全坚持点（Complete Checkpoint）。常规检查点按特定的条件触发（log_chechpoint_interval、log_checkpoint_timeout参数设置及log switch等条件触发），触发时会同时更新数据文件头和控制文件以记录检查点信息。

从oracle8开始，oracle演进了新的算法，进而引入了增量检查点（Incremental Checkpoint）的概念。和以前的版本相比，在新版本中，主要的变化是引入了检查点队列（Checkpoint Queue，CKPTQ）机制。在数据库内部，每一个脏数据库块都会被记录到检查点队列，按照LRBA（Low RBA，第一次对此数据块修改对于的Redo Byte Address）的顺序来排列，如果一个数据块进行多次修改，该数据块在检查点队列的顺序并不会发生变化（相对于LRBA，后面修改的RBA称为HRBA）。

在执行增量检查点时，CKPT告诉 DBWR写dirty buffer要一直写到Checkpoint Queue中的一个最新位置，在这个检查点过程中，可以继续产生dirty buffer