完全检查点和增量检查点详解

完全检查点和增量检查点 下 2、增量检查点 说白了，就是  CKPT 每3 秒一次的检查DBWn 写进度并在控制文件中记录检查点位置 (checkpoint position)和更新heartbeat 信息  以及  CKPT
定期触发DBWn 去写checkpoint queue 中的脏数据  这两项操作合一起被称为增量检查点。可能这块描述的过于笼统，大家继 续往下看  我们都知道被修改过的数据块，在oracle 中都被统称为脏数据块(dirty  buffer)。所有的脏块被一个链表串起来,称做检查点队列(checkpoint queue)。 在buffer cache 中,每一个块都有一个buffer
header 简称BH,在BH 中有一个 ckptq 项,此项目中记录了指向检查点队列上一个块和下一个块的指针。如果某 一个块不在检查点队列中,他的ckptq 项为空.通过ckptq 项oracle 将所有的脏 块串成了一个双向链表。这个双向链表就是检查点队列了。  Oracle 从8i 开始引入了检查点队列(checkpoint queue)的概念，用于记 录数据库里面当前所有的dirty buffer 的信息，这些dirty buffer 的信息按 被修改的时间先后存放在checkpoint queue
里面(当块首次被更改时，块会立 即被加进检查点队列)，所涉及的条目主要包含RBA(Redo Block Address，重 做日志里面用于标识事务期间数据块在重做日志里面发生更改的编号)和数据块 的数据文件号和块号。  不论数据块(buffer)更改几次，它在checkpoint queue 里面的位置始终保 持不变，checkpoint queue 也只会记录它最早的RBA(这个最早的RBA 其实就是 Low RBA，也就是数据块第一次被修改时所对应的RBA)，从而保证最早更改的 数据块能够尽快从内存写入数据文件。DBWR
每到一定的时机，就会被触发 (DBWn 并不是只有当检查点发生的时候才写，它大约有10 几种条件触发写操 作)，沿着检查点队列的顺序刷新脏块，同时CKPT 进程，会监控着检查点队列 的长度，当检查点队列的长度达到一定限制时(具体有几个参数来确定 checkpoing queue 的长度，下面会提到比如
log_checkpoint_timeout,fast_start_mttr_target 等)，CKPT 会通知DBWR 写 脏块。CKPT 会根据几个参数的设置和I/O 的速度以及繁忙程度，计算出来一个 Target rba(目标rba)，DBWn 会沿着检查点队列，按照dirty buffer 的Low  RBA 顺序将所有Target rba 之前对应的脏块从内存写入数据磁盘文件。当CKPT 通知完DBWn Target rba 后，CKPT 的任务就结束了。他并不会等待DBWn 写完 所有的Target
rba 之前的脏块。因此这里CKPT 只是起到了一个通知DBWn 进程 写入的作用。  当完全检查点发生的时候，Oracle 一方面通知DBWn 进行下一批写操作， 另一方面是将这个触发检查点时刻DBWn 当前刚写完dirty buffer 对应的SCN 写入数据文件头和控制文件，这个SCN 就是checkpoint scn。但Oracle 考虑 到检查点SCN 的间隔还是太大了，因为检查点的触发条件有限，周期可能比较
长，有些情况下比如检查点需要5 分钟左右才触发，那这个时候系统crash 再 重新启动就意味着很可能系统需要5 分钟左右才能启动。于是Oracle 采用了一 个heartbeat 的概念，以3 秒的频率将DBWn 写的进度反应到控制文件中，这样 系统crash 重新启动的时候将从更近的一个时间点开始恢复。Oracle 这么做的 目的就是要缩短崩溃恢复时间！因此CKPT 另外一个任务就是每3 秒，检测一次 DBWn 的写进度。DBWn 是沿着检查点队列写脏块，由于这里有一个顺序的关系， 所以DBWn 的写的进度就是可衡量的，写到哪个buffer
的时候该buffer 的首次 变化时候的scn(对应了LRba)就是当前所有数据文件block 的上面最新scn， 但是由于无法适时的将DBWn 的进度记录下来，所以Oracle 选择了一些策略。 其中就包括CKPT 进程的检查点位置更新和心跳，所以说CKPT 每3 秒钟查看一 下DBWn 沿检查点队列写到了哪里,并且将这个位置设置为检查点位置 (checkpont position)。也就是说检查点位置之前的块，都是已被DBWn 刷新到 磁盘上的块。因此我们可以理解为，CKPT 进程每3 秒会根据DBWn
写的进度设 置并记录一个检查点位置，也就是说这个检查点位置就是由DBWn 的在往 Target RBA 写过程中的进度决定的(如果没有dirty buffer 产生，那么就不会 更新检查点位置信息)。因此CKPT 每3 秒会将检查点位置对应的数据块的 rba(low cache rba-表示Instance Recovery 时开始恢复的日志条目)更新和记 录到控制文件的CHECKPOINT PROGRESS RECORDS 区域，当然同时被记录进控制 文件的还有heartbeat 等其他信息。DBWn 将检查点队列里面的dirty
buffer 写入到数据文件后，检查点的位置也要相应地往后移。  检查点位置(checkpoint position)实际上就可以直接理解为是一个rba， 他指向着重做日志文件中的某条重做记录。在此检查点位置前的重做记录，其 对应的buffer cache 中的dirty buffer 已经被写进了数据文件，在此位置后 的重做记录，所对应数据脏块有可能还在内存中。如果发生了实例崩溃，只需 要在日志文件中找到检查点位置(low cache rba)，从此处开始应用所有的重做 日志文件，就完成了前滚操作。实例崩溃后，再次启动数据库，oracle
会到控 制文件中读取 low cache rba，这就是检查点位置。从此处开始应用重做日志， 应用到on disk rba 的位置。on disk rba 是磁盘中重做日志文件的最后一条 重做记录的rba。如果某条重做记录的rba 高于on disk rba，那说明此重做记 录还没有被写进日志文件中，崩溃发生时，他是不可能被恢复的。on disk rba 是oracle 前滚操作的终点。比这个更高的rba，都应该还驻留在log buffer 中。还没有被LGWR 写入日志文件。所以是不能被用于恢复的。  在DBWn
写dirty buffer 这个检查点过程中，Oracle 也可以继续产生 dirty buffer，DBWn 也不是一次要把所有dirty buffer 全部写到磁盘(不同于 完全检查点的地方)，这样就提高了检查点的效率，使得数据库要做恢复的时候 从这个最新位置开始做恢复，而不是从数据文件中的checkpoint scn(上一个 完全检查点位置)开始做恢复，这样将缩短恢复时间。  Oracle 11g 的Concept 里面提到：An incremental checkpoint is atype  of
thread checkpoint partly intended to avoid writing large numbers  of blocks at online redo log switches.DBWn checks at least every  three seconds to determine whether it has work to do.When DBWn writes  dirty buffers,it advances the checkpoint position,causing
CKPT to  write the checkpoint position to the control file,but not to the data  file headers.ITPUB 个人空间2i5C MA.oi  因此我们需要注意的是：增量检查点并不会去更新数据文件头，以及控制 文件中数据库SCN 以及数据文件条目的SCN 信息，而只是每3 秒由CKPT
进程去 更新控制文件中的low cache rba 信息，也就是检查点的位置。  检查点位置发生变更后,Oracle 主要通过4 个参数和1 个机制来控制检查 点位置和最后的重做日志条目之间的距离(检查点队列的长度)。  fast_start_io_target(Oracle 9i 以后已经废弃)  该参数用于表示数据库发生Instance Recovery 的时候需要产生的IO 总数， 它通过v$filestat 的AVGIOTIM 来估算的。比如我们一个数据库在发生 Instance Crash 后需要在10
分钟内恢复完毕，假定OS 的IO 每秒为500 个， 那么这个数据库发生Instance Recovery 的时候大概将产生500*10*60=30,000 次IO，也就是我们将可以把fast_start_io_target 设置为30000。  fast_start_mttr_target  我们从上面可以看到fast_start_io_target 来估算检查点位置比较麻烦。 Oracle 为了简化这个概念，从9i 开始引入了fast_start_mttr_target 这么一 个参数，用于表示数据库发生Instance
Recovery 的时间，以秒为单位。这个 参数我们从字面上也比较好理解，其中的mttr 是mean time to recovery 的简 写，如上例中的情况我们可以将fast_start_mttr_target 设置为600。注意当 设置了fast_start_mttr_target 后,fast_start_io_target 这个参数将不再生 效，从9i 后fast_start_io_target 这个参数被Oracle 废除了。  log_checkpoint_timeout  该参数用于表示检查点位置和重做日志文件末尾之间的时间间隔，以秒为
单位，默认情况下是1800 秒。相比fast_start_mttr_target，它也是时间， 但它的时间值表示完成恢复操作所需要的时间，即从最后的检查点位置开始， 应用所有日志直到日志末尾所需要的时间。而本参数log_checkpoint_timeout 表示从最后的检查点位置开始,到日志末尾经过的时间。  log_checkpoint_interval  该参数是表示检查点位置和重做日志末尾的重做日志块的数量，以OS 块表 示。  除了以上4 个初始化参数外，Oracle 内部事实上还将重做日志文件末尾前
面90%的位置设为检查点位置。在每个重做日志中，这么几个参数指定的位置 可能不尽相同，Oracle 将离日志文件末尾最近的那个位置确认为检查点位置。  在Oracle 9i 后,对检查点频率,建议只设置fast_start_mttr_target。根 据需要,也可以通过设置log_checkpoint_timeout,设置一个脏块保持脏状态的 最大时间，而其他两个参数fast_start_io_target,log_checkpoint_interval 建议不再使用。