rman恢复pdb数据文件必须在cdb$root上下文中操作，因控制文件、备份元数据等为cdb全局资源；直接连接pdb会因权限缺失、视图不可见及文件号解析错误而失败；官方推荐使用restore tablespace pdb_name:ts_name语法，安全精准。
rman 在 cdb 级别恢复损坏的 pdb 数据文件，不是“先连 pdb 再恢复”，而是必须在 cdb root 上下文中操作。因为控制文件、备份元数据、归档日志都属于 cdb 全局资源，rman 不支持直接以 pdb 身份连接后执行 restore/recover。
为什么不能用 connect target /@pdb_name 恢复数据文件
看似方便，但实际会失败：RMAN-06004: ORACLE error from recovery catalog database: RMAN-20001: target database not found in recovery catalog 或直接报 ORA-01031: insufficient privileges。原因有三：
-
SYSBACKUP权限只在 CDB$ROOT 生效，PDB 中无对应角色映射 - PDB 的
v$backup_set视图不可见，RMAN 无法定位该 PDB 的备份片 - 即使绕过权限问题，
restore datafile 42这类命令仍会解析为 CDB 全局文件号，而非 PDB 内部编号
restore tablespace pdb_name:ts_name 是最稳的写法
这是 Oracle 官方明确支持的语法（12.2+），它自动完成三件事：识别目标 PDB、过滤其专属备份集、映射正确的数据文件路径。比手动指定 datafile 编号更安全。
常见错误现象：RMAN-06026: some targets not found - aborting restore，往往是因为：
- PDB 当前处于
MOUNTED或UNPLUGGED状态 —— 必须先ALTER PLUGGABLE DATABASE pdb_name OPEN RESTRICTED或至少OPEN READ ONLY - 备份时未启用归档（
ARCHIVELOG模式），导致无法做介质恢复 - 误删的是
SYSTEM或SYSAUX表空间，此时 PDB 无法 open，需先 offline 对应数据文件再恢复
损坏 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 明确禁止。
恢复后 PDB 无法 open 的典型陷阱
即使 RMAN 显示 “media recovery complete”，ALTER PLUGGABLE DATABASE pdb_name OPEN 仍可能报 ORA-65086。这不是恢复失败，而是你之前执行过 UNPLUG 操作，且未清理残留元数据。此时：
- 检查
SELECT con_id, name, open_mode FROM v$pdbs—— 若状态为UNPLUGGED，说明该 PDB 已逻辑移除 - 必须用
DROP PLUGGABLE DATABASE pdb_name INCLUDING DATAFILES彻底清理 - 再通过
CREATE PLUGGABLE DATABASE ... USING 'xxx.xml' NOCOPY重新挂载（前提是当初留了UNPLUG INTO的 XML 文件） - 否则只能从最近一次全 PDB 备份中 restore，没有捷径
这个环节最容易被忽略：恢复操作本身成功了，但元数据状态不一致，导致整个 PDB 变成“幽灵库”——看得见、打不开、删不掉。
