能恢复，但需同时满足三个条件：undo中仍保留10分钟前数据、undo_retention≥600秒、当前用户具备flashback权限；否则as of timestamp查询将失败或返回空，应优先用scn替代时间戳并检查v$undostat和权限。
能恢复，但不是“执行一条语句就完事”，关键取决于三个实时条件是否成立：UNDO 是否还存着那十分钟前的数据、undo_retention 是否 ≥ 600 秒、当前用户是否有查询该表的 FLASHBACK 权限。
AS OF TIMESTAMP 查询不到数据？先查 UNDO 是否还在
执行 SELECT * FROM t AS OF TIMESTAMP SYSTIMESTAMP - INTERVAL '10' MINUTE 返回空或报 ORA-01555，大概率不是语法错，而是 UNDO 已被覆盖：
- 查当前
undo_retention值：SHOW PARAMETER undo_retention—— 若小于 600，10 分钟前的数据基本不可见 - 查 UNDO 表空间压力：
SELECT MAX(undoblks) * 8192 / 1024 / 1024 AS mb FROM v$undostat WHERE begin_time > SYSDATE - 1/24—— 若峰值超表空间容量，旧 UNDO 被强制回收 - 确认数据库未开
RETENTION GUARANTEE（尤其含BLOB/CLOB的表），UNDO 更易被挤掉
用 SCN 比时间戳更稳，尤其跨会话或高并发时
时间戳受 NLS 设置、时区、系统负载抖动影响；SCN 是全局单调递增的序列号，一致性更强：
- 先查当前 SCN：
SELECT current_scn FROM v$database（需SELECT_CATALOG_ROLE） - 估算删除前 SCN：比如当前是
15200000，可试15199500、15199000逐次回退 - 验证快照：
SELECT COUNT(*) FROM t AS OF SCN 15199500—— 看行数是否符合预期 - 注意：
TIMESTAMP_TO_SCN函数有精度损失（秒级对齐），不如直接用 SCN 靠谱
INSERT 恢复时主键冲突怎么绕过？别硬插
直接 INSERT INTO t SELECT * FROM t AS OF TIMESTAMP ... 几乎必报 ORA-00001，因为原表可能已插入新记录：
- 安全做法：先建临时表存快照：
CREATE TABLE t_rec AS SELECT * FROM t AS OF SCN 15199500 - 再用
NOT EXISTS插入缺失行：INSERT INTO t SELECT * FROM t_rec r WHERE NOT EXISTS (SELECT 1 FROM t WHERE t.id = r.id) - 禁用主键约束（
ALTER TABLE t DISABLE CONSTRAINT pk_t）仅适用于无业务语义的序列主键，且恢复后必须ENABLE VALIDATE -
ON DUPLICATE KEY UPDATE是 MySQL 语法，Oracle 不识别
权限和配置漏一项，整个流程就卡住
普通用户查自己表也需显式授权，且不能依赖“默认就有”：
- 确认有
FLASHBACK ANY TABLE（DBA 授予）或FLASHBACK对象权限（表 owner 授予） - 若用
FLASHBACK TABLE t TO TIMESTAMP ...（DDL 方式），必须提前ALTER TABLE t ENABLE ROW MOVEMENT，否则报ORA-08189 - 归档模式（
ARCHIVELOG）非必需，但关闭归档时 UNDO 回收策略更激进，闪回窗口实际更短 - TRUNCATE 或带
PURGE的 DROP 无法用闪回查询恢复 —— 这类操作不走 UNDO
真正耗时间的从来不是写 SQL，而是判断“那个 SCN 到底有没有被覆盖”“当前用户到底缺哪条权限”“这张表的主键是不是真能 safely ignore”。动手前花两分钟查 v$undostat 和 dba_tab_privs，比反复试时间字符串强得多。
