BACKUP DATABASE在CDB根下只备份当前OPEN状态的容器：CDB$ROOT、PDB$SEED及会话连接时处于OPEN模式的PDB；MOUNT或READ ONLY状态的PDB不会被备份，需先ALTER PLUGGABLE DATABASE pdb1 OPEN再执行备份。
BACKUP DATABASE 在 CDB 根下到底备了哪些容器
执行 BACKUP DATABASE 时，RMAN **只备份当前 OPEN 状态的容器**：CDB$ROOT、PDB$SEED，以及会话连接时恰好处于 OPEN 模式的 PDB（不是所有 PDB）。如果其他 PDB 处于 MOUNT 或 READ ONLY 状态，它们的数据文件根本不会进入备份集。
常见错误现象：RMAN-06207 警告或备份完成后发现某个 PDB 恢复失败——实际是它压根没被备份过。
- 用
SELECT NAME, OPEN_MODE FROM V$PDBS;确认目标 PDB 状态 - 若需全备，必须先
ALTER PLUGGABLE DATABASE pdb1 OPEN;，再运行BACKUP DATABASE - 不建议依赖“自动包含所有 PDB”，这是默认行为里最危险的假设
如何单独备份一个 PDB
不能在 CDB 根容器中直接执行 BACKUP PLUGGABLE DATABASE pdb1 ——这条命令语法合法但**必须满足三个硬性前提**，缺一不可，否则静默跳过或报错 ORA-65040。
真正可靠的方式是：切换到该 PDB 上下文后再备份。
- 先用
sqlplus / as sysdba登录，执行ALTER SESSION SET CONTAINER = pdb1; - 再用
CONNECT / AS SYSBACKUP（或SYSDBA）重连，确保 RMAN 会话绑定到该 PDB - 此时运行
BACKUP DATABASE，只备份 pdb1 的数据文件、SPFILE 副本（若启用了CONFIGURE CONTROLFILE AUTOBACKUP ON）和控制文件快照 - 注意：
BACKUP DATABASE在 PDB 内执行时，完全不涉及 CDB$ROOT 或其它 PDB
RMAN 配置中容易被忽略的多租户陷阱
很多 DBA 按单机库习惯配置 RMAN，但在多租户环境下，某些配置项作用域会出人意料。
-
CONFIGURE RETENTION POLICY是全局生效的，但恢复时需按容器指定目标（如RESTORE PLUGGABLE DATABASE pdb1），不能跨容器混用 -
CONFIGURE CONTROLFILE AUTOBACKUP ON在 CDB 根下启用后，每次备份都会生成 CDB 级控制文件快照，**不会为每个 PDB 单独生成** -
CONFIGURE DEFAULT DEVICE TYPE TO SBT_TAPE和云备份参数（如PARMS 'SBT_LIBRARY=...'）必须在 CDB 根下配置，PDB 内无法覆盖或重新设置 - 归档日志备份（
BACKUP ARCHIVELOG）始终覆盖整个 CDB，但还原时仍要指定容器上下文
备份归档日志与恢复时的容器边界
归档日志本身是 CDB 级资源，BACKUP ARCHIVELOG ALL 或 PLUS ARCHIVELOG 总是备份全 CDB 的归档，这点没问题。但恢复阶段必须严格区分容器边界。
- 想恢复 pdb1 到某时间点？必须先
RESTORE PLUGGABLE DATABASE pdb1，再RECOVER PLUGGABLE DATABASE pdb1 - 不能在 CDB 根下执行
RECOVER DATABASE来恢复某个 PDB —— 它只会尝试恢复 CDB$ROOT - 如果使用恢复目录（recovery catalog），确保其版本与 CDB 版本兼容；PDB 元数据由 CDB 控制文件统一记录，catalog 不感知 PDB 粒度
多租户备份真正的复杂点不在语法，而在于容器状态、上下文切换、恢复路径三者的耦合——任何一个环节脱离预期状态，备份就等于没做。
