RMAN没有PDB级独立恢复上下文，所有元数据存于CDB$ROOT，必须在CDB$ROOT中用pdb_name:tablespace_name格式执行恢复，且CDB需处于MOUNT状态以确保文件可操作。
RMAN 没有 PDB 级别的独立恢复上下文
rman 的备份元数据（rc_backup_set、rc_datafile 等）全部存储在 cdb$root 的控制文件和恢复目录中，pdb 本身不维护自己的 rman 元数据。即使你用 rman target pdbuser/pdbpwd@pdb1 连接进某个 pdb，rman 实际仍通过 cdb$root 的实例服务进程执行操作，只是会自动过滤视图结果——但这个“过滤”不等于“作用域隔离”。一旦执行 restore tablespace users 这类命令，rman 默认按 cdb$root 的命名空间解析，users 会被当作根容器的表空间（如果存在），而非当前连接的 pdb。
表空间名在 CDB 中不是全局唯一标识
多个 PDB 可以同时拥有同名表空间（比如都叫 USERS），CDB 层面只靠 pdb_name:tablespace_name 这种二元路径才能准确定位。RMAN 在 CDB$ROOT 中运行时，能识别这种格式；而如果你连到 PDB 再执行恢复，RMAN 无法将 USERS 映射回所属 PDB 的物理数据文件路径，更不会去查那个 PDB 的 V$TABLESPACE 视图。结果就是：要么报 RMAN-06023: no backup of datafile found，要么静默恢复错容器。
CDB MOUNT 状态是物理文件操作的前提
- PDB 处于 OPEN 状态时，其数据文件被前台进程持有句柄，RMAN
RESTORE虽能写入新文件，但后续RECOVER必须重放归档日志——这要求数据文件处于OFFLINE或未被挂载状态，否则卡在ORA-01153: active database file - 只有 CDB 处于
MOUNT（非 OPEN）时，所有 PDB 的数据文件才真正“释放”，RMAN 才能安全覆盖、校验、应用日志 - 而
MOUNT是 CDB 级别指令，PDB 本身没有MOUNT状态——你不可能对一个 PDB 单独执行STARTUP MOUNT
权限与对象可见性限制
公用用户（如 SYS）在 CDB$ROOT 中拥有对所有 PDB 数据文件的 ALTER DATABASE DATAFILE ... OFFLINE DROP 权限；但在 PDB 内部，即使以 SYS AS SYSDBA 登录，也无法直接操作其他 PDB 或根容器的数据文件。例如修复 PDB 的 SYSTEM 表空间损坏，必须先在 CDB$ROOT 中执行 ALTER DATABASE DATAFILE '/path/to/pdb/system01.dbf' OFFLINE DROP，再用 RESTORE TABLESPACE pdb1:SYSTEM。这个 OFFLINE DROP 步骤在 PDB 内不可达。
pdb_name: 前缀、数据库当前是不是 MOUNT、以及控制文件里有没有对应备份记录。
