oracle体系结构图：
后台进程和恢复：检查点（DBWR）
DBWR进程是将DATA BUFFER中的数据写入，磁盘数据文件，在这个过程中，首先保证安全，所谓安全，就是在写过程中，一旦发生实例崩溃，要有一套完整的机制能够保证用户以及提交的数据不丢失，其次保证安全基础上，要尽可能的提高效率，众所周知，I/O操作是最昂贵的操作，所以应尽可能的将脏数据收集到一定程度以后在批量写入磁盘。
最直观，简单的方法就是，只要用户提交的时候将所改变的内存数据给DBWR，写入到数据文件，这样的话，一定能保证提交的数据不丢失，但是这种方式效率最低，在高并发环境中，频繁离散写效率最低，
因此oracle引入了LGWR 和 CKPT 这两个后台进程，这两个进程与DBWR进程相互合作，提供了既安全又高效的写脏数据的解决办法，
DBWR触发条件
1. 产生检查点
2. 脏数据缓冲区达到阀值 默认 10%
3.扫描整个data buffer没有空闲
data buffer 中包含脏的和未脏的优先写脏数据列表 再写未脏块
4. timeout 超时，如果DBWR没事做 会被每三秒唤醒一次去巡检 写不写不一定
5. 表级别的truncate 或 drop 也会触发数据写
6. 修改表空间的 read only
7. 做表空间的offline （离线）
8. 热备份 begin backup 命令
后台进程和恢复：重做日志文件和LGWR
用户在修改日志内存数据块时都会在日志缓冲区中构造一个相应的重做条目（redo entry），该redo条目描述了被修改的数据块在修改之前和修改之后的值，而LGWR进程负责将这些redo条目写入到联机日志文件，只要redo条目写入了联机日志文件，那么数据就安全了。
假如DBWR在写脏数据块的过程中，突然发生实例崩溃，该怎么办？我们已经知道，用户提交时，oracle不一定会把提交的数据块写入数据文件的，那么实例崩溃时，必然会有一些已经提交但是还没有写入数据文件的内存块丢失，当实例再次启动时，oracle需要利用日志文件记录的redo条目在buffer cache中重新构造出被丢失的数据块，从而完成前滚和回滚的工作，将丢失的数据块找回来。
这里存在一个问题，就是oracle在日志文件中找redo条目时，到底应该找哪些redo 条目？换句话说，应该在日志文件中从哪个起点开始往后应用redo条目，注意这里的日志文件可能不止一个日志文件，为预防随时可能的实例崩溃现象，所以oracle在数据库的正常运行过程中，会不断地定位这个起点，以便在不可预期的实例崩溃中能够有效的保护并恢复数据，同时，这个起点的选择非常讲究，首先这个启动不能太靠近日志文件头部，太靠近日志文件头部意味着要处理很多redo条目，这样导致再次启动实例时所进行恢复的时间太长；其次，这个起点不能太靠近日志文件尾部，太靠近日志文件尾部说明只有很少的脏数据块没有写入数据文件，也就是说已经有很多脏数据块被写入数据文件，那就意味着只有在DBWR进程很频繁的写数据文件的情况下，才能使Buffer cache中所残留的脏数据块的数据量很少，但很明显，DBWR写的越频繁，那么占用写数据文件的I/O就越严重，那么留给其他操作（比如读取buffer cache中不存在的数据块等）的I/O资源就越少，这显然也是不合理的。
为了能够确定这个最佳的起点，oracle引入了CKPT进程，通常也叫做检查点进程实现完全检查点和增量检查点来分别定位起点
在重做日志文件中记录了由于执行事务处理和oracle服务期内部操作而对数据库所做的更改。（事务处理是逻辑工作单元，由用户运行的一个或多个SQL语句组成。）使用重做日志文件时，可避免因断电、磁盘故障等引起的系统故障而导致数据库的数据不完整。重做日志文件必须多路复用，才能确保在出现磁盘故障事件时不丢失其中存储的信息。
重做日志由重做日志文件组组成。重做日志文件组又由重做日志文件和其多路复用副本组成。每个相同的副本都是该组的一个成员，每个组按编号标识。LogWriter(LGWR) 进程将重做记录从重做日志缓冲区写入重做日志组的所有成员，直至文件已填满或请求了日志切换操作。然后，这个进程会切换至下一组中的文件并执行写入。重做日志组以循环方式使用。
最佳方案提示：多路复用的重做日志文件应尽量驻留在不同的磁盘中。
重做日志文件：
· 记录数据库的更改
· 应多路复用以避免文件丢失
LogWrier触发条件：
· 提交时（commit）
· Redo log buffer 达到三分之一满时
· Redo log buffer 达到1M
· 每隔三秒写一次
· DBWn执行写入之前
后台进程和恢复：检查点（CKPT）
oracle为检查点进程提供了检查点队列，该队列串起来的都是脏数据块所对应的buffer header.每次DBWR写脏数据时，也是从检查点队列上扫描脏数据块，并将这些脏数据块写入数据文件中，当写完以后，DBWR会将这些已经写入数据文件的脏数据块从检查点队列上摘下来。
检查点队列上的buffer header 是按照数据块第一次被脏的时间先后顺序来排列的。
越早修改的数据块的buffer header排在越前面，
同时如果一个数据块被修改了多次的话，在该链表上也只出现一次。
检查点队列里记录着这次的修改产生的redo 条目在redo 文件中的位置，简称（RBA）
检查点队列上的buffer header 还记录了脏数据块在第一次被修改时，所对应的重做条目在重做日志文件中的地址，也就是LRBA(Low Redo Block Address)
数据块最后一次修改的地址叫做 HRBA
当数据块第一次被修改时LRBA与HRBA是同一个地址，当同一个数据块第二次修改时则更新HRBA值。
在检查点队列里最后一个记录的 RBA 被称为ON DISK RBA
概括下来其实就是 DBWn 负责写检查点队列上的脏数据块，而CKPT 负责记录当前检查点队列的第一个数据库块所对应的重做日志条目在日志文件中的地址，将其写入到控制文件中去。
oracle8I 版本前只是完全检查点，完全检查点就意味着buffer cache中所有脏数据都完全写入到了数据文件中。
那个版本，日志切换就会触发完全检查点
到了8I 版本后，完全检查点只有在两种情况下才触发：
1. alter system checkpoint;
2. 除了shutdown abort 以为的正常关库命令
手动执行 alter system checkpoint 完全检查点会将所有脏块写盘（包括未提交的）
关闭数据库时会将未完成的事务回滚，再将脏块写盘
同时，完全检查点会更新控制文件和数据文件头，
检查点队列随着时间增长，由CKPT 通知DBWR 去写，每次告诉DBWR 写到队列的什么地方，与主机的I/O效率有关，也就是CKPT 是监工，向 DBWR 提交任务， DBWR 即为劳力
CKPT 除了通知DBWR 去写以外，还会每三秒检查一次 DBWR 的工作进度，并将DBWR 当前记录到控制文件，如果三秒触发，CKPT 只做一件事，就是找出检查点队列里的第一个 buffer header，并将该buffer header 中所记录的LRBA(Low Redo Block Address Low 表示第一次被脏对应的RBA) 将LBRA 记录到控制文件中去。
每隔三秒（或频率更高
），CKPT进程在 控制文件中存储一次数据，以记录DBWn从SGA写入磁盘的修改数据块。这就成为“检查点”。
检查点的用途就是标识联机重做日志文件开始进行实例恢复的位置（这个位置称为“检查点位置”）。
如果使用日志切换，CKPT 进程还会将这个检查点信息写入到数据文件头。
检查点因以下原因而存在：
· 确保定期将内存中的修改数据块写入磁盘，以便在系统或数据库出现故障的情况下不丢失数据
· 减少实例恢复所需的时间。只有跟在最后一个检查点后面的联机重做日志文件才需要进行过恢复处理。
· 确保所有提交数据在关闭过程中都写入数据文件
由CKPT进程写入的检查点信息包含检查点位置、系统更改号、联机重做日志文件中开始恢复的位置、关于日志的信息等等。
注：CKPT进程并不将数据块写入磁盘，也不将重做块写入联机重做日志文件。
在检查点上发出DBWn信号
使用检查点信息更新数据文件头
使用检查点信息更新控制文件
后台进程和恢复：归档程序 （ARCn）
ARCn是一个可选的后台进程。但是，在丢失磁盘后恢复数据库时，这个进程的作用至关重要。联机重做日志文件填满后，oracle实例开始写入下一个联机重做日志文件。从一个联机重做日志文件切换到另一个联机重做日志文件的过程称为日志切换。
ARCn进程在每次进行日志切换时都会开始对已填满的日志组进行备份或归档。它会在可以重新使用日志之前自动归档重做日志文件，因此会保留对数据库所做的所有更改。这样，即使磁盘驱动器损坏，也可以将数据库恢复到故障点。
DBA 必须做出的一个重要决策是，配置数据库在ARCHIVELOG模式下运行，还是在NOARCHIVELOG模式下运行。
· 在NOARCHIVELOG模式下，每次发生日志切换时，都会件覆盖联机重做日志文件。
· 在ARCHIVELOG模式下，必须先归档非活动的已填满联机重做日志文件组，才可以再次使用这些组。
注：ARCHIVELOG 模式对大多数备份策略而言是必须选择的模式（并且极易配置）。
一个可选的后台进程
为数据库设置了ARCHIVELOG模式后自动归档联机重做日志文件
保留对数据库进行的所有更改的记录
oracle四个重要的后台进程（DBWR / LGWR / ARCH / CKPT）,布布扣,bubuko.com
oracle四个重要的后台进程（DBWR / LGWR / ARCH / CKPT）
原文：http://blog.csdn.net/wanghui5767260/article/details/20715809
