检查点问题

 

oracle8以后Oracle推出了incremental checkpoint的机制，在以前的版本里每次常规checkpoint时都会做一个full thread checkpoint,这样的话所有脏数据会被写到磁盘，巨大的i/o对系统性能带来很大影响。为了解决这个问题，oracle引入了checkpoint queue机制，每一个脏块会被移到检查点队列里面去，按照low rdb（第一次对此块修改对应的redo block address）来排列，靠近检查点队列尾端的数据块的low rba值是最小的，而且如果这些赃块被再次修改后它在检查点队列里的顺序也不会改变，这样就保证了越早修改的块越早写入磁盘。每隔3秒钟ckpt会去更新控制文件中的checkpoint progress recored区域，记录checkpoint执行的情况。

注意：增量检查点并不去更新数据文件头，只是在控制文件中记录了checkpoint progress record这个区域，记下low rba,on-disk rba等信息。这些信息就可以用来快速恢复。

每隔3秒钟ckpt会去更新控制文件中的checkpoint progress recored区域，记录checkpoint执行的情况。

解疑:这里应该是只更新控制文件，每3秒不是更新数据文件头，而是在控制文件中记录checkpoint的执行情况，基于增量检查点和checkpoint  queue的原理，在发生检查点的时候，ckpt 进程每次只是告诉dbwr，写dirty  buffe要一直写到最新这个位置(发生检查点：也就是alter system checkpoint)，这样做呢，仅仅是告诉dbwr一个checkpoint queue中的结束点，ckpt绝对不会等到dbwr写完所有脏数据在更新控制文件和数据文件头，而是每3秒钟，在控制文件中的checkpoint progress recored区域中报告一下dbwr最新写入的位置(也就是dbwr的写状态的scn)。这样使得，比如数据库要做恢复的时候（instance  recovery）可以从这个最新报告的scn位置开始做恢复，而不是从数据文件中的checkpoint  scn开始做恢复，这样将缩短恢复时间，尤其是instance  crash的情况下启动更快。另外要注意的是，检查点发生的时候，ckpt 去更新数据文件头和控制文件，并不是把当前检查点发生时候的scn 更新进去，而是把上一次dbwr写入已经完成的检查点发生时候的  scn 更新进去，也就是说，更新控制文件和数据文件头是滞后于检查点的发生的，这个从恢复的原理也很容易理解，因为检查点发生的时候dirty buffer还没有写入，自然不能立即更新成当前的scn了。