实例恢复用于恢复崩溃失败或者并行服务器环境中的实例失败，所以实例恢复既可以指崩溃恢复也可以指并行服务器环境中的实例恢复（只要有一个存活的实例就可以恢复其他一个或多个失败的实例）。

                实例恢复的目标就是还原失败实例在数据缓冲区中的数据块并关闭还开着的线程。实例恢复只用联机归档日志和当前联机数据文件（不需要还原历史备份）。实例恢复一次只能恢复一个线程，它从该线程最近的线程检查点开始恢复直至线程的结束。

5.1  检测是否需要实例恢复

                当Oracle内核发现一个实例死掉而对应线程在控制文件中的线程打开状态位还是开的时候会自动进行实例恢复。实例恢复在下面两种情形下自动进行：

1.       崩溃失败后第一次打开数据库。

2.       并行服务器个别实例（不是所有的）失败了。

在并行服务器环境中，存活的实例通过下列方法检测到一个或多个实例失败需要进行实例恢复：

1.       存活实例的一个前台进程在将数据文件中的块读入数据缓冲区时检测到“Invalid block lock” 。这个多发生在另一个实例已经将该块读入数据缓冲区并用锁保护了该块‘脏数据’，然后该实例失败了。

2.       存活实例的前台进程通知它的SMON进程查看失败的实例。

3.       存活实例可以申请死亡实例的线程打开标志锁从而发现该实例已经死亡。

存活实例的SMON进程得到一个死亡实例的列表和错误的数据块列表。注：当实例恢复结束后，这些列表中的锁都会被清掉。

5.2  Thread-at-a-Time Redo Application

实例恢复同一时间只能处理一个线程，因此同一时间也只能恢复一个实例。在处理下一个线程之前，实例恢复会将每个线程的所有重做日志（从该线程的线程检查点开始到线程结束）应用到数据文件上。这个算法的正确性取决于同一时刻只有一个实例能修改数据缓冲中的块。在不同的实例修改同一块之间，该块会被写回磁盘。因此，实例恢复时从磁盘中读入数据缓存中块只需要某一个线程就够了，那个线程包含了该块最新的修改日志。

实例恢复总是能够只要该线程的联机日志就可以完成。崩溃恢复首先处理线程检查点最低的那个线程，按照线程检查点SCN递增的顺序进行恢复。保证了数据库检查点是由每个恢复过的线程推进的。

5.3  当前联机数据文件

检查点计数器用于校验数据文件是当前联机数据文件而不是历史备份。如果数据文件是从备份中还原出来的，则需要首先进行介质恢复。

当数据文件是从备份中还原出来的时候，即使只要联机重做日志就可以恢复，介质恢复仍然不可避免。理由是崩溃恢复在处理每个线程的时候都是应用该线程检查点以后的重做日志。崩溃恢复能够用这种重做算法是因为每个块只需要最多一个线程的重做日志。

然而，如果在还原的备份上进行恢复时，无法断定要哪些线程的重做日志。因此一次一个线程的算法在这种情况下不起作用。在备份上恢复需要将多个线程的重做合并。如把数据文件检查点后的所有重做日志，按照SCN递增的顺序合并各个线程中的重做日志。这种线程合并重做算法只有介质恢复才会用（见第6节）。

崩溃恢复如果使用线程合并重做算法恢复一个备份，即使数据文件的检查点跟数据库检查点一致，依然会失败。原因是在所有的线程中，崩溃恢复会丢失数据库检查点和最高的检查点之