首页 > 数据库 >Oracle 12c PDB备份后为何CDB中查不到记录？

Oracle 12c PDB备份后为何CDB中查不到记录？

来源：互联网 2026-07-10 08:31:09

oracle资讯合集

Oracle12c中PDB备份后LISTBACKUP无记录，因默认查询CDB$ROOT，需指定LISTBACKUPOFPLUGGABLEDATABASEpdb1。PDB须处于OPEN状态，表空间备份需加PDB前缀且大小写敏感，底层由CON_ID字段区分。

如果遇到过这种情况：刚跑完BACKUP PLUGGABLE DATABASE pdb1，心情还不错，结果敲了个LIST BACKUP，发现啥也没有。别急着怀疑补丁打错了——这不是备份失败，而是你在错误的“上下文”里查。先记住一个原则：list backup默认只查CDB$ROOT（也就是CON_ID=0）范围内的备份记录。PDB级别的备份，元数据有自己的专属CON_ID。如果不显式告诉RMAN“我要看PDB的”，它就自动隐身了。而且，这还有个附加条件：PDB必须处于OPEN或READ ONLY状态，RMAN才承认它是个有效的备份目标。

为什么RMAN备份PDB后LIST BACKUP没显示？

不是备份失败，而是你没在正确的上下文里查——list backup默认只查cdb$root范围内的备份记录，而pdb级备份（如backup pluggable database pdb1）的元数据虽然存在，但不会自动“透出”到cdb$root的全局视图中，除非显式指定容器。

Oracle 12c PDB备份后为何CDB中查不到记录？

长期稳定更新的攒劲资源： >>>点此立即查看<<<

执行BACKUP PLUGGABLE DATABASE pdb1时，RMAN确实是在CDB$ROOT下操作的，但备份集的描述符（BP_KEY、BS_KEY这些）归属到的是那个PDB的逻辑上下文。LIST BACKUP不加限定时只返回CDB$ROOT自身的对象。
想看PDB的备份，必须用LIST BACKUP OF PLUGGABLE DATABASE pdb1，否则它就是不显示，没商量。
如果连这个命令也查不到，那就先看看PDB是不是挂掉了——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是它的专属ID（比如3、4之类的），你没指定要查它，它自然不出现。

验证方法很直接：在CDB$ROOT里跑一句SELECT CON_ID, SET_STAMP, SET_COUNT FROM V$BACKUP_SET WHERE CON_ID > 0，你会看到PDB备份的真实模样。
恢复的时候倒不用担心这个——RESTORE TABLESPACE pdb1:USERS内部会自动按CON_ID去匹配。但查询这一步，你必须手动带上上下文。
如果用了恢复目录（recovery catalog），情况会不同。目录表RC_BACKUP_SET默认是包含所有容器的，但前提是注册时已经同步了PDB元数据。而且RESYNC CATALOG必须在CDB$ROOT执行才能做对。