必须用set until scn配合restore和recover两步执行，且恢复后必须open resetlogs；恢复前需确认目标scn在归档日志链中、数据库处于mount状态、备份集包含早于该scn的数据文件。
必须用 SET UNTIL SCN 配合 RESTORE 和 RECOVER 两步执行，不能跳过还原直接恢复，也不能漏掉 OPEN RESETLOGS。
SCN 恢复前必须确认的三件事
SCN 是 Oracle 内部事务序号，不是时间戳，它不可逆、不跨库、不保证全局单调（多实例下需指定 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 在不同节点可能对应不同物理时间，跨 RAC 恢复时务必用 V$DATABASE.CURRENT_SCN 或 DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER 实时抓取，别依赖记忆或日志里的模糊描述。
