Oracle 19c中Data Guard仅作用于CDB层，不支持单个PDB独立同步；因物理备库依赖块级复制与CDB整体一致性，PDB无独立数据文件集且共享SYSTEM/SYSAUX/UNDO，其容灾行为完全继承自CDB。
Oracle 19c 中无法直接配置“PDB 级 Data Guard”——Data Guard 始终作用于 CDB 层，PDB 本身不参与角色切换或日志传输决策。 所有 PDB 的容灾行为完全继承自其所在 CDB 的物理 standby 状态。想保护某个 PDB，必须把整个 CDB（含所有 PDB）纳入 DG 架构。
为什么不能只同步单个 PDB？
物理 standby 是块级复制，依赖主库的控制文件、数据文件、在线日志和归档日志整体一致性。PDB 在物理层没有独立的数据文件集（除部分元数据外），它与 CDB 共享 SYSTEM、SYSAUX、UNDO 表空间；ALTER PLUGGABLE DATABASE 操作本身也生成 CDB 级重做。因此 Oracle 不支持对单个 PDB 启用独立的 redo 传输或应用进程。
常见误解场景：
- 误以为在主库上只 open 某个 PDB，就能让备库也只同步该 PDB —— 实际上备库
STARTUP MOUNT后，所有 PDB 都处于MOUNTED状态，且恢复进程（MRP）始终作用于整个 CDB。 - 试图在备库上
ALTER PLUGGABLE DATABASE pdb1 OPEN READ ONLY而其他 PDB 保持 mounted —— 这是允许的（Active Data Guard 功能），但前提是整个 CDB 已完成日志应用，且该 PDB 未被排除在恢复之外（即没被ALTER DATABASE RECOVER MANAGED STANDBY DATABASE SKIP）。
实际可行的 PDB 容灾策略
所谓“PDB 级容灾”，本质是通过 CDB 级 DG + 精细管控实现的间接效果。关键操作点如下：
- 主库 CDB 必须启用
FORCE LOGGING，且所有 PDB 默认继承该设置（无需单独为 PDB 开启）。 - 备库 CDB 的
DB_UNIQUE_NAME必须与主库不同，但DB_NAME必须一致（这是 DG 同步前提）。 - 若仅需保障某几个 PDB 的可用性，可在备库上关闭无关 PDB 的自动打开：修改备库初始化参数
enable_pluggable_database=TRUE后，在spfile中添加alter system set "_excluded_pdb_names"='PDB2,PDB3' scope=spfile;（注意：该隐含参数仅影响 OPEN 阶段，不影响日志应用）。 - 验证 PDB 级一致性：主库执行
ALTER PLUGGABLE DATABASE pdb1 CLOSE IMMEDIATE;后立即切日志，备库应能正常应用该 SCN 后的所有日志；之后在备库ALTER PLUGGABLE DATABASE pdb1 OPEN READ ONLY;应成功，且查询结果与主库一致。
容易踩的坑：PDB 名称与 TNS 连接错位
主备库 PDB 名称必须严格一致（大小写敏感），否则备库 OPEN 时会报 ORA-65096: invalid common user or role name 或连接时提示 TNS-12514: Service not found。
- 检查主库 PDB 名称：
SELECT NAME, CON_ID, OPEN_MODE FROM V$PDBS; - 确认备库监听中服务名是否包含对应 PDB：监听器日志里出现
Service "pdb1.skedudg" has 1 instance(s)才表示注册成功（其中skedudg是备库DB_UNIQUE_NAME）。 - tnsnames.ora 中连接串的
SERVICE_NAME必须拼写为pdb1.<db_unique_name></db_unique_name>，例如：SERVICE_NAME = pdb1.skedudg；不能写成pdb1.skedudb（主库名）。
最易被忽略的是：当主库 CDB 中新增 PDB 后，备库不会自动创建同名 PDB，也不会自动应用该 PDB 的初始数据文件。必须手动在备库执行 CREATE PLUGGABLE DATABASE ... FROM ... RELOCATE 或使用 RMAN DUPLICATE，再启动 MRP 恢复。否则该 PDB 在备库始终为 MOUNTED 且无数据——这不是同步失败，而是根本没纳入同步范围。
