[2018年必威体育精装版整理]07-内存组件与Oracle进程.ppt

安全高效的写脏数据块的解决方案 CKPT、LGWR、DBWR进程互相之间合作，实现上面的解决方案 LGWR 用户进程修改内存数据块、在日志缓冲区中都会构造一个相应的重做条目（被修改的数据块在修改之前的值和修改之后的值） LGWR负责将这些条目写入到联机重做日志文件中，一旦写入到了联机重做日志文件中以后，数据就是安全的 LGWR负责维护系统完整性的任务、保证数据不会丢失 实例突然崩溃、怎么办？ Oracle是不一定会把提交的数据块写入数据文件的 实例崩溃以后，必然会有一些已经提交但是还没有写入数据文件的内存数据块丢失 实例启动以后，Oracle利用日志文件中记录的重做条目来在buffer cache中重新构造这些内存块，然后完成前滚和回滚 日志文件有多个、里面的条目更是很多 我们需要从哪个起点来开始往后应用重做条目呢？ 为了预防实例崩溃，Oracle需要不断的定位这个起点 为什么需要定位起点？ 1、这个起点不能太靠近日志文件的头部、太靠近日志文件的头部意味着要处理很多的重做条目 2、不能太靠近日志文件的尾部（实时的尾部），太靠近日志文件的尾部意味着有很少的脏数据块需要写入到数据文件中，说明大量的脏数据块已经写入到了数据文件中，也就说明DBWR进程在此前频繁的写数据文件，显然这样造成的后果就是IO频繁，数据库性能低下 起点的意义 1、实例崩溃以后的重做条目如下 A B C 我们可以选择在A点，也可以选择在B点，也可以选择在C点 选择A、B、C作为起点，进行实例崩溃恢复都可以 如果选择A作为起点，那么说明起点A以前的重做条目对应的数据块的改变已经写入到数据文件中，我们只需要使用A以后的条目重新构建buffer cache 同样对于B和C来说，都可以 但是A可能太远、C可能太近，B相对好一些，Oracle是如何来处理的呢？ Oracle为了更好的定位起点（起点以前的不进行重做、起点以后的进行重做），引入了检查点的概念（一个进程叫做CKPT） 这是一个后台进程 检查点发生的时候，DBWR会将所有的脏数据块写入到数据文件中，检查点周期性的执行，我们就可以使用检查点作为起点。实例恢复的时候，寻找最后一个检查点的位置，作为起点进行恢复。 相关概念 1、buffer cache可能非常的大，因此寻找脏数据块可能耗费时间较长 因此引入了检查点队列的概念 检查点队列上串起来的都是脏数据块的buffer header Oracle寻找脏数据块的时候，使用的是是检查点队列 脏数据块写入到数据文件以后，就会从检查点队列上摘除下来 这样在非常大的buffe cache下面，CKPT能够非常快速的定位脏数据库块 文件队列（每个文件上一个检查点队列） 文件队列上也是挂接着脏数据块的buffer header，不过所有的脏数据块都来自这个文件 增量检查点 增加了检查点启动的次数 如果buffer cache很大，而且检查点时间比较长，那么实例恢复的时候速度就很慢。 DBWR触发的条件中不仅仅是CKPT，在两个检查点之间，DBWR可能已经触发过 DBWR执行 检查点 按时间应该发生检查点 崩溃 1、从上一个检查点开始恢复 2、显然上一个检查点和DBWR之间的改变已经写入到了数据文件中，再次执行恢复的意义就是重复，造成效率低下 （CKPT做的事情中包括：启动DBWR、将起点记录到控制文件中） Oracle启用了增量检查点 检查点队列和增量检查点 检查点队列上的buffer cache是按照数据块第一次被修改的时间的先后顺序来排序的。越早修改的数据块的buffer cache排在越前面，数据块如果被修改了多次，在该链表上也只出现一次，而且检查点队列上的buffer header还记录了脏数据块在第一次被修改时，所对应的重做条目在重做日志中的地址，叫做LRBA（low redo block address） 检查点队列 重做日志条目 最早被修改的数据块第一次被修改时所对应的日志条目在重做日志中的地址 最早的脏数据块被修改时所对应的日志条目 因为日志条目是顺序写的，因此后面的所有的脏数据块对应的日志条目一定在 后面 之前的所有日志条目对应的数据块一定已经写入到数据文件中了，之后的日志条目对应的数据块一定没有写入到数据文件中，这就是一个分界 这条 这个地址信息就存储在控制文件中，这也就是检查点信息，检查点信息就就是崩溃恢复的起点 完全检查点和增量检查点 1、完全检查点 标识出buffer cache中所有的脏数据块 以最高优先级启动DBWR进程将这些脏数据块写入数据文件 触发条件（8i以后） 1、alter system checkpoint 2、除了shutdown abort以外的正常关闭数据库 8i以前 日志切换的时候，也