recover table 本质是启动临时辅助库还原整个cdb到指定时间点再导出导入，需连cdb$root、指定auxiliary destination、确保归档链完整、手动重建索引约束，rac环境不支持。
RECOVER TABLE 不是“执行一条命令就完事”的操作，它本质是启动一个临时辅助库、还原整个 CDB 到指定时间点、再用 Data Pump 导出导入——你得为这套流程准备好空间、权限和归档链，否则会卡在静默失败或 ORA-19921 上。
必须连到 CDB$ROOT 才能执行 RECOVER TABLE
哪怕你要恢复的是 PDB1.MY_SCHEMA.MY_TABLE，RMAN 也必须以 rman target / 连接到 CDB 根容器，而不是用 @pdb1 连进 PDB。误连 PDB 的典型表现是：命令不报错、不提示、不干活，最后导出为空或报 ORA-65096。
验证方式：SELECT SYS_CONTEXT('USERENV', 'CON_NAME') FROM DUAL; 返回值必须是 CDB$ROOT。环境变量 ORACLE_SID 必须指向 CDB 实例名，不是 PDB 名。
UNTIL TIME 必须早于误操作 SCN，且归档不能断链
对 DROP TABLE ... PURGE 或 TRUNCATE 这类操作，目标时间点一旦晚于该 DDL 提交的 SCN，RECOVER TABLE 就找不到表定义，直接失败。
查误操作时间别只看 DBA_LOGSTDBY_LOG（需逻辑备库），更可靠的是 LogMiner：EXEC DBMS_LOGMNR.START_LOGMNR(OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + DBMS_LOGMNR.COMMITTED_DATA_ONLY);
然后查 V$LOGMNR_CONTENTS 中 OPERATION IN ('DROP', 'TRUNCATE') 的记录。
归档缺失不一定立刻报错，但若缺的是 DDL 前后那几个 sequence，就会卡在 ORA-19921: no archive log found。
AUXILIARY DESTINATION 必须显式指定且空间充足
不指定 AUXILIARY DESTINATION，RMAN 会在 “creating auxiliary instance” 阶段挂住，错误信息模糊，容易误判为网络或权限问题。
这个路径要满足：
• 目录存在且 Oracle 用户可读写：chown oracle:oinstall /u01/oradata/aux、chmod 755 /u01/oradata/aux
• 空间至少是目标 PDB 所有数据文件总大小的 2–3 倍（含临时文件、redo、controlfile 复本）
• 不能和 DATAPUMP DESTINATION 共用同一磁盘，避免 I/O 竞争
示例命令：RECOVER TABLE MY_SCHEMA.MY_TABLE UNTIL TIME "TO_DATE('20260720 142500','yyyymmdd hh24miss')" AUXILIARY DESTINATION '/u01/oradata/aux';
恢复后索引、约束、触发器不会自动重建
RECOVER TABLE 只导出数据行，不导出依赖对象定义。恢复后的表能查到数据，但主键、外键、唯一约束、函数索引甚至触发器全都没了——业务逻辑可能悄无声息地出错。
必须手动补：
• 查原定义：SELECT DBMS_METADATA.GET_DDL('INDEX', index_name, owner) FROM DBA_INDEXES WHERE table_name = 'MY_TABLE' AND owner = 'MY_SCHEMA';
• 补约束前先验证数据一致性，比如外键列是否真有对应主表记录
• 若原表名已存在，加 REMAP TABLE 'MY_SCHEMA.MY_TABLE':'MY_SCHEMA.MY_TABLE_BAK' 避免冲突
RAC 环境下这条路根本走不通，RECOVER TABLE 底层强制单机辅助实例，会直接报 ORA-19566 或启动失败。
