主库必须开启归档和FORCE LOGGING，否则备库无法接收日志；RAC环境需统一用DG Broker管理，监听器须静态注册GLOBAL_DBNAME=＜db_unique_name＞_DGMGRL，物理备库必须配置Standby Redo Log并启用实时应用，多租户下DG仅在CDB层级生效。
主库必须开启归档和FORCE LOGGING
不满足这两项，备库连日志都收不到，后续所有配置都是空谈。归档模式保证重做日志可被传输，FORCE LOGGING堵住NOLOGGING操作导致的数据不一致漏洞。
常见错误现象：ORA-01278（无法创建standby log）、V$ARCHIVE_DEST_STATUS.STATUS显示ERROR或INACTIVE、备库V$ARCHIVED_LOG无新日志记录。
- 归档模式需在MOUNT状态下启用：
ALTER DATABASE ARCHIVELOG，之后OPEN -
ALTER DATABASE FORCE LOGGING必须执行，且确认V$DATABASE.FORCE_LOGGING = 'YES' - RAC环境所有节点共享同一
DB_UNIQUE_NAME，且该值不能是默认ORCL
RAC主库必须用Data Guard Broker统一管理
手动改LOG_ARCHIVE_DEST_2或在单个RAC节点上执行ALTER DATABASE切换，必然失败。RAC多实例日志输出需DMON进程协调，否则出现ORA-16789或ORA-16664。
Broker不是“可选增强”，而是RAC+DG的强制依赖路径。
- 主备库监听器必须静态注册
GLOBAL_DBNAME = <db_unique_name>_DGMGRL.<domain>，否则dgmgrl连接直接报ORA-12154 -
LOG_ARCHIVE_CONFIG必须双向声明，例如'DG_CONFIG=(rac_prim,rac_stby)' - 创建配置时
CONNECT IDENTIFIER填的是tnsnames.ora中定义的服务名，且该服务名对应监听必须注册了_DGMGRL全局名
物理备库必须配齐Standby Redo Log（SRL）并启用实时应用
SRL不是“建议配置”，而是LGWR SYNC/ASYNC传输模式正常工作的硬性前提。缺SRL会导致MRP进程卡在WAIT_FOR_LOG，延迟飙升甚至中断同步。
即使备库已OPEN READ ONLY，若SRL未就位或未启用实时应用，查询结果仍可能滞后数分钟甚至更久。
- SRL组数 ≥ 主库Online Redo Log组数 + 1，大小 ≥ 主库最大日志文件尺寸
- 启动实时应用必须用：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT（注意是USING CURRENT LOGFILE，不是NOREDO） - 验证是否生效：查
V$MANAGED_STANDBY.PROCESS中RFS和MRP0状态均为APPLYING_LOG，且V$DATAGUARD_STATS.DELAY_MINS = 0
多租户（PDB）环境下不能单独为某个PDB配DG
所有DG机制都在CDB层级运行，PDB内执行任何DG命令都会报ORA-65040。所谓“单PDB容灾”本质是架构误用——业务隔离需求没被CDB满足，不该在DG上硬凑。
强行在一个CDB里混用不同保护模式，只会让高要求PDB降级，或拖慢低要求PDB提交。
-
LOG_ARCHIVE_DEST_2的SERVICE参数必须指向备库CDB的监听名（如stby_cdb），绝不能填PDB服务名（如pdb1_stby） - 备库PDB默认
MOUNTED，要只读必须先CANCEL恢复，再ALTER PLUGGABLE DATABASE ... OPEN READ ONLY，最后CLOSE IMMEDIATE才能重新启动同步——漏掉CLOSE IMMEDIATE是自动化脚本最常踩的坑 - 真有混合RPO需求，合规路径只有拆成多个独立CDB，各自配一套DG
最关键的细节藏在监听器配置里：Broker启动时依赖_DGMGRL服务名，而这个服务名不会自动注册，必须手工加到listener.ora静态注册段。很多环境卡在ORA-12154就栽在这一步，查tnsnames.ora能连通不代表Broker能连通。
