1 数据库的启动过程
当数据库从关闭阶段到完全打开阶段时，它执行以下阶段的内部一致性检查:
NOMOUNT:对于要达到NOMOUNT(也称为STARTED)状态的实例，该实例必须读取初始化参数文件。当实例进入NOMOUNT状态时，不会检查数据库文件。
mount:当实例为挂载状态时，它检查初始化参数文件中列出的所有控制文件是否都存在并同步。即使有一个控制文件丢失或损坏，该实例也会向管理员返回一个错误(指出丢失的控制文件)，并保持NOMOUNT状态。
open:当实例从挂载状态到打开状态时，它会执行以下操作:
检查控制文件已知的所有重做日志组是否至少有一个成员。任何丢失的成员都将记录在警报日志中。
验证控制文件已知的所有数据文件是否存在，除非它们已脱机。在管理员试图使脱机文件联机之前，不会检查脱机文件。如果数据文件不属于系统或UNDO表空间，管理员可以脱机数据文件并打开该实例。如果丢失了任何文件，则会向管理员返回一个错误，说明丢失的第一个文件，并且该实例保持挂载状态。当实例发现丢失的文件时，错误消息中只出现导致问题的第一个文件。要找到所有需要恢复的文件，管理员可以检查v$recover_file动态性能视图，以获得需要注意的文件的完整列表:
SQL> startup
ORACLE instance started.
Total System Global Area 171966464 bytes
Fixed Size 775608 bytes
Variable Size 145762888 bytes
Database Buffers 25165824 bytes
Redo Buffers 262144 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 4 - see DBWR trace file
ORA-01110: data file 4: '/oracle/oradata/orcl/users01.dbf'
SQL> SELECT name, error
2 FROM v$datafile
3 JOIN v$recover_file
4 USING (file#);
NAME ERROR
----------------------------------- ------------------
/oracle/oradata/orcl/users01.dbf FILE NOT FOUND
/oracle/oradata/orcl/example01.dbf FILE NOT FOUND
验证所有非脱机或只读的数据文件是否与控制文件同步。如果需要，会自动执行实例恢复。但是，如果文件不同步到无法使用联机重做日志组恢复的程度，则管理员必须执行介质恢复。如果有文件需要介质恢复，则会向管理员返回一个错误消息，说明第一个需要恢复的文件，并且该实例保持挂载状态:
ORA-01113: file 4 needs media recovery
ORA-01110: data file 4: '/oracle/oradata/orcl/users01.dbf'
同样，v$recover_file提供了需要注意的文件的完整列表。列出了现有的和需要介质恢复的文件，但没有显示错误消息。
2 介质故障会影响数据库打开
数据库打开后，介质故障可能导致实例故障:例如，丢失控制文件、丢失整个重做日志组或丢失属于系统或UNDO表空间的数据文件。即使丢失了不活动的重做日志组，数据库最终也会由于日志丢失开启失败。
在许多情况下，失败的实例不会完全关闭，而是无法继续执行工作。必须在数据库关闭时从这些类型的介质故障中恢复。因此，在开始恢复工作之前，管理员必须使用SHUTDOWN ABORT命令。
属于其他表空间的数据文件的丢失不会导致实例失败，并且数据库可以在打开时恢复，而在其他表空间中继续工作。
可以通过检查警报日志文件或使用数据恢复顾问来检测这些错误。
