确认带宽不足需先排除干扰：若V$DATAGUARD_STATS中transport lag持续大于apply lag，且主库V$ARCHIVE_DEST_STATUS显示STATUS=VALID、ERROR为空、TRANSMIT_MODE=LGWR，则问题在传输层；再用iftop或ss实测吞吐，结合ping -s 1472/8972对比丢包率，辅以tshark抓包验证MTU与包长，最终定位物理链路瓶颈。
网络带宽不足是Data Guard日志传输延迟最常被误判为“配置问题”的真实瓶颈——尤其在LGWR ASYNC模式下，它不报错、不中断，只默默堆积，直到备库ARCH进程卡在"waiting for archive log"。
怎么确认真是带宽不够，而不是配置或IO问题？
先排除其他干扰，再聚焦带宽：
- 查
V$DATAGUARD_STATS：如果transport lag持续大于apply lag，说明日志根本没传到备库，问题在主库发送端，和备库I/O无关 - 查主库
V$ARCHIVE_DEST_STATUS中STATUS为VALID但ERROR为空，且TRANSMIT_MODE是LGWR，基本可锁定传输层 - 用
iftop -P tcp或ss -i实时看主库到备库IP的TCP连接吞吐：单连接长期稳定在10~20MB/s以下（千兆网卡理论上限约110MB/s），而主库LOG_ARCHIVE_DEST_2配置了ASYNC=256K，却只跑出几MB/s，就是带宽或链路限制 - 对比
ping -s 1472 -c 10 <standby_ip></standby_ip>和ping -s 8972 -c 10 <standby_ip></standby_ip>：后者丢包率明显升高，说明MTU不一致或中间设备不支持巨帧，实际有效带宽被大幅压缩
LGWR ASYNC下哪些参数直接影响带宽利用率？
不是配了ASYNC就等于“快”，缓冲区、超时、重试三者必须协同：
-
ASYNC=256K必须显式指定：默认值是0（即同步），漏写等于白配；数值不宜过大（如1M），否则单次网络抖动导致重传数据量翻倍 -
NET_TIMEOUT=30：默认180秒太长，短暂抖动会卡住整个LGWR线程；设为30能快速失败并触发重传，避免阻塞归档生成 -
REOPEN=60：必须配，且不能设成0或过大；60秒是平衡故障恢复与重试频率的合理值，REOPEN=0会导致归档永久挂起 - 主库
LOG_BUFFER建议≥100MB：小LOG_BUFFER（如默认几MB）会频繁触发LGWR写入，把网络等待放大成大量小包，严重降低吞吐
为什么调了参数还是慢？检查这三处物理链路
很多团队调完LOG_ARCHIVE_DEST_2就以为搞定，结果流量根本没走预期路径：
- 查交换机端口是否开启Jumbo Frames：仅服务器设
mtu=9000没用，show interface里必须看到jumbo frames enabled，否则所有>1500字节包都会被分片或丢弃 - 抓包验证真实包长：
tshark -i eth1 -f "tcp port 1521" -T fields -e frame.len | sort -u，若输出全是1500左右，说明链路某处（通常是交换机或防火墙）强制截断，巨帧未生效 - 确认TCP接收缓冲区足够：
cat /proc/sys/net/core/rmem_max应≥25165824（24MB），否则内核收包后立即丢弃，重传激增；改完需重启数据库实例，LMS/RFS进程启动时才读该值
别忽略压缩——但它只对ARCH有效，LGWR不压缩
这是最容易被混淆的一点：
-
LOG_ARCHIVE_DEST_2加COMPRESSION=ENABLE对LGWR传输完全无效，Oracle明确不支持LGWR路径压缩（19c文档ID 2678129.1） - 压缩只作用于ARCH模式：需配合
ARCHIVE_LAG_TARGET和足够多的LOG_ARCHIVE_MAX_PROCESSES（建议8~12），否则压缩本身反而成为CPU瓶颈 - 真要压带宽，唯一办法是换传输模式：从LGWR切到ARCH + 压缩 + 高并发归档进程，但RPO会从秒级退化到分钟级，业务必须能容忍
真正卡住Data Guard带宽的，往往不是参数本身，而是你没看到的那层——交换机MTU开关、内核缓冲区大小、甚至网卡驱动是否启用jumbo_frames。调参前先抓包，看包长；调参后看transport lag是否回落，别只盯着apply lag。一旦发现transport lag始终高于apply lag，问题一定在主库到备库这段路上，不在数据库内部。
