5.1 描述和调整实例恢复

数据库故障常常与数据库本身无关（例如，Oracle bug、程序员错误或者介质故障），而可能是由于操作系统级别的故障或者暂时性的硬件问题（例如断电或者断网）引发的。发生这些问题时，Oracle数据库不会正常关闭，这意味着缓冲区缓存中的所有脏块还没有写入磁盘，每个数据文件的头部没有同步。这类故障要求进行实例恢复，也称为崩溃恢复，在暂时性问题解决、数据库重启时发生。

由于这类故障不是介质故障，因此一些已提交的事务只存在于联机重做日志中，而不存在于数据文件中。另外，在发生实例故障时，可能还有未被提交的事务，必须回滚它们，并且如果这些块已被写入各自的数据文件中，必须删除它们。每个数据文件的头部中的系统更改号（SCN）必须与控制文件中最新的SCN匹配，以同步数据和控制文件。

当数据库重启后，Oracle内核会检查每个数据文件的头部，如果它们与控制文件中的SCN不同，那么Oracle会执行实例恢复。注意，这是一个自动执行的操作：Oracle将使用联机重做日志文件前滚，确保所有已提交的事务被写入每个表空间中各自的表中，然后回滚在发生实例崩溃时未提交、且包含对每个数据文件中的表所做的修改的所有事务。此操作自动发生，不需要DBA的干预。实例恢复的各个阶段如下：

（1）实例启动时，数据文件不同步。

（2）通过应用重做日志文件记录（已提交和未提交的数据现在都在数据文件中）前滚。

（3）打开数据库。

（4）回滚未提交的事务（现在数据库处于一致状态，已经同步）；在数据库已经打开且可被用户和应用程序访问的同时，此阶段会继续执行。

注意，通过使用联机重做日志文件，故障点前的所有事务（包括未提交的事务）都被应用到数据库。打开数据库后，使用UNDO表空间中的撤消段回滚未提交的事务。因此，UNDO表空间中的记录对于实例恢复十分关键。

检查点进程（CKPT）使用重做日志文件中的位置来更新控制文件，在该位置，重做日志文件中之前的数据块被成功写入到数据文件中。图5-1显示了当前重做日志文件的内容，以及重做日志文件中的检查点位置。

图5-1 重做日志文件中的检查点位置

图5-1中两个箭头之间高亮显示的块还未被写入数据文件。检查点位置总是刚好在最早的未写入块的后面。为了控制发生实例崩溃后数据库在多久以后可用，管理员使用参数FAST_START_MTTR_TARGET。这个参数的值越低，实例的恢复越快，但其结果是，DBWn进程必须执行更频繁、但是更小的写入。这对OLTP系统性能可能产生影响。

通过设置FAST_START_MTTR_TARGET参数，可使MTTR顾问程序调整其他参数，以满足FAST_START_MTTR_TARGET指定的实例恢复时间：

        SQL> alter system set fast_start_mttr_target=100;
        System altered.
        SQL>

FAST_START_MTTR_TARGET的范围为0～3600。设为0将禁用MTTR顾问程序；也可以设为1，但是由于数据库启动期间发生的其他事件，设为1是通常无法实现的。