影响Oracle数据库打开速度的因素

当Oracle发起一个事务需要更改数据时，如果所涉及的数据块不在BUFFER CACHE中，那么Oracle服务进程首先会将相关数据块从数据文件中读进BUFFER CACHE进行更改（直接路径读除外），更改后的数据块称之为脏块（DIRTY BLOCK）。当事物提交或者回滚时，基于性能上的考虑，脏块并不会立刻写至数据文件，而是由LGWR进程优先将脏块的信息写至ONLINE REDOLOG，只有当LGWR进程返回写成功之后，事务才算提交成功。这就是Oracle为了保证不丢数据的“日志优先写”原则。
提示:为了保证数据不丢失，LGWR进程写REDOLOG时，一般会采用同步I/O。
“日志优先写”原则带来的问题就是当数据库异常宕机时，可能会仍有部分脏块在BUFFER CACHE的脏缓冲区列表中，并没写进数据文件。所以在启动数据库时，首先会由服务器进程进行实例恢复（CRASH RECOVERY，又叫前滚），即服务器进程扫描ONLINE REDOLOG，在BUFFER CACHE中重构未写进数据文件的脏块信息之后，会通知DBWR进程将脏块写进数据文件。CRASH RECOVERY完毕以后，BUFFER CACHE里既有数据库异常宕机时已经提交还没有写入数据文件的脏数据块，也包含了事务被突然终止，以致既没有提交又没有回滚的事务所弄脏的数据块。CRASH RECOVER完成操作之后则由SMON进程扫描UNDO段头进行事务恢复（TX RECOVERY，又叫后滚），最终将数据库恢复至宕机前的那一刻。
由前面分析可知，除去硬件性能等因素以外，数据库打开的速度受2个自身因素影响：
1、在线日志（ACTIVE和CURRENT状态）所对应的脏块数量。脏块数量越多，数据库恢复的时间就越长，数据库打开速度越慢。需要恢复的脏块的数量可以在CRASH RECOVERY日志中看到，如下所示：
Sat Jul 28 22:27:47 2012
Completed redo scan
134146 redo blocks read, 8902 data blocks need recovery
2、需要恢复的事务的数量和大小。事务数量越多，事务越大，数据库打开越慢。为加快事务恢复速度，后台进程往往采用并行恢复，其并行度主要受参数fast_start_parallel_rollback影响。