Oracle 12c中RECOVER TABLE并非在线点对点恢复，而是通过启动辅助实例还原整个CDB至指定时间点，再用Data Pump导出导入目标表，必须连接CDB$ROOT、时间点早于误操作SCN、依赖完整归档链及充足磁盘空间，且不支持RAC和SYSTEM/SYSAUX对象。
oracle 12c 中没有“基于时间的 rman 点对点恢复”这个功能——rman 本身不支持直接按时间点精确恢复单个表，所谓“recover table”是离线重建流程，不是原库上执行的在线操作。
RECOVER TABLE 不是“点对点”，而是辅助实例重建
执行 RECOVER TABLE 时，RMAN 实际会：启动一个临时辅助实例 → 把整个 CDB（含所有 PDB）还原到指定时间点 → 从该实例中用 Data Pump 导出目标表 → 再导入回原库。这不是在原库上“跳转时间点取数据”，而是另起一套环境做快照导出。
- 耗时长：哪怕只恢复一张表，也要还原 SYSTEM、SYSAUX、UNDO 和目标表所在表空间的全部数据文件
- 空间大：AUXILIARY DESTINATION 至少要预留等于当前 PDB 数据文件总大小 ×2 的磁盘空间
- 静默失败风险高：连错容器（比如连了 PDB 而非 CDB$ROOT）不会报错，但后续导出阶段直接卡住或报
ORA-65096、ORA-19554
必须连 CDB$ROOT，且时间点早于误操作 SCN
即使你要恢复的是 PDB1 里的 EMP 表，RMAN 命令也必须以 target / 连接 CDB 根容器，不能用 tnsnames.ora 指向 PDB 服务名。
- 验证连接：运行
SELECT SYS_CONTEXT('USERENV', 'CON_NAME') FROM DUAL，返回值必须是CDB$ROOT - 时间点判断不能靠猜测：DROP 或 TRUNCATE 后，数据字典已清空，目标时间点一旦晚于该 DDL 的提交 SCN，就会报
ORA-19921: no archive log found - 查真实 SCN 最可靠方式是 LogMiner：
EXEC DBMS_LOGMNR.START_LOGMNR(OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + DBMS_LOGMNR.COMMITTED_DATA_ONLY)，再查V$LOGMNR_CONTENTS中OPERATION = 'DROP'
RAC 环境下 RECOVER TABLE 直接不可用
命令底层强制创建单机辅助实例，与 OCR、ASM、集群心跳机制冲突，强行运行会卡在辅助实例启动阶段，报 ORA-19566 或静默退出。
- 真实可行路径是“异地恢复”：在独立主机部署同版本 Oracle，用原 RAC 的 RMAN 备份 + 归档还原出只读副本
- 还原前第一句必须
SET DBID xxx，DBID 要从原 RAC 的v$database.dbid查出 - 还原完成后，用
expdp导出表，再通过 DBLINK 或文件拷贝方式拉回原环境
没建还原点？别硬上 RECOVER TABLE
官方文档写“支持时间点恢复”，但实际前提极苛刻：必须提前建过保证型还原点（CREATE RESTORE POINT before_drop GUARANTEE FLASHBACK DATABASE），否则运行 RECOVER TABLE 必报 ORA-65086: cannot recover table without restore point。
- 没建还原点时，优先走回收站：
SHOW PARAMETER RECYCLEBIN→SELECT * FROM RECYCLEBIN WHERE ORIGINAL_NAME = 'EMP'→FLASHBACK TABLE "BIN$xxx" TO BEFORE DROP - 回收站已清空？改用 RMAN 时间点恢复 + EXPDP：
RESTORE DATABASE UNTIL TIME '...'; RECOVER DATABASE UNTIL TIME '...';后，用expdp指定FLASHBACK_TIME导出，别直接impdp回原库 - 注意：
SYSTEM和SYSAUX表空间下的表、SYS用户下的表，RECOVER TABLE一律不支持
真正容易被忽略的是空间预估和连接上下文——RMAN 不检查 AUXILIARY DESTINATION 是否真有足够空间，直到辅助实例启动那一刻才报 ORA-19809；而连错容器的问题，在日志里往往只体现为导出阶段超时或对象不存在，排查成本远高于事前确认 CON_NAME。
