checkpoint

什么是检查点：

简单地讲，检查点（checkpoint）是一个事件，不定期地在满足一定条件后，由CKPT进程发出，由DBWn进程将 Data buffer cache中的已修改的数据写入到磁盘中。内存中的数据越少，我们需要进行实例恢复时所需要的时间也就越短。缩短实例恢复的时间是检查点存在的一个主要目的，这是提到检查点时，你首先应该想到的，然后再去思考它为什么能缩短恢复时间（下面的工作原理将会讲述）。而不是只知道它用来向磁盘刷新数据，数据被刷新到磁盘不一定需要检查点，还有很多触发条件会使内存中的数据不经检查点而直接刷新到磁盘。

检查点分类：

完全检查点（normal checkpoint）

增量检查点（increment checkpoint）

检查点的工作原理

1.      在说明检查点的工作原理之前，首先需要理解一些即将会涉及到的术语。

RBA(redo byte address)，即重做日志块的地址，通过这个地址来定位恢复时需要利用的重做日志块，RBA是一串地址数字，由三部分组成：

日志文件序列号

日志文件块编号

重做日志记录在日志块中的起始偏移字节数

通常使用的RBA有三种形式：

LRBA: 数据缓存（buffer cache）最后一个完成的检查点对应的ＲＢＡ就称为LRBA。

HRBA: 数据缓存（buffer cache）中一个脏块最近一次被更新的时候产生的重做日志记录在重做日志文件中所对应的位置就称为HRBA。

checkpoint RBA：当一个checkpoint事件发生的时候，checkpoint进程会记录下当时所写的重做日志块的地址即RBA，此时记录的RBA被称为checkpoint RBA。从上一个checkpoint RBA到当前的checkpoint RBA之间的日志所保护的buffer cache中的脏块接下来将会被写入到数据文件当中去

比如说，用户发出了一条Update命令来更新了缓存中的块A，块A现在变成了脏块，同时 oracle会为A上的update操作生成一条重做记录，这条重做记录在redo log中的位置就是RBA.然后块A就等待着被刷新到磁盘中，此时块A还没有被刷到磁盘，但用户又发出了一条更新A块的命令，这又会生成一条重做记录，对应一个RBA。则第一条update命令对应的重做记录的RBA称为块A的lrba（low rba），第二条更新命令对应的rba，被称为hrba(high rba).

Checkpoint queue:Oracle将缓存中被修改的脏块按照lrba的顺序组成一个队列，这条队列记录了缓存中块第一次被修改的先后顺序。在检查点时，DBWn进程按照这条队列将脏块写入到磁盘上的数据文件中，这样也保证了最先修改的块先被写入到磁盘中。队列的引入是为了支持增量检查点的。

完全检查点的工作过程：

2 .完全检查点

一个完全checkpoint可以分三个阶段：

第一阶段，checkpoint进程开始一个checkpoint事件，并记录下checkpoint RBA，这个通常是当前的RBA。

第二阶段，checkpoint进程通知DBWn进程将所有checkpoint RBA之前的buffer cache里面的脏块写入磁盘。

第三阶段， 确定脏块都被写入磁盘以后进入， checkpoint进程将checkpoint信息（SCN）写入/更新数据文件和控制文件中。SCN为发出检查点命令时对应的SCN。

完全检查点的触发条件：

日志切换，通过alter system switch logfile

发出checkpoint命令，通过alter system checkpoint

Shutdown immediate命令发出

运行alter tablespace read only时

对数据文件进行热备时，针对该数据文件的checkpoint也会进行，通过alter tablespace tbs begin backup

3.  增量检查点：

特别注意，增量检查点和完全检查点是存在不同之处的，上面的两点讨论的是完全检查点，下面将讲述增量检查点的工作过程。

