企业官网建设流程全解析

半夜两点被电话叫醒，应用那边说连不上数据库，报错ORA-12170: TNS:Connect timeout occurred。我第一反应是监听挂了，结果lsnrctl status一看监听活得好好的，数据库也开着。折腾半天最后发现，罪魁祸首是Oracle连接超时参数没配好——不是数据库挂了，是连接建立阶段在网络层超时了。那次之后我把Oracle这一堆跟超时相关的参数彻底捋了一遍，发现里面门道不少，而且特别容易混淆。

如果你也维护Oracle，不管是11g还是19c，甚至云上的RDS，这篇内容应该能帮你少踩几个坑。我尽量把连接建立阶段的超时、会话空闲超时、死连接检测这几个层面的参数讲清楚，还会带上排查思路和典型报错对照。

1. 先把Oracle连接超时的"链路"搞清楚

很多人一提到Oracle连接超时，就以为是一个参数的事，其实不是。一条连接从客户端发起，到真正能跑SQL，中间要经过客户端TCP握手、监听器接收、服务端进程创建、认证和会话建立这几个环节。超时可能发生在任何一个环节，配置参数也散落在不同的文件里。

1.1 一条连接经历的几个阶段

我用一个最简单的JDBC连接场景来拆解：

• 客户端通过jdbc:oracle:thin:@//host:1521/orcl发起连接，首先做TCP三次握手，这个阶段由操作系统TCP层管，Oracle自身一般不插手。
• TCP建立后，客户端把数据包发给监听器（listener），监听器在listener.ora里登记的端口上接收请求，这个阶段受listener.ora里的CONNECT_TIMEOUT参数影响。
• 监听器收到请求后，根据连接描述符找到对应服务名，再派生一个专用服务进程（dedicated server process）或交给共享服务器处理。如果这时数据库负载很高、processes满了，进程创建就会变慢，容易触发SQLNET.INBOUND_CONNECT_TIMEOUT。
• 服务进程起来后，客户端和服务端之间还要做版本协商、认证，最后才建立会话。这期间任一方长时间不响应，客户端侧的oracle.net.CONNECT_TIMEOUT就会报错。

1.2 参数虽然多，按层面分只有四类

我整理了一下，Oracle连接超时相关参数可以按作用位置分成四层：

每一层管一段，别指望只要设了JDBC的ReadTimeout，就能解决监听器的接收超时问题。实际排查时，要根据报错信息判断丢在哪一段。

2. 服务端和监听器：最容易背锅的两个超时参数

先说不容易踩坑但问题最隐蔽的：SQLNET.INBOUND_CONNECT_TIMEOUT。它在服务端的sqlnet.ora里，默认是60秒（不同版本有差异，11g以后默认60）。这个参数的意思是：从客户端连接请求到达监听器，到客户端完成认证和信息交换的最长时间。超了，服务端会主动断开连接，客户端往往看到ORA-3136: WARNING: inbound connection timed out。

2.1 SQLNET.INBOUND_CONNECT_TIMEOUT：不是越大越好

这个参数很多DBA会犯一个毛病——遇到报错就把它调大，调到300秒、600秒。其实这是一个防御性参数，设计初衷是防止客户端连上后长时间不完成握手，占着监听器的槽位不放。比如有客户端程序写了错误的连接方式，或者网络里有设备在悄悄探测端口，连上后不发数据，如果这个参数太小，正常客户端在慢网络上可能来不及完成连接；但如果调得过大，恶意连接或故障连接会长时间占用进程和会话槽位。

我踩过的一个坑是这样的：某次做数据库迁移，新机房网络策略比较严，客户端到数据库中间还有一层代理，TCP握手没问题，但代理转发数据有延迟。应用连库时频繁报ORA-3136，我一开始把SQLNET.INBOUND_CONNECT_TIMEOUT从60改成120，结果还是偶发报错。后来用抓包发现，连接请求到达监听器后，客户端要隔很久才发下一步数据包，不是服务端慢，是中间代理缓冲导致。最后在代理上关闭了TCP的延迟ACK，并把INBOUND_CONNECT_TIMEOUT保持60秒，问题就消失了。

实操建议：这个参数默认值在绝大多数场景够用，除非你的网络确实有代理转换、跨地域专线等场景，否则不建议动。

