RMAN不支持直接对PDB执行UNTIL TIME恢复，因PDB无独立控制文件和归档日志流，其恢复依赖CDB$ROOT全局SCN；必须先用RECOVER DATABASE UNTIL TIME重建CDB骨架至一致性状态，再通过FLASHBACK/UNPLUG/COPY提取目标PDB。
为什么不能直接对PDB做UNTIL TIME恢复
RMAN不支持recover pluggable database pdb1 until time这类语法，执行会报RMAN-06813: could not translate pluggable database或ORA-65023。根本原因在于：PDB没有独立的控制文件和归档日志流，它的恢复依赖CDB$ROOT的全局SCN和归档序列。RMAN在CDB上下文中解析时，无法将“PDB级时间点”映射到物理日志位置——它只认CDB整体的一致性时间点。
必须先让CDB回到目标时间点
所有PDB时间点恢复的前提是CDB$ROOT先完成一致性的前滚（RECOVER DATABASE UNTIL TIME）。这步做完后，CDB处于MOUNT状态，show pdbs仍看不到目标PDB（如果它已被删），但它的元数据已回归字典，后续才能被识别。
- 先
restore controlfile，否则recover database until time会报ORA-01507: database not mounted - 时间值必须早于PDB被DROP或损坏发生的时刻（查
alert.log里的drop pluggable database时间戳） - 归档日志必须完整覆盖从备份结束到目标时间点的区间，缺任何一段都会卡在
RMAN-06026
恢复后如何提取指定PDB
CDB骨架重建完成后，有三种方式把目标PDB“拿出来”，优先级依次为：
-
FLASHBACK DATABASE：如果开启且保留时间足够，直接
flashback database to timestamp，然后alter pluggable database pdb1 open resetlogs——最快，但依赖闪回区空间和保留策略 -
UNPLUG/PLUG：用
alter pluggable database pdb1 unplug into '/tmp/pdb1.xml'导出定义，再create pluggable database pdb1 using '/tmp/pdb1.xml' source_file_name_convert——适合PDB未被DROP但数据文件损坏 -
手动COPY数据文件：从恢复后的CDB数据文件目录中，把
pdb1对应的数据文件（查select file_name from cdb_data_files where con_id = (select con_id from cdb_pdbs where pdb_name='PDB1')）复制出来，再用create pluggable database ... as clone挂载——最通用，但需手工校验文件头一致性
容易被忽略的验证环节
恢复完PDB不代表数据可用。必须立刻检查两件事：
-
select status, open_mode from v$pdbs where pdb_name = 'PDB1'—— 确保状态是READ WRITE，不是MOUNTED或UNPLUGGED -
select file#, status, error from v$datafile_header where con_id = (select con_id from cdb_pdbs where pdb_name='PDB1')—— 任一error非空都说明文件头损坏，需重新restore
跳过这两步，上线后可能遇到ORA-01157或查询返回ORA-00376，问题会延后爆发。
