必须在cdb$root中执行rman命令，不能在pdb会话中运行restore或recover操作，否则报ora-65023错误或误恢复cdb根容器对象；表空间恢复必须使用pdb_name:tablespace_name格式显式指定目标，并验证备份存在、权限正确及路径干净。
必须在CDB$ROOT中执行RMAN命令，不能切到PDB会话
所有 restore 和 recover 操作都必须在 CDB$ROOT 连接下运行，哪怕你已经用 ALTER SESSION SET CONTAINER = pdb1 切进去了。RMAN 不认 PDB 上下文，强行在 PDB 里执行会报 ORA-65023 或静默恢复 CDB 根容器的同名对象（比如把 USERS 当成 CDB 的表空间去还原）。
常见错误现象：
- RMAN 报
ORA-65023: active session exists for the container -
restore tablespace users成功但数据没回来——它恢复的是 CDB$ROOT 的USERS，不是你的 PDB
正确做法只有一条：连上 / as sysdba，确认 SELECT SYS_CONTEXT('USERENV', 'CON_NAME') FROM DUAL 返回 CDB$ROOT，再操作。
表空间恢复必须带 pdb_name:tablespace_name 前缀
RMAN 要靠这个格式识别目标，否则根本找不到备份片。比如你要恢复 PDB1 的 USERS 表空间，命令必须写成：
restore tablespace pdb1:users;
注意大小写和冒号位置——pdb1:USERS 或 PDB1:users 都可能失败，因为 RMAN 匹配严格区分大小写，且依赖 DBA_PDBS.CON_NAME 中的实际值。
实操前务必验证备份存在：
-
list backup of tablespace pdb1:users;—— 如果返回空，说明没做过该表空间级备份 - 若只有全 PDB 备份，得用
set newname+restore database pdb1，但会多占一倍临时空间 - 备份时 PDB 是
READ ONLY状态？默认不备份只读表空间，需加include current controlfile
误删整个 PDB 后不能直接 recover pluggable database
Oracle 19c 不支持这个命令，RMAN-06813: could not translate pluggable database 就是典型报错。DROP 操作清空了 CDB_PDBS 元数据，RMAN 失去目标标识，备份片还在，但“不认识”那个 PDB 了。
必须分两步走：
- 先用
restore controlfile→restore database until time '...'→recover database until time '...'把整个 CDB 回滚到删除前一刻（时间点必须早于drop pluggable database ... including datafiles执行时刻） - 完成后数据库处于
MOUNT状态，show pdbs还看不到被删的 PDB，但它已回到数据字典里 - 再选一种提取方式：
flashback pluggable database pdb1 to before drop（最快，但依赖闪回区保留）、create pluggable database pdb1 using '/path/pdb.xml'（需提前 unplugged）、或手动 copy 数据文件重建
恢复后 ONLINE 前必须校验权限与路径
表空间恢复成功 ≠ 数据可用。ALTER DATABASE DATAFILE ... ONLINE 之前，两个检查缺一不可：
- 文件权限：Oracle 进程（如
oracle用户）对还原后的数据文件要有读写权限，否则报ORA-01157: cannot identify/lock data file - 路径干净：如果误删后有人用
touch或空文件占位，RMANrestore会失败；必须先rm /oradata/CDB1/PDB1/users01.dbf，再执行还原
特别注意：PDB 的 SYSTEM 表空间文件丢失，不要和 CDB$ROOT 的 SYSTEM 混淆——它们物理路径不同，定位要靠 SELECT CON_ID, FILE_NAME FROM CDB_DATA_FILES WHERE TABLESPACE_NAME = 'SYSTEM' 查出对应 CON_ID 再操作。