2.2 listener.ora里的CONNECT_TIMEOUT：跟版本和命名有关

监听器还有一个自己的超时参数，写法是CONNECT_TIMEOUT_listener_name，默认值一般是10秒，10g时代有的平台默认0（也就是不限制）。它管的是监听器在接收客户端连接请求时，允许客户端在完成连接之前的最长等待时间，比SQLNET.INBOUND_CONNECT_TIMEOUT更靠前。如果客户端已经TCP连上了监听器，但迟迟没有发出完整的连接描述符，监听器会在超时后主动断开。

这里有个容易被忽略的点：改完listener.ora后，需要lsnrctl reload或lsnrctl stop/start才生效，而SQLNET.INBOUND_CONNECT_TIMEOUT的修改不需要重启监听器，新的连接会立即使用新值。动手前务必要区分当前正在调的是哪个参数，否则容易白忙活。

2.3 两个参数之间的关系和典型配置

这两个参数其实是串联关系，客户端请求先经过监听器的CONNECT_TIMEOUT，然后进入服务端的SQLNET.INBOUND_CONNECT_TIMEOUT。实操中我通常这样配：

• 监听器的CONNECT_TIMEOUT设置10秒左右，防止TCP连接占着端口不干活；
• 服务端SQLNET.INBOUND_CONNECT_TIMEOUT保持默认60秒，或者根据跨专线实际情况调整到90~120秒。

注意：如果数据库并发很高，派生服务进程比较慢，可以适当观察告警日志里是否有WARNING: inbound connection timed out，有的话结合抓包确认是网络问题还是进程创建瓶颈，不要盲目调大超时。

3. 应用侧JDBC参数：真正决定你业务报错的几个值

服务端的超时参数再合理，如果应用侧没配好，业务该报错还是报错。JDBC驱动里跟超时相关的有三个经常被混用的参数：oracle.net.CONNECT_TIMEOUT、oracle.jdbc.ReadTimeout、oracle.net.READ_TIMEOUT。

3.1 连接建立超时和读取超时是两回事

oracle.net.CONNECT_TIMEOUT控制的是建立连接阶段的超时，单位是毫秒，默认值在某些版本里是0（无限等待）。它处理的是从客户端发起TCP连接到数据库返回“已连接”这个阶段。如果数据库IP不通、端口不通、监听异常，这个参数直接决定你的应用是等几秒报错还是挂半天。

oracle.jdbc.ReadTimeout和oracle.net.READ_TIMEOUT控制的是连接建立后，客户端等待数据库返回数据的超时时间。它们的区别是：oracle.jdbc.ReadTimeout是旧的、只作用于thin驱动，而oracle.net.READ_TIMEOUT是11.2版本以后引入的，对thin和OCI都生效，而且它覆盖了oracle.jdbc.ReadTimeout的语义。如果你两个都配了，以oracle.net.READ_TIMEOUT为准。

3.2 一个慢SQL引发的“思考题”

我遇到过这样一个案例：运维同事觉得数据库偶尔“卡住”了，就在JDBC URL里加了oracle.jdbc.ReadTimeout=3000，想做到3秒读超时。结果上线后，一批正常的夜维报表在数据量大的时候全挂，报ORA-17002或者Socket read timed out。查了半天发现，报表SQL本身要跑20秒，但ReadTimeout设成了3秒，等于把正常慢查询全部误杀。

所以配置读取超时前，先统计一下业务里最慢SQL的执行时间，把超时时间设置成“合理慢查询上限”，而不是凭感觉设一个很小的值。如果是连接池场景，还要考虑连接池获取连接的超时，那是连接池自身的参数（比如HikariCP的connectionTimeout），别跟JDBC参数混在一起。

3.3 一个可靠的JDBC参数配置示例

我现在的项目里用的是这样的配置，供参考：

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=dbhost)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=orcl))) ?oracle.net.CONNECT_TIMEOUT=10000&oracle.net.READ_TIMEOUT=60000

注意：在JDBC URL里参数用&连接，oracle.net.CONNECT_TIMEOUT是毫秒，10秒建立连接。oracle.net.READ_TIMEOUT是60秒。如果走的是Properties方式，则是：

