磁盘块在buffer中对应的buffers被修改后称为脏块,修改为脏块时不同步写入数据文件,而同步写到log buffer。
当buffer里有太多脏块时或其他原因,会有多种方式触发DBWR把脏块写到数据文件,腾出buffer空间,每种方式可能按不同的优先顺序写脏块,也就是按不同的链来写,其中一种是按lrba的顺序写。
先静态的解释一些名词,再讨论增量检查点的过程。
RBA(redo buffer address)脏块指向的redo buffer内存物理地址,lrba是指buffers第一次被修改时的rba,也就是这个buffers成为脏块时的rba,以后再脏多少次,他成为脏块的时候间不变,即lrba不会变。脏块最近一次被脏的rba称为hrba,两个rba之间的rba没有特定名称,他们这个脏块被事务修改的全部重做日志记录。所有脏块都有lrba和hrba,如果只脏过一次,两个rba相同。
CKPTQ。将所有脏块的lrba链起来就是CKPTQ检查点队列。(不知道buffer真的有这个队列的独立物理结构,还是所有脏块lrba信息在逻辑上向下指,在概念上形成CKPTQ。)
CKPT有多种词性,指一个动作,如进行CKPT,这次检查点;指一个进程,如CKPT进程;指逻辑上的一个时间点,检查点位置。
LRBA。每个脏块里有个LRBA信息,控制文件中也有个LRBA,准确的讲叫 low cache rba,他是ckpt进程从某一个脏块里读取过来的。
On disk RBA。先记着他指向log file里最新的(最后的)一条重做日志条目,他也是ckpt进程从某一个脏块里读取过来的。
增量检查点工作过程,和在实例恢复中的作用
只是串行化的图出重做日志条目,不必区分这些条目是否是current logfile。
一个脏块对应一个事务,但不一定对应一个重做日志条目,因为脏块脏一次产生一条重做日志条目。
1.CKPT进程发现CKPTQ太长(多长算长,oracle里有些参数可以控制),打算通知DBWR让他刷出一些脏块,缩短CKPTQ,从low cache rba到traget rba的位置,traget rba是CKPT根据CKPTQ长度和系统I/0繁忙程序计算出来的值。通知后立即返回,不等DBWR写完,即异步通知。
2.由于写前协议,DBWR写脏块前都通知LGWR先把脏块写到重做日志文件。
3.DBWR按照CKPTQ从上到下的顺序将脏块写入数据文件(图中从上到下是时间上越来越新)。
如果是完全检查点,DBWR按照dirty list写此时的checkpoint SCN之前的脏数据
4.在DBWR写的过程中,CKPT会每隔3秒来检查一次DBWR的写进度,并把进度信息(就是哪一个脏块)写到控制文件中,叫做low cache rba,这每隔3秒一次的动作叫心跳,他与low cache rba配套,比如从控制文件中dump出这样的信息,表示第793694908次检查DBWR时,他写到0x5.15119.0这个位置。
low cache rba:(0x5.15119.0) on disk rba:(0x5.15314.0)
on disk scn: 0x0000.0008ea68 10/20/2012 17:15:34
resetlogs scn: 0x0000.0006ce7b 03/30/2012 11:15:03
heartbeat: 793694908 mount id: 1363550103
可以这样说,DBWR缩短了CKPTQ的长度,low cache rba是CKPT记录的DBWR的写进度。
每隔3秒具体写的什么
为了减少频繁增量检查点的性能影响,CKPT进行的是轻量级更新,他并不会改写控制文件中数据文件的检查点信息,以及数据文件头信息,而只是在控制文件中记录这个检查点的SCN(Controlfile Checkpointed at scn),以及DBWR此时写到的脏块的RBA信息。
5. 估计on disk rba是LGWR写日志文件时值到控制文件中的。
6.当他写完时(target rba的位置),target rba 和low cache rba相同,并把这一次检查点的lrba记录到控制文件中
7.控制文件中的 low cache rba指向的重做日志位置一定在on disk rba的下面(图中是从下往上写,越上面越新)。如果在他上面,就会出现脏块写入了数据文件而没写入重做日志文件,
这两个rba之间的所有重做日志条目就是恢复时需要恢复的条目,称为前滚。
8。提交过的事务,他的log buffer一定在log file里,但log file里也有没提交过的条目。这一脏块没有提交,他被写入了数据文件和重做日志文件,恢复时他也被恢复到buffer里,通过undo回滚可以去除这没提交的数据,这不在讨论范围内。
原博:http://blog.sina.com.cn/s/blog_a71c258a01019ru1.html