Oracle Data Guard强一致性不能仅靠修改LOG_ARCHIVE_DEST_n参数实现，必须闭环LGWR传输、网络确认及备库STANDBY REDO LOG接收与实时应用三要素，缺一不可。
oracle data guard 无法通过“切换参数”把异步模式临时转为同步模式来实现强一致性——这是常见误解。强一致性必须在传输路径上杜绝日志丢失，而异步模式（async）本身设计就允许主库不等待备库确认即提交，数据已注定存在窗口期。
为什么 LOG_ARCHIVE_DEST_n 的 VALID_FOR 和 SYNC/ASYNC 不是开关式配置
很多人以为改个 LOG_ARCHIVE_DEST_2 的 SYNC 就能“启用同步”，但实际生效取决于三要素是否闭环：传输进程（LGWR）、网络确认机制、备库日志接收能力。若主库仍用 ARCH 进程归档后才传日志，或 LOG_ARCHIVE_DEST_2 没绑定 LGWR，哪怕写上 SYNC 也无效。
-
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)是必要前提，否则 LGWR 不会触发该目标的传输 -
SYNC必须搭配NET_TIMEOUT（默认30秒）和REOPEN（失败后重试间隔），否则网络抖动直接降级为 DEFERRED - 备库必须启用
STANDBY REDO LOGS，且大小、组数 ≥ 主库 ONLINE REDO LOGS，否则 LGWR 无法持续推送
从异步到同步：不是改参数，而是重建传输链路
现有异步配置（如仅靠 ARC0 归档传输）下强行加 SYNC，ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='...' SCOPE=BOTH 会报错 ORA-16026 或备库 ARCH 进程卡在 WAIT_FOR_LOG 状态。真正要落地同步，得走 LGWR 通道重配：
- 停掉当前归档传输：执行
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER - 新增 LGWR 专用目标：例如
LOG_ARCHIVE_DEST_3='SERVICE=stdby19 LGWR SYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=stdby19' - 主库创建 standby redo log：至少比 online redo log 多一组，命令如
ALTER DATABASE ADD STANDBY LOGFILE SIZE 200M - 检查备库是否已启用了实时应用：
SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY WHERE PROCESS IN ('RFS','MRP0')；若MRP0为APPLYING_LOG才算链路通
SYNC 模式下容易被忽略的性能与容错临界点
同步模式不是“设了就稳”，它把网络延迟、备库 I/O 压力、redo buffer 写入节奏全部暴露给主库事务链路。几个硬指标必须盯住：
- 主库
v$system_event中log file sync平均等待时间超过 5ms，说明 LGWR 在等 RFS 回执，需查网络 RTT 或备库standby redo log切换是否频繁 - 备库
v$archive_dest_status的STATUS必须是VALID，ERROR字段为空；一旦出现ORA-16198（timeout），主库会自动切回ASYNC（如果配置了ALTERNATE） -
DB_LOST_WRITE_PROTECT应设为TYPICAL，否则主库可能因底层存储丢写误判备库已收到日志
真正决定强一致性的，从来不是参数名里有没有 “SYNC”，而是 LGWR 是否真把每笔 redo buffer 刷出、RFS 是否真落盘到 standby redo log、MRP 是否实时应用——这三步缺一不可。任何环节绕过（比如用归档代替在线日志传输，或备库没开实时应用），所谓“同步”只是纸面配置。
