ADG低延迟需配置LGWR SYNC AFFIRM并匹配SRL组数与大小，启用Real-Time Apply后验证MRP状态，备库须禁用QUERY_REWRITE_ENABLED且可评估关闭校验参数。
LGWR进程配置直接影响ADG同步延迟
主库用LGWR进程传输日志是ADG低延迟的前提，但默认的ASYNC模式只是“发完就不管”，实际网络抖动或备库I/O压力大会导致日志堆积。生产环境必须显式指定传输方式和确认机制：
-
SERVICE=orcldg LGWR SYNC AFFIRM：强制主库等待备库写入Standby Redo Log才返回提交成功，RPO≈0，但主库TPS会受网络RTT影响 -
SERVICE=orcldg LGWR ASYNC：适合跨城部署，需配合增大LOG_ARCHIVE_DEST_2的REOPEN值（如REOPEN=15）避免临时断连后归档中断 - 切忌混用
SYNC和ASYNC在同一个LOG_ARCHIVE_DEST_n里——Oracle不校验语法，但会导致ARCH进程异常退出
Standby Redo Log组数和大小必须匹配主库联机日志
ADG启用实时应用（Real-Time Apply）时，MRP进程直接从Standby Redo Log读取并应用，而不是等归档完成。如果组数不足或单组太小，会出现ORA-00313错误且MRP自动停止：
- 组数至少比主库联机日志多1组，例如主库有3组
ONLINE LOGFILE，备库应建4组STANDBY LOGFILE - 每组大小必须≥主库最大联机日志文件尺寸，否则日志无法完整写入，表现为
V$MANAGED_STANDBY中STATUS为WRITING但SEQUENCE#长期不推进 - 创建命令示例：
ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 ('+DATA') SIZE 1G;，注意路径必须指向ASM磁盘组且有足够空间
实时应用（Real-Time Apply）开启后必须验证MRP状态
很多人以为执行ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;就万事大吉，但MRP可能因权限、归档GAP或参数冲突静默退出：
- 检查
V$MANAGED_STANDBY中PROCESS='MRP0'且STATUS='APPLYING_LOG'，而非WAIT_FOR_LOG或IDLE - 若发现
THREAD#=0，说明MRP未绑定到任何线程——常见于RAC主库但备库未配置THREAD参数，需在备库SPFILE中补thread=1 - 禁用Broker管理时，不要依赖
DGMGRL的SHOW DATABASE VERBOSITY判断状态，它可能缓存旧信息；直接查视图更可靠
备库只读开放前必须关闭查询重定向（Query Rewrite）
ADG备库以READ ONLY WITH APPLY模式运行时，若主库启用了物化视图查询重写（Query Rewrite），备库会尝试解析主库的重写规则，但缺少主库物化视图日志（MLOG）元数据，导致大量ORA-12008错误并拖慢查询：
- 在备库执行
ALTER SYSTEM SET QUERY_REWRITE_ENABLED=FALSE SCOPE=BOTH;，这是硬性要求，不是可选项 - 即使备库没建物化视图，只要主库设了
QUERY_REWRITE_ENABLED=TRUE且通过DBLINK访问过主库对象，该参数就会被继承 - 该设置不影响备库自身创建的物化视图，只禁用对主库重写规则的依赖
ADG调优最易被忽略的是备库的db_block_checksum和db_lost_write_protect参数——它们默认开启，但在高吞吐场景下会引入额外CPU开销。若网络和存储已具备强一致性保障（如光纤直连+企业级SSD），可评估关闭，但务必先在非高峰时段做IO压测验证。