Properties props = new Properties(); props.setProperty("user", "scott"); props.setProperty("password", "tiger"); props.setProperty("oracle.net.CONNECT_TIMEOUT", "10000"); props.setProperty("oracle.net.READ_TIMEOUT", "60000"); Connection conn = DriverManager.getConnection(url, props);

如果业务里有批处理、大查询，建议把READ_TIMEOUT设置得更宽松一些，或者干脆不设置，只靠数据库侧的IDLE_TIME等参数兜底。

3.4 OCI连接还有一个容易忽略的OUTBOUND参数

如果你用的是OCI模式（比如通过sqlplus、Pro*C、某些中间件），sqlnet.ora里还有SQLNET.OUTBOUND_CONNECT_TIMEOUT，单位是秒，默认是0也就是无限等待。这个参数限制的是客户端到服务端TCP连接建立的时间。thin模式JDBC不走这个参数，但sqlplus会走。有一次用户反应sqlplus连远程数据库时长时间卡住不报错，网络又不通，问题就出在这个参数没设。加上：

SQLNET.OUTBOUND_CONNECT_TIMEOUT=10

之后，网络不通时sqlplus能在10秒内快速失败，而不是让DBA干等。

4. 会话空闲与死连接检测：连接池里的隐形杀手

连接超时不只在建立连接时发生。连接建立后，如果长时间空闲或中间网络设备把连接静默断掉，应用感知不到，继续用这条“死连接”就会报错。这时候就看SQLNET.EXPIRE_TIME和数据库Profile的IDLE_TIME了。

4.1 SQLNET.EXPIRE_TIME 是做“心跳检测”的

SQLNET.EXPIRE_TIME写在服务端sqlnet.ora，单位是分钟，默认0（不启用）。它的原理是：服务端每隔设定时间向客户端发送一个探测包，如果连续多次没有收到响应，服务端就认为这个连接已经死了，回收对应的服务进程。

注意，这个探测间隔比较长，默认配置下探测包发送频率很低（比如EXPIRE_TIME=10，每10分钟才探测一次），所以它解决不了“中间网络设备几分钟就空闲超时”的场景。如果NAT网关、防火墙或负载均衡的会话空闲超时是300秒，那你把EXPIRE_TIME设为30分钟就完全没意义，死连接照样会被网关先掐断。

我之前的经验是，EXPIRE_TIME至少要小于网络设备空闲超时的一半。举个例子，公司的防火墙对空闲TCP会话有15分钟的超时，我就把SQLNET.EXPIRE_TIME=5，这样数据库每5分钟发一个探测包，让连接一直处于“活跃”状态，防火墙就不会把连接清掉。

4.2 Profile里的IDLE_TIME和CONNECT_TIME

除了网络层面的死连接检测，数据库Profile可以限制会话的空闲时间和总连接时间：

ALTER PROFILE app_user LIMIT IDLE_TIME 30 CONNECT_TIME 480 RESOURCE_LIMIT TRUE;

IDLE_TIME是指一个会话空闲超过30分钟后被断开。执行这个变更前先确认RESOURCE_LIMIT是TRUE，否则Profile里的很多资源限制不生效。CONNECT_TIME是指会话从连接到断开的总时长上限，主要是为了防止某些应用连接泄漏、长期不释放。

这个功能在生产环境要慎用。曾有开发让我帮他们把IDLE_TIME设为10分钟，结果一个Java应用因为连接池里的连接空闲超过10分钟被数据库狠心掐断，而应用连接池的验证查询（validation query）没配好，应用一直在往已断掉的连接上发SQL，报错报了一大片。后来我把IDLE_TIME调到60分钟，同时在连接池里配了SELECT 1 FROM DUAL作为每次借出连接前的校验，问题才消停。

4.3 Linux内核层的TCP超时参数：Oracle本身管不了的那段

客户端和服务端之间的TCP连接，在操作系统层面还有一套超时机制。以Linux为例：

sysctl net.ipv4.tcp_keepalive_time sysctl net.ipv4.tcp_keepalive_intvl sysctl net.ipv4.tcp_keepalive_probes

tcp_keepalive_time默认7200秒（2小时），也就是说TCP层的keepalive探测包默认要2小时才发一次。这对于很多网络设备来说太慢了，所以上面提到的SQLNET.EXPIRE_TIME才显得重要——它比TCP keepalive更灵敏。

但如果网络条件允许，也可以调Linux内核参数来配合：

