根本原因是Oracle默认TCP/IP行为在高延迟链路下放大开销:缓冲区填满才发包、小包合并等待、无压缩传输、DNS反复查询;必须同时配置sqlnet.compression=on、sqlnet.compression_threshold=2048、tcp.nodelay=yes(protocol.ora),并改用IP直连、禁用反向DNS。
根本原因不是带宽低本身,而是oracle默认的tcp/ip行为在高延迟、低带宽链路上放大了开销:缓冲区填满才发包、小包合并等待、无压缩传输、dns反复查询。这些在局域网里不显眼,但在4g/卫星链路或跨国专线(rtt >150ms)下会把一次简单查询拖到秒级。
只改一端效果有限,尤其当客户端是Navicat、JDBC或旧版ODBC时,服务端配置才是兜底关键:
sqlnet.compression = on:开启SQL*Net层压缩,low级别足够,high在ARM服务器上反而CPU吃紧sqlnet.compression_threshold = 2048:只压缩≥2KB的数据包,避免小结果集(如单行查询)频繁启停压缩上下文tcp.nodelay = yes:写入protocol.ora(非sqlnet.ora),跳过Nagle算法,让每个小包立即发出,对交互式查询提升最明显注意:protocol.ora需放在$ORACLE_HOME/network/admin/下,权限644,且必须由监听器进程可读;JDBC驱动不读protocol.ora,但服务端启用后所有客户端都受益。
CONNECT_TIMEOUT和RECV_TIMEOUT在11g及更早版本完全无效,写了反而可能因语法错误导致tnsnames解析失败;12cR1+才真正生效,但只管TCP连接建立和接收,对DNS卡顿毫无作用。
真正该做的:
tnsnames.ora里的主机名全换成IP地址,或确保/etc/hosts(Linux/macOS)或C:WindowsSystem32driversetchosts(Windows)有对应条目——这是绕过慢DNS最稳的方式SQLNET.EXPIRE_TIME:空闲保活probe在弱网下极易丢包重传,徒增首次连接延迟MyDB.example.com和mydb.example.com视为不同域名,缓存未命中JDBC Thin驱动不读sqlnet.ora,所有网络行为靠URL参数控制:
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=mydb)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=orcl))) → 改成(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.10.5)(PORT=1521))
...?oracle.net.disableOob=true&oracle.net.compression=on&oracle.net.compressionThreshold=2048
System.setProperty("oracle.net.disableOob", "true")(需在DriverManager.getConnection前执行)最关键的一点:不要指望sqlnet.ora能统一管控JDBC行为——它只影响OCI、ODBC和sqlplus,Java得自己填参数。
慢速网络下真正起效的从来不是“调优”,而是砍掉所有非必要环节:关DNS查、关反向解析、关Nagle、开压缩、用IP直连。这些改动都不需要重启数据库,reload监听器或重启应用即可验证。