必须用LIST BACKUP OF PLUGGABLE DATABASE pdb1才能查到PDB备份，因默认LIST BACKUP只查CDB$ROOT（CON_ID=0）范围；PDB备份元数据归属其专属CON_ID，不显式指定容器则“隐身”，且PDB须处于OPEN或READ ONLY状态才可被识别为有效备份目标。
为什么RMAN备份PDB后LIST BACKUP没显示？
不是备份失败，而是你没在正确的上下文里查——list backup默认只查cdb$root范围内的备份记录，而pdb级备份（如backup pluggable database pdb1）的元数据虽然存在，但不会自动“透出”到cdb$root的全局视图中，除非显式指定容器。
- 执行
BACKUP PLUGGABLE DATABASE pdb1时，RMAN确实在CDB$ROOT下完成操作，但备份集描述符（BP_KEY、BS_KEY等）仍归属该PDB的逻辑上下文，LIST BACKUP不加限定时只返回CDB$ROOT自身对象的备份 - 想看到PDB的备份，必须用
LIST BACKUP OF PLUGGABLE DATABASE pdb1，否则它就“隐身”了 - 如果连这个命令也查不到，先确认PDB是否处于OPEN或READ ONLY状态——MOUNTED或UNPLUGGED的PDB无法被RMAN识别为有效备份目标，
BACKUP会静默跳过或报RMAN-06004
为什么BACKUP TABLESPACE pdb1:USERS成功却查不到？
表空间级备份对容器感知更敏感。即使命令执行成功，LIST BACKUP OF TABLESPACE USERS依然找不到，因为没带PDB前缀；而LIST BACKUP OF TABLESPACE pdb1:USERS才是唯一能命中它的语法。
-
LIST BACKUP OF TABLESPACE USERS→ 查CDB$ROOT的USERS表空间（很可能不存在），返回空 -
LIST BACKUP OF TABLESPACE pdb1:USERS→ 正确路径，但注意：PDB名和表空间名大小写敏感，且PDB名必须与V$PDBS.NAME完全一致（比如PDB1≠pdB1） - 实操中常因漏掉双引号导致失败：
BACKUP TABLESPACE pdb1:TEST报错，必须写成BACKUP TABLESPACE pdb1:"TEST"（Oracle 12.1+要求）
备份记录存在但LIST不显示的底层原因
RMAN的备份元数据存于控制文件，但不同容器的数据块归属关系由CON_ID字段标记。CDB$ROOT的V$BACKUP_SET视图默认过滤CON_ID = 0，而PDB备份的CON_ID是其对应PDB的ID（如3、4等），所以不显式限定就查不到。
- 验证方式：在CDB$ROOT中运行
SELECT CON_ID, SET_STAMP, SET_COUNT FROM V$BACKUP_SET WHERE CON_ID > 0，能看到PDB备份的真实CON_ID - 恢复时不用操心这个——
RESTORE TABLESPACE pdb1:USERS内部会自动按CON_ID匹配，但查询必须手动带上下文 - 如果你启用了恢复目录（recovery catalog），
LIST行为会不同：目录表RC_BACKUP_SET默认包含所有容器，但前提是注册时已同步PDB元数据（RESYNC CATALOG需在CDB$ROOT执行）
最容易被忽略的检查点
备份命令返回“completed”不代表元数据已落盘——尤其在高负载或控制文件写入延迟时，LIST可能滞后几秒。别急着重跑，先SLEEP 5再查；更关键的是，确认当前SQL*Plus或RMAN session的CON_NAME确实是CDB$ROOT，而不是误连进了某个PDB（SHOW CON_NAME必须输出CDB$ROOT）。
