意外关机后能在最短时间内恢复，这对于生产环境的Oracle服务器显得尤为重要。Oracle架构健壮且能够避免除媒介故障外的已提交事务所带来的损失。如果没有媒介故障发生，那么实例恢复就可以得到保障。而作为数据库管理员，真正想要的是快速恢复。数据库越快回归在线状态，用户才能尽早停止打电话、发邮件以及找上门来询问数据库何时才能修复。这也正是对Oracle实例恢复调优的关键所在。

　　实例与崩溃恢复是一种重做日志记录的自动应用程序，它在崩溃或是系统故障发生之后会将日志记录到数据块中。每当数据库执行一个正常关闭，实例内存中任何尚未写入磁盘的变化都会记录进系统检查点。其中一些内存变化可能会包含尚未写到数据文件的已提交事务。Oracle将每个事务同步写入重做日志的缓存，然后再写入在线重做日志。重做日志的内容会包括已提交和未提交的事务。当数据库关闭带有中断选项时，一个单实例数据库崩溃或是一个Oracle RAC配置的所有实例崩溃，那么就不会产生任何的系统检查点。因为数据文件可能会有已到位的一些未提交事务，或一些未到位的已提交事务，所以崩溃恢复必须在下一个启动的时候执行以确保数据库的一致。

　　Oracle实例恢复分为两步：缓存恢复，接着是事务恢复。

　　在缓存恢复中（也称为前滚），Oracle会将重做日志文件中的所有已提交和未提交的更改应用到受影响的数据块中。必须要应用到数据文件中的重做数据的数量是与数据块的变化率和检查点的时间间隔成比例的。

　　事务恢复是在所有的重做日志变更都已经应用到数据文件之后发生的。任何在崩溃之时尚未提交的事务都必须进行回滚。对于该操作，数据库利用撤销信息退回未提交的变更。

　　就Oracle实例恢复调优而言，缓存恢复操作是至关重要的。一旦缓存恢复完成，数据库就可以运行了。在不影响系统可用性的条件下是可以进行事务恢复操作的。而加速缓存恢复将会提高数据库的可用性。

　　Oracle使用检查点进行实例恢复

　　当Oracle执行一个检查点时，系统记录了最高的系统变更号，而等于或小于SCN的所有数据块会写入到数据文件中去。在实例故障事件中，最近检查点的SCN就是缓存恢复的起点。只有变更数目大于SCN的重做记录才必须应用。执行一个实例恢复需要多久，这取决于变更量大于SCN的数据块的数目以及必须读取来定位这些变更的重做日志块的数量。如果数据库过于频繁的执行检查点，那么Oracle就会更多的向数据文件写入脏数据。如果发生实例故障后进行缓存恢复的话，那么必须要写入数据文件的重做日志块会较少。也就是说，系统中的频繁检查点经常更新的话会导致数据库性能的降低。在正常操作期间以牺牲系统性能来减少发生异常后的恢复时间其实是不明智的。

　　Oracle的故障恢复快速启动功能（Oracle Fast-Start Fault Recovery）就是设计用来减少缓存恢复时间的，并可以在不明显影响性能的情况下让恢复时间更具可预测性。它能有效限制脏数据的数量以及最近重做日志记录和最后检查点之间产生的重做日志记录的数量。

　　Oracle中的传统检查点是事件驱动的且当检查点发生时会执行批量读写。当使用快速启动（Fast-Start）架构时，检查点会增量产生。每个数据库读写器都会定期处理读写缓冲到磁盘以将检查点的位置提前。这些结果在那些消除I/O峰值的较小检查点中与传统检查点异曲同工。这一功能可以通过将FAST_START_MTTR_TARGET 的初始参数设置为非零值来开启。对于Oracle实例恢复，这就为预期的平均时间设定了一个目标。此参数应该按秒来进行设置（0至3600），然后它就应该以这个参数值来启动实例并执行缓存恢复。一旦设置了此参数，Oracle就会通过管理增量检查点来尝试达到目标。