Oracle 12c Data Guard不支持为单个PDB设置日志传输优先级。LGWR按CDB粒度发送redo流，所有PDB共享同一传输通道，无法在DG层面区分redo发送顺序或带宽分配。
不能单独为某个PDB配置Data Guard——Data Guard是CDB级机制，所有PDB自动包含在内。 试图“只保护XEPDB1而不保护PDB$SEED”或“只为一个PDB建备库”在Oracle 12c+中根本不可行，任何尝试都会失败或产生未定义行为。
为什么PDB无法独立参与Data Guard
Data Guard同步的是整个CDB的物理块变更，不是按PDB粒度拆分的逻辑单元。重做流（Redo Stream）来自CDB实例，包含所有PDB的事务日志，备库收到后也只能以CDB为单位应用。即使你只在某个PDB里执行DML，生成的redo仍会写入CDB全局的redo log组，无法被过滤或路由到“仅该PDB”的备库。
常见误解场景：
- 误以为
ALTER PLUGGABLE DATABASE XEPDB1 CLOSE IMMEDIATE后，Data Guard就“跳过”该PDB —— 实际上备库仍会同步其数据文件头、控制文件变更等元数据，且OPEN状态不一致会导致ORA-16789或ORA-16664 - 试图在备库上只
ALTER PLUGGABLE DATABASE XEPDB1 OPEN READ ONLY而保持其他PDB MOUNT —— 备库必须整体OPEN（或MOUNT），PDB打开状态由CDB统一控制 - 用
CREATE PLUGGABLE DATABASE ... FROM ...@dblink复制单个PDB到远端 —— 这是克隆，不是Data Guard，无实时同步、无角色切换能力
CDB级Data Guard对PDB的实际影响
启用Data Guard后，所有PDB的行为由CDB主/备角色决定，但仍有几个关键点需手动对齐：
- 主库上新建PDB（如
CREATE PLUGGABLE DATABASE pdb2 ADMIN USER...）会自动生成对应redo，备库自动创建同名PDB并处于MOUNT状态；但若主库用FILE_NAME_CONVERT指定了非默认路径，备库必须提前创建对应目录，否则ALTER DATABASE RECOVER MANAGED STANDBY DATABASE会报ORA-01119 - PDB级别的
FORCE LOGGING无效，必须在CDB ROOT执行ALTER DATABASE FORCE LOGGING，否则PDB内DML可能不生成足够redo，导致备库数据块不一致 - 备库上PDB的
OPEN_MODE取决于CDB启动方式：STARTUP后所有PDB默认MOUNT；需显式执行ALTER PLUGGABLE DATABASE ALL OPEN READ ONLY（物理备库）或ALTER PLUGGABLE DATABASE ALL OPEN（快照备库） - 主库执行
ALTER PLUGGABLE DATABASE XEPDB1 UNPLUG INTO '/tmp/xepdb1.xml'不会触发redo传输，备库不会自动删除对应PDB——这是元数据操作，需人工干预
想实现“PDB级容灾隔离”，替代方案有哪些
如果业务确实需要某PDB故障不影响其他PDB（例如开发PDB出问题不能拖垮生产PDB），原生Data Guard做不到，只能换架构：
- 把关键PDB拆成独立CDB：每个PDB升级为单独的CDB实例，各自配独立Data Guard。代价是资源开销翻倍、管理复杂度上升，但隔离性最强
- 用GoldenGate做逻辑复制：针对特定PDB内的表级对象配置捕获和投递，支持异构、跨版本、部分对象同步，但不保证块级一致性，且DDL支持有限（如
ALTER TABLE ... MOVE可能丢失） - 结合OCI或云厂商服务：例如Oracle Cloud Infrastructure的Database Service允许为每个DB系统（即CDB）单独启停，配合网络ACL可实现逻辑隔离，但底层仍是CDB级DG
最易被忽略的一点：当主库CDB发生Failover后，所有PDB的DBID和CON_ID不变，但CON_UID会变——这意味着基于CON_UID做权限绑定或审计策略的应用，在切换后可能失效，必须提前验证。
