不完全恢复失败本质是目标终点不可达，因控制文件无路径、归档链断裂或数据文件SCN不一致；需查V$ARCHIVED_LOG确认UNTIL SCN是否在可用归档区间内，手动归档须CATALOG注册，缺一不可。
不完全恢复失败，本质是目标终点不可达——不是命令写错了，而是控制文件里没路径、归档链断了、或数据文件状态不一致。
RECOVER DATABASE UNTIL 报错 ORA-00279 / ORA-00289：归档日志缺失或未注册
这是最常见现象：RMAN 找不到指定 SCN/时间点之后的下一个归档，直接中断。它不提示“缺哪个”，只报“无法生成序列号 X 的归档”。
- 先查已有归档边界：
SELECT MIN(FIRST_CHANGE#), MAX(NEXT_CHANGE#) FROM V$ARCHIVED_LOG WHERE DEST_ID = 1;确认你选的UNTIL SCN是否落在MIN(FIRST_CHANGE#)和MAX(NEXT_CHANGE#)之间 - 手动拷贝的归档必须
CATALOG START WITH '/path/to/arch/'，否则LIST ARCHIVELOG ALL永远看不到它；若提示 “already cataloged”，说明控制文件里存着旧记录（比如时间戳是 2026年5月3日），得先CHANGE ARCHIVELOG ... UNCATALOG再重试 -
UNTIL SEQUENCE很容易踩坑：它要求该序号及之前所有归档都存在。哪怕只缺 sequence 11，SET UNTIL SEQUENCE 12就会失败——此时换用UNTIL SCN更可靠
RECOVER DATABASE UNTIL CANCEL 卡在 “Specify log:” 却无可用日志
这通常发生在 CURRENT 或 ACTIVE 日志损坏、且归档也不全时。RMAN 应用完最后一个可用归档后，会等你输日志名，但你手里根本没有下一个归档文件。
- 输入大写
CANCEL（不能小写、不能带空格），这是唯一合法退出方式；输错会卡住或触发 ORA-00308 - 如果连第一个归档都读不了（比如
ORA-19505找不到文件），检查DB_RECOVERY_FILE_DEST权限和路径是否真实可读，RMAN 不会自动解压 tar 包，必须提前解到目录下 - 确认数据库处于
MOUNT状态，且所有数据文件已从备份中完整还原——漏一个就会在RECOVER阶段报ORA-01113
OPEN RESETLOGS 失败：ORA-01589 / ORA-01139 / ORA-00600 [2662]
不完全恢复完成后，OPEN RESETLOGS 是强制步骤，但失败往往意味着内部 SCN 或块头不一致，不是权限或语法问题。
-
ORA-01589表示必须用RESETLOGS，别尝试NORESETLOGS；ORA-01139说明某个数据文件需要介质恢复，检查V$RECOVER_FILE是否还有NEEDS RECOVERY的条目 -
ORA-00600 [2662]是典型 SCN 裂缝：控制文件里的 current SCN 小于某个数据块头里的 dependent SCN，常见于用_ALLOW_RESETLOGS_CORRUPTION强行打开后——此时数据库虽能启，但极可能几秒内崩溃，不可用于生产 - 如果控制文件来自旧备份（比如 3 天前），
V$LOG里显示的状态仍是错的，必须先RESTORE CONTROLFILE FROM '/backup/cf.bkp'，再STARTUP MOUNT，否则整个恢复逻辑就建立在错误元数据上
使用备份控制文件恢复时忘了加 USING BACKUP CONTROLFILE
当控制文件不是当前的，而是从备份里还原的，RMAN 或 SQL*Plus 的 RECOVER 命令必须显式声明这个前提，否则它按“最新控制文件”逻辑找归档，必然失败。
- RMAN 中：执行
RECOVER DATABASE USING BACKUP CONTROLFILE，不能省略USING BACKUP CONTROLFILE - SQL*Plus 中：用
RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL ...，漏掉USING BACKUP CONTROLFILE会导致 ORA-00283 或 ORA-01152 - 这种场景下，
UNTIL TIME容易不准——因为备份控制文件里的时间戳滞后，优先用UNTIL SCN，SCN 是物理连续的，不依赖时间同步
真正难处理的从来不是命令怎么写，而是你手上的归档有没有覆盖到“最后一次完好事务结束的位置”。所有绕过手段（如隐含参数、BBED）都在赌一致性，而赌赢的前提，是你清楚自己丢了多少数据、哪些块已经不可逆损坏。
