增量检查点

  首先本文不会作过多的概念描述，对于增量检查点机制，其实在任何关系型数据库里都会存在。从事务的持久性角度来看，他的目的也是显而易见的，即保证数据块的正常刷新以及崩溃恢复，那么检查点其实也就是对数据块刷新情况的一个位点记录，至于通过什么形式记录，不同的数据库各有差异。因此，要想实现日志预写协议，检查点机制是必不可少的。

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机制拙见