ora-16198本质是tcp层不稳定信号，非oracle参数问题；须优先调优tcp_window_scaling、tcp_rmem/wmem（匹配bdp）、禁用_tcp_fast_open，并用tcpping验证真实网络质量。
ora-16198 不是必须修复的错误，而是网络质量不佳或配置不匹配的明确信号——直接调大 net_timeout 只是掩盖问题，真正要动的是 tcp 栈参数和传输模式选择。
为什么 NET_TIMEOUT 调到 60 还报 ORA-16198
这个参数只控制 LGWR 等待备库 ACK 的最长时间，它不解决底层 TCP 传不出去、收不到、窗口卡死的问题。常见误判是：看到日志里 NET_TIMEOUT=60 还报错，就继续加到 120，结果延迟更高、重传更频繁、LOG_ARCHIVE_DEST_2 长期处于 UNSYNCHRONIZED 状态。
根本原因往往在 OS 层：
-
tcp_window_scaling被禁用（sysctl net.ipv4.tcp_window_scaling = 0），导致最大接收窗口锁死在 64KB，高延迟链路（RTT > 10ms）下吞吐直接腰斩 - 中间设备（如防火墙、WAF）剥离了 TCP Options，使 window scaling 和 timestamp 失效
-
tcp_rmem第三项（max）小于带宽时延积（BDP），例如 1Gbps + 30ms RTT → BDP ≈ 3.75MB，但tcp_rmem设成"4096 262144 1048576"（1MB），内核被迫反复收缩通告窗口 - Oracle 12c+ 默认启用
_tcp_fast_open=TRUE，某些 Linux 内核（如 4.15–5.4）与 DG 的 LNS 重传逻辑冲突，触发假超时
检查真实网络质量，别信 ping
ping 测的是 ICMP，而 DG 走的是 Oracle 自定义协议封装在 TCP 上（端口通常是 1521 或自定义监听端口），ICMP 通 ≠ TCP SYN 通 ≠ Oracle 网络通道通。
必须用 tcpping 替代：
tcpping -x 5 1521
看输出的平均响应时间（ms）和丢包率。如果平均 > RTT 基线 2×，或丢包 ≥ 1%，NET_TIMEOUT 再大也救不了。
进一步确认 TCP 参数是否生效：
sysctl net.ipv4.tcp_timestamps net.ipv4.tcp_window_scaling<br>cat /proc/sys/net/ipv4/tcp_rmem<br>cat /proc/sys/net/ipv4/tcp_wmem
两个 tcp_* 必须为 1；tcp_rmem 输出第三项（max）应 ≥ 估算 BDP × 1.2。
同步模式下必须调整的三个关键参数
若必须用 LGWR SYNC（如最大保护模式），以下三处不调，NET_TIMEOUT 就是纸糊的：
- OS 层：
sysctl -w net.ipv4.tcp_window_scaling=1且确保中间设备不 strip TCP options - OS 层：
sysctl -w net.ipv4.tcp_rmem="4096 524288 4194304"和net.ipv4.tcp_wmem="4096 524288 4194304"（适配 1Gbps + ≤30ms RTT 场景） - Oracle 层：禁用有风险的优化，
ALTER SYSTEM SET "_tcp_fast_open"=FALSE SCOPE=SPFILE;（需重启）
注意：tcp_rmem 第三项必须 ≥ 第二项，否则内核静默忽略；永久生效写入 /etc/sysctl.conf 后运行 sysctl -p。
什么时候该放弃 SYNC，改用 ASYNC
不是所有场景都适合 SYNC。当出现以下任一情况，强行保 SYNC 只会放大故障面：
- 主备跨地域（RTT ≥ 50ms）、带宽 ≤ 100Mbps
- 备库 I/O 延迟波动大（
iostat -x 1中 %util 持续 > 90 或 await > 50ms） - 归档生成速率长期 > 传输能力（查
v$archived_log中first_time与next_time差值持续 > 30s）
ASYNC 模式下，NET_TIMEOUT 不再约束 LGWR，而是由 ARCH 进程异步推送，对网络抖动容忍度高得多。只需确保 FAL_SERVER 可达、log_archive_dest_2 中去掉 SYNC 和 AFFIRM，加上 ASYNC 即可。
真正容易被忽略的是：TCP timestamp 和 window scaling 在虚拟化环境（如 VMware、KVM）中常被 hypervisor 默认关闭，必须在 guest OS 和 host 网络策略两端同时确认。
