必须在CDB$ROOT中执行RMAN恢复操作，不能在PDB会话中运行restore或recover命令；因RMAN元数据和控制流由CDB$ROOT统一管理，PDB会话下执行会报ORA-65023错误或误恢复根容器对象，正确做法是在CDB$ROOT连接下用pdb_name:tablespace_name格式显式指定目标，并验证表空间状态为ONLINE且数据文件无错误。
必须先在cdb$root中执行恢复操作，不能直接在pdb会话里运行restore或recover命令——这是最常踩的坑。
为什么不能在PDB里直接运行RMAN表空间恢复？
Oracle 19c的RMAN元数据和控制流完全由CDB$ROOT统一管理。即使你用ALTER SESSION SET CONTAINER = pdb1切进PDB，RMAN仍以CDB为上下文解析对象名。一旦在PDB session中执行restore tablespace users，RMAN会报错ORA-65023: active session exists for the container或直接忽略容器上下文，尝试恢复CDB根容器的USERS表空间（根本不存在）。
正确路径只有一条：所有RMAN命令必须在CDB$ROOT连接下发出，并显式指定PDB限定符。
恢复PDB中表空间的完整命令格式
关键点在于表空间名必须带PDB_NAME:TABLESPACE_NAME前缀，且RMAN需能识别该PDB当前状态（OPEN/MOUNTED/UNPLUGGED）。
- 确认PDB已加载但无需OPEN：
ALTER PLUGGABLE DATABASE pdb1 CLOSE;（避免恢复时被写入） - 检查备份是否存在对应表空间：
RMAN> list backup of tablespace pdb1:users; - 执行恢复（注意冒号和大小写）：
restore tablespace pdb1:users; - 应用归档日志完成介质恢复：
recover tablespace pdb1:users; - 切换回PDB并联机：
ALTER PLUGGABLE DATABASE pdb1 OPEN;（此时表空间自动ONLINE）
常见错误与绕过条件
遇到RMAN-06023: no backup or copy of datafile ... found to restore，不是备份丢了，而是RMAN没找到匹配的备份集——原因通常是：
- 备份时用了
backup pluggable database pdb1，但没单独备份该表空间，而restore tablespace pdb1:users要求有明确的表空间级备份片 - 备份片被
CATALOG START WITH漏掉，尤其当备份存放在非默认目录时，必须手动catalog注册 - PDB在备份时刻处于READ ONLY状态，而RMAN默认不备份只读表空间（需加
include current controlfile或显式指定）
如果只有全PDB备份，仍可恢复单个表空间：用set newname for datafile ... to ...配合restore database pdb1，再switch和recover目标文件，但临时空间开销翻倍。
恢复后必须验证的两个状态
表空间恢复成功不等于数据可用。务必检查：
-
SELECT con_id, tablespace_name, status FROM cdb_tablespaces WHERE tablespace_name = 'USERS' AND con_id IN (SELECT con_id FROM v$pdbs WHERE name = 'PDB1');—— 状态必须是ONLINE，不是RECOVER -
SELECT file#, status, error FROM v$datafile_header WHERE con_id = (SELECT con_id FROM v$pdbs WHERE name = 'PDB1') AND tablespace_name = 'USERS';—— 所有数据文件ERROR列为空，STATUS为ONLINE
跳过这两步验证，可能在后续业务访问时才暴露块损坏或SCN断层，那时已错过最佳重做时机。
