rman无法直接恢复已被drop的pdb，因元数据已清除导致rman无法识别；必须先全库时间点恢复重建cdb骨架（含控制文件、数据库、归档日志），再通过flashback/unplug/手动copy三种方式提取目标pdb。
误删PDB后RMAN不能直接RECOVER PLUGGABLE DATABASE
不能。Oracle 19c 和 12c 均不支持 RECOVER PLUGGABLE DATABASE 恢复已被 DROP PLUGGABLE DATABASE INCLUDING DATAFILES 删除的 PDB——命令本身不存在，或执行时报 RMAN-06813: could not translate pluggable database。因为 DROP 操作会立即清除 CDB$ROOT 中的元数据（CDB_PDBS、CDB_DATA_FILES 等视图记录全空），RMAN 失去目标标识（CON_ID、DBID 匹配失败），备份片虽存在但无法关联。
典型错误现象包括：RMAN-06023: no backup or copy of datafile X found to restore 或 RMAN-06026: some targets not found - aborting restore。这不是备份缺失，而是 RMAN 根本“不认识”这个 PDB 了。
必须重建CDB骨架才能提取目标PDB
恢复路径强制分两步：先用 RMAN 把整个 CDB 恢复到删除前的时间点（含 CDB$ROOT 和所有 PDB 元数据），再从中提取目标 PDB。这本质是时间点恢复（TSPITR）的变体，不是“还原一个 PDB”，而是“重建 CDB 到过去状态，再把那个 PDB 拿出来”。
-
RESTORE CONTROLFILE→ 必须先做，否则后续命令报ORA-01507: database not mounted -
RESTORE DATABASE UNTIL TIME 'yyyy-mm-dd hh24:mi:ss'→ 时间必须早于DROP命令执行时刻 -
RECOVER DATABASE UNTIL TIME ...→ 应用归档日志，使 CDB$ROOT 达到一致性状态 - 完成后数据库处于
MOUNT状态，SHOW PDBS仍看不到已删 PDB，但它的定义已回到数据字典里
提取PDB的三种可行方式（按优先级排序）
第二阶段取决于 Oracle 版本和前期准备：
- Oracle 19c 19.11+ 且启用
ENABLE_PLUGGABLE_DATABASE：执行FLASHBACK PLUGGABLE DATABASE pdb_name TO BEFORE DROP—— 最快，但依赖闪回区保留足够长 - 曾执行过
ALTER PLUGGABLE DATABASE pdb_name UNPLUG INTO '/path/pdb.xml'：用CREATE PLUGGABLE DATABASE pdb_name USING '/path/pdb.xml'插回 —— 不依赖备份，但需 XML 文件完好 - 无 XML 且版本不支持 FLASHBACK BEFORE DROP：从备份中手动
COPY数据文件，再用CREATE PLUGGABLE DATABASE ... AS CLONE+USINGXML（需生成描述符）—— 步骤繁琐，易出路径/SCN 错误
注意：UNTIL TIME 对应的完整备份集 + 归档日志链必须全部可用，缺一不可；任何一步跳过 RESTORE CONTROLFILE 或用错时间点，都会导致后续 OPEN RESETLOGS 失败或 ORA-01194。
表空间级恢复只适用于PDB未DROP的场景
如果 PDB 仍在 SHOW PDBS 列表中（即仅数据文件丢失，未执行 DROP），可直接在 CDB$ROOT 中恢复其表空间：
- 确保 CDB 处于
MOUNT状态，PDB 已CLOSE（强烈建议） - 命令必须带容器前缀：
RESTORE TABLESPACE pdb_name:USERS，绝不能写RESTORE TABLESPACE USERS -
RECOVER TABLESPACE pdb_name:USERS必须紧随其后，顺序不可颠倒 - 漏掉
pdb_name:前缀，RMAN 默认操作 CDB$ROOT，大概率覆盖根容器 SYSTEM 表空间
这个路径快、安全，但前提是你能确认 PDB 还“活着”。一旦 DROP 执行完成，这条路就彻底堵死。
