必须在cdb$root中执行pdb恢复操作，因pdb无独立控制文件和数据文件集；restore database在pdb下必然失败，唯一合法路径是recover pluggable database或restore/recover tablespace pdb_name:ts_name。
不能直接在 pdb 级别执行 restore database —— 这是 oracle 内核硬性禁止的操作，不是权限或语法问题，而是多租户架构决定的。
为什么 RESTORE DATABASE 在 PDB 下必然失败
当你用 rman target pdbuser/pdbpwd@pdb_name 连入某个 PDB 后执行 RESTORE DATABASE，RMAN 实际仍依赖 CDB 的控制文件，但作用域被限制在 PDB 视图内：它无法获取该 PDB 完整的数据文件列表（比如 SYSTEM 文件路径可能指向 CDB 公共位置），也无法触发归档日志应用。常见报错包括：ORA-65086、RMAN-06026，或静默跳过不还原任何文件。
根本原因在于：PDB 没有独立的控制文件、SPFILE 和完整数据文件集，所有物理结构归属 CDB。RMAN 只允许在 CDB$ROOT 中执行全库级还原动作。
必须在 CDB$ROOT 中执行 RECOVER PLUGGABLE DATABASE
这是恢复单个 PDB 的唯一合法路径，且仅适用于 PDB 未被 DROP 的场景（即 SHOW PDBS 仍可见该 PDB）。
- 先确认当前容器：
SELECT SYS_CONTEXT('USERENV', 'CON_NAME') FROM DUAL;必须返回CDB$ROOT - 关闭目标 PDB：
ALTER PLUGGABLE DATABASE pdb1 CLOSE IMMEDIATE; - 确保 CDB 处于
ARCHIVELOG模式，且归档日志覆盖目标时间点 - 执行核心命令：
RECOVER PLUGGABLE DATABASE pdb1 UNTIL TIME 'SYSDATE-1/24';
这条命令会自动完成三件事：还原该 PDB 关联的数据文件（仅限其用户表空间 + SYSTEM/SYSAUX）、应用归档日志到指定时间点、跳过其他 PDB 的变更记录。它不要求单独的 BACKUP PLUGGABLE DATABASE，只要 CDB 备份中包含该 PDB 数据即可。
RESTORE TABLESPACE pdb_name:ts_name 是表空间级恢复的唯一安全写法
如果只是某个 PDB 的非关键数据文件丢失（如用户表空间 USERS），且 PDB 当前处于 MOUNT 或 OPEN 状态，可在 CDB$ROOT 中直接还原特定表空间。
- 绝对不能写
RESTORE TABLESPACE USERS—— 这默认作用于CDB$ROOT，极大概率覆盖根容器表空间 - 必须带前缀：
RESTORE TABLESPACE pdb1:USERS;，RMAN 才能识别容器、过滤专属备份、映射正确路径 - CDB 必须处于
MOUNT状态（STARTUP MOUNT），PDB 不需要OPEN，但建议先CLOSE -
RESTORE只拷贝文件，RECOVER TABLESPACE pdb1:USERS;才真正应用归档日志；两者必须成对使用，顺序不可颠倒
漏掉 pdb1: 前缀，是 RMAN-06023 和误恢复至 CDB$ROOT 的 SYSTEM 表空间的主因。
DROP PLUGGABLE DATABASE ... INCLUDING DATAFILES 后无法用 RMAN 恢复
一旦执行该命令，CDB 数据字典中该 PDB 的元数据（CDB_PDBS、CDB_DATA_FILES 等）被彻底清除，ASM 或文件系统中数据文件也被同步删除。RMAN 备份片虽存在，但因 CON_ID 和 DBID 匹配失败，无法识别恢复目标。
此时你会看到：RMAN-06023（“no backup or copy of datafile X found”）或 RMAN-06026（“some targets not found”）。这不是备份缺失，而是“找不到匹配的恢复目标”。唯一补救手段是：若此前执行过 ALTER PLUGGABLE DATABASE pdb_name UNPLUG INTO '/path/pdb.xml'，可用 CREATE PLUGGABLE DATABASE ... USING 方式重建。
最容易被忽略的是：恢复操作前没验证 CON_NAME，也没确认 PDB 是否真的还存在于 CDB$ROOT 中 —— 这两个检查点缺一不可。