sysctl -w net.ipv4.tcp_keepalive_time=300 sysctl -w net.ipv4.tcp_keepalive_intvl=30 sysctl -w net.ipv4.tcp_keepalive_probes=3

这样TCP层在300秒没有数据时会发探测包，30秒一次，连续3次没响应就判定连接断开。注意这会影响整个操作系统上的所有TCP连接，不只是Oracle，改动前要评估对其他业务的影响。新版本内核还可以用TCP_USER_TIMEOUT，单位是毫秒，可以在发送数据后多久内没收到ACK就报错，比keepalive配置更精准，不过这个一般是在应用层通过socket选项设置，Oracle本身不暴露这个配置。

5. 常见报错与排查：直接对号入座

前面讲了参数原理，这一节放点实战东西。我列一个常见Oracle连接超时报错对照表，然后说一次完整排查套路。

5.1 报错速查表

这里要提醒一下，ORA-12170不一定就是网络问题。有一次我发现数据库服务器CPU打满，监听器收到了连接请求但派发不出来，客户端也报ORA-12170。所以报错只能做线索，不要当成结论。

5.2 完整排查套路：从一端到另一端

我在处理连接超时时基本按下面这个顺序做：

第一步，确认网络连通性。先telnet 数据库IP 1521看端口通不通。如果telnet就卡住，说明问题在网络层。此时可以顺带ping一下，测一下丢包率，但很多防火墙禁ping，所以ping不通不代表TCP不通。

第二步，看监听器状态。执行lsnrctl services和lsnrctl status，确认服务名是否正确注册。如果service_name没注册，客户端连接会直接超时或报ORA-12514。

