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