增量检查点
首先本文不会作过多的概念描述，对于增量检查点机制，其实在任何关系型数据库里都会存在。从事务的持久性角度来看，他的目的也是显而易见的，即保证数据块的正常刷新以及崩溃恢复，那么检查点其实也就是对数据块刷新情况的一个位点记录，至于通过什么形式记录，不同的数据库各有差异。因此，要想实现日志预写协议，检查点机制是必不可少的。
dump控制文件
oracle里的增量检查点是由ckpt进程维护在控制文件里的，这里我们借助trace从控制文件头部找到相关信息。
SQL> alter session set events 'immediate trace name controlf level 2';
Session altered.接下来查看trace文件，
向下寻找出本次dump结果里的checkpoint信息，如下，
***************************************************************************
CHECKPOINT PROGRESS RECORDS
***************************************************************************
(size = 8180, compat size = 8180, section max = 11, section in-use = 0,
last-recid= 0, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 2, numrecs = 11)
THREAD #1 - status:0x2 flags:0x0 dirty:43
low cache rba:(0x211.43f.0) on disk rba:(0x211.540.0)
on disk scn: 0x0000.0073a315 08/14/2015 20:31:34
resetlogs scn: 0x0000.001a002c 08/04/2015 16:38:12
heartbeat: 887720057 mount id: 2580966972那么，这里注意几个关键信息.。
low cache rba 最早的脏块对应的日志地址
on disk rba redolog中最后一条日志所在的地址
on disk scn LGWR每写完日志，会更新这个值
heartbeat 控制文件每被修改一次，heartbeat增加一次我们不难发现，low cache rba与on disk rba之间的日志对应当前数据库中已提交的脏块。而checkpoint主要的功能，也是维护这两个地址。如果此时发生断电，这里就是进行崩溃恢复的依据。
从脏块查看LRBA
SQL> alter system dump datafile 1 block 178440;
System altered.该操作会dump出磁盘中的数据块、对应的dirty buffer及CR块。
接下来查看刚生成的dump文件，
[oracle@oracle11g trace]$ pwd
/u01/app/oracle/diag/rdbms/oracle11g/oracle11g/trace
[oracle@oracle11g trace]$ vim oracle11g_ora_2564.trc
这里需要关注的关键信息如下，
rdba: 数据块地址
ST: CR/XCURRENT（CR块/当前块）
current块lru： LRUW链上下指针
ckptq: 检查点队列上下成员指针
LRBA: 这个脏块第一次被修改时的redo日志地址。为空值表示对应日志还未写入磁盘
LSCN、HSCN: 构造这个脏块所需日志的SCN。为空值表示对应日志还未写入磁盘
cr：[scn：] 构造CR块的SCN号
xid、uba: 构造CR块时读取的undo数据的xid及undo数据块地址 那么这里，我们看到的是同一个block在buffer中的两种状态，即CR块和XCURRENT块，对于CR块记录的是事务号以及undo块的地址，对于XCURRENT块记录的则是redo日志相关的信息。需要注意的一点是，dirty buffer里的lrba与控制文件中lrba的意义是不一样的，dirty buffer中的记录只会关心与此buffer相关的redo log，而控制文件中的lrba是针对整个buffer cache中的dirty buffer。
另外，这里还有一个信息，就是ckptq（检查点队列），检查点队列由ckpt进程去维护。dbwr进程沿着此队列进行刷新工作，ckpt进程检查此队列完成向控制文件中的检查点信息维护。
除buffer之外，trace文件中的block信息如下，
rdba: 数据块的地址
scn: 最近写入磁盘的SCN号对于DBWR，每次刷新脏块后，会去维护这个block的SCN号，代表这个block的数据版本。
比对事务槽信息
对于前面dump出来的CR块信息，可以通过查看事务槽的信息来做比对验证。
这里我们所关注的uba地址以及xid完全吻合。
ps，关于undo机制以及事务槽的分析，可参考博文：Oracle undo机制拙见
