Oracle 23ai Data Guard低延迟关键在于LGWR实时推送、网络RTT
Oracle 23ai 中 Data Guard 链路的延迟主要卡在日志传输路径和网络配置上，不是靠调大 LOG_ARCHIVE_DEST_2 的 REOPEN 值就能解决的。
物理备库启用实时应用时，USING CURRENT LOGFILE 必须配对 SYNC 传输模式
异步（ASYNC）下即使开了实时应用，备库仍会等归档完成才开始接收新日志，导致秒级延迟；而 SYNC 模式让 LGWR 直接将日志块推到备库并等待确认，才能写入本地 Online Redo Log。这要求：
– 主库 LOG_ARCHIVE_DEST_2 必须设为 SYNC NOAFFIRM（若用 AFFIRM 会强制写备库磁盘，放大网络抖动影响）
– 备库监听必须启用 DEDICATED 连接模式，避免共享服务器线程排队
– 网络往返时间（RTT）需稳定低于 5ms，否则 LGWR 会频繁超时并退化为 ARCH 传输
检查 v$archive_dest_status 里的 gap_status 和 transmit_mode
延迟问题常被误判为“同步慢”，实际是传输中断后形成归档缺口（gap）。执行以下查询能快速定位：
SELECT dest_id, dest_name, status, gap_status, transmit_mode,
delay_mins, apply_lag FROM v$archive_dest_status
WHERE dest_id = 2;
重点关注：
– gap_status 显示 RESOLVABLE GAP 或 ERROR：说明归档序列断连，需手动补传或重建日志流
– transmit_mode 是 ARCH 而非 LGWR：表示日志传输已降级，检查主库是否因网络重试失败自动切回 ARCH 模式
– apply_lag 持续 > 0：不是传输问题，而是备库 MRP 进程应用慢，需查 v$managed_standby 中 PROCESS 为 MRP0 的 STATUS 是否为 APPLYING_LOG
Oracle 23ai 新增的 FASTSYNC 传输模式比传统 SYNC 更适合低延迟场景
FASTSYNC 是 23ai 引入的优化模式，它保留 SYNC 的零丢失语义，但不等待备库写盘确认，只等日志块接收成功即返回主库。这对跨可用区部署特别关键：
– 配置方式：将 LOG_ARCHIVE_DEST_2 的 SYNC 替换为 FASTSYNC，例如：ALTER SYSTEM SET LOG_ARCHIVE_DEST_2 = 'SERVICE=standby_db FASTSYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=standby_db';
– 不兼容旧版 Oracle：备库也必须是 23ai，否则启动时报错 ORA-16778
– 不能与 DELAY 参数共存，否则会被忽略
– 实测在 Azure 同一区域不同可用区间，FASTSYNC 下平均 apply_lag 可压至 200ms 内，而传统 SYNC 在网络波动时容易跳到 800ms+
备库端启用 ADG 并限制只读查询负载，避免 I/O 竞争拖慢 MRP
Active Data Guard 允许物理备库开放只读访问，但默认不限制并发查询量。一旦报表类 SQL 大量扫描表空间，会抢占 DBWn 和 LGWR 的 I/O 带宽，直接拖慢 MRP0 的日志应用速度：
– 必须设置 ALTER SYSTEM SET STANDBY_MAX_DATA_DELAY = 0; 强制 MRP 优先级高于用户会话
– 对只读用户使用资源管理器限制 CPU 和 I/O：BEGIN DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA(); ... END;
– 关闭 PARALLEL_EXECUTION_MESSAGE_SIZE 的自动扩展，防止并行查询突发占用大量 PGA
真正影响低延迟的，从来不是参数名是否带 “fast” 或 “sync”，而是 LGWR 是否真正在推、网络是否真正在收、MRP 是否真正在跑——三者中间任一环节被阻塞，apply_lag 就会不可控地漂移。
