rman全库恢复必须在mount状态执行，先restore database（拷贝数据文件）再recover database（应用归档日志），缺一不可；open状态下会报错或挂起，跳过recover则启动时报ora-01113。
rman全库恢复必须在数据库处于mount状态时执行，且restore database和recover database不可省略任一环节；open状态下直接运行会报错或挂起，强行跳过recover会导致启动时报ora-01113。
数据库必须先STARTUP MOUNT，不能OPEN下操作
全库恢复不是“连上RMAN就能跑命令”的事。Oracle要求SYSTEM表空间所在的数据文件必须在控制文件已加载、但实例未打开时才能被替换——也就是MOUNT状态。如果当前是OPEN，RESTORE DATABASE会失败并提示RMAN-06023或直接卡住。
- 确认状态：
SELECT status FROM v$instance;，结果必须是MOUNTED - 若为
OPEN：先SHUTDOWN IMMEDIATE，再STARTUP MOUNT（不能STARTUP） - 权限检查：
CONNECT TARGET /必须带SYSDBA，否则报RMAN-06102
RESTORE DATABASE只是拷文件，不解决一致性
这个命令的作用非常朴素：从最近可用的完整备份集中，把所有数据文件（不含控制文件、SPFILE）复制到目标路径。它不读归档日志，也不校验SCN，还原后的文件是“冷快照”，与控制文件记录的当前SCN严重脱节。
- 默认还原路径就是原路径，若磁盘满或路径不存在，需提前用
SET NEWNAME重定向 - 不建议手动改
db_create_file_dest来绕过路径问题，RMAN不会自动识别该参数用于restore - 执行后别急着
ALTER DATABASE OPEN——此时任何访问都会触发ORA-01113
RECOVER DATABASE才是真恢复，必须跟在RESTORE之后
RECOVER DATABASE会自动扫描控制文件中记录的归档日志位置，找出从备份结束SCN到当前控制文件SCN之间缺失的所有归档，并逐个应用。这是让数据文件“活过来”的关键一步。
- 若归档缺失，会停在第一个找不到的日志处，报
ORA-00308或RMAN-06054 - 可临时指定截止点：如
RECOVER DATABASE UNTIL SEQUENCE 123，避免卡死 - 成功完成后，控制文件与各数据文件SCN对齐，此时才可安全打开
收尾动作：ALTER DATABASE OPEN前必须确认无残留异常
做完RESTORE和RECOVER，别以为万事大吉。实际生产中最容易漏掉两个隐性前提：
- 检查
v$datafile里所有文件status是否为ONLINE，如有RECOVER或OFFLINE状态，需手动ALTER DATABASE DATAFILE X ONLINE - 确认闪回恢复区（FRA）还有足够空间——
RECOVER过程可能产生大量临时归档应用中间文件，空间不足会静默失败 - 打开后立刻查
v$database.open_mode，确保是READ WRITE而非MOUNTED或READ ONLY
真正麻烦的从来不是命令本身，而是恢复前没确认控制文件是否最新、恢复后没验证每个数据文件的在线状态——这两处出问题，往往要重跑整个流程。
