必须先 startup nomount，否则RMAN恢复必失败；异机恢复几乎总是不完全恢复，因归档日志难以传全，须手动指定set until time/scn/sequence；controlfile和spfile必须最先还原，否则报ORA-01078或RMAN-06172；set newname需与restore同run块且配switch datafile all；归档路径不一致时须catalog start with注册。
必须先 startup nomount，否则所有 RMAN 恢复操作都会失败——这不是可选步骤，是硬性前提。
为什么异机恢复几乎总是不完全恢复
异地机器不可能把生产库从备份时刻起的所有归档日志都传全，尤其跨网络、跨存储或归档未集中管理时。RMAN 不会自动推断截止点，你必须手动指定 set until time、set until scn 或 set until sequence。常见错误是漏掉 set until 就直接 recover database，结果报 ORA-00279 或卡在找不到归档。
- 时间点恢复最常用：用
to_date('2026-06-24 02:00:00','yyyy-mm-dd hh24:mi:ss')格式，注意时区与源库一致 - SCN 恢复更精确：从源库查
select current_scn from v$database;后倒退几万，避免刚好落在 DDL 中间 - 归档序号恢复需谨慎：RMAN 可能跳过缺失的归档（如
sequence=11已被删），但前提是前面的归档 SCN 连续覆盖了该段变更
controlfile 和 spfile 必须最先还原
没 spfile，startup nomount 直接报 ORA-01078；没 controlfile，RMAN 根本识别不了备份集里的 DBID、数据文件列表和路径映射。常见错误 RMAN-06172: no autobackup found 90% 是因为：
- 没提前
set dbid（目标库从未建过实例时，控制文件里 DBID 是空的） -
control_files参数在 pfile/spfile 中写错路径或拼写错误（比如写成control01.ctl但实际备份片名是ctl_h6133g4i_1_1_ORCL_20220720_1110556818） - 备份片没放在 RMAN 默认扫描路径下，又没配
catalog start with或allocate channel ... send 'NB_OR...'（NBU 场景）
路径不一致时，set newname 必须和 restore 在同一个 run 块里
set newname for datafile 1 to '/new/system01.dbf' 不是全局设置，只对紧随其后的 restore 生效，且必须包裹在 run { } 中。单独执行再退出 RMAN，下次进就失效。
- 漏掉
switch datafile all→ 控制文件仍指向旧路径 →recover database报ORA-01152 -
switch datafile all只切换你显式set newname过的文件，不会自动推导其他文件路径 - 临时文件要单独处理：
set newname for tempfile 1 to '/new/temp01.dbf' - 路径批量替换建议用动态 SQL 生成：
SELECT 'set newname for datafile '||file#||' to '''||REPLACE(name,'/u01/oradata/','/u01/app/oracle/oradata/')||''';' FROM v$datafile;
挂载后必须校验，不能直接 restore database
alter database mount 后立刻运行：
-
report schema：确认控制文件“认得”所有数据文件，且状态为ONLINE -
list backup：看 RMAN 是否识别你传过来的备份片（特别是backup of database和backup of archivelog） -
crosscheck backup; delete noprompt expired;：清理控制文件里残留的无效记录，避免误用旧路径或已删除的备份片
真正容易被忽略的是：归档日志路径在 controlfile 里是硬编码的，如果目标机归档目录结构不同，recover database 会因找不到归档而中断，此时需用 catalog start with '/path/to/arch' 手动注册。
