TRUNCATE表无法用FLASHBACK TABLE恢复，因其是DDL操作，会立即重置段头EXTENT MAP并清空元数据，导致闪回依赖的UNDO和活跃段结构失效；回收站不捕获TRUNCATE，仅RMAN不完全恢复或PRM-DUL等物理层工具可行。
truncate 表无法用闪回表（flashback table）直接恢复，必须依赖 rman 的不完全恢复或第三方工具（如 prm-dul），因为 truncate 是 ddl 操作，会清空段头的 extent map，且不生成可回滚的 undo。
为什么 FLASHBACK TABLE 对 TRUNCATE 无效
TRUNCATE 执行后，Oracle 会立即重置段头块中的区段映射信息，FLASHBACK TABLE ... TO TIMESTAMP 或 TO SCN 依赖的是 UNDO 和活跃的段结构，而 TRUNCATE 后段头已失效，闪回查询可能返回空结果或 ORA-01466 错误。即使撤销表空间仍有保留数据，也无法重建被清空的段元数据。
-
FLASHBACK TABLE要求表结构完整、行移动已启用（ALTER TABLE ... ENABLE ROW MOVEMENT），但 TRUNCATE 后该前提已破坏 - 闪回数据归档（
FLASHBACK ARCHIVE）仅在提前启用时才可用，且不能绕过 TRUNCATE 的元数据清除行为 - 回收站（
RECYCLEBIN）对 TRUNCATE 完全无感知 —— 它只捕获DROP操作
RMAN 不完全恢复：还原整个表空间到截断前时间点
这是最可控、生产环境首选的方式，前提是：已开启归档模式、有可用备份、归档日志连续、目标时间点在备份覆盖范围内。
- 确认截断发生的大致时间，例如
'2026-04-15 14:22:30'，需早于该时间点至少几分钟（避免刚好卡在日志切换边界） - 使用
SET UNTIL TIME启动恢复流程，注意时间格式必须严格匹配："to_date('20260415 142200','yyyymmdd hh24miss')" - 恢复对象不是单张表，而是其所在表空间 —— 因为 RMAN 最小恢复粒度是数据文件，而表空间是逻辑容器
- 执行后必须用
ALTER DATABASE OPEN RESETLOGS，这会重置日志序列，后续需重新做全备
run {
shutdown immediate;
startup mount;
set until time "to_date('20260415 142200','yyyymmdd hh24miss')";
restore tablespace USERS;
recover tablespace USERS;
alter database open resetlogs;
}
PRM-DUL：从数据文件中直接扫描未覆盖的数据块
当 RMAN 备份缺失、或只想恢复某几张表（不想影响其他对象）时，PRM-DUL 是实际可行的替代方案。它不依赖数据字典，靠物理块扫描重建数据。
- 必须选用
Non-Dictionary Mode（非字典模式），否则无法识别 TRUNCATE 后丢失的段头 - 执行
SCAN DATABASE后，务必选择SCAN TABLES FROM EXTENTS—— 这是关键，FROM SEGMENTS会失败 - 若数据库使用 ASM 存储，必须选
Non-Dictionary Mode (ASM)，否则无法定位磁盘位置 - 恢复成功率取决于截断后是否发生大量写入：只要原始数据块未被新 EXTENT 分配覆盖，就能提取出完整行记录
容易被忽略的细节
TRUNCATE 恢复不是“找回来就行”，而是和时间窗口、存储状态强绑定的操作。最容易踩的坑是：以为查到了某个 SCN 就能直接 FLASHBACK TABLE，结果报错；或者用 RMAN 恢复时没关闭所有应用连接，导致 OPEN RESETLOGS 失败；又或者用 PRM-DUL 时选错扫描模式，白白浪费数小时却一无所获。真正决定成败的，往往不是命令本身，而是对操作发生前后系统状态的准确判断 —— 比如归档日志是否已被删除、ASM diskgroup 是否在线、甚至 Linux 文件句柄是否还被 DBWR 持有。
