必须在CDB$ROOT中执行RMAN表空间恢复，不能在PDB会话中运行；因RMAN元数据和控制流由CDB$ROOT统一调度，PDB下执行会报ORA-65023或误恢复根容器对象；正确做法是连接CDB$ROOT后显式使用pdb_name:tablespace_name格式（如restore tablespace pdb1:users），并确保表空间先脱机、归档日志链完整、恢复后验证状态。
必须在CDB$ROOT中执行，不能进PDB会话运行
Oracle 19c+ 的 RMAN 表空间恢复完全由 CDB$ROOT 统一调度，哪怕你要恢复的是 pdb1 里的 users 表空间，也绝不能先 ALTER SESSION SET CONTAINER = pdb1 再进 RMAN。否则会报 ORA-65023，或更隐蔽地把命令解析成对 CDB 根容器对象的操作——而根容器根本没有那个表空间，导致静默失败或恢复错目标。
正确做法是：确保当前连接的是 CDB$ROOT（用 SELECT SYS_CONTEXT('USERENV', 'CON_NAME') FROM DUAL 验证返回值为 CDB$ROOT），然后在 RMAN 中显式写 restore tablespace pdb1:users。冒号前的 PDB 名必须大小写、拼写完全一致，且该 PDB 当前状态需为 MOUNTED 或 OPEN（不建议 OPEN 状态下恢复，可先 ALTER PLUGGABLE DATABASE pdb1 CLOSE）。
表空间必须先脱机，再还原+前滚+联机
RMAN 的 restore tablespace 和 recover tablespace 不会自动处理表空间在线状态。如果表空间处于 ONLINE，直接执行 restore 会报 ORA-01157 或卡住；recover 则可能因数据文件被写入而应用不完整重做。
所以四步顺序不可颠倒：
- 在 SQL*Plus 中执行
ALTER TABLESPACE pdb1:users OFFLINE IMMEDIATE;（注意：PDB 名前缀只在 RMAN 命令中用，SQL 里不加） - 进入 RMAN，执行
restore tablespace pdb1:users; - 紧接着执行
recover tablespace pdb1:users;（这一步会自动找归档日志；若缺归档，会停在ORA-00279，不是报错就退出） - 最后回到 SQL*Plus，执行
ALTER PLUGGABLE DATABASE pdb1 OPEN;（表空间随 PDB OPEN 自动 ONLINE）
归档日志链断裂是最常见失败原因
recover tablespace 失败，90% 是因为归档日志不连续。RMAN 不会跳过缺失的归档，也不会提示“缺哪个”，只会卡在恢复阶段不动，或报模糊错误如 ORA-19921、RMAN-06023（后者常被误判为备份不存在，其实是归档找不到）。
验证方法：
- 查
v$archived_log，确认从数据文件脱机时刻到你期望恢复的时间点之间，所有SEQUENCE#都存在且DELETED = 'NO' - 检查
log_archive_dest_1路径是否可读，权限是否为oracle:oinstall - 如果归档分散在多个目录，用
CATALOG START WITH '/path/to/arch'让 RMAN 重新识别
补救方式只有两个：从其他节点拷贝缺失归档，或改用 SET UNTIL SCN 指定一个已知归档覆盖到的 SCN 点（比如用 SELECT MIN(FIRST_CHANGE#) FROM v$archived_log WHERE SEQUENCE# >= X 反推）。
恢复后必须验证表空间和数据文件状态
命令跑完不代表数据可用。表空间恢复成功后，立刻查两处：
-
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 -
SELECT file#, name, status, error FROM v$recover_file WHERE con_id = (SELECT con_id FROM v$pdbs WHERE name = 'PDB1');——ERROR列必须为空，STATUS为ONLINE
最容易被忽略的是：即使这两项都 OK，如果原表空间里有只读数据文件（比如历史归档表空间），而备份时没加 INCLUDE CURRENT CONTROLFILE，恢复后它仍会保持 READ ONLY，但业务应用可能默认它可写——这种隐性不一致比报错更危险。
