SCN恢复必须先将数据库置于MOUNT状态，因RMAN禁止在OPEN状态下执行不完全恢复，否则报ORA-01127或ORA-01589；SET UNTIL SCN需置于RESTORE和RECOVER之前并用RUN块封装，且目标SCN须真实存在、可追溯于归档或在线日志范围；恢复成功后必须执行ALTER DATABASE OPEN RESETLOGS，该操作不可逆，会重置SCN并清空重做日志，旧备份链失效。
SCN恢复必须先确认数据库处于MOUNT状态
直接在OPEN状态下执行 RESTORE 或 RECOVER 会报 ORA-01127：database name too long 或 ORA-01589，根本原因是 RMAN 不允许对已打开的数据库做不完全恢复。必须先关闭并挂载：
SHUTDOWN IMMEDIATESTARTUP MOUNT
注意 STARTUP MOUNT FORCE 在某些异常场景（如控制文件损坏）下更可靠，但普通情况用 STARTUP MOUNT 即可。如果启动失败，先检查告警日志中是否有 ORA-00205（识别控制文件失败）等前置错误。
SET UNTIL SCN 必须放在 RESTORE 和 RECOVER 之前
RMAN 的 SET UNTIL SCN 不是独立命令，它只对后续同一批次的 RESTORE 和 RECOVER 生效。常见错误是写成三步分开执行：
SET UNTIL SCN 123456; RESTORE DATABASE; RECOVER DATABASE;
这会导致 RESTORE 用默认策略（即最新可用备份），而 RECOVER 才应用 SCN 限制——结果可能还原了太新的备份，导致日志链断裂。正确做法是用 RUN 块封装：
RUN {
SET UNTIL SCN 123456;
RESTORE DATABASE;
RECOVER DATABASE;
}
或者分两步手动执行（需确保中间不退出 RMAN）：
SET UNTIL SCN 123456RESTORE DATABASERECOVER DATABASE
SCN值本身必须真实存在且可追溯
不是任意整数都能当 SCN 使用。RMAN 要求目标 SCN 必须落在某个归档日志或在线日志覆盖的范围内，否则报 ORA-00283: recovery session canceled due to errors 或 ORA-01547。验证方式有：
- 查最近的 SCN 时间映射：
SELECT TO_CHAR(SCN_TO_TIMESTAMP(123456), 'YYYY-MM-DD HH24:MI:SS') FROM DUAL;—— 若报 ORA-08181，说明该 SCN 过老或未记录 - 查 SMON 记录的 SCN 历史：
SELECT TIME_DP, SCN FROM V$SMON_SCN_TIME ORDER BY TIME_DP DESC FETCH FIRST 10 ROWS ONLY; - 确认归档日志是否覆盖该 SCN：
LIST ARCHIVELOG ALL;看输出中LOW SCN和NEXT SCN是否包含目标值
特别注意：如果数据库启用了闪回区（FRA），且 db_recovery_file_dest_size 已满，旧归档可能被自动删除，导致 SCN 不可恢复。
OPEN RESETLOGS 是强制步骤，且不可逆
RECOVER DATABASE 成功后，数据库仍处于 MOUNT 状态，必须执行：
ALTER DATABASE OPEN RESETLOGS;
这不是可选项。跳过会报 ORA-01531：a database already open by the instance。执行后，所有在线重做日志被清空重建，SCN 从 1 开始计数，原日志序列号作废。这意味着：
- 此前所有未归档的日志彻底丢失，无法再做前滚
- 如果只是想恢复单张表，不该走全库 SCN 恢复——应优先考虑
FLASHBACK TABLE或基于表空间的时间点恢复（TSPITR） - RESETLOGS 后的备份必须作为新备份链起点，旧备份无法再用于后续恢复
最容易被忽略的是：SCN 恢复本质是“不完全恢复”，它会让整个数据库回到一个过去状态，所有在此之后提交的事务（包括其他用户操作）全部丢失。务必确认业务停机窗口和数据取舍边界。
