不能用BACKUP DATABASE备份单个PDB，因为它始终备份整个CDB（含root和所有PDB），与连接方式无关；必须显式使用BACKUP PLUGGABLE DATABASE mypdb，且要求该PDB处于OPEN或MOUNT状态，否则报ORA-65086。
为什么不能用 BACKUP DATABASE 备份单个PDB
因为 backup database 总是备份整个 cdb（包括 root 和所有 pdb），哪怕你用 sys@mypdb 连接上去。rman 不会根据连接点自动缩小范围——它只认当前实例的容器上下文，而目标实例仍是 cdb。想只备一个 pdb，必须显式写 backup pluggable database mypdb，否则就是全量冗余操作。
如何给高优先级 PDB 分配独立通道和压缩策略
Oracle 19c 不支持按 PDB 设置全局配置（如 CONFIGURE 级别的压缩或并行度），所有配置都是 CDB 级别生效。但你可以在 run { } 块里为不同 PDB 的备份任务手动分配通道并指定压缩方式：
- 先
ALLOCATE CHANNEL c1 DEVICE TYPE DISK，再BACKUP AS COMPRESSED BACKUPSET PLUGGABLE DATABASE hrpdb - 紧接着
ALLOCATE CHANNEL c2 DEVICE TYPE DISK，再BACKUP AS COMPRESSED BACKUPSET PLUGGABLE DATABASE finpdb - 若需更高压缩率，确保已启用许可：
CONFIGURE COMPRESSION ALGORITHM 'ADVANCED'；否则即使写了AS COMPRESSED BACKUPSET，实际仍走BASIC - 注意：每个
ALLOCATE CHANNEL必须顶格、无空格、成对出现在run { }内，否则报RMAN-01009
PDB 备份顺序与资源竞争怎么协调
当多个 PDB 同时进 run { } 块，RMAN 按语句顺序调度，但实际执行受通道数量和 SECTION SIZE 影响。容易踩的坑：
- 如果对大 PDB 使用
SECTION SIZE=500M，而只配了 2 个通道，但拆出 6 个 section，后 4 个会排队——此时应设CONFIGURE DEVICE TYPE DISK PARALLELISM 6或在run中分配足够通道 - 低优先级 PDB（如测试库）建议避开业务高峰，用
SET COMMAND ID TO 'low_prio'配合 OS 层 CPU 限制（如cgroups），避免抢占高优 PDB 的 I/O 资源 -
BACKUP PLUGGABLE DATABASE不支持INCREMENTAL LEVEL 1，所有 PDB 级备份都是全量。若想减小窗口，只能靠BACKUP TABLESPACE pdb1:users这类表空间粒度操作，但恢复时需额外处理依赖关系
备份后如何验证某个 PDB 是否可独立恢复
VALIDATE BACKUPSET 只校验备份集头和块校验和，不保证 PDB 元数据完整。真正有效的验证是模拟恢复路径：
- 运行
RESTORE PLUGGABLE DATABASE mypdb PREVIEW，它会列出所需的所有备份片、归档日志及应用顺序 - 若输出中包含
ORA-65086错误，说明该 PDB 当前状态非法（如UNPLUGGED或READ ONLY），需先ALTER PLUGGABLE DATABASE mypdb OPEN或MOUNT - 注意：PREVIEW 不检查物理文件是否存在，仅验证 RMAN 目录逻辑链。真正执行前仍需确认备份片在磁盘上可读且未被
DELETE OBSOLETE清理
OPEN 或 MOUNT 才能被 BACKUP PLUGGABLE DATABASE 接受，而很多自动化脚本在调度时并不检查这个前提——结果是备份静默跳过或报错中断，但日志里只有一行 ORA-65086，极易被监控漏捕。 
