OracleDB执行数据库恢复分解.docx

Oracle DB 执行数据库恢复 ? 确定是否需要执行恢复 ? 访问不同的界面（如Enterprise Manager 和命令行） ? 描述并使用可用的方案，如Recovery Manager (RMAN) 和数据恢复指导 ? 对以下文件执行恢复： – 控制文件 – 重做日志文件 – 数据文件 打开数据库 要打开数据库，必须满足以下条件： ? 所有控制文件都必须存在且已同步 ? 所有联机数据文件都必须存在且已同步 ? 每个重做日志组必须至少有一个成员存在 打开数据库 当数据库从关闭阶段转为完全打开阶段时，数据库会对以下阶段执行内部一致性检查： ? NOMOUNT：实例要达到NOMOUNT（又称STARTED）状态，就必须读取初始化参数文件。实例进入NOMOUNT状态时，不会检查任何数据库文件。 ? MOUNT：实例进入MOUNT状态时，会检查初始化参数文件中列出的所有控制文件是否都存在且已同步。即使有一个控制文件缺失或损坏，实例也会向管理员返回错误 （指明控制文件缺失）并保持NOMOUNT状态。 ? OPEN：实例从MOUNT状态转为OPEN状态时，它会执行以下操作： - 检查控制文件已知的所有重做日志组是否至少有一个成员存在。任何缺失的成员会记录在预警日志中。 - 验证控制文件已知的所有数据文件是否存在，但不验证脱机文件。 在管理员尝试使脱机的文件联机之前，不会检查这些文件。如果数据文件不属于SYSTEM或UNDO表空间，管理员就可使数据文件脱机并打开实例。如果缺失了任何文 件，则向管理员返回一个错误，指出第一个缺失的文件，此时实例保持MOUNT状态。当实例发现缺失文件时，错误消息中只显示导致问题的第一个文件。要查找需要恢复的所有文件，管理员可通过检查v$recover_file动态性能视图来获取需要注意的文件的完整列表： SQL startup ORACLE instance started. Total System Global Area 171966464 bytes Fixed Size 775608 bytes Variable Size 145762888 bytes Database Buffersbytes 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 FROM v$datafile JOIN v$recover_file USING (file#); NAME ERROR ----------------------------------- ------------------ /oracle/oradata/orcl/users01.dbf FILE NOT FOUND /oracle/oradata/orcl/example01.dbf FILE NOT FOUND -?验证所有未脱机数据文件或只读数据文件是否与控制文件同步。必要时，实例会自动执行恢复。但是，如果某个文件不同步，导致无法通过使用联机重做日 志组进行恢复，管理员必须执行介质恢复。如果任何文件需要进行介质恢复，则向管理员返回一条错误消息，指出第一个需要恢复的文件，此时实例保持MOUNT状态： ORA-01113: file 4 needs media recovery ORA-01110: data file 4: /oracle/oradata/orcl/users01.dbf 此外，v$recover_file会提供需要注意的文件的完整列表。其中列出了存在的且需要进行介质恢复的文件，但不显示错误消息。 使数据库保持在打开状态 打开数据库后，如果有以下项丢失，数据库会失败： ? 任何控制文件 ? 属于系统表空间或还原表空间的数据文件 ? 整个重做日志组（只要组中至少有一个成员可用，实例就会保持打开状态。） 使数据库保持在打开状态 打开数据库后，以下介质故障可能会导致实例失败：丢失了控制文件，丢失了整个重做日志组，或者丢失了属于SYSTEM或UNDO表空间的数据文件。即使是丢失了一个非活动的重做日志组，数据库也会因为日志切换而最终失败。 在许多情况下，失败的实例并没有完全关闭，但是不能继续工作。必须在关闭了数据库的情况下从这些类型的介质故障进行恢复。因此，管理员必须先执行SHUTDOWN ABORT命令，然后才能开始恢复工作。 丢失了属于其它表空间的数据文件不会导致实例失败，并且可以在数