DG同步卡顿与网卡绑定关系不大，因其依赖TCP层质量而非物理网卡数量；真正影响因素是RTT、窗口大小、SACK及丢包恢复能力，网卡绑定仅用于防止单点故障，且需严格配置mode=1并确保两端一致。
为什么DG同步卡顿，和网卡绑定关系不大
oracle data guard 的传输稳定性主要取决于 tcp 层质量，不是物理网卡数量或是否绑定。常见误区是以为“绑两张网卡就能抗丢包”，但 dg 实际走的是 oracle 自己封装的 tcp 连接（lns/rfs），底层不感知 bonding 模式，更不支持跨 bond 接口的连接负载均衡。真正影响同步的是单条 tcp 流的 rtt、窗口大小、sack 和丢包恢复能力。
网卡绑定在DG中唯一有效的场景：避免单点物理故障
如果你用 bonding，目的只能是防止单根网线/单个交换机端口失效导致网络中断。此时必须满足：
- 使用
mode=1（active-backup），其他 mode（如 balance-rr、802.3ad）会导致 TCP 连接重置或乱序，DG 日志里频繁出现ORA-16198或ORA-12537 - 主备库两端 bonding 配置完全一致（包括 miimon、arp_interval、primary 设置）
- 交换机侧不能做链路聚合（LACP），否则会与 active-backup 冲突；若必须用 LACP，需改用
mode=4且确保所有路径 MTU 一致、无中间设备截断 TCP options - 绑定接口的 IP 必须用于
log_archive_dest_n中的 SERVICE 名称解析——也就是说，tnsnames.ora里写的 host 必须 resolve 到这个 bond IP，不能写物理网卡 IP
比绑定网卡更重要的三件事
真正决定 DG 同步稳定性的，是以下配置，优先级远高于 bonding：
-
tcp_rmem和tcp_wmem必须按带宽 × RTT 计算后调大，例如 1Gbps + 10ms RTT → BDP ≈ 1.25MB，对应net.ipv4.tcp_rmem="4096 262144 1310720"（第三项 ≥ BDP） -
net.ipv4.tcp_sack=1和net.ipv4.tcp_timestamps=1必须启用，否则单 segment 丢包就触发整块重传（DG 归档日志块常 >1MB） -
_tcp_fast_open隐含参数建议显式设为FALSE（通过alter system set "_tcp_fast_open"=false scope=spfile），某些内核版本下 TFO 与 DG 的重传逻辑不兼容
验证是否真需要绑定：先看 tcpping 和 v$dataguard_stats
别急着配 bonding，先确认问题根源：
- 用
tcpping -x 5 <standby_ip> 1521</standby_ip>替代 ping，测真实 TCP SYN 延迟。如果结果波动大（如 1ms～200ms 跳变），说明物理链路不稳定，才考虑 bonding - 查
v$dataguard_stats：若transport lag持续增长，但v$managed_standby中MRP0进程 CPU 很低，说明卡在主库发送端，和网卡无关，是 TCP 参数或网络设备问题 - 抓包看是否有重复 ACK 或 dup ACK：用
tcpdump -i bond0 port 1521 -w dg.pcap，Wireshark 打开后过滤tcp.analysis.retransmission，大量重传说明窗口或 SACK 失效
网卡绑定只是最后兜底手段，调错 TCP 参数或忽略中间设备对 TCP options 的截断，绑十张网卡也没用。
