sync模式下事务提交变慢是因为主库lgwr必须等待备库确认（如affirm）后才完成commit，直接将网络rtt、备库i/o延迟及抖动风险引入提交路径，导致阻塞；async则不等待，提交耗时仅取决于本地log file sync。
SYNC模式会让主库事务提交延迟明显升高，ASYNC基本无感知；差异不是“多少毫秒”，而是“是否阻塞提交”这个根本逻辑。
SYNC模式下事务提交为什么会变慢
主库的 LGWR 进程必须等备库返回确认（AFFIRM 或 NOAFFIRM），才允许本地事务完成 COMMIT。这意味着：
- 网络 RTT（哪怕同城 2ms）直接叠加进事务响应时间
- 备库 I/O 延迟（如磁盘写入慢、SRL 空间不足）会卡住所有同步事务
- 一旦网络抖动或备库短暂不可达，主库可能报错
ORA-16198或直接 hang 住（取决于LOG_ARCHIVE_DEST_n的REOPEN和DELAY设置） - 高并发 OLTP 场景下，这种等待会放大成锁争用和 log file sync 等待事件飙升
ASYNC模式实际性能表现如何
ARCH 或 LGWR ASYNC 不参与事务提交流程，主库只管归档或发日志，不等任何反馈：
- 事务提交耗时几乎等于本地
log file sync时间，不受备库状态影响 - 备库延迟通常在秒级（取决于网络带宽、redo 生成速率、备库应用能力）
- 主库即使完全断开备库，也不会报错或降级——除非你显式配置了
VALID_FOR或MANDATORY属性 - 但要注意：
ASYNC+NOAFFIRM仍可能丢数据，比如主库写完网络缓冲区就宕机，而日志还没真正发出去
log_archive_dest_n 中 SYNC/ASYNC 的关键参数组合
真正起作用的是 SYNC/ASYNC 和 AFFIRM/NOAFFIRM 的组合，不是单看传输方式：
-
SYNC AFFIRM：最安全，也最慢。要求日志落盘到备库 SRL 才返回，RPO=0，但对网络和备库 I/O 要求极高 -
SYNC NOAFFIRM：折中方案。只要日志抵达备库内存（未落盘）就返回，延迟比AFFIRM低，但存在极小概率丢数据（备库断电） -
ASYNC AFFIRM：不合法组合，Oracle 会忽略AFFIRM，实际按ASYNC NOAFFIRM行为运行 -
ASYNC NOAFFIRM：默认行为，性能最好，但 RPO 可能达几十秒甚至分钟级（尤其大事务+网络拥塞时）
实测中容易被忽略的瓶颈点
很多人只盯着网络延迟，却忽略了这些隐性开销：
-
DB_BLOCK_SIZE和STANDBY_FILE_MANAGEMENT配置不当，会导致备库 apply 阶段卡住，反过来拖慢主库LGWR在SYNC模式下的确认速度 - 主库未启用
ENABLE_PLUGGABLE_DATABASE且备库是 CDB 架构时，SYNC模式下部分 PDB 切换可能失败，错误信息是ORA-16664 -
LOG_ARCHIVE_DEST_2中漏配VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)，导致主库误用归档路径，引发归档失败连锁反应 - 使用
Far Sync实例时，它本身不存数据，但若其所在节点 CPU 或网络打满，SYNC流量照样卡住——它只是个转发跳板，不是性能黑洞吸收器
真正决定性能差异的，从来不是“SYNC vs ASYNC”这四个字母，而是你是否清楚每一处 log_archive_dest_n 参数背后的真实 I/O 路径、确认时机和故障传播逻辑。
