pdb无法直接执行时间点恢复，必须先重建cdb骨架再提取pdb；因pdb元数据全存于cdb$root，rman不支持recover pluggable database until time，单独指定pdb时间点会导致con_id无法解析。
不能直接对PDB执行时间点恢复（PITR），必须通过CDB骨架重建 + PDB提取两阶段完成。 Oracle 19c 的 RMAN 不支持 RECOVER PLUGGABLE DATABASE ... UNTIL TIME，所有 PITR 操作本质是 CDB 级别的时间点恢复，PDB 只是其中可被“提取”的逻辑单元。
为什么 RMAN 没有 RECOVER PLUGGABLE DATABASE UNTIL TIME？
因为 PDB 的元数据（如 CDB_PDBS、服务名映射、SCN 一致性锚点）全部存于 CDB$ROOT 的 SYSTEM 表空间中。DROP 或误操作会直接清除这些字典记录，而 RMAN 恢复的起点永远是控制文件和 CDB 整体状态。单独指定 PDB 名称 + 时间点，RMAN 无法解析目标容器上下文——它连 CON_ID 都查不到。
常见错误现象包括：RMAN-06023: no backup or copy of datafile found（实际是 CDB 控制文件未恢复到对应时间点）、ORA-01194: file X needs more recovery（CDB$ROOT 未完成 UNTIL TIME 恢复就尝试 OPEN PDB）。
必须分两阶段：先重建 CDB 骨架，再提取目标 PDB
第一阶段（CDB 骨架重建）：
- 启动实例到
NOMOUNT，用RESTORE CONTROLFILE FROM AUTOBACKUP或指定备份片还原控制文件 -
ALTER DATABASE MOUNT后，执行RESTORE DATABASE UNTIL TIME '2026-08-27 14:30:00'（该时间必须早于 DROP PDB 命令在 alert.log 中的精确时间戳） -
RECOVER DATABASE UNTIL TIME '2026-08-27 14:30:00'，确保归档日志完整应用；完成后数据库处于MOUNT状态，SHOW PDBS应能看到目标 PDB 显示为MOUNTED或UNPLUGGED
第二阶段（PDB 提取）：
- 若 Oracle 版本 ≥ 19.11 且启用了
ENABLE_PLUGGABLE_DATABASE，可直接执行：FLASHBACK PLUGGABLE DATABASE pdb1 TO BEFORE DROP - 否则需手动提取：用
CREATE PLUGGABLE DATABASE pdb1 USING '/tmp/pdb1.xml' SOURCE_FILE_NAME_CONVERT=('/oradata/cdb/pdbseed/','/oradata/cdb/pdb1/')，其中 XML 描述符需从备份中提取或由 RMANBACKUP PLUGGABLE DATABASE pdb1 FORMAT '/tmp/pdb1_%U.xml' PLUS ARCHIVELOG预留 - 最后
ALTER PLUGGABLE DATABASE pdb1 OPEN RESETLOGS（注意不是 OPEN READ WRITE）
验证备份是否可用的关键命令
不要跳过这步——很多失败源于误判备份覆盖范围：
-
LIST BACKUP OF PLUGGABLE DATABASE pdb1：确认存在该 PDB 的完整备份（非仅全库备份） -
LIST BACKUP OF TABLESPACE pdb1:system：验证 SYSTEM 表空间有对应时间点的备份片 -
LIST ARCHIVELOG ALL：检查从备份 SCN 到目标时间点之间的归档是否连续，缺失则 PITR 失败 - 若使用恢复目录（catalog），务必先
RESYNC CATALOG，否则 RMAN 可能读不到最新备份元数据
容易被忽略的是：UNTIL TIME 必须严格早于 DROP PLUGGABLE DATABASE 命令在 alert.log 中的 第一条 日志时间（如 drop pluggable database pdb1 出现时刻），而不是用户主观认为的“删除前几分钟”。差一秒，CDB$ROOT 字典里就找不到该 PDB 的 CON_UID 记录，后续所有提取动作都会失效。
