随着内存的不断增加，1个DBWR进程可能不够用了。所以从8i起，我们可以为系统配置多个DBWR进程。初始化参数：db_writer_processe决定了启动多少个DBWR进程。每个DBWR进程都会分配一个lru latch，也就是说每个DBWR进程对应一个working set。
因此oracle建议配置的DBWR进程的数量应该等于lru latch的数量，同时应该小于CPU的数量。系统启动时，就确定好了working set与DBWR进程的对应关系，每个DBWR进程只会将分配给自己的working set上的脏数据块写入数据文件。DBWR作为一个后台进程，只有在某些条件满足了才会触发。这些条件包括：
1) 当进程在辅助LRU链表和主LRU链表上扫描以查找可以覆盖的buffer header时，如果已经扫描的buffer header的数量到达一定的限度（由隐藏参数：_db_block_max_scan_pct决定）时，触发DBWR进程。_db_block_max_scan_pct表示已经扫描的buffer header的个数占整个LRU链表上buffer header总数的百分比。这时，搜索可用buffer header的进程挂起，在v$session_wait中表现为等待“free buffer wait”事件，同时增加v$sysstat中的“dirty buffers inspected”的值。
2) 当DBWR在主LRUW链表上查找已经更新完而正在等待被写入数据文件的buffer header时，如果找到的buffer header的数量超过一定限度（由隐藏参数：_db_writer_scan_depth_pct决定）时，DBWR就不再继续往下扫描了，而转到辅助LRUW链表上将其上的脏数据块写入数据文件。_db_writer_scan_depth_pct表示已经扫描的脏数据块的个数占整个主LRUW链表上buffer header总数的百分比。
3) 如果主LRUW链表和辅助LRUW链表上的脏数据块的总数超过一定限度，也将触发DBWR进程。该限度由隐藏参数：_db_large_dirty_queue决定。
4) 发生增量检查点（incremental checkpoint）或完全检查点（complete checkpoint）时触发DBWR。
5) 每隔三秒钟启动一次DBWR。
6) 将表空间设置为离线（offline）状态时触发DBWR。
7) 发出命令：alter tablespace … begin backup，从而将表空间设置为热备份状态时触发DBWR。
8) 将表空间设置为只读状态时，触发DBWR。
9) 删除对象时（比如删除某个表）会触发DBWR。
当DBWR要写脏数据块时，并不是说立即将所有的脏数据块都同时写入磁盘。为了尽量减少物理的
I/O的次数，DBWR会将要写的脏数据块所对应的buffer header拷贝到一个名为批量写（write batch）的结构中。每个working set所对应的DBWR进程都可以向该结构里拷贝buffer header。当write batch的buffer header的个数达到一定限额时，才会发生实际的I/O，从而将脏数据块写入磁盘。这个限额为硬件平台所能支持的同时并发的异步I/O的最大数量。8i之前是可以用隐藏参数（_db_block_write_batch）来控制这个限额的。但是8i以后，取消了该参数，而由oracle自己来计算。
3.2.5 DBWR、CKPT、LGWR进程之间的合作
将内存数据块写入数据文件实在是一个相当复杂的过程，在这个过程中，首先要保证安全。所谓安全，就是在写的过程中，一旦发生实例崩溃，要有一套完整的机制能够保证用户已经提交的数据不会丢失；其次，在保证安全的基础上，要尽可能的提高效率。众所周知，I/O操作是最昂贵的操作，所以应该尽可能的将脏数据块收集到一定程度以后，再批量写入磁盘中。
直观上最简单的解决方法就是，每当用户提交的时候就将所改变的内存数据块交给DBWR，由其写入数据文件。这样的话，一定能够保证提交的数据不会丢失。但是这种方式效率最为低下，在高并发环境中，一定会引起I/O方面的争用。oracle当然不会采用这种没有扩展性的方式。oracle引入了CKPT和LGWR这两个后台进程，这两个进程与DBWR进程互相合作，提供了既安全又高效的写脏数据块的解决方法。
用户进程每次修改内存数据块时，都会在日志缓冲区（redo buffer）中构造一个相应的重做条目（redo entry），该重做条目描述了被修改的数据块在修改之前和修改之后的值。而LGWR进程则负责将这些重做条目写入联机日志文件。只要重做条目进入了联机日志文件，那么数据的安全就有保障了，否则这些数据都是有安全隐患的。LGWR 是一个必须和前台用户进程通信的进程。LGWR 承担了维护系统数据完整性的任务，它保证了数据在任何情况下都不会丢失。
LGWR将重做条目写入联机日志文件的情况分两种：后台写（background write）和同步写（sync write）。触发后台写的条件有四个：1）每隔三秒钟，LGWR启动一次；2）在DBWR启动时，如果发现脏数据块所对应的重做条目还没有写入联机日志文件，则DBWR触发LGWR进程并等待LRWR写完以后才会继续；3）重做条目的数量达到整个日志缓冲区的1/3时，触发LGWR；4）重做条目的数量达到1MB时，触发LGWR。而触发同步写的条件就一个：当用户提交（commit）时，触发LGWR。
假如DBWR在写脏数据块的过程中，突然发生实例崩溃。我们已经知道，用户提交时，oracle是不一定会把提交的数据块写入数据文件的。那么实例崩溃时，必然会有一些已经提交但是还没有被写入数据文件的内存数据块丢失了。当实例再次启动时，oracle需要利用日志文件中记录的重做条目在buffer cache中重新构造出被丢失的数据块，从而完成前滚和回滚的工作，并将丢失的数据块找回来。于是这里就存在一个问题，就是oracle在日志文件中找重做条目时，到底应该找哪些重做条目？换句话说，应该在日志文件中从哪个起点开始往后应用重做条目？注意，这里所指的日志文件可能不止一个日志文件。
因为oracle需要随时预防可能的实例崩溃现象，所以oracle在数据库的正常运行过程中，会不断的定位这个起点，以便在不可预期的实例崩溃中能够最有效的保护并恢复数据。同时，这个起点的选择非常有讲究。首先，这个起点不能太靠前，太靠前意味着要处理很多的重做条目，这样会导致实例再次启动时所进行的恢复的时间太长；其次，这个起点也不能太靠后，太靠后说明只有很少的脏数据块没有被写入数据文件，也就是说前面已经有很多脏数据块被写入了数据文件，那也就意味着只有在DBWR启动的很频繁的情况下，才能使得buffer cache中所残留的脏数据块的数量很少。但很明显，DBWR启动的越频繁，那么所占用的写数据文件的I/O就越严重，那么留给其他操作（比如读取buffer cache中不存在的数据块等）的I/O资源就越少。这显然也是不合理的。
从这里也可以看出，这个起点实际上说明了，在日志文件中位于这个起点之前的重做条目所对应的在buffer cache中的脏数据块已经被写入了数据文件，从而在实例崩溃以后的恢复中不需要去考虑。而这个起点以后的重做条目所对应的脏数据块实际还没有被写入数据文件，如果在实例崩溃以后的恢复中，需要从这个起点开始往后，依次取出日志文件中的重做条目进行恢复。考虑到目前的内存容量越来越大，buffer cache也越来越大，buffer cache中包含几百万个内存数据块也是很正常的现象的前提下，如何才能最有效的来定位这个起点呢？
为了能够最佳的确定这个起点，oracle引入了名为CKPT的后台进程，通常也叫作检查点进程（checkpoint process）。这个进程与DBWR共同合作，从而确定这个起点。同时，这个起点也有一个专门的名字，叫做检查点位置（checkpoint position）。
oracle为了在检查点的算法上更加的具有可扩展性（也就是为了能够在巨大的buffer cache下依然有效工作），引入了检查点队列（checkpoint queue），该队列上串起来的都是脏数据块所对应的buffer header。而DBWR每次写脏数据块时，也是从检查点队列上扫描脏数据块，并将这些脏数据块实际写入数据文件的。当写完以后，DBWR会将这些已经写入数据文件的脏数据块从检查点队列上摘下来。这样即便是在巨大的buffer cache下工作，CKPT也能够快速的确定哪些脏数据块已经被写入了数据文件，而哪些还没有写入数据文件，显然，只要在检查点队列上的数据块都是还没有写入数据文件的脏数据块。而且，为了更加有效的处理单实例和多实例（RAC）环境下的表空间的检查点处理，比如将表空间设置为离线状态或者为热备份状态等，oracle还专门引入了文件队列（file queue）。
文件队列的原理与检查点队列是一样的，只不过每个数据文件会有一个文件队列，该数据文件所对应的脏数据块会被串在同一个文件队列上；同时为了能够尽量减少实例崩溃后恢复的时间，oracle还引入了增量检查点（incremental checkpoint），从而增加了检查点启动的次数。如果每次检查点启动的间隔时间过长的话，再加上内存很大，可能会使得恢复的时间过长。因为前一次检查点启动以后，标识出了这个起点。然后在第二次检查点启动的过程中，DBWR可能已经将很多脏数据块已经写入了数据文件，而假如在第二次检查点启动之前发生实例崩溃，导致在日志文件中，所标识的起点仍然是上一次检查点启动时所标识的，导致oracle不知道这个起点以后的很多重做条目所对应的脏数据块实际上已经写入了数据文件，从而使得oracle在实例恢复时再次重复的处理一遍，效率低下，浪费时间。
上面说到了有关CKPT的两个重要的概念：检查点队列（包括文件队列）和增量检查点。检查点队列在我们上面转储出来的buffer header里可以看到，就是类似ckptq: [65abceb4,63bec66c]和fileq: [65abcfbc,63becd10]的结构，记录的同样都是指向前一个buffer header和指向后一个buffer header的指针。这个队列上面挂的也是脏数据块对应的buffer header链表，但是它与LRUW链表不同。检查点队列上的buffer header是按照数据块第一次被修改的时间的先后顺序来排列的。越早修改的数据块的buffer header排在越前面，同时如果一个数据块被修改了多次的话，在该链表上也只出现一次。而且，检查点队列上的buffer header还记录了脏数据块在第一次被修改时，所对应的重做条目在重做日志文件中的地址，也就是RBA（Redo Block Address）。同样在转储出来的buffer header中可以看到类似LRBA: [0xe9.229.0]的结构，这就是RBA，L表示Low，也就是第一次被修改的时候的RBA。但是注意，在检查点队列上的buffer header，并不表示一定会有一个对应的RBA，比如控制文件重做（controlfile redo）就不会有相应的RBA。对于没有对应RBA的buffer header来说，在检查点队列上始终处于最尾端，其优先级永远比有RBA的脏数据块的buffer header要低。8i以前，每个working set都有一个检查点队列以及多个文件队列（因为一个数据文件对应一个文件队列）；而从8i开始，每个working set都有两个检查点队列，每个检查点都会由checkpoint queue latch来保护。
而增量检查点是从8i开始出现的，是相对于8i之前的完全检查点（complete checkpoint）而言的。完全检查点启动时，会标识出buffer cache中所有的脏数据块，然后启动DBWR进程将这些脏数据块写入数据文件。8i之前，日志切换的时候会触发完全检查点。而到了8i及以后，完全检查点只有在两种情况下才会被触发：1）发出命令：alter system checkpoint；2）除了shutdown abort以外的正常关闭数据库。注意，这个时候，日志切换不会触发完全检查点，而是触发增量检查点。8i所引入的增量检查点每隔三秒钟或发生日志切换时启动。它启动时只做一件事情：找出当前检查点队列上的第一个buffer header，并将该buffer header中所记录的LRBA（这个LRBA也就是checkpoint position了）记录到控制文件中去。如果是由日志切换所引起的增量检查点，则还会将checkpoint position记录到每个数据文件头中。也就是说，如果这个时候发生实例崩溃，oracle在下次启动时，就会到控制文件中找到这个checkpoint position作为在日志文件中的起点，然后从这个起点开始向后，依次取出每个重做条目进行处理。
上面所描述的概念，用一句话来概括，其实就是DBWR负责写检查点队列上的脏数据块，而CKPT负责记录当前检查点队列的第一个数据块所对应的的重做条目在日志文件中的地址。从这个意义上说，检查点队列比LRUW还要重要，LRUW主要就是区分出哪些数据块是脏的，不可以被重用的。而到底应该写哪些脏数据块，写多少脏数据块，则还是要到检查点队列上才能确定的。
我们用一个简单的例子来描述这个过程。假设系统中发生了一系列的事务，导致日志文件如下所示：
事务号 数据文件号 block号 行号 列 值 RBA
这时，对应的检查点队列则类似如下图六所示。我们可以看到，T1事务最先发生，所以位于检查点
图六
更多内容请看网络管理实用手册专题，或进入讨论组讨论。
相关专题
- 网络管理实用手册 (22210篇文章)
- Oracle初学者必知的100个问题 (33377次浏览)
- Oracle PL/SQL语言基础 (14253次浏览)
- Oracle架构的基础知识(入门级) (13523次浏览)
- Win 2003 Server重新安装Oracle9i (614次浏览)
- Oracle优化的五个方面 (613次浏览)
- 多个Oracle数据库创建一个Excel报表 (554次浏览)
- 怎么样快速复制表或者是插入数据 (527次浏览)
- 解决Oracle中Exp/Imp大量数据处理问题 (526次浏览)
- 重启系统的时候自动启动oracle服务 (396次浏览)
- 记几个容易忘的oracle 函数 (366次浏览)
