必须满足三个前提：数据库处于ARCHIVELOG模式、FLASHBACK_ON=YES、目标SCN在闪回保留窗口内，否则报ORA-38729；检查用SELECT log_mode, flashback_on FROM v$database。
flashback database 到 SCN 前提条件是否满足
直接用 flashback database to scn 前，必须确认三件事：数据库处于 archivelog 模式、启用了闪回日志（flashback_on = yes）、且目标 scn 在闪回保留窗口内。否则会报错 ora-38729: not enough flashback database log data to do flashback。
检查命令：
SELECT log_mode, flashback_on FROM v$database;
若 flashback_on 为 NO，需先执行：
ALTER DATABASE FLASHBACK ON;
注意：FLASHBACK ON 要求数据库已挂载（MOUNT）且未打开；如果数据库是 OPEN 状态，得先 SHUTDOWN IMMEDIATE → STARTUP MOUNT。
RMAN 中 UNTIL SCN 恢复的完整流程
UNTIL SCN 是 RMAN 的时间点恢复（PITR）方式，不依赖闪回日志，只要归档日志完整、控制文件可用即可。它比 FLASHBACK DATABASE 更底层、更可靠，尤其适用于闪回功能未启用或 SCN 已超出保留期的场景。
操作步骤（在 RMAN 客户端中执行）：
- 确保数据库已关闭：
SHUTDOWN IMMEDIATE - 启动到
NOMOUNT，然后用备份控制文件恢复控制文件（如果原控制文件损坏）；否则直接STARTUP MOUNT - 运行恢复命令：
RESTORE DATABASE UNTIL SCN 1499220;<br>RECOVER DATABASE UNTIL SCN 1499220;
- 以
RESETLOGS方式打开：ALTER DATABASE OPEN RESETLOGS;
关键点：RESTORE 是从备份中还原数据文件（物理拷贝），RECOVER 是应用归档日志前滚到指定 SCN（逻辑重做）。两者缺一不可。
SCN 获取不准会导致恢复失败
误用 CURRENT_SCN 直接当恢复目标，大概率失败——因为 CURRENT_SCN 是当前时刻的 SCN，但归档日志可能只覆盖到更早的 SCN，且 RMAN 恢复要求目标 SCN 必须 ≤ 最新归档日志的 END_SCN。
稳妥做法是：
- 查最近可用归档日志范围：
SELECT MIN(first_scn), MAX(next_scn) FROM v$archived_log WHERE archived='YES';
- 用
timestamp_to_scn()把已知时间点转成 SCN：SELECT timestamp_to_scn(TO_TIMESTAMP('2026-04-10 15:22:00', 'YYYY-MM-DD HH24:MI:SS')) FROM dual; - 验证该 SCN 是否在闪回窗口内（仅对
FLASHBACK DATABASE）：SELECT oldest_flashback_scn, retention_target FROM v$flashback_database_log;
如果目标 SCN 小于 oldest_flashback_scn，就只能走 RMAN UNTIL SCN，不能用闪回。
open resetlogs 后的副作用必须清楚
无论用 RMAN 还是 FLASHBACK DATABASE 恢复到旧 SCN，最终都必须执行 ALTER DATABASE OPEN RESETLOGS。这会触发三件事：
- 重置在线重做日志序列号，生成新的日志线程
- 清空当前控制文件中的旧日志历史（
v$log_history被截断） - 所有此前备份的归档日志，对该新数据库实例失效——后续不能再用这些备份做恢复
所以恢复后第一件事，就是立刻做一次全库 RMAN 备份，否则等于裸奔。
