必须在cdb$root中执行rman表空间恢复命令，并显式指定pdb_name:tablespace_name前缀；否则rman默认作用于cdb$root，可能覆盖根容器同名表空间导致库崩溃，且需满足cdb mount、pdb未drop、备份存在三个硬条件。
必须在CDB$ROOT中执行，且命令里要带pdb_name:tablespace_name前缀，否则大概率覆盖CDB$ROOT的同名表空间，直接搞崩根容器。
为什么RESTORE TABLESPACE USERS会出事
你在PDB里连进RMAN，或者用tnsnames.ora指向PDB的服务名连接，RMAN实际仍跑在CDB上下文里，默认作用域是CDB$ROOT。USERS在CDB里可能根本不存在，也可能指向根容器的USERS表空间。一旦执行RESTORE TABLESPACE USERS，RMAN就真去还原CDB的USERS——轻则ORA-01950报错，重则覆盖关键系统对象。
常见错误现象包括：RMAN-06023（找不到备份）、RMAN-06026（跳过所有文件）、或静默还原了CDB的SYSTEM文件。
- 必须先确认当前容器：
SELECT SYS_CONTEXT('USERENV', 'CON_NAME') FROM DUAL，结果得是CDB$ROOT - 不能用
tnsnames.ora里带PDB服务名的连接串，得用CDB实例名（如orcl） - OS用户必须是
oracle，且ORACLE_SID、ORACLE_HOME已正确加载
RESTORE TABLESPACE pdb1:USERS的硬性前提
这条命令不是“写了就能跑”，三个条件缺一不可：
- CDB必须处于
MOUNT状态（STARTUP MOUNT），PDB不需要OPEN，但建议先ALTER PLUGGABLE DATABASE pdb1 CLOSE IMMEDIATE - PDB不能已被
DROP（SHOW PDBS里还能看到它） - 备份集中必须存在该PDB表空间的备份——注意：不是非得单独做过
BACKUP PLUGGABLE DATABASE，只要CDB全备里含pdb1:USERS的数据即可
执行前务必验证：LIST BACKUP OF TABLESPACE pdb1:USERS。如果返回空，说明备份链缺失，后续RESTORE必失败。
RESTORE和RECOVER必须成对出现，顺序不能反
RESTORE TABLESPACE pdb1:USERS只负责把备份片里的文件拷到磁盘，不应用归档日志；RECOVER TABLESPACE pdb1:USERS才真正做前滚/回滚。漏掉RECOVER，数据文件就是“冷备份态”，ALTER PLUGGABLE DATABASE pdb1 OPEN时会报ORA-01113或ORA-01157。
- 不要手动
ALTER DATABASE DATAFILE ... ONLINE——RECOVER会自动处理offline/online状态 - 归档日志必须完整覆盖目标SCN，否则
RECOVER报ORA-19505或ORA-19625 - 如果
FAST_RECOVERY_AREA空间不足，RECOVER启动辅助实例时会卡住，需显式加AUXILIARY DESTINATION '/some/path'
恢复后PDB打不开？先查这三件事
执行完RECOVER TABLESPACE，ALTER PLUGGABLE DATABASE pdb1 OPEN失败，不是恢复失败，而是状态没同步到位。
- 查路径是否一致：
SELECT FILE_NAME FROM DBA_DATA_FILES WHERE TABLESPACE_NAME = 'USERS' AND CON_ID = (SELECT CON_ID FROM V$PDBS WHERE NAME = 'PDB1')，比对RMAN输出的restored file路径 - 确认所有相关数据文件都已
RECOVER完成（比如pdb1:USERS有多个数据文件，LIST BACKUP OF TABLESPACE能看全） - 检查
V$RECOVER_FILE是否有未完成项，或SELECT * FROM V$ARCHIVED_LOG确认归档日志链是否断开
最易被忽略的是：表空间名大小写和引号——backup tablespace pdb1:test会报错，必须写pdb1:"TEST"（大写+双引号），否则RMAN解析失败。
