LOG_ARCHIVE_DEST_2未配ASYNC或缓冲过小会导致ARCH卡在waiting for archive log；LGWR默认同步，须显式设LGWR ASYNC=256K、禁用AFFIRM、调大LOG_BUFFER至100M以上，并配置NET_TIMEOUT=30、REOPEN=60。
LOG_ARCHIVE_DEST_2没配ASYNC或ASYNC值太小，主库ARCH卡住
主库归档进程（ARCH）长时间停留在 waiting for archive log，本质是归档传输被阻塞。如果用了 LGWR 但没显式加 ASYNC，Oracle 默认走同步模式，每写一个日志块都等备库确认，网络抖动直接拖垮主库吞吐。更隐蔽的是写了 ASYNC 却没给缓冲区大小，比如只写 LGWR ASYNC 而漏掉 ASYNC=256K，此时 Oracle 用默认极小缓冲（通常 4KB），频繁触发小包发送，TCP开销翻倍。
实操建议：
- 必须显式指定缓冲大小：
LGWR ASYNC=256K（19c 推荐 256K–1M，根据网络 MTU 和延迟调） - 禁用
AFFIRM（除非在最高可用性模式下且能接受log file sync延迟） - 确认
LOG_ARCHIVE_DEST_2中VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)，避免误配成ALL_LOGFILES导致本地归档也走网络
NET_TIMEOUT 和 REOPEN 参数设得太严，网络抖动引发重传风暴
NET_TIMEOUT 不是“超时就断”，而是“连续多少秒收不到 ACK 就触发重连”。默认 180 秒看似宽松，但实际中若网络偶发丢包、防火墙会话老化、中间设备限速，会导致 LGWR 频繁重试，日志堆积在 standby redo log 缓冲区，V$DATAGUARD_STATS 显示 transport lag 持续上涨。
实操建议：
- 将
NET_TIMEOUT=30（单位秒），让短暂抖动快速恢复，不累积失败状态 -
REOPEN=60（非默认的 300），缩短故障后重连间隔，避免长等待 - 搭配
DELAY=0（禁用人为延迟），否则即使网络通了也会强制挂起
主库 LOG_BUFFER 太小，放大网络等待影响
LOG_BUFFER 是内存中 redo 的暂存区。若设得太小（如默认几 MB），高并发 OLTP 下 LGWR 频繁刷盘，每次刷都触发一次网络发送请求。网络稍慢，LGWR 就卡在 log file sync，进而拖慢事务提交，形成负反馈循环。
实操建议：
- OLTP 场景下
LOG_BUFFER至少设为100M（19c 可安全设到 200–500M） - 观察
V$SYSSTAT中redo buffer allocation retries是否 > 0，>0 说明 buffer 不够用 - 不要盲目调大——过大会增加 crash recovery 时间，需结合
_log_io_size和 I/O 吞吐实测
备库端未启用归档压缩，WAN 传输带宽吃紧
跨机房或云上部署时，归档日志明文传输极易打满带宽。Oracle 12c+ 支持 COMPRESSION=ENABLE，对 redo 日志做轻量级压缩（LZ4 级别），实测压缩率 30%–60%，且 CPU 开销极低（LOG_ARCHIVE_DEST_2 上配，备库自己不会压缩接收流。
实操建议：
- 主库执行：
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=standby LGWR ASYNC=256K NET_TIMEOUT=30 REOPEN=60 COMPRESSION=ENABLE' SCOPE=BOTH; - 确认主库
COMPATIBLE≥ '12.1.0'，否则该参数无效 - 压缩只作用于网络传输段，备库存储的归档文件仍是明文，不影响恢复逻辑
网络参数调优不是堆配置，关键在闭环验证：改完后盯紧 V$DATAGUARD_STATS 的 transport lag 和 apply lag 差值，再查 V$MANAGED_STANDBY 看 PROCESS 状态是否稳定在 WRITING 或 APPLYING_LOG。任何“看起来好了”的配置，没跑过真实流量峰值，都不算真正生效。
