在pdb内执行backup database最稳妥，需先切换容器至目标pdb再备份，仅备份该pdb自身数据文件、控制文件快照及spfile副本（若启用自动备份），不涉及cdb$root或其他pdb；归档日志须在cdb根下单独备份。
在PDB内执行BACKUP DATABASE最稳妥
直接连进目标PDB再备份，是唯一不依赖其他PDB状态、也不受RMAN通道配置“侥幸影响”的路径。你连进某个PDB后，BACKUP DATABASE就只备份它自己：数据文件、当前控制文件快照、SPFILE副本（如果启用了CONFIGURE CONTROLFILE AUTOBACKUP ON），不会碰CDB$ROOT或其他PDB。
操作步骤：
- 先用
sqlplus / as sysdba登录，执行ALTER SESSION SET CONTAINER = pdb1; - 再用
CONNECT / AS SYSBACKUP（推荐）或CONNECT / AS SYSDBA重连，确保上下文已切换 - 运行
BACKUP DATABASE FORMAT '/backup/pdb1_%U.bkp';
注意：BACKUP DATABASE PLUS ARCHIVELOG在PDB内执行时，归档日志不会被备份——归档日志始终是全CDB级别的，得在根下单独处理。
BACKUP PLUGGABLE DATABASE pdb_name必须满足三个前提
这条命令语法合法，但RMAN不会自动检查前提条件，缺一就会静默失败（比如只打印RMAN-06207: WARNING: no channels allocated for maintenance然后退出），导致你以为备份成功了，实际没生成任何备份集。
三个硬性前提：
- 必须在
CDB$ROOT中连接RMAN：即CONNECT TARGET /后未执行过ALTER SESSION SET CONTAINER - 目标PDB必须为
OPEN状态（查SELECT NAME, OPEN_MODE FROM V$PDBS WHERE NAME = 'PDB1';，不能是MOUNTED或READ ONLY） - RMAN必须已配置默认设备类型：
CONFIGURE DEFAULT DEVICE TYPE TO DISK;或TO SBT;，否则即使磁盘有空间，也会因找不到通道而失败
示例有效命令：BACKUP PLUGGABLE DATABASE pdb1 FORMAT '/u01/backup/pdb1_%U.bkp';
别踩BACKUP DATABASE在根下执行的坑
很多人误以为在CDB根下执行BACKUP DATABASE就能“选中”某个PDB，其实它只备份当前OPEN的PDB（不是所有PDB），且默认跳过MOUNTED状态的PDB。如果你运行该命令时，只有CDB$ROOT和PDB$SEED是OPEN的，那结果就是只备份这两个容器，你的业务PDB完全没进备份集。
常见错误现象：
- 执行完
BACKUP DATABASE，LIST BACKUPSET里找不到目标PDB的数据文件备份 - 恢复时报
no backup of datafile，但归档日志有备份——说明数据文件根本没被纳入 - 备份日志里出现
RMAN-06207却没报错，其实是通道没配，命令直接跳过
正确做法：要么显式写BACKUP PLUGGABLE DATABASE pdb1（并确保三前提满足），要么先ALTER PLUGGABLE DATABASE pdb1 OPEN;再跑BACKUP DATABASE。
备份后验证PDB是否真能独立恢复
VALIDATE BACKUPSET只校验备份集头和块校验和，不保证PDB元数据完整。真正有效的验证是模拟恢复路径：
运行RESTORE PLUGGABLE DATABASE mypdb PREVIEW，它会列出所需的所有备份片、归档日志及应用顺序。如果输出中包含ORA-65086错误，说明该PDB当前状态非法（比如UNPLUGGED或MOUNTED），即使备份集存在，也无法恢复。
容易被忽略的点：PDB恢复必须依赖CDB$ROOT和SYSTEM表空间可用，且SCN时间线需匹配源CDB；备份时若没同步归档日志覆盖到PDB变更点，PREVIEW也可能不报错，但实际恢复会卡在介质恢复阶段。
