能撤销已提交事务，但需用AS OF TIMESTAMP闪回查询查旧数据再手动还原，因Oracle无通用撤回命令，ROLLBACK仅对未提交事务有效。
能撤销，但不是“回滚”，而是靠 AS OF TIMESTAMP 查过去的数据再手动还原。 Oracle 没有通用的“撤回已提交事务”命令，ROLLBACK 只对未提交事务有效。真正能救误改/误删数据的，是闪回查询（Flashback Query）——它不改变当前数据，而是让你看到某个时间点前的样子，然后你用这个结果做 INSERT、UPDATE 或 DELETE 把数据“手工拉回来”。
为什么 SELECT ... AS OF TIMESTAMP 能查到旧数据
Oracle 用 UNDO 表空间保存被修改前的数据镜像，只要没被覆盖、且时间在 UNDO_RETENTION 设置范围内（默认通常 900 秒），就能查到。这不是快照，也不是备份，而是实时从 undo 数据里重构出来的逻辑视图。
-
UNDO_RETENTION不是硬保证：即使设为 3600，空间紧张时 Oracle 仍可能提前覆写旧 undo - 必须确保表所在表空间启用了
UNDO（几乎所有常规数据库都默认启用） - 不能查
TRUNCATE后的数据 —— 这个操作不走 undo，直接释放段 - 时间精度依赖系统时钟，跨时区要注意
TO_TIMESTAMP的格式和时区上下文
怎么写出可用的闪回查询语句
核心就是加 AS OF TIMESTAMP 子句，但得注意语法细节和常见报错：
- 时间字符串必须用单引号包裹，格式严格匹配
TO_TIMESTAMP的第二个参数，比如'2026-05-07 14:22:30'对应'yyyy-mm-dd hh24:mi:ss' - 别漏掉
TO_TIMESTAMP()函数，直接写字符串会报ORA-01861: literal does not match format string - 如果不确定精确时间，可先查
v$sql找执行记录：SELECT sql_text, last_load_time FROM v$sql WHERE sql_text LIKE '%UPDATE%your_table%' - 查出来结果后，别直接
INSERT INTO ... SELECT—— 主键冲突、约束失败很常见，建议先导出为临时表或文件再处理
示例：SELECT * FROM orders AS OF TIMESTAMP TO_TIMESTAMP('2026-05-07 15:30:00', 'yyyy-mm-dd hh24:mi:ss') WHERE order_id = 1001;
闪回查询后怎么安全还原数据
查到旧数据只是第一步，还原动作本身容易出错：
- 用
INSERT /*+ APPEND */或MERGE替代简单INSERT，避免主键/唯一约束冲突 - 对已修改的行，优先用
UPDATE回填字段值，而不是删了再插 —— 触发器、审计字段、外键依赖可能被破坏 - 如果误操作涉及多张表，要按外键依赖顺序还原，否则
INSERT会报ORA-02291 - 还原前务必
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE，防止中间又被其他会话改 - 还原后立刻
COMMIT，别拖着事务太久，undo 压力会增大
比闪回查询更直接的方案：FLASHBACK TABLE
如果目标只是把整张表拉回某个时间点，且该表满足两个条件：ROW MOVEMENT 已启用 + 时间点在 undo 保留窗口内，那比手动查再还原更干脆：
- 先检查是否启用行移动：
SELECT table_name, row_movement FROM user_tables WHERE table_name = 'ORDERS'; - 没启用就执行：
ALTER TABLE orders ENABLE ROW MOVEMENT; - 然后直接：
FLASHBACK TABLE orders TO TIMESTAMP TO_TIMESTAMP('2026-05-07 15:30:00', 'yyyy-mm-dd hh24:mi:ss'); - 注意：这个操作会阻塞 DML，且无法跨 DDL（比如表结构变更后就不能闪回了）
真正容易被忽略的是 undo 空间压力 —— 一次大表闪回可能瞬间吃光 undo 表空间，导致其他事务报 ORA-01555。动手前先看：SELECT tablespace_name, status, used_ublk FROM v$undostat ORDER BY begin_time DESC FETCH FIRST 5 ROWS ONLY;
