RMAN不完全恢复必须明确目标后执行，需先MOUNT数据库，再按SET UNTIL TIME/SCN/SEQUENCE指定终点，依次RESTORE、RECOVER，最后OPEN RESETLOGS；顺序错误或状态不符将报ORA-01126等错，RESETLOGS后须立即全备并验证归档生成。
RMAN 不完全恢复不是“能不能做”，而是“必须明确恢复目标再动手”。它不还原到最新状态，而是倒退到某个可控点——时间、SCN 或归档序列号。一旦执行 ALTER DATABASE OPEN RESETLOGS，就不可逆，后续所有归档日志起点重置，旧备份和日志基本失效。
必须先确认数据库处于 MOUNT 状态
不完全恢复不能在 OPEN 状态下进行，否则 RESTORE 和 RECOVER 会直接报错 ORA-01127: database name length exceeds 30 characters（实际是状态冲突的伪装错误）或更常见的 ORA-01126: database must be mounted in this instance。
实操建议：
- 用
sqlplus / as sysdba连接后执行SHUTDOWN IMMEDIATE，再STARTUP MOUNT - 别跳过
MOUNT直接STARTUP—— 即使数据库能启动，RMAN 也会拒绝执行SET UNTIL后的恢复 - 检查当前状态：
SELECT status FROM v$instance;输出必须是MOUNTED
三种 UNTIL 条件选哪个？看误操作发生时间精度
时间、SCN、归档序列号三者本质等价，但实操中容错性和可追溯性差异很大：
-
SET UNTIL TIME最直观，适合知道大概时间点（如“上午10:23误删表”），但要注意时区：RMAN 默认用数据库服务器本地时间，不是客户端时间；格式必须严格为'YYYY-MM-DD HH24:MI:SS'，少空格或大小写错就报ORA-19602: cannot backup or copy active file in NOARCHIVELOG mode（其实是解析失败） -
SET UNTIL SCN最精确，适合已知误操作前一刻的 SCN（比如从v$archived_log查到某条日志的FIRST_CHANGE#），但 SCN 无法直接“猜”，必须查表或日志，否则容易设高（跳过误操作）或设低（多删数据） -
SET UNTIL SEQUENCE依赖归档连续性，只适用于单实例且归档未缺失的场景；若中间缺一个归档（如sequence=11被删），RMAN 可能自动跳过，也可能卡在waiting for archive log，需提前用LIST ARCHIVELOG ALL核对序列完整性
RESTORE 和 RECOVER 的顺序不能颠倒
RESTORE DATABASE 是把备份文件拷回数据文件位置，RECOVER DATABASE 是用归档日志“重演”变更。顺序错了会报错：
- 先
RECOVER后RESTORE→ORA-00283: recovery session canceled due to errors+ORA-01110: data file 1: ...（找不到物理文件） - 只
RESTORE不RECOVER→ 数据库能OPEN，但状态是“非一致性”，查询表会报ORA-01578: ORACLE data block corrupted - 关键点：
RECOVER DATABASE必须紧接在SET UNTIL之后，且不能加NOLOGGING或其他干扰参数——RMAN 会自动按UNTIL截断应用日志
RESETLOGS 后第一件事是立刻全备
ALTER DATABASE OPEN RESETLOGS 不是终点，而是新起点的开关。它重置日志序列、清空在线日志内容、让控制文件标记“incarnation change”。这意味着：
- 之前所有备份（包括全备）在新 incarnation 下默认不可用，除非用
RESET DATABASE TO INCARNATION切回去 - 旧归档日志无法再用于后续恢复（因为 SCN 断层），所以必须立刻执行一次
BACKUP DATABASE PLUS ARCHIVELOG - 如果跳过这步，下次出问题时只能从这次
RESETLOGS后的备份开始恢复，中间几天的变更彻底丢失
真正容易被忽略的，是 RESETLOGS 后没验证归档是否正常生成——用 ARCHIVE LOG LIST 确认 Automatic archival 是 Enabled，再手动 ALTER SYSTEM SWITCH LOGFILE 看新归档是否落地。
