oracle-8将内存数据块写入数据文件实在是一个相当复杂的过程在这个中.pdfVIP

将内存数据块写入数据文件实在是一个相当复杂的过程，在这个过程中，首先要保证安全。所谓安全，就是在写的过 程中，一旦发生实例 ，要有一套完整的机制能够保证用户已经提交的数据 丢失；其次，在保证安全的基础 上，要尽可能地提高效率。众所周知，I/O 操作是最昂贵的操作，所以应该尽可能地将脏数据块收集到一定程度以后， 再批量写入磁盘中。 直观上最简单的解决方法就是，每当用户提交的时候就将所改变的内存数据块交给 DBWn，由其写入数据文件。这样 的话，一定能够保证提交的数据 丢失。但是这种方式效率最为低下，在高并发环境中，一定会引起 I/O 方面的争 用。Oracle 当然 采用这种没有伸缩性的方式。Oracle 引入了 CKPT 和 LGWR 这两个 进程，这两个进程与 DBWn 进程互相合作，提供了既安全又高效的写脏数据块的解决方法。 用户进程每次修改内存数据块时，都会在日志缓冲区（log buffer）中构造一个相应的重做条目（redo entry），该重做 条目描述了被修改的数据块在修改之前和修改之后的值。而 LGWR 进程则负责将这些重做条目写 机日志文件。只 要重做条目进入了联机日志文件，那么数据的安全就有保障了，否则这些数据都是有安全隐患的。LGWR 是一个必须 和前台用户进程通信的进程。LGWR 承担了维护系统数据完整性的任务，它保证了数据在任何情况下都 丢失。 假如 DBWR 在写脏数据块的过程中，突然发生实例 时，该怎么办 ？我们已经知道，用户提交时，Oracle 是不一定 会把提交的数据块写入数据文件的。那么实例 时，必然会有一些已经提交但是还没有被写入数据文件的内存数据 块丢失了。当实例再次启动时，Oracle 需要利用日志文件中 的重做条目在 buffer cache 中重新构造出被丢失的数 据块，从而完成前滚和回滚的工作，并将丢失的数据块找回来。于是这里就存在一个问题，就是 Oracle 在日志文件中 找重做条目时，到底应该找哪些重做条目？换句话说，应该在日志文件中从哪个起点开始往后应用重做条目？注意， 这里所指的日志文件可能不止一个日志文件。 因为需要预防随时可能的实例 现象，所以 Oracle 在数据库的正常运行过程中，会不断地 这个起点，以便在不 可预期的实例 中能够最有效地保护并恢复数据。同时，这个起点的选择非常有讲究。首先，这个起点不能太靠近 日志文件的头部，太靠近日志文件头部意味着要处理很多的重做条目，这样会导致实例再次启动时所进行恢复的时间 太长 ；其次，这个起点也不能太靠近日志文件的尾部，太靠近日志文件的尾部说明只有很少的脏数据块没有被写入数 据文件，也就是说前面已经有很多脏数据块被写入了数据文件，那也就意味着只有在 DBWn 进程很频繁地写数据文件 情况下，才能使得 buffer cache 中所残留的脏数据块的数量很少。但很明显，DBWn 写得越频繁，那么所占用写数据 文件的 I/O 就越严重，那么留给其他操作（比如 buffer cache 中不存在的数据块等）的 I/O 就越少。这显然也 是不合理的。 从这里也可以看出，这个起点实际上说明了，在日志文件中位于这个起点之前的重做条目所对应的在 buffer cache 中 的脏数据块已经被写入了数据文件，从而在实例 以后的恢复中不需要去考虑。而这个起点以后的重做条目所对应 的脏数据块实际还没有被写入数据文件，如果在实例 以后的恢复中，需要从这个起点开始往后，依次取出日志文 件中的重做条目进行恢复。考虑到目前的内存容量越来越 uffer cache 也越来越 uffer cache 中包含几百万个 内存数据块也是很正常的现象的前提下，如何才能最有效的来 这个起点呢？ 为了能够确定这个最佳的起点，Oracle 引入了名为CKPT 的 进程，通常也叫作检查点进程（checkpoint process）。 这个进程与 DBWn 共同合作，从而确定这个起点。同时，这个起点也有一个专门的名字，叫做检查点位置（checkpoint position，该检