针对你遇到的这个Oracle ODBC在Unix下的网络超时检测问题，我结合Oracle官方文档和实际运维经验来给你拆解分析：

一、默认超时参数的来源位置 #

你使用的oracle-instantclient11.2-odbc-11.2.0.4.0-1驱动，其超时行为并非完全由ODBC标准的connection_timeout/lock_timeout参数控制，大部分是继承自Oracle Net Services的底层配置，具体位置如下：

• sqlnet.ora配置文件：这是Oracle网络通信的核心配置文件，默认路径为$ORACLE_HOME/network/admin；如果是Instant Client环境，也可能在TNS_ADMIN环境变量指向的目录，或者用户主目录下的~/.sqlnet.ora。
  其中和网络超时直接相关的关键参数：
  • SQLNET.RECV_TIMEOUT：控制Oracle Net等待接收数据库服务器数据的时长（单位：秒），11gR2版本默认值为0（无限等待）
  • SQLNET.SEND_TIMEOUT：控制Oracle Net等待向数据库服务器发送数据的时长（单位：秒），默认同样为0
  • TCP.CONNECT_TIMEOUT：控制TCP连接建立阶段的超时（单位：秒），默认60秒，但仅作用于连接初始化阶段，和你遇到的查询执行中网络中断无关
• ODBC驱动自身参数：在odbc.ini或odbcinst.ini中，Oracle ODBC支持扩展参数，比如Connection Timeout（对应ODBC标准的SQL_ATTR_CONNECTION_TIMEOUT）和Query Timeout（对应SQL_ATTR_QUERY_TIMEOUT），默认值均为0（无超时）。由于你当前的odbc.ini未配置这些参数，所以驱动使用的是默认的无限等待逻辑。

二、17分钟超时延迟的根因 #

你遇到的17分钟才检测到网络中断，本质上是操作系统TCP层的Keepalive机制在起作用，而非Oracle的默认配置。

当Oracle Net的SQLNET.RECV_TIMEOUT设为0时，驱动不会主动检测连接存活状态，而是依赖Unix系统的TCP Keepalive参数来发现连接失效。不同Unix系统的默认Keepalive参数组合通常是：

• tcp_keepalive_time：连接空闲后开始发送探测包的时长（比如部分Linux系统默认600秒/10分钟）
• tcp_keepalive_intvl：每次探测包的间隔时长（默认75秒）
• tcp_keepalive_probes：探测失败后重试的次数（默认6次）

总检测时长就是tcp_keepalive_time + tcp_keepalive_intvl * tcp_keepalive_probes，计算下来刚好接近17分钟，这就是你遇到的延迟来源。

三、优化建议 #

要缩短网络中断的检测时间，你可以从三个层面调整：

1. 配置Oracle Net主动超时：在sqlnet.ora中添加以下参数（时长根据业务需求调整）：

   SQLNET.RECV_TIMEOUT=300  # 5分钟，超过该时间未收到数据则判定连接失效
   SQLNET.SEND_TIMEOUT=300
   

2. 设置ODBC查询超时：在odbc.ini的对应DSN配置中添加：

   QueryTimeout=120  # 2分钟，查询执行超过该时长则主动终止
   

3. 调整系统TCP Keepalive参数：如果需要更底层的控制，可以修改Unix系统的TCP参数（比如Linux下修改/proc/sys/net/ipv4/下的tcp_keepalive_time、tcp_keepalive_intvl、tcp_keepalive_probes），但注意这会影响系统上所有TCP连接，需谨慎操作。

内容的提问来源于stack exchange，提问作者Mayuri