rman必须用set until scn显式指定目标scn，否则默认完全恢复；restore只还原文件，recover才应用日志推进状态；未执行alter database open resetlogs会导致ora-01113/ora-01152错误且数据库卡在mount状态。
能直接恢复到指定scn，但必须用 set until scn 显式声明，且后续步骤顺序不能错——漏掉 alter database open resetlogs 会导致数据库卡在 mount 状态，报 ora-01113、ora-01152。
为什么不能只执行 RESTORE + RECOVER？
RMAN 的 RESTORE DATABASE 只还原物理文件，不改变数据库状态；RECOVER DATABASE 才应用归档和联机日志向前推进。但若没提前告诉 RMAN “停在哪”，它会默认恢复到最新可用点（即完全恢复），而不是你想要的 SCN。
- 不设
SET UNTIL SCN→ RMAN 恢复到最新归档结尾，不是目标 SCN - 设了但没在
RECOVER前执行 → RMAN 忽略该设置，仍走默认路径 - 恢复后忘了
RESETLOGS→ 控制文件里日志序列号与实际不匹配，数据库无法 OPEN
SCN 不完全恢复的标准操作链
整个流程必须按顺序执行，中间不能跳步或混入其他命令：
- 先
STARTUP MOUNT（不能是 OPEN 状态） - 在
RUN块内一次性完成：SET UNTIL SCN→RESTORE DATABASE→RECOVER DATABASE - 最后单独执行
ALTER DATABASE OPEN RESETLOGS（不能放在 RUN 块里）
示例：
RMAN> RUN {
SET UNTIL SCN 123456789;
RESTORE DATABASE;
RECOVER DATABASE;
}
RMAN> ALTER DATABASE OPEN RESETLOGS;
注意：SET UNTIL SCN 必须紧邻 RESTORE 和 RECOVER，且三者在同一个 RUN 块中；RESETLOGS 是 SQL 命令，必须退出 RMAN 或显式切换上下文执行。
SCN 值从哪来？别硬猜
误操作发生前的 SCN 不能靠估算，得从真实记录里查：
- 查闪回日志：
SELECT SCN, TIMESTAMP FROM V$FLASHBACK_DATABASE_LOG ORDER BY FIRST_TIME DESC - 查归档日志头：
LIST BACKUP OF ARCHIVELOG FROM SCN 123456780（看哪个备份覆盖目标 SCN） - 查告警日志或审计日志（如果开了 AUDIT DDL），找 DROP/DELETE 时间点再反推 SCN
- 用
FLASHBACK DATABASE TO SCN xxx测试性验证（仅限有足够闪回区空间时）
常见误区：用 CURRENT_SCN 减去一个固定值“大概估”，结果恢复后发现表还在——说明 SCN 太小；或者恢复后多出不该有的数据——说明 SCN 太大。必须依据日志证据定位。
恢复后必须立刻做两件事
RESETLOGS 不是终点，而是新生命周期起点：
- 立即执行一次全备（
BACKUP DATABASE PLUS ARCHIVELOG），否则后续所有备份都只能用于这个新 Incarnation - 检查
V$DATABASE.RESETLOGS_ID和V$DATABASE.CURRENT_INCARNATION#，确认已生成新对应物（Incarnation）
忽略这点，下次想恢复到 RESETLOGS 之前的时间点，RMAN 会报 RMAN-06025：“no backup of archived log with sequence”——因为旧归档日志属于上一个 Incarnation，新控制文件根本不认。