第三步，看告警日志。连接超时类问题，数据库的alert_log往往有记录。grep -i timeout $ORACLE_BASE/diag/rdbms/*/trace/alert_*.log。如果有WARNING: inbound connection timed out，那就是SQLNET.INBOUND_CONNECT_TIMEOUT或监听器超时被触发。

第四步，抓包确认断开方。用tcpdump -i eth0 port 1521抓包，如果客户端在连接建立后发了一个RST包，说明是客户端等不及主动断开；如果服务端先发RST，说明是服务端或中间设备做了拦截。这个步骤可以快速把锅甩到正确的一方。

第五步，复查配置文件。show parameter resource_limit确认是否开启；检查sqlnet.ora里SQLNET.EXPIRE_TIME、SQLNET.INBOUND_CONNECT_TIMEOUT；检查listener.ora里CONNECT_TIMEOUT_listener_name；检查应用侧JDBC URL里加的超时参数。把每个参数当前值列出来，对照超时时间线，看哪个值跟故障时间点最吻合。

5.3 一个典型的排查案例

之前处理过一个批量导入程序，报“ORA-12170”但出现时间毫无规律。我先telnet数据库1521端口，秒通；lsnrctl services正常；告警日志里没有任何超时记录。然后抓包，发现客户端发出的TCP SYN包到了数据库，数据库回了SYN-ACK，但客户端那边没有继续发ACK。再往下看，发现数据库返回的SYN-ACK之后，客户端几秒后直接发了RST。

这个现象说明，客户端某些线程在TCP层面就放弃连接了，根本没走到Oracle监听器。后来查到是Java应用里的oracle.net.CONNECT_TIMEOUT被设成了2000毫秒，而那条链路因为中间有网关做安全检查，TCP三次握手本来就需要2~3秒。把连接超时调成10秒就再没报过错。

所以，连接超时排查有一个核心心法：先确定断在哪一段，再决定调哪个参数。

5.4 参数修改后的验证方式

修改完参数，建议分两步验证。第一步，用sqlplus模拟客户端的普通连接是否正常；第二步，模拟超时故障，比如临时用iptables把1521端口的包丢掉，看看报错是否能在预期时间内出现。

# 模拟端口丢包（注意：实际生产环境谨慎操作，建议在测试环境验证） iptables -A INPUT -p tcp --dport 1521 -j DROP sqlplus scott/tiger@host:1521/orcl # 观察是否在预期时间后报出超时错误 iptables -D INPUT -p tcp --dport 1521 -j DROP

这样一来，参数是不是真的生效，一测便知，比改完不管强得多。

6. Oracle 11g与19c在超时参数上的小差异

如果你还在维护11g，可能会遇到一些跟新版本不太一样的默认行为。

6.1 11g与19c默认值不完全一样

在Oracle 11g中，SQLNET.INBOUND_CONNECT_TIMEOUT默认已经是60秒，但有些操作系统平台上的listener.ora默认没有显式写CONNECT_TIMEOUT_listener_name，这时候监听器是否有限制取决于版本和平台，有的默认不限制。而在19c中，监听器默认会有一个合理的超时值，整体更安全。

JDBC驱动的差别更大。老版本的Oracle JDBC驱动（比如11.2.0.x）对oracle.net.READ_TIMEOUT支持不完整，用的时候需要把驱动升级到较新的版本，否则配了也可能不生效。

6.2 升级到19c后注意连接参数兼容

19c的服务器对老版本客户端的兼容性整体还行，但如果客户端JDBC驱动太老（10g时代），连接服务端时可能出现认证参数协商超时。这时候不能只调服务端超时，还要考虑把客户端驱动升级到至少11.2.0.4以上版本。

升级驱动的经验是：先在一台测试服务器验证，再看应用服务器的JDK版本是否兼容。Oracle 19c驱动要求JDK8以上，有些人还在用JDK6跑老应用，驱动升不上去，这种情况只能保持旧驱动并调大连接超时参数来缓解。

7. 到底该怎么设计一套合理的超时配置

写到这里，我把配置Oracle连接超时参数的思路做个收拢，方便你对照自己环境去调整。

7.1 先分层，不盲目调大

设计超时参数之前，先把链路每一层的期望值写清楚。我的习惯是：

• 客户端TCP连接建立：5~10秒。如果超过10秒还没建上连接，多半是网络配置有问题，靠调超时治标不治本。
• 监听器接收连接描述符：10秒左右，跟客户端建立超时匹配。
• 服务端完成认证与进程创建：30~60秒。如果数据库负载正常但超过60秒，说明连接风暴或进程创建瓶颈，要考虑的是容量问题，不是调超时。
• 读取数据超时：按业务最慢SQL的P95时间乘以1.5~2倍，并且要区分报表、批处理和在线交易。
• 空闲会话：按应用连接池的空闲策略和网络设备超时来定，原则是SQLNET.EXPIRE_TIME小于网络设备空闲超时，IDLE_TIME大于连接池最大空闲时间（否则连接池里的连接会被数据库先干掉）。

7.2 一个相对稳妥的参考配置

这个配置适合大多数中型OLTP系统，可以直接抄作业，但要根据业务微调：

# 服务端 sqlnet.ora SQLNET.INBOUND_CONNECT_TIMEOUT=60 SQLNET.EXPIRE_TIME=10

# 监听器 listener.ora CONNECT_TIMEOUT_LISTENER=10

-- 数据库Profile ALTER PROFILE app_profile LIMIT IDLE_TIME 60 CONNECT_TIME 480 RESOURCE_LIMIT TRUE;

// JDBC URL参数 oracle.net.CONNECT_TIMEOUT=10000 oracle.net.READ_TIMEOUT=60000

这套配置的思路是：连接建立阶段的超时控制在10~60秒内，空闲检测每10分钟一次，会话最长8小时，JDBC读取超时60秒。如果业务里确实有超过60秒的大查询，把READ_TIMEOUT适当放大，或者对大查询走单独的连接配置。

7.3 配置之后需要持续观察

参数改完不是结束，还要关注两件事。一是告警日志里是否还有超时相关警告，二是在数据库里查询当前会话的空闲时间分布，判断IDLE_TIME是否合理：

SELECT username, status, count(*), ROUND(MAX(last_call_et)/60, 1) AS max_idle_min FROM v$session WHERE type = 'USER' GROUP BY username, status ORDER BY 4 DESC;

如果很多会话空闲超过几小时，说明应用连接池配置有问题，光靠数据库断开也不能根治。

我个人在实际操作中的体会是，Oracle连接超时参数看起来零散，但掌握了“一条链路四层参数”的框架后，大部分超时问题都能快速定位。别急着调大数值，更别所有超时都设成一样大的值，先搞清楚当前故障断在哪一段，再有针对性地调整。最后留一句经验之谈：遇到连接超时，先抓包，再改参数，能少走很多弯路。