必须在cdb$root中执行恢复操作，因pdb无独立控制文件、spfile及完整数据文件集；restore database在pdb下必然失败，仅支持recover pluggable database或restore tablespace pdb_name:ts_name。
不能在PDB里执行RESTORE DATABASE，必须切到CDB$ROOT上下文，用RECOVER PLUGGABLE DATABASE或RESTORE TABLESPACE pdb_name:ts_name——这是多租户架构决定的硬限制，不是权限或语法问题。
为什么RESTORE DATABASE在PDB下必然失败
你连进某个PDB后执行RESTORE DATABASE，RMAN仍依赖CDB的控制文件，但作用域被限制在PDB视图内：它拿不到该PDB完整的数据文件列表（比如SYSTEM文件路径可能指向CDB公共位置），也无法触发归档日志应用。常见报错包括ORA-65086、RMAN-06026，或者静默跳过不还原任何文件。
根本原因在于：PDB没有独立的控制文件、SPFILE和完整数据文件集，所有物理结构归属CDB。RMAN只允许在CDB$ROOT中执行全库级还原动作。
- 确认当前容器：
SELECT SYS_CONTEXT('USERENV', 'CON_NAME') FROM DUAL;必须返回CDB$ROOT - 不要用tnsnames.ora里指向PDB的服务名连接RMAN，得用CDB实例名（如
orcl） - OS用户必须是
oracle，且环境变量（ORACLE_SID、ORACLE_HOME）已正确加载
RECOVER PLUGGABLE DATABASE是恢复单个PDB的唯一合法路径
这条命令适用于PDB未被DROP的场景（即SHOW PDBS仍可见该PDB）。它会自动完成三件事：还原该PDB关联的数据文件（仅限其用户表空间 + SYSTEM/SYSAUX）、应用归档日志到指定时间点、跳过其他PDB的变更记录。
- 先关闭目标PDB：
ALTER PLUGGABLE DATABASE pdb1 CLOSE IMMEDIATE; - 确保CDB处于
ARCHIVELOG模式，且归档日志覆盖目标时间点 - 执行：
RECOVER PLUGGABLE DATABASE pdb1 UNTIL TIME 'SYSDATE-1/24'; - 不需要事先做过
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表空间时的特殊处理流程
一旦PDB的SYSTEM01.DBF损坏，ALTER PLUGGABLE DATABASE OPEN必然报ORA-01113或ORA-01157。这时不能硬开，必须走离线恢复路径：
- 在
CDB$ROOT中执行：ALTER DATABASE DATAFILE '/path/to/pdb/system01.dbf' OFFLINE DROP; - 再用RMAN执行：
RESTORE TABLESPACE pdb_name:SYSTEM;（注意不是RESTORE DATAFILE） - 接着：
RECOVER TABLESPACE pdb_name:SYSTEM; - 最后：
ALTER DATABASE DATAFILE '/path/to/pdb/system01.dbf' ONLINE;
关键点：不能跳过OFFLINE DROP直接RESTORE——否则RMAN会因文件已存在而拒绝覆盖；也不能在PDB OPEN状态下对SYSTEM做online recover，Oracle明确禁止。