因为每次的完全检查点都会将buffer cache中的脏块完全刷新到磁盘，这样会产生一个很大的I/O消耗，频繁的完全检查点操作对系统性能有很大的影响，为此oracle引入增量检查点的概念。前面我们提到检查点队列的概念。有了检查点队列之后,脏块按照首次变脏的时间顺序排列,DBWR每到一定的时机,就会被触发,沿着检查点队列的顺序刷新脏块,具体在oracle中有几个参数用来确定检查点队列的长度.另有一个CKPT进程,会监控着检查点队列的长度,当检查点队列的长度达到一定限制时,CKPT会通知DBWR写脏块.CKPT会根据参数的设置和I/O的速度以及繁忙程度,计算出来一个Target rba(目标rba),DBWR会沿着检查点队列,将所有Target rba之前的脏块刷新到磁盘.当CKPT通知完DBWR Target rba后,CKPT的任务就结束了.他并不会等待DBWR写完所有的Target rba之前的脏块.通知DBWR写脏块,这是CKPT的任务之一,CKPT另有一个任务,就是每3秒,检测一次DBWR的写进度.检查点队列最前面的块被称为检查点位置.DBWR是沿着检查点队列写脏块的,CKPT每3秒钟查看一下DBWR沿检查点队列写到了哪里,并且将这个位置设置为检查点位置.也就是说检查点位置之前的块,都是已被DBWR刷新到磁盘上的块.这个3秒一次检查DBWR进度的工作,也是CKPT的一个重要的任务.CKPT每3秒一次将检查点位置记录进控制文件,当然同时被记录进控制文件的还有'心跳'等其他信息.CKPT每3秒一次的工作和CKPT定期触发DBWR,这两项操作合一起被称为--增量检查点.

   这里所谓的ckpt的每3秒写，并不是必须的，必须在增量检查点期间的每3秒写，而不是总是不停的每3秒写一次。

   检查点位置是是个rba,他指向着重做日志文件中的某个重做记录.在此位置前的重做记录,其对应的信息已经被写进了数据文件,在此位置后的重做记录,所对应的是数据块,有可能还在内存中.如果发生了实例崩溃,只需要在日志文件中找到检查点位      置,从此处开始应用所有的重做日志文件,就完成了前滚操作.实例崩溃后,再次启动数据库,oracle会到控制文件中读取low cache rba,这就是检查点位置.从此处开始应用重做信息,应用到on disk rba处.on disk rba是磁盘中重做日志文件的最后一条重做记录的rba.  如果某条命令的重做记录的rba高于on disk rba，那说明此重做记录还没有被写进日志文件中，崩溃发生时，他是不可能被恢复的.on disk rba是oracle前滚操作的终点.on disk 顾名思义 就是'在磁盘上'的意思.比这个更高      的rba,都在log buffer中,还没有来的急被写进磁盘中的日志文件.所以是不能被用于恢复的。

low cache rba就是CKPT记录的DBWR写的进度。

on disk rba就是LGWR的写进度

4 . 增量检查点与完全检查点的不同

完全checkpoint会将checkpoint的信息写入到控制文件以及数据文件头中

增量checkpoint只会将RBA信息写入到控制文件中。

 

5.   查看一下系统的CHECKPOINT动作

         SCN，system change number,系统变更号，塔提供oracle数据库的内部时钟机制，定义数据库在某个确切的时间提交的版本，用于维护数据库的一致性。

    在控制文件中为每一个数据文件保存着一个checkpoint scn和一个stop scn.checkpoint scn是一个完全检查点对应的snc，stop scn只有针对数据文件有stop scn这个概念，但是它在控制文件中存放着（具体作用后面讲述）。可以通过：

  Selectname,checkpoint_change#,last_change#from v$datafile;

  Select checkpoint_change# from v$database；  

 

   同时在数据文件头还存储着checkpoint scn，可以查看：

  Select name,checkpoint_change# from v$datafile_header;

 

   当一个完全检查点完成后，（注意，我这里说的是完全检查点，而不是增量检查点，增量检查点并不会做这样更新操作，下面会验证）oracle会更新控制文件中的checkpoint scn，以及数据文件头中的checkpoint scn。

   当数据库正常shutdown（immediate,transcational,normal）,执行完全检查点，更新存储在控制文件中的数据文件的stop scn，此值等于数据文件头中的checkpoint scn。

   这样做的目的是什么呢？

 

Checkpoint cnt用于保证在正常操作中使用的数据文件是当前版本

在恢复时防止恢复数据文件的错误版本.Checkpoint cnt是一直递增的,即使表空间处于热备份模式.

由于表空间的创建时间不尽相同,所以不同表空间/数据文件的Checkpoint cnt通常是不同的.

我们知道:

在数据库open的过程中,Oracle要进行两次检查.

第一次检查数据文件头中的Checkpoint cnt是否与对应控制文件中的Checkpoint cnt一致.

如果相等,进行第二次检查.

第二次检查数据文件头的开始SCN和对应控制文件中的结束SCN是否一致

如果结束SCN等于开始SCN,则不需要对那个文件进行恢复.

2.      如果abort数据库，则不会执行完全检查点，存储在控制文件中的数据文件的stop scn仍为无穷大；下次启动数据库做两次检查时，如果第1次相等，再进行第2次比较时，数据文件头的checkpoint scn一定小于stop scn，则需要进行实例的恢复，进行相应的前滚和回滚

3.       如果用备份代替了数据文件在启动数据库，做第一次比较时，数据文件头的 Checkpoint cnt 一定小于控制文件中的数据库文件的 Checkpoint cnt ;或者用备份的控制文件代替了控制文件再启动数据库，这时数据文件头的 Checkpoint cnt 一定大于存储在控制文件中的数据文件的 Checkpoint cnt ；只要比较不相等，就需要进行介质恢复。