recover table对truncate无效，因其依赖归档日志中的逻辑变更记录，而truncate仅写minimal redo、不记录原数据行，导致指定scn时导出为空；必须通过全备+归档还原临时库再抽表。
不能直接“快速”恢复被 TRUNCATE 的表——RMAN 的 RECOVER TABLE 不支持 TRUNCATE 场景，且默认不重建约束/索引，必须手动补全。
为什么 RECOVER TABLE 对 TRUNCATE 无效
TRUNCATE 是 DDL 操作，不写入 undo，不触发归档日志中的逻辑变更记录（只记 minimal redo），RECOVER TABLE 依赖归档日志中可解析的 DML/DDL 变更流来重建数据行，但 TRUNCATE 后的日志里没有“原数据行”，只有“清空段”的物理标记。RMAN 实际执行的是：拉起临时库 → 启动到指定 SCN → 导出目标表数据 → 导入回原库。若目标 SCN 时该表已被 TRUNCATE，则导出结果为空。
- 查证方式：
SELECT * FROM V$LOGMNR_CONTENTS WHERE OPERATION = 'TRUNCATE' AND SEG_NAME = 'YOUR_TABLE';—— 基本查不到有效行 - 替代路径：只能靠 TRUNCATE 前最近一次完整备份 + 归档日志链还原到那个时间点，再从中抽表
- 12c+ 中
RECOVER TABLE明确排除 TRUNCATE 场景，文档标注为 “not supported for DDL that drops segment data”
真正可行的三步落地路径
前提是数据库为 ARCHIVELOG 模式、有可用 RMAN 全备+归档连续、且未启用 FORCE LOGGING（否则部分 TRUNCATE 可能无归档）。
- 先定位 TRUNCATE 发生前一刻的 SCN：
SELECT CURRENT_SCN FROM V$DATABASE;要在误操作后立即查；若已错过，用SELECT MIN(FIRST_CHANGE#) FROM V$ARCHIVED_LOG WHERE FIRST_TIME > TO_DATE('2026-09-30 14:22:00', 'yyyy-mm-dd hh24:mi:ss');逼近 - 用
RESTORE DATABASE+RECOVER DATABASE UNTIL SCN xxxxx拉起一个临时库（非 AUXILIARY INSTANCE，而是完整克隆），确保该库中表仍含数据 - 从临时库导出数据：
expdp system/password DIRECTORY=dpump_dir DUMPFILE=t1_pre_trunc.dmp TABLES=schema.t1，再导入生产库：impdp system/password DIRECTORY=dpump_dir DUMPFILE=t1_pre_trunc.dmp TABLE_EXISTS_ACTION=REPLACE
容易被忽略的关键权限与路径陷阱
临时库启动阶段失败，90% 出在权限或路径不可写，而非 SQL 语法错误。
-
AUXILIARY DESTINATION必须显式指定且 Oracle 用户可写：chmod 755 /u01/oradata/aux，否则卡在ORA-19809，报错不提“磁盘满” - 临时库的
$ORACLE_BASE/admin/<sid>/adump</sid>目录也要可写，否则监听器起不来，RMAN-03002报错无上下文 - 如果原表在 PDB 中，
RMAN TARGET /必须连 CDB$ROOT，SELECT SYS_CONTEXT('USERENV', 'CON_NAME') FROM DUAL;返回值必须是CDB$ROOT，否则静默失败 -
NOTABLEIMPORT参数必须加进RECOVER TABLE命令里，否则约束缺失导致业务插入失败却查不出原因
最麻烦的不是恢复动作本身，而是恢复后表结构完整性验证——索引、主键、外键、CHECK 约束、触发器全得人工比对重建，RECOVER TABLE 只管数据行。
