必须在CDB$ROOT中执行RMAN表空间恢复，因RMAN元数据解析、备份匹配及路径映射均由CDB统一调度；在PDB会话中执行RESTORE TABLESPACE users会误解析为恢复CDB$ROOT的USERS表空间（不存在），导致ORA-65023错误或静默失败，故必须使用pdb_name:tablespace_name格式并在CDB$ROOT下操作。
不能在PDB会话里执行RMAN表空间恢复命令，必须连CDB$ROOT、显式带pdb_name:tablespace_name前缀，否则报ORA-65023或静默恢复错容器。
为什么RESTORE TABLESPACE users在PDB里一定失败
RMAN的元数据解析、备份集匹配、路径映射全部由CDB$ROOT统一调度。即使你用ALTER SESSION SET CONTAINER = pdb1切进去，RMAN仍按CDB上下文干活——RESTORE TABLESPACE users会被解释成恢复CDB$ROOT的USERS表空间（根本不存在），结果要么报ORA-65023: active session exists for the container，要么直接跳过不报错。这不是权限问题，是多租户架构硬性限制。
正确命令必须带PDB限定符且在CDB$ROOT中运行
所有操作起点：先确认当前连接的是CDB$ROOT：SELECT SYS_CONTEXT('USERENV', 'CON_NAME') FROM DUAL;返回值必须是CDB$ROOT。然后按顺序执行：
-
ALTER PLUGGABLE DATABASE pdb1 CLOSE IMMEDIATE;（PDB必须CLOSED，避免恢复时被写入） -
RMAN> LIST BACKUP OF TABLESPACE pdb1:users;（验证备份存在，注意大小写和冒号） -
RMAN> RESTORE TABLESPACE pdb1:users;（必须写pdb1:users，不能省略pdb1:） -
RMAN> RECOVER TABLESPACE pdb1:users;（自动应用归档日志到最新可用SCN） -
ALTER PLUGGABLE DATABASE pdb1 OPEN;（此时表空间自动ONLINE）
常见报错原因和绕过条件
RMAN-06023: no backup or copy of datafile found to restore不是备份丢了，而是RMAN没匹配上：
- 备份时用了
BACKUP PLUGGABLE DATABASE pdb1，但没单独做过BACKUP TABLESPACE pdb1:users，而RESTORE TABLESPACE默认只找表空间级备份片 - 备份存放在非默认目录，且没用
CATALOG START WITH '/path/to/backup'注册进控制文件 - PDB在备份时刻是
READ ONLY，而RMAN默认跳过只读表空间（需加INCLUDE CURRENT CONTROLFILE或显式指定） - 如果只有全PDB备份，可改用
RESTORE DATABASE pdb1+SWITCH DATAFILE+RECOVER DATAFILE，但临时空间开销翻倍
恢复后必须验证的两个状态
表空间ONLINE不等于数据可用：
- 查
SELECT tablespace_name, status FROM dba_tablespaces WHERE tablespace_name = 'USERS' AND con_id = (SELECT con_id FROM v$pdbs WHERE name = 'PDB1');确认状态是ONLINE - 查
SELECT file_name, status FROM cdb_data_files WHERE tablespace_name = 'USERS' AND con_id = (SELECT con_id FROM v$pdbs WHERE name = 'PDB1');确认所有数据文件STATUS是ONLINE，没有MISSING或OFFLINE
最易被忽略的是：恢复完成后没检查v$archived_log是否覆盖到还原点之后——哪怕只缺一个归档，后续RECOVER就会卡住不动，且错误提示极不直观。
