严重灾难恢复必须分三步：重建控制文件→恢复数据文件→重做日志兜底；跳过任一步将导致ORA-01157或ORA-01110错误。
能直接用 restore database + recover database 恢复的，说明控制文件还在、归档完整、数据库能 mount —— 这不算“严重灾难”。真到严重灾难（比如整个 /oradata 目录被误删、存储挂载丢失、控制文件全毁），必须分三步走：重建控制文件 → 恢复数据文件 → 重做日志兜底。跳过任何一步都可能卡在 ORA-01157 或 ORA-01110。
控制文件全丢时，必须先重建再 mount
当 startup mount 报 ORA-00205: error in identifying control file，说明控制文件物理丢失且无可用备份（或 autobackup 路径不可达）。此时不能等 restore controlfile from autobackup —— 它依赖当前 DB_RECOVERY_FILE_DEST 或手动指定路径，而灾难场景下这些路径往往已失效。
- 用
alter database backup controlfile to trace as '/tmp/ctl.sql'在故障前有访问权限时提前生成过 trace 文件？现在就用它：编辑/tmp/ctl.sql，把所有旧路径（如/oradata/old_db/control01.ctl）替换成新位置（如/oracle/oradata/newdb/control01.ctl），去掉注释和冗余行，只留CREATE CONTROLFILE ...语句 - 没有 trace？只能手写最小控制文件语句，至少包含：
SET DATABASE、LOGFILE（明确写出每个 online redo 日志路径）、DATAFILE（列出所有数据文件绝对路径，哪怕只是占位）、MAXLOGFILES/MAXLOGMEMBERS等基础参数 - 执行前确保实例在
NOMOUNT状态；执行后立刻alter database mount，否则restore命令会报错 “database not mounted”
restore database 时必须显式指定 newname
原 /oradata 分区已卸载或损坏，RMAN 默认尝试往老路径写文件，必然失败（ORA-19504: failed to create file '/oradata/...'）。不能靠 set db_file_name_convert，那是启动后生效的参数，restore 阶段不读取。
- 进 RMAN 后先
run { set newname for database to '/new_oradata/%b'; restore database; switch database to copy; } -
%b是关键：它保留原始文件名（如system01.dbf），避免手动逐个set newname for datafile 1 to '...' -
switch database to copy必须加：它把控制文件里记录的数据文件路径更新为新路径，否则后续recover会找不到文件 - 如果部分数据文件路径需差异化（如 temp 表空间放 SSD，其他放 HDD），得拆开写：
set newname for datafile '/old/temp01.dbf' to '/ssd/temp01.dbf'
recover database 失败常见于归档断链或缺失 online redo
执行 recover database 后卡住、报 ORA-00308: cannot open archived log 或 ORA-00314: log 1 of thread 1, expected sequence# doesn't match，本质是 SCN 断层 —— 控制文件里记录的 checkpoint SCN > 所有可用归档日志的终点 SCN。
- 先查断点：
select checkpoint_change#, current_scn from v$database;和select thread#, sequence#, first_change#, next_change# from v$archived_log order by first_change# desc;对比 - 若归档确实缺失（如未启用归档、或归档目录也被删），只能用
recover database until cancel，手动输入auto让 Oracle 尝试应用所有能找的归档，最后强制中断；再alter database open resetlogs - 若 online redo 日志还在（
/redo/log01a.log等），recover database会自动应用它们；但如果 redo 日志也损坏，resetlogs后必须立刻做一次全备，因为旧归档日志从此失效 - 临时表空间文件（
temp01.dbf）不会被restore，但open resetlogs后会报ORA-01157: cannot identify/lock data file，需手动重建：alter tablespace temp add tempfile '/new_oradata/temp01.dbf' size 100m;
真正麻烦的不是命令本身，而是每一步的依赖关系：没 control file 就 mount 不了，mount 不了就 run 不了 restore，restore 不完 recover 就找不到文件，recover 不完 resetlogs 就不敢 open —— 中间任何一环路径、权限、SCN 对不上，都会停在报错界面。实际操作时，建议把每个步骤的输出（尤其是 list backup、report schema、select * from v$recovery_file_dest）截屏存档，比凭记忆排查快得多。
