recover table本质是离线重建流程，需通过辅助实例+data pump实现，必须连接cdb$root执行，时间点须早于误操作scn，依赖完整归档链、充足本地磁盘空间，且不支持rac环境。
不能直接“在线”恢复——recover table本质是离线重建流程，必须走辅助实例+data pump路径，所谓“在线”仅指原库不停机、其他对象不受影响。
必须连 CDB$ROOT 才能执行 RECOVER TABLE
即使你要恢复的是某个 PDB 里的表，RMAN 也必须以 target / 连接到 CDB 根容器。连错 PDB 会静默失败或报 ORA-65096、ORA-19554 等错误。
- 确认连接位置：
SELECT SYS_CONTEXT('USERENV', 'CON_NAME') FROM DUAL;返回值必须是CDB$ROOT - 确保 OS 用户是
oracle，且ORACLE_SID指向 CDB 实例名（不是 PDB 名） - 若用
tnsnames.ora连接，目标服务名必须对应 CDB，而非 PDB 服务别名
RECOVER TABLE 的时间点必须严格早于误操作 SCN
DROP PURGE 或 TRUNCATE 后，数据字典里表定义就消失了。目标时间点一旦晚于该 DDL 的提交 SCN，恢复就会找不到对象，最终报 ORA-19921: no archive log found 或导出为空。
- 查误操作时间最可靠方式是 LogMiner：
EXEC DBMS_LOGMNR.START_LOGMNR(OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + DBMS_LOGMNR.COMMITTED_DATA_ONLY);，再查V$LOGMNR_CONTENTS中OPERATION = 'DROP'或'TRUNCATE' - 不要依赖
DBA_LOGSTDBY_LOG——它只在开启逻辑备库时才有记录 - 归档日志链必须完整：缺失任意一个关键 DDL 前后的归档（哪怕只缺 sequence# = 11），恢复过程会在应用日志阶段卡住
AUXILIARY DESTINATION 和 DATAPUMP DESTINATION 要提前规划空间
辅助实例不是轻量进程，它会还原整个 CDB（含所有 PDB）的数据文件到指定时间点。磁盘空间需求 ≈ 当前 PDB 数据文件总大小 × 2（含临时文件、redo、controlfile 复本）。
-
AUXILIARY DESTINATION必须是本地文件系统路径（不能是 ASM 或 NFS），且需有写权限和足够空间 -
DATAPUMP DESTINATION用于存放.dmp文件，建议与AUXILIARY DESTINATION分开，避免 I/O 竞争 - RMAN 不检查空间余量，直到真正启动辅助实例时才报
RMAN-05026或ORA-19809，此时已浪费大量时间
RAC 环境下 RECOVER TABLE 直接不可用
命令底层强制创建单机辅助实例，与 OCR、ASM、集群心跳机制天然冲突。强行运行会报 ORA-19566 或辅助实例启动失败，根本走不到恢复逻辑。
- 真实可行路径是“异地恢复”：在独立主机部署同版本 Oracle，用原 RAC 的 RMAN 备份 + 归档还原出一个只读副本，再通过
expdp/impdp或 DBLINK 把数据拉回 - 新主机的
DBID必须从原 RAC 的v$database.dbid查出，并在 RMAN 中第一句就SET DBID xxx - 控制文件必须从备份中
RESTORE CONTROLFILE，不能用BACKUP CONTROLFILE TO TRACE生成的 SQL —— 它不含归档序列链，会导致RECOVER DATABASE UNTIL失败
最容易被忽略的是：恢复后导入的表，约束、索引、触发器不会自动重建，REMAP 选项对含命名 NOT NULL 约束的表会失败；另外，PDB 中的表恢复依赖 CDB 级 SYSTEM/UNDO 表空间备份，缺一不可。
