Oracle恢复内部原理（实例恢复）

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

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

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节）。

崩溃恢复如果使用线程合并重做算法恢复一个备份，即使数据文件的检查点跟数据库检查点一致，依然会失败。原因是在所有的线程中，崩溃恢复会丢失数据库检查点和最高的检查点之间的重做日志。相比之下，介质恢复会从数据文件检查点开始应用重做程序。而且，即使崩溃恢复也从数据文件检查点开始应用重做程序，还是会失败。因为它只会去找联机重做日志。而所有线程可能都已经将其重做日志归档了并重用了联机日志。

如果使用了命令STARTUP RECOVER ，崩溃恢复会因为数据文件需要介质恢复而失败。此时在数据库打开之前会自动调用RECOVER DATABASE进行介质恢复。

5.4  检查点

实例恢复不会尝试应用数据文件检查点之前的重做日志（数据文件头部的检查点SCN不能决定是否需要实例恢复）。

实例恢复读取从数据文件检查点之后到线程结束之际的重做日志，找到该线程分配的最大的SCN。用于关闭线程和推进线程检查点。实例恢复结束后也会推进数据文件检查点和检查点计数器。

5.5  崩溃恢复完成

崩溃恢复完成时，所有数据文件的联机模糊位，热备份模糊位，介质恢复模糊位都将被清除掉，然后在重做日志中写入一笔特殊的重做记录，标记崩溃恢复的结束。这条记录用于通知介质恢复在恢复时何时可以清除数据文件的联机模糊位和热备份模糊位。