DBWn：数据库块写入器（Database Block Writer）负责将脏块写入磁盘的后台进程。
CKPT：检查点进程（Checkpoint Process）只是更新数据文件的文件首部，以辅助建立检查点的进程（DBWn）。
LGWR：日志写入器（Log Writer）负责将SGA中重做日志缓冲区的内容刷新输出到磁盘。
其实这三个进程都是为了更好地完成一件事：安全高效地实现内存数据块写入数据文件，就是将内存中修改的数据反映到硬盘的数据文件上。
将内存数据块写入数据文件实在是一个相当复杂的过程，在这个过程中，首先要保证安全。所谓安全，就是在写的过程中，一旦发生实例崩溃，要有一套完整的机制能够保证用户已经提交的数据不会丢失；其次，在保证安全的基础上，要尽可能地提高效率。众所周知，I/O操作是最昂贵的操作，所以应该尽可能地将脏数据块收集到一定程度以后，再批量写入磁盘中。
如何保证安全？
用户进程每次修改内存数据块时，都会在日志缓冲区（log buffer）中构造一个相应的重做条目（redo entry），该重做条目描述了被修改的数据块在修改之前和修改之后的值。而LGWR进程则负责将这些重做条目写入联机日志文件。只要重做条目进入了联机日志文件，那么数据的安全就有保障了，否则这些数据都是有安全隐患的。LGWR是一个必须和前台用户进程通信的进程。LGWR 承担了维护系统数据完整性的任务，它保证了数据在任何情况下都不会丢失。
假如DBWR在写脏数据块的过程中，突然发生实例崩溃时，该怎么办？我们已经知道，用户提交时，Oracle是不一定会把提交的数据块写入数据文件的。那么实例崩溃时，必然会有一些已经提交但是还没有被写入数据文件的内存数据块丢失了。当实例再次启动时，Oracle需要利用日志文件中记录的重做条目在buffer cache中重新构造出被丢失的数据块，从而完成前滚和回滚的工作，并将丢失的数据块找回来。于是这里就存在一个问题，就是Oracle在日志文件中找重做条目时，到底应该找哪些重做条目？换句话说，应该在日志文件中从哪个起点开始往后应用重做条目？注意，这里所指的日志文件可能不止一个日志文件。
这个起点意义重大，在日志文件中位于这个起点之前的重做条目所对应的在buffer cache中的脏数据块已经被写入了数据文件，从而在实例崩溃以后的恢复中不需要去考虑。而这个起点以后的重做条目所对应的脏数据块实际还没有被写入数据文件，如果在实例崩溃以后的恢复中，需要从这个起点开始往后，依次取出日志文件中的重做条目进行恢复。考虑到目前的内存容量越来越大，buffer cache也越来越大，buffer cache中包含几百万个内存数据块也是很正常的现象的前提下，如何才能最有效的来定位这个起点呢？
上面说到了有关CKPT的两个重要的概念：检查点队列（包括文件队列）和增量检查点。检查点队列上的buffer header是按照数据块第一次被修改的时间的先后顺序来排列的。越早修改的数据块的buffer header排在越前面，同时如果一个数据块被修改了多次的话，在该链表上也只出现一次。而且，检查点队列上的buffer header还记录了脏数据块在第一次被修改时，所对应的重做条目在重做日志文件中的地址，也就是LRBA（Low Redo Block Address），Low表示第一次修改时对应的RBA。每个检查点都会由checkpoint queue latch来保护。
上面所描述的概念，用一句话来概括，其实就是DBWn负责写检查点队列上的脏数据块，而CKPT负责记录当前检查点队列的第一个数据块所对应的的重做条目在日志文件中的地址。而到底应该写哪些脏数据块，写多少脏数据块，则要到检查点队列上才能确定的。