必须用 SET UNTIL SCN 配合 RESTORE 和 RECOVER 两步执行，且恢复后必须 OPEN RESETLOGS；SCN 恢复前须确认三件事：目标 SCN 存在于归档日志链中、数据库处于 MOUNT 状态、备份集包含早于该 SCN 的数据文件。
必须用 SET UNTIL SCN 配合 RESTORE 和 RECOVER 两步执行，且恢复后必须 OPEN RESETLOGS；跳过任一环节都会失败。
SCN 恢复前必须确认的三件事
SCN 不是时间戳，它只反映事务提交顺序，不跨实例、不可逆、也不保证全局单调（RAC 下需指定 THREAD）。所以动手前得先确认：
- 目标
SCN确实存在于归档日志链中——运行LIST ARCHIVELOG ALL，检查输出里是否有覆盖该SCN范围的日志；若使用 FRA，还要查DB_RECOVERY_FILE_DEST_SIZE是否未满，且ARCHIVELOG DELETION POLICY没误删关键日志 - 数据库当前处于
MOUNT状态，不是OPEN或NOMOUNT；STARTUP MOUNT前建议先SHUTDOWN IMMEDIATE - 备份集必须包含早于目标
SCN的数据文件——RMAN 不会自动选“最新备份”，得靠RESTORE DATABASE显式触发还原；若要限定备份，加FROM TAG 'full_bak_20260725'
SET UNTIL SCN 必须写在 RUN 块内且位于 RESTORE 之前
RMAN 解析顺序严格：SET 定义恢复边界 → RESTORE 拷贝旧数据文件 → RECOVER 应用日志到目标 SCN。任何顺序错乱都会失败：
- 错误写法：
RECOVER DATABASE UNTIL SCN 123456单独执行——报ORA-01126: database must be mounted in exclusive mode and not open - 正确写法必须用
RUN封装，且SET在最前：RUN { SET UNTIL SCN 123456; RESTORE DATABASE; RECOVER DATABASE; } - 多实例环境（RAC）下，若目标
SCN来自特定实例，需补THREAD 2，否则 RMAN 默认只查THREAD 1的日志
恢复成功后 OPEN RESETLOGS 不可省略
完成 RECOVER DATABASE 后，控制文件仍认为数据库处于“需要介质恢复”状态。此时直接 ALTER DATABASE OPEN 会报 ORA-01113。必须强制重置日志序列：
- 执行
ALTER DATABASE OPEN RESETLOGS——这会清空在线日志、生成新日志序列号、重置控制文件中的SCN记录 -
RESETLOGS后所有旧归档日志失效，不能再用于后续恢复；如需再次 PITR，必须重新做全备或增量备份 - 若执行后报
ORA-01248: file XXX was created after the last checkpoint，说明某个数据文件头SCN新于控制文件记录，常见于未完整还原或控制文件未同步；此时应先RESTORE CONTROLFILE FROM AUTOBACKUP再重试
真正容易被忽略的是 SCN 的“时效性”：它只反映事务提交顺序，不等于时间。你拿到一个 SCN，不能默认它对应某个具体时刻——得用 scn_to_timestamp() 反查，而且这个函数本身有保留窗口限制（通常 5 天），超出就查不到。
