根本原因是TCP缓冲区满导致DG探测包卡在内核层，而非Oracle心跳超时；需调大tcp_rmem/wmem max至16MB并配合SDU=32767，而非调整NET_TIMEOUT。

主库压力大时心跳超时，根本原因不是心跳本身慢，而是网络协议栈缓冲区被填满、tcp重传加剧、ack延迟堆积，导致data guard进程（如lnsn）发出去的探测包在内核层就卡住，备库根本收不到——这和oracle层面的net_timeout设置无关，是底层传输通道已淤塞。

为什么默认TCP缓冲区在DG场景下容易成为瓶颈

Oracle Data Guard日志传输（尤其LGWR ASYNC模式）是持续高吞吐、小包+大包混合的流量：redo块切片后频繁发送SDU大小的数据包（默认8KB），而Linux内核默认的net.ipv4.tcp_rmem和net.ipv4.tcp_wmem三元组（如4096 16384 4194304）在突发写压下极易触顶。一旦发送队列积压，ss -i会显示retrans上升、qdisc排队增长，LNSn进程虽已调用send()，但数据卡在socket send buffer里，心跳探测自然“石沉大海”。

• 典型现象：v$dataguard_stats中transport lag和apply lag同步跳涨，但log_archive_dest_status仍为VALID；netstat -s | grep "retransmitted"每秒递增
• 关键区别：这不是Oracle连接超时（如EXPIRE_TIME），而是TCP连接“活着但哑了”——SYN/ACK正常，但应用层数据无法透出
• 影响范围：仅作用于DG专用链路；若共用监听器，需通过tnsnames.ora中(SOURCE_ROUTE=yes)或独立服务名隔离

如何安全调大TCP接收/发送缓冲区

不能全局改/etc/sysctl.conf——会影响所有TCP连接，可能引发内存碎片或OOM Killer误杀。必须针对DG流量做流控级优化：

• 确认当前值：sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem，重点看第三个值（max）是否低于16MB
• 临时生效（验证用）：sysctl -w net.ipv4.tcp_rmem="4096 262144 16777216"，net.ipv4.tcp_wmem同理，将max设为16MB（16777216）
• 永久生效（仅限DG网卡）：在/etc/sysctl.conf中追加net.core.wmem_max = 16777216和net.core.rmem_max = 16777216，再用ip rule + ip route为DG网段打标记，配合tc qdisc限速保底
• 必须同步调整Oracle：tnsnames.ora中DG条目增加(SDU=32767)，否则内核缓冲区再大，Oracle Net层仍按8KB切片，徒增系统调用次数

为什么NET_TIMEOUT调小反而让问题更糟

NET_TIMEOUT控制的是LNSn进程级重试间隔，不是TCP超时。当网络缓冲区已满，把NET_TIMEOUT从30秒改成5秒只会让LNSn更频繁地尝试send()，进一步加剧socket send queue堆积，触发更多TCP重传和拥塞控制退避，形成恶性循环。

• 错误操作示例：ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=standby LGWR ASYNC NET_TIMEOUT=5';
• 正确做法：先确保tcp_wmem max ≥ 16MB，再观察ss -i输出中send-q是否稳定在100KB以内；此时NET_TIMEOUT保持默认30秒即可
• 隐藏风险：某些云厂商虚拟网卡（如AWS ENA）对tcp_rmem max有硬限制，强行设为32MB会导致send()返回EAGAIN，必须结合ethtool -g调大ring buffer

真正要盯住的不是Oracle参数，而是ss -i输出里的retrans、send-q和rtt三项——它们不撒谎。一旦发现rtt波动超过2倍基线值，或retrans非零且持续增长，说明协议栈缓冲区已经成了瓶颈，这时候再调Oracle参数，只是给堵车路口多装几个红绿灯。