简述oracle 检查点队列,OCP知识点讲解之检查点队列与增量检查点

5268f80b9b1e01f982625ef6fac83ca1.png

检查点的主要目的是以对数据库的日常操作影响最小的方式刷新脏块。脏块不断的产生,如何将脏块刷新到磁盘中去呢?在8i之前,Oracle定期的锁住所有的修改操作,刷

302a05a00e9d8b8984a2480007e21c3b.png

如上图,检查点队列中的每一节点,都指向一个脏块。检查点队列每个节点中的信息其实非常少,就是记录对应块在Buffer cache中的地址,脏块对应的重做记录在日志文件中的位置,另外还有前一个节点、后一个节点的地址。检查点队列还有LRU、脏LRU,这些都是双向链表。双向链表就是在节点中记录前、后两个节点的地址。

检查点队列头部的块是最早变脏的,因此,Oracle会定期唤醒DBWn从检查点队列头开始,沿着检查点队列的顺序,刷新脏块。在刷新脏块的同时,仍可以不断的有新的脏块被链接到检查点队列的尾部。这个定期唤醒DBWn刷新脏块的操作,Oracle就称为增量检查点。

d3f588f3add1a8c632b21ea23fd4bcc1.png

如上图,1、2、3号节点所指向的脏块已经被刷新为干净块。同时,又有两个块变脏,它们被链接到了检查点队列的末尾,它们是9号、10号节点。

检查点队列的头,又被称为检查点位置,Checkpoint postion,这些名称我们不必从字面上去理解。总之,检查点位置就是检查点队列头。检查点队列头节点(也就是检查点位置)的信息,Oracle会频繁的将它记录到控制文件中,而且会很频繁的记录。一般是每隔三秒,有一个专门的进程CKPT,会将检查点位置记录进控制文件。

9aa050dbcfb474676dbb15f080e3007e.png

如上图,当前的检查点位置是检查点队列的1号节点。又一个三秒到了,CKPT进程启动,将新的检查点位置记入控制文件:

a1f40a439a9d4f3644ac7f3e3fa4e506.png

新的检查点位置是4号节点,它对应当前变脏时间最早的脏块。1、2、3号节点已经从检查点队列中摘除了。因为它们对应的脏块已经不脏了。一般来说,控制文件中的检查点位置之后的块都是脏块。但是有时也例外,因检查点位置每三秒才会更新一次,就像上图,1、2、3号节点对应的脏块已经被刷新过了,但是由于三秒间隔没到,检查点位置还是指向1号节点。只有当三秒到后,检查点位置才会被更新到4号节点上。

关于检查点队列、检查点位置我们先说到这里,在全面的介绍什么是增量检查点之前,我们先说一下检查点队列的一个重要作用。

让我们先来总结一下用户修改块时,Oracle内部都发生了什么:

1.如果块不在Buffer cache,将块读入Buffer cache

2.先生成重做记录,并记入日志缓存,在用户提交时写到日志文件中

3.在Buffer cache中修改块

4.在Buffer cache中设置块的脏标志位,标志块变成脏块,同时在检查点队列末尾增加一个新节点,记录这个新脏块的信息,信息包括:脏块在Buffer cache中的位置,在步骤2时生成的与此脏块对应的重做记录位置。

5.用户提交后,将相应的重做记录从重做缓存写入日志文件。

我现在将日志补充到上面的图中:

0c72f70c3d25200c37daf80f327fdd5c.png

就像上图,检查点队列的每个节点,都保存有脏块的地址和脏块对应的重做记录的编号。脏块在Buffer cache中的位置是随机的,用户不一定修改那个块。但重做记录是顺序生成的,就和检查点队列的排列顺序一样。因为,它们都是当块被修改而变脏时产生的。块A先被修改,块A的重做记录就排在前面,块B后被修改,块B对应的重做记录会被排在块A对应的重做记录的后面。和它们在检查点中的顺序是一样。每当数据库因异外而当机,比如异常死机、断电等等,Buffer cache中有许多脏块没来的及写到磁盘上。以图为例,比如说现在断电了,现在磁盘上还有7个脏块,它们里面有用户修改过的数据,Oracle已经将反馈信息“你的修改完成”发送给用户,用户也以为他们的修改完成了,将为一直保存到数据库中。但是,断然的断电,令这几个脏块中的数据丢失了,它们没来得及写到磁盘上。

Oracle如何解决这个问题呢?很简单,当数据库重新启动时,Oracle只需从控制文件中读出检查点位置,检查点位置中记录有重做记录编号,香港虚拟主机,根据此编号,Oracle可以很快的定位到日志文件中的重做记录n,它读出重做记录n中的重做数据,将用户的修改操作重现到数据库。接着,Oracle读取重做记录n+1中的重做数据,重现用户修改,这个过程将沿着日志流的顺序,一直进行下去,直挡最后一条重做记录,在上图的例子中,最后一条重做记录是第n+6条。这个过程完成后,用户所有的修改又都被重现了,一点都不会丢失。只要你的日志文件是完整,日志流是完整的,就一点信息都不会丢失。

有人可能会有一个问题,重做记录在生成后,也是先被送进重做缓存,再由重做缓存写往日志文件。这样的机制下,一定会有某些重做记录在没来的及写到日志文件中时,数据库突然当机,而造成这些重做记录丢失。这样,这些重做记录所对应的脏块,将得不到恢复。用户还是会丢失一些数据。

1428d0e076c3959ab11d28a39bc84fab.png

5268f80b9b1e01f982625ef6fac83ca1.png

本条技术文章来源于互联网,如果无意侵犯您的权益请点击此处反馈版权投诉

本文系统来源:php中文网

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值