深入理解Data Guard的日志传输机制_SYNC与ASYNC模式的性能对比

sync与async本质区别在于主库事务提交时是否等待备库rfs进程将redo写入磁盘：sync等待落盘后返回，async完全不等待；两者均需lgwr传输且依赖standby redo log。

sync 和 async 的本质区别在哪？

SYNC 不是“等备库应用完”，而是等备库的 RFS 进程把 redo record 写入磁盘（即写入 standby redo log 文件），就立刻返回确认；ASYNC 则完全不等，LGWR 提交事务前连网络发没发成功都不管。

• SYNC 模式下，LNS 进程从 redo buffer 实时抓取日志，边写 online redo log 边往外推，主库事务延迟直接受网络 RTT + 备库磁盘 I/O 影响
• ASYNC 模式下，LNS 跟不上时会自动降级去读 online redo log 文件发，所以即使备库短暂断连，主库也不卡
• 两者都依赖 LOG_ARCHIVE_DEST_n 中的 SYNC/ASYNC 属性，但必须搭配 LGWR（不能是 ARCH），否则谈不上实时性

常见错误现象：ORA-16198（timeout 掉线）、主库大量 log file sync 等待、DG Broker 显示 TRANSMIT STATUS = FAILED —— 很可能是因为用了 SYNC 却没配 NET_TIMEOUT 或备库磁盘太慢。

什么时候必须用 SYNC？又为什么很多人悄悄切回 ASYNC？

最大保护（MAXIMUM PROTECTION）模式强制要求 SYNC，且主库会在备库不可写时直接 shutdown；最大可用性（MAXIMUM AVAILABILITY）也用 SYNC，但允许临时降级为 ASYNC 维持主库运行。

• 如果主备之间跨公网或高延迟链路（比如 >10ms），SYNC 基本不可用：一个简单 INSERT/COMMIT 可能多出 50–200ms 延迟
• 备库若没配置 standby redo log，SYNC 会直接失败 —— 因为 RFS 没地方落盘，只能报 ORA-16055
• ASYNC 在主备网络抖动时更“耐操”：ARCH 进程会在恢复连通后自动补传归档，而 SYNC 断了就是断了，得靠 dba 手动干预

性能影响很实在：在 OLTP 高并发场景下，启用 SYNC 后 log file sync 平均等待时间可能翻 3–5 倍；ASYNC 下该指标基本和单机库持平。

怎么验证当前走的是 SYNC 还是 ASYNC？

别只看 LOG_ARCHIVE_DEST_2 里写了 SYNC，得确认实际生效路径：

• 查主库：select DEST_ID, TRANSMIT_MODE, AFFIRM, DATABASE_MODE FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;
  • TRANSMIT_MODE = 'SYNC' 且 AFFIRM = 'YES' 才是真 SYNC（写磁盘才确认）
  • 若 AFFIRM = 'NO'，哪怕写了 SYNC，也只是等 RFS 收到 network buffer 就返回（12c+ 支持，叫 SYNC NOAFFIRM，性能接近 ASYNC）
• 查备库：SELECT PROCESS, STATUS, CLIENT_PROCESS, Thread#, SEQUENCE# FROM V$MANAGED_STANDBY;
  • 看 PROCESS = 'RFS' 对应的 CLIENT_PROCESS 是 LNS（说明走 LGWR）还是 ARCH（说明实际退化成归档传输）

容易踩的坑：改完参数没 reload，或者忘了在备库开 STANDBY_FILE_MANAGEMENT=auto，导致 standby redo log 创建失败，SYNC 自动失效。

ASYNC 真的安全吗？数据丢失风险到底有多大？

ASYNC 不等于裸奔。它只是不阻塞主库提交，但日志依然会持续外送 —— 只是“尽力而为”。

• 最坏情况：主库刚写完一条 redo record 到 redo buffer，还没来得及刷盘或发送，主机就硬重启，这条记录就丢了
• 实测中，只要主库配置了合理大小的 LOG_BUFFER（比如 256MB）+ 快速刷盘策略，未发送的 redo 通常不超过几 MB，对应几秒事务量
• 关键点在于：ASYNC 仍依赖 LGWR 发送，不是 ARCH；如果误配成 ARCH + ASYNC，那宕机瞬间 online redo log 里的所有未归档内容全丢

真正危险的是“以为用了 SYNC，其实 fallback 到了 ASYNC”，比如备库磁盘满、standby redo log 权限不对、或者 NET_TIMEOUT 设得太小频繁超时 —— 这些状态不会自动告警，得靠定期查 V$DATAGUARD_STATS 里的 transport lag 和 apply lag。

DG 的传输机制看着绕，但核心就两条：主库愿不愿意等、备库有没有地方存。其余都是在这两个约束下的工程权衡。