recover database until time 在 oracle 11g 中单独执行必失败，因 rman 要求数据文件已处于可应用日志状态，而备份文件的 checkpoint 时间通常早于目标时间点，导致 ora-01190 或 ora-01113 错误。
不能直接用 RECOVER DATABASE UNTIL TIME —— 这是 Oracle 11g RMAN 最常踩的坑，一执行就报 ORA-01190 或 ORA-01113，根本走不通。
为什么 RECOVER DATABASE UNTIL TIME 单独执行必失败
Oracle 11g 的 RMAN 不支持在 MOUNT 状态下仅靠 RECOVER 就跳到任意时间点。它要求数据文件“已处于可应用日志的状态”，但实际备份里的数据文件往往比目标时间早得多——比如你备份是上周五做的，现在想恢复到今天上午 10 点，那数据文件本身还停留在上周五的 checkpoint，根本没资格直接应用日志。
错误现象典型表现为：ORA-01190: control file or data file is from before the last RESETLOGS，或 ORA-01113: file 1 needs media recovery。查 v$datafile 会发现 checkpoint_time 明显早于你要恢复的时间，说明还没还原过。
-
SET UNTIL TIME不是独立命令，必须放在RUN块最开头，它只对后续的RESTORE和RECOVER生效 - 控制文件必须完好（或已从备份恢复），否则
RESTORE DATABASE会找不到元数据 - 归档日志必须完整覆盖从备份时间点到目标时间点之间的所有变更，缺一段就卡住
正确三步顺序：restore → recover → open resetlogs
必须严格按顺序执行，缺一不可，且全部在同一个 RUN 块里完成：
RUN {
SET UNTIL TIME "TO_DATE('2026-05-14 10:30:00', 'YYYY-MM-DD HH24:MI:SS')";
RESTORE DATABASE;
RECOVER DATABASE;
ALTER DATABASE OPEN RESETLOGS;
}
注意：RESTORE DATABASE 是还原数据文件到 SET UNTIL TIME 所指时间点之前最近的一致状态；RECOVER DATABASE 则是应用归档日志和联机日志，把它们“滚”到那个时间点。
- 如果只恢复部分表空间，用
RESTORE TABLESPACE users+RECOVER DATABASE SKIP TABLESPACE system，但必须确保跳过的表空间不依赖被恢复的表空间 -
OPEN RESETLOGS会重置日志序列并生成新 Incarnation，之后不能再用旧备份做恢复，除非先RESET DATABASE TO INCARNATION - 执行前确认数据库处于
MOUNT状态，不是NOMOUNT（否则RESTORE DATABASE找不到控制文件上下文）
替代方案：闪回查询（Flashback Query）更轻量
如果只是单表误删/误改，且满足以下条件，优先用 AS OF TIMESTAMP，不用停库、不依赖备份：
- 数据库启用了
UNDO_RETENTION，且误操作时间在 UNDO 保留窗口内（默认通常 15 分钟，可调） - 表没被
DROP，只是DELETE或UPDATE - 不需要恢复整个库，只要找回某几张表的数据
示例：
SELECT * FROM orders AS OF TIMESTAMP TO_TIMESTAMP('2026-07-27 14:22:00', 'YYYY-MM-DD HH24:MI:SS');
再配合 INSERT INTO ... SELECT 插回原表。注意主键冲突要处理，且表需开启 ROW MOVEMENT 才能用 FLASHBACK TABLE。
真正难的不是语法，而是判断时间点是否还在 UNDO 或归档日志覆盖范围内——一旦日志被覆盖或 UNDO 被刷掉，就只能靠备份了。
