OracleDBWnCKPTLGWR进程之间的合作-mysql教程

DBWn：数据库块写入器（Database Block Writer）负责将脏块写入磁盘的后台进程。 CKPT：检查点进程（Checkpoint Process）只是更

DBWn：数据库块写入器（Database Block Writer）负责将脏块写入磁盘的后台进程。

CKPT：检查点进程（Checkpoint Process）只是更新数据文件的文件首部，以辅助建立检查点的进程（DBWn）。

LGWR：日志写入器（Log Writer）负责将SGA中重做日志缓冲区的内容刷新输出到磁盘。

其实这三个进程都是为了更好地完成一件事：安全高效地实现内存数据块写入数据文件，就是将内存中修改的数据反映到硬盘的数据文件上。

将内存数据块写入数据文件实在是一个相当复杂的过程，在这个过程中，首先要保证安全。所谓安全，就是在写的过程中，一旦发生实例崩溃，要有一套完整的机制能够保证用户已经提交的数据不会丢失；其次，在保证安全的基础上，要尽可能地提高效率。众所周知，I/O操作是最昂贵的操作，所以应该尽可能地将脏数据块收集到一定程度以后，再批量写入磁盘中。

直观上最简单的解决方法就是，每当用户提交的时候就将所改变的内存数据块交给DBWn，由其写入数据文件。这样的话，一定能够保证提交的数据不会丢失。但是这种方式效率最为低下，在高并发环境中，一定会引起I/O方面的争用。Oracle当然不会采用这种没有伸缩性的方式。Oracle引入了CKPT和LGWR这两个后台进程，这两个进程与DBWn进程互相合作，提供了既安全又高效的写脏数据块的解决方法。

如何保证安全？

用户进程每次修改内存数据块时，都会在日志缓冲区（log buffer）中构造一个相应的重做条目（redo entry），该重做条目描述了被修改的数据块在修改之前和修改之后的值。而LGWR进程则负责将这些重做条目写入联机日志文件。只要重做条目进入了联机日志文件，那么数据的安全就有保障了，否则这些数据都是有安全隐患的。LGWR是一个必须和前台用户进程通信的进程。LGWR 承担了维护系统数据完整性的任务，它保证了数据在任何情况下都不会丢失。

假如DBWR在写脏数据块的过程中，突然发生实例崩溃时，该怎么办？我们已经知道，用户提交时，Oracle是不一定会把提交的数据块写入数据文件的。那么实例崩溃时，必然会有一些已经提交但是还没有被写入数据文件的内存数据块丢失了。当实例再次启动时，Oracle需要利用日志文件中记录的重做条目在buffer cache中重新构造出被丢失的数据块，从而完成前滚和回滚的工作，并将丢失的数据块找回来。于是这里就存在一个问题，就是Oracle在日志文件中找重做条目时，到底应该找哪些重做条目？换句话说，应该在日志文件中从哪个起点开始往后应用重做条目？注意，这里所指的日志文件可能不止一个日志文件。

这个起点意义重大，在日志文件中位于这个起点之前的重做条目所对应的在buffer cache中的脏数据块已经被写入了数据文件，从而在实例崩溃以后的恢复中不需要去考虑。而这个起点以后的重做条目所对应的脏数据块实际还没有被写入数据文件，如果在实例崩溃以后的恢复中，需要从这个起点开始往后，依次取出日志文件中的重做条目进行恢复。考虑到目前的内存容量越来越大，buffer cache也越来越大，buffer cache中包含几百万个内存数据块也是很正常的现象的前提下，如何才能最有效的来定位这个起点呢？

为了能够确定这个最佳的起点，Oracle引入了名为CKPT的后台进程，通常也叫作检查点进程（checkpoint process）。这个进程与DBWn共同合作，从而确定这个起点。同时，这个起点也有一个专门的名字，叫做检查点位置（checkpoint position，该检查点位置记录在控制文件里）。Oracle为了在检查点的算法上更加的具有可扩展性（也就是为了能够在巨大的buffer cache下依然有效工作），引入了检查点队列（checkpoint queue），该队列上串起来的都是脏数据块所对应的buffer header。而每次DBWn写脏数据块时，也是从检查点队列上扫描脏数据块，并将这些脏数据块实际写入数据文件的。当写完以后，DBWn会将这些已经写入数据文件的脏数据块从检查点队列上摘下来。这样即便是在巨大的buffer cache下工作，CKPT也能够快速的确定哪些脏数据块已经被写入了数据文件，而哪些还没有写入数据文件，显然，只要在检查点队列上的数据块都是还没有写入数据文件的脏数据块。同时为了能够尽量减少实例崩溃后恢复的时间，Oracle还引入了增量检查点（incremental checkpoint），从而增加了检查点启动的次数。如果每次检查点启动的间隔时间过长的话，再加上内存很大，可能会使得恢复的时间过长。因为前一次检查点启动以后，标识出了这个起点。然后在第二次检查点启动之前，DBWn可能已经将很多脏数据块已经写入了数据文件，而假如在第二次检查点启动之前发生实例崩溃，导致在日志文件中，所标识的起点仍然是上一次检查点启动时所标识的，导致Oracle不知道这个起点以后的很多重做条目所对应的脏数据块实际上已经写入了数据文件，从而使得Oracle在实例恢复时重复地处理一遍，效率低下，浪费时间。

上面说到了有关CKPT的两个重要的概念：检查点队列（包括文件队列）和增量检查点。检查点队列上的buffer header是按照数据块第一次被修改的时间的先后顺序来排列的。越早修改的数据块的buffer header排在越前面，同时如果一个数据块被修改了多次的话，在该链表上也只出现一次。而且，检查点队列上的buffer header还记录了脏数据块在第一次被修改时，所对应的重做条目在重做日志文件中的地址，，也就是LRBA（Low Redo Block Address），Low表示第一次修改时对应的RBA。每个检查点都会由checkpoint queue latch来保护。

上面所描述的概念，用一句话来概括，其实就是DBWn负责写检查点队列上的脏数据块，而CKPT负责记录当前检查点队列的第一个数据块所对应的的重做条目在日志文件中的地址。而到底应该写哪些脏数据块，写多少脏数据块，则要到检查点队列上才能确定的。