restore database在pdb中必然失败，因pdb无独立控制文件、spfile及完整数据文件集，所有物理结构归属cdb；唯一合法路径是在cdb$root中执行recover pluggable database或restore/recover tablespace pdb_name:ts_name。
RESTORE DATABASE在PDB里必然失败，不是权限问题
直接用 rman target pdbuser/pdbpwd@pdb_name 连入 PDB 后执行 RESTORE DATABASE，RMAN 会报 ORA-65086 或 RMAN-06026，甚至静默跳过——这不是你输错了命令，也不是缺权限，而是 Oracle 内核硬性禁止。PDB 没有独立控制文件、SPFILE 和完整数据文件集，所有物理结构归属 CDB，RMAN 在 PDB 上下文里根本无法获取该 PDB 的全部数据文件路径（比如 SYSTEM 文件可能指向 CDB 公共目录），也无法触发归档日志应用。
必须在CDB$ROOT中执行RECOVER PLUGGABLE DATABASE
这是恢复单个 PDB 的唯一合法路径，前提是该 PDB 未被 DROP（SHOW PDBS 仍可见）：
- 先确认容器：
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 当前是 OPEN 或 MOUNT 状态，可在 CDB$ROOT 中直接恢复该表空间：
- 绝对不能写
RESTORE TABLESPACE USERS—— 默认作用于 CDB$ROOT，极大概率覆盖根容器的同名表空间 - 必须带容器前缀：
RESTORE TABLESPACE pdb1:USERS;，RMAN 才能识别归属、过滤专属备份、映射正确路径 - CDB 必须处于
MOUNT状态（STARTUP MOUNT），PDB 不需要OPEN，但建议先CLOSE -
RESTORE只拷文件，必须紧跟着执行RECOVER TABLESPACE pdb1:USERS;才能应用归档日志；顺序不可颠倒
已DROP的PDB无法直接恢复，需辅助实例重建
如果执行过 DROP PLUGGABLE DATABASE pdb1 INCLUDING DATAFILES，控制文件中该 PDB 的 incarnation 信息会被清除，此时 RECOVER PLUGGABLE DATABASE 会报 RMAN-06813: could not translate pluggable database pdb1。这不是备份缺失，而是元数据已丢失。唯一可行路径是：
- 在同一服务器上创建新辅助实例（非原 CDB）
- 用 RMAN
DUPLICATE命令，基于 CDB 全备 + 归档，将该 PDB 作为独立数据库克隆出来 - 再通过
CREATE PLUGGABLE DATABASE ... USING XML方式插回原 CDB（需提前导出 XML 描述文件）
这个过程绕开了原 CDB 的元数据限制，但操作链长、依赖归档完整性，且无法做到“原地还原”。最容易被忽略的是：DROP ... INCLUDING DATAFILES 后，连 LIST BACKUP OF PLUGGABLE DATABASE pdb1 都查不到记录——别等 RMAN 报错才意识到元数据已清空。
