必须在CDB层面配置Data Guard，因Oracle不支持单个PDB独立搭建DG；日志传输、保护模式、FORCE LOGGING等均为CDB级操作，PDB状态（如OPEN）不自动同步，需手动干预且仅限READ ONLY。
如何在CDB中启用Data Guard并确保CDB级日志传输
必须先在cdb层面配置data guard，否则pdb状态无法被同步。oracle不支持仅对单个pdb单独搭建dg；alter database set standby database to maximize availability这类命令只作用于cdb容器，不是pdb。
常见错误是直接在PDB里执行ALTER PLUGGABLE DATABASE ... OPEN READ ONLY，结果主库PDB能开，备库PDB始终MOUNTED——因为日志没传过去。
- 主库和备库都必须以
CDB$ROOT身份启动，并确认V$DATABASE.OPEN_MODE为READ WRITE -
LOG_ARCHIVE_DEST_2的SERVICE必须指向备库的CDB监听名（如stby_cdb），不是某个PDB的服务名 - 检查
V$ARCHIVE_DEST_STATUS.STATUS是否为VALID，而非ERROR或INACTIVE - 务必启用
FORCE LOGGING：在CDB$ROOT下执行ALTER DATABASE FORCE LOGGING，否则PDB的DML可能不写归档
为什么备库PDB默认处于MOUNTED状态，而不是自动OPEN
这是Oracle 12c+的明确设计：Data Guard同步的是CDB的物理块，PDB的OPEN状态不复制。备库PDB不会随主库PDB自动OPEN，必须手动干预。
典型现象：SELECT CON_ID, NAME, OPEN_MODE FROM V$PDBS在备库返回MOUNTED，即使主库已是READ WRITE。
- 备库PDB只能在
RECOVER MANAGED STANDBY DATABASE暂停后才能OPEN，且必须加READ ONLY（不能READ WRITE） - 若需备库PDB提供只读查询，先停应用日志：执行
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL，再ALTER PLUGGABLE DATABASE pdb1 OPEN READ ONLY - 切回同步前，必须先
CLOSE IMMEDIATE该PDB，否则START APPLY会报错ORA-65115
如何为不同PDB设置独立的保护模式（如某些PDB要求最大保护，其余仅最大性能）
做不到。Data Guard的保护模式（MAXIMUM PROTECTION / MAXIMUM AVAILABILITY / MAXIMUM PERFORMANCE）是CDB级配置，绑定在LOG_ARCHIVE_DEST_2的SYNC/ASYNC和AFFIRM属性上，无法按PDB拆分。
如果业务真有混合RPO要求，唯一可行路径是拆成多个独立CDB，各自配DG。强行在一个CDB内混用，只会让高要求PDB降级，或低要求PDB被拖慢。
-
LOG_ARCHIVE_DEST_2设SYNC AFFIRM→ 全CDB走最大可用性，所有PDB都受约束 - 想给某PDB“降级”？不行。但可对该PDB停用归档：在CDB$ROOT执行
ALTER PLUGGABLE DATABASE pdb2 CLOSE IMMEDIATE，再ALTER PLUGGABLE DATABASE pdb2 UNPLUG INTO '/tmp/pdb2.xml'，物理隔离它 - 监控时别只看
V$DATAGUARD_STATS，要结合V$MANAGED_STANDBY.PROCESS和STATUS，确认LNS、RFS、MRP进程都在跑
切换后PDB服务名丢失或TNS连接失败怎么办
Switchover后，原备库变主库，但其listener.ora里的SID_LIST仍指向旧CDB名，且PDB服务名不会自动注册到监听器，导致客户端连不上service_name=pdb1。
错误信息典型为ORA-12514: TNS:listener does not currently know of service requested in connect descriptor。
- 在新主库（原备库）的
$ORACLE_HOME/network/admin/listener.ora中，确认SID_LIST_LISTENER包含当前CDB的ORACLE_SID，并重启监听：lsnrctl reload - PDB服务名需触发动态注册：确保新主库的
LOCAL_LISTENER参数正确，且ALTER SYSTEM REGISTER被执行过 - 检查
SELECT NAME, NETWORK_NAME FROM V$SERVICES，确认NETWORK_NAME列有对应PDB的服务名；若为空，执行ALTER PLUGGABLE DATABASE pdb1 SAVE STATE再启库
最易被忽略的一点：CDB级别的DB_UNIQUE_NAME在DG配置前后必须保持一致，哪怕PDB名字相同，只要CDB的DB_UNIQUE_NAME在主备端不匹配，ALTER DATABASE COMMIT TO SWITCHOVER就会卡在WAITING FOR GAP RESOLUTION——这个gap不是归档缺失，而是CDB身份校验失败。
