当Oracle发起一个事务需要更改数据时，如果所涉及的数据块不在BUFFER CACHE中，那么Oracle服务进程首先会将相关数据块从数据文件中读进BUFFER CACHE进行更改（直接路径读除外），更改后的数据块被称为脏块（DIRTY BLOCK）。当事物提交或者回滚时，基于性能上的考虑，脏块并不会立刻写至数据文件，而是由LGWR进程优先将脏块的信息写至ONLINE REDOLOG，只有当LGWR进程返回写成功之后，事务才算提交成功。这就是Oracle为了保证不丢数据的“日志优先写”原则。提示　为了保证数据不丢失，LGWR进程写REDOLOG时，一般会采用同步I/O。

日志写优先的问题

“日志优先写”原则带来的问题就是当数据库异常宕机时，可能会仍有部分脏块在BUFFER CACHE的脏缓冲区列表中，并没写进数据文件。

实例前滚及后滚（先前滚后回滚）

前滚：通过redolog重构未写进数据文件的脏块信息，通知DBWR进程将脏块写进数据文件

回滚：回滚异常宕机时未提交的脏的数据块，未回滚的事务，通过扫描undo进行这些事务的回滚。

启动数据库时，首先会由服务器进程进行实例恢复（CRASH RECOVERY，又叫前滚），即服务器进程扫描ONLINE REDOLOG，在BUFFER CACHE中重构未写进数据文件的脏块信息之后，会通知DBWR进程将脏块写进数据文件。CRASH RECOVERY完毕以后，BUFFER CACHE里既有数据库异常宕机时已经提交还没有写入数据文件的脏数据块，又包含了事务被突然终止，以致既没有提交又没有回滚的事务所弄脏的数据块。CRASH RECOVER完成操作之后则由SMON进程扫描UNDO段头进行事务恢复（TX RECOVERY，又叫后滚），最终将数据库恢复至宕机前的那一刻。图4-4清晰地展示了这一过程。

由前面分析可知，除去硬件性能等因素以外，数据库打开的速度受两个自身因素影响：

◆ 在线日志（ACTIVE和CURRENT状态）所对应的脏块数量。脏块数量越多，数据库恢复的时间就越长，数据库打开速度越慢。需要恢复的脏块的数量可以在CRASH RECOVERY日志中看到，如下所示：

Sat Jul 28 22:27:47 2012
Completed redo scan
134146 redo blocks read，8902 data blocks need recovery

◆ 需要恢复的事务的数量和大小。事务数量越多，事务越大，数据库打开越慢。为加快事务恢复速度，后台进程往往采用并行恢复，其并行度主要受参数fast_start_parallel_rollback影响。

CHECKPOINT优化

Oracle引入增量CHECKPOINT的目的是将BUFFER CACHE中的脏块写操作分散到不同的时间点完成，但在I/O压力比较大的业务系统下，过于频繁的脏块写操作显然会给系统带来额外的负担，甚至影响业务系统的响应时间，那么我们需要对此进行一些优化，我们不能改变CHECKPOINT的算法，但是可以减少DBWR进程写脏块的频率。以下便是业务系统在不同I/O压力下的优化思路。

在I/O压力比较大的系统中，建议设置参数FAST_START_MTTR_TARGET为0或者将参数设置成较大值（如3000），从而降低DBWR写脏块的频率，使得脏块尽可能地保存在BUFFER CACHE中。对于ONLINE REDOLOG，如果其大小过小，容易引起在线日志的频繁切换，从而导致频繁的CHECKPOINT。为缓减I/O压力，在日志量较大的系统中，可以设置比较大的ONLINE REDOLOG（比如2GB或者4GB）。如果系统内存充足，建议设置较大的BUFFRE CACHE，不但更多的数据块可以保存在缓冲区中，而且可以进一步减少增量CHECKPOINT的频率。如果观察到DBWR进程比较繁忙（比如该进程CPU占用率较高），则可以设置db_writer_processes参数增加DBWR进程数量，从而加快CHECKPOINT速度。

提示　一般情况下，日志切换维持在20分钟左右比较合适。

在I/O压力较小的系统中，建议不要设置参数FAST_START_MTTR_TARGET（事实上Oracle默认就不设置该参数）。实践经验表明，数据库在异常宕机后的启动过程中，扫描和应用ONLINE REDOLOG的速度一般都能在几分钟内能完成。ONLINE REDOLOG的应用速度不仅跟脏块数量有关，还跟扫描数据文件头的数量有关，数据文件越多，其扫描速度越慢。

参考《DBA实战攻略》