崩溃恢复

崩溃恢复：

可以在数据库打开时，由Oracle 服务器自动执行崩溃恢复。

不必执行任何恢复操作。所有必需的重做信息都由SMON 来读取。

从这种类型的故障中进行恢复，请启动实例：

SQL> CONNECT / AS sysdba

Connected.

SQL> STARTUP

. . .

Database opened.

在启动数据库和出现“数据库已打开” (Database opened) ,在通知实例恢复完成前可能有一个时间延迟，这是数据库装载时发生的前滚阶段。

如果有大批量的未完成的大事务突然崩溃，那么崩溃恢复需要大量的回滚,会比较慢,实例恢复会由快速检查点来控制崩溃恢复最长所花的时间.

SMON 通过应用联机重做日志文件（来自最后一个检查点）中记录的更改来执行前滚进程。

前滚尚未记录到数据库文件中、但已记录到联机重做日志中的数据，包括回滚段的(UNDO性质的REDO)内容。

打开数据库后可能发生回滚，因为有些未提交的数据,需要到一致性状态.

前滚->打开数据库，提供服务->后台在回滚

在数据库打开时，ORACLE会对控制文件和数据文件头进行两次比较

控制文件里记录了数据库的物理结构、包括数据文件，临时文件，日志文件，以及文件的一致性信息

而每个数据文件的头部，也记录了自己的一致性信息

同样也包括SCN，检查点等信息

如果控制文件里记录的数据文件一致性信息和数据文件头记录的一致性信息一致

那表示控制文件和数据文件是一致的，都是当前的

如果他们记录的不一致，有2种情况？

1.控制文件是老的

2.数据文件是老的

有可能控制文件老，而数据文件是当前的，也有可能控制文件是当前的，而数据文件是老的备份

这都会造成一些信息的不一致：

那具体有哪两步检查呢？

第一次检查数据文件头中的Checkpoint cnt

检查数据文件头的Checkpoint cnt是否和对应控制文件中的Checkpoint cnt一致.如果相等,进行第二次检查.

第二次检查：

检查数据文件头的开始SCN和对应控制文件中的结束SCN是否一致，如果结束SCN等于开始SCN，则不需要对那个文件进行恢复.由于数据文件和控制文件介质没有坏，不需要恢复。

突然崩溃的实例这种情况:

还没有来得及记录数据文件结束SCN，结束SCN是无穷大

但是数据文件头有一个检查点后的开始SCN，所以第二步比较不通过，需要执行崩溃恢复

开始SCN

而最后一次的检查点发生时的时钟（检查点SCN），我们把这个SCN理解成开始SCN

我们每个文件恢复的起点就从这个开始的SCN开始的

所以叫开始的SCN ，也可以理解为恢复的开始

最终的scn

在控制文件里，会记录每个数据文件最终结束的SCN 如果数据文件是在线的，仍然有业务在处理，那么最后的SCN在不断的推进

所以没有最后结束的SCN 这个时候scn是无穷大，如果实例正常关闭

如SHUTDOWN IMMEDIATE，最后的结束SCN才会有

如果是正常DOWN，比如SHUTDOWN IMMEDIATE

那么数据库最后关闭数据库前会做一个完全检查点

做完检查点后，再没有新的业务，新的SCN了

所以会把最后的检查点SCN作为结束SCN，记录到控制文件中

异常DOWN的，比如停电，那么还来不及记录最后结束的SCN到控制文件

所以控制文件里每个文件的结束SCN都是无穷大

如果第2部数据文件头的开始SCN与控制文件的结束SCN不相等

那就是异常关闭实例