Oracle 19c 的 Data Guard 不支持为单个 PDB 单独配置物理备库——物理备库粒度始终是 CDB 级别，不是 PDB 级别。你无法让 hr_pdb 有自己独立的备库，而 fin_pdb 用另一个。

为什么不能只为一个PDB建物理备库

物理备库基于块级重做应用，依赖整个 CDB 的控制文件、数据文件和归档流。PDB 是逻辑隔离单元，不拥有独立的重做日志、控制文件或归档路径。RMAN DUPLICATE、ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 等所有底层机制都面向 CDB 实例，而非某个 PDB 子集。

常见误解来源：误把“在备库上只打开某几个 PDB”当成“只为这几个 PDB 同步”。实际上，所有 PDB 都随 CDB 一起被复制和恢复，只是你可以选择性地 ALTER PLUGGABLE DATABASE ... OPEN。

• 主库上新增 PDB → 备库会自动创建同名 PDB（需 standby_file_management=AUTO）
• 主库上删除 PDB → 备库不会自动删除，但该 PDB 将处于 MOUNTED 状态且无有效数据文件，不可用
• 主库上执行 ALTER PLUGGABLE DATABASE hr_pdb CLOSE IMMEDIATE → 备库上对应 PDB 状态不变，仍为 MOUNTED 或 READ ONLY，不受影响

替代方案：按业务需求隔离同步范围

若目标是“仅同步特定 PDB 的变更”，必须放弃物理备库，改用逻辑复制方案：

• DBMS_LOGSTDBY 不再推荐，19c 中已标记为废弃
• 真正可行的是 Oracle GoldenGate 或 Oracle Data Pump + 自定义增量脚本，但它们不提供 RPO=0 保障
• GoldenGate 可以精确到表级过滤，通过 TABLE hr_pdb.EMPLOYEES 这类语法限定捕获范围，但需在源端启用补充日志：ALTER PLUGGABLE DATABASE hr_pdb ADD SUPPLEMENTAL LOG DATA;
• 注意：GoldenGate 对 PDB 的支持要求主备端 CDB 版本一致，且 PDB 名称在主备间必须相同（hr_pdb 不能在备库叫 hr_stby）

如果坚持用物理DG，必须接受CDB整体同步

所谓“为特定 PDB 配置 DG”，实际只能做到以下三点：

• 主库 CDB 启用归档 + FORCE LOGGING + STANDBY REDO LOG（全局生效，无法按 PDB 开关）
• 使用 RMAN DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE NOREDO NOFILENAMECHECK 克隆整个 CDB
• 备库启动后，手动关闭不需要的 PDB：ALTER PLUGGABLE DATABASE fin_pdb CLOSE IMMEDIATE;，再只打开目标 PDB：ALTER PLUGGABLE DATABASE hr_pdb OPEN READ ONLY;
• 后续主库对 fin_pdb 的任何 DML 仍会生成重做并传到备库，只是备库上该 PDB 处于 CLOSED 状态，MRP 进程跳过其数据文件应用（但归档日志仍持续接收并堆积）

这种“选择性打开”不减少网络带宽或存储开销，只是降低备库内存与进程占用。真正被忽略的只有打开状态下的查询负载，而非同步本身。

最容易被忽略的权限与路径陷阱

即使你只关心一个 PDB，以下检查项一个都不能少，否则 RMAN DUPLICATE 直接失败：

• 主库 TNS alias 必须能解析到 CDB root，不能指向 PDB service_name；否则 CONNECT TARGET 报 ORA-12514
• 主库密码文件必须复制到备库，且 REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE；PDB 没有独立密码文件
• 备库初始化参数中 db_unique_name 必须与主库不同，但 db_name 必须相同；PDB 名称不影响这个规则
• 如果主库用 ASM，备库也必须用 ASM，且磁盘组名、冗余模式、AU size 必须一致；否则 NOFILENAMECHECK 也无法绕过 ORA-17502

最后强调：没有“PDB 级 Data Guard”这回事。所有声称支持的文档，要么混淆了逻辑复制与物理 DG，要么把 Broker 的 PDB 级开关操作当成了同步粒度控制。真实世界里，同步单位就是 CDB。