如何配置会话超时断开_sqlnet.expire_time死连接检测-Oracle-PHP中文网

sqlnet.expire_time是Oracle服务器端心跳探测间隔（秒），用于清理死连接；设太小会误杀长事务，设太大则无效，需与应用层超时协同配置且仅对Oracle Net有效。

sqlnet.expire_time 是 oracle 客户端与数据库之间心跳检测的配置项，单位是秒。它让服务器端定期发一个空包（probe）给客户端，如果收不到响应，就主动断开连接——用来清理死连接，比如客户端崩溃、网络中断但 tcp 连接没正常关闭的情况。

但它不是“超时自动登出”开关，也不影响用户会话的 idle_time 或应用层的登录态。设得太小（比如 10 秒），会误杀长事务、大数据导出、报表生成这类本该持续的连接；设得太大（比如 0 或不配），又起不到清理作用。

常见错误现象：ORA-03113: end-of-file on communication channel 频繁出现，但查不到明确异常日志；或连接池里一堆 INACTIVE 状态却始终不释放。

改完 sqlnet.ora 不等于立刻生效。Oracle 监听器（lsnrctl）不读这个文件，只有数据库实例在建立新连接时才会加载它。也就是说：已存在的连接不会受新配置影响，必须等它们自然断开或重启实例。

实操建议：

确认修改的是数据库服务器上的 $ORACLE_HOME/network/admin/sqlnet.ora，不是客户端的，也不是 RAC 中某节点漏配
检查文件权限：必须是 oracle 用户可读，且不能有 BOM 或 UTF-8 with signature
不需要重启监听器或数据库，但新连接从下一次 CONNECT 开始才按新值检测
验证是否加载成功：在会话中执行 SELECT sys_context('USERENV', 'NETWORK_PROTOCOL') FROM DUAL;，确保是 tcp；再查 v$session 的 last_call_et 和状态变化节奏

很多 Java 应用用了 HikariCP 或 Druid，自己配了 connection-timeout、idle-timeout、max-lifetime。这时候 sqlnet.expire_time 和应用连接池的回收逻辑可能打架。

典型表现：连接池认为连接还健康（没超 max-lifetime），但数据库端因 probe 失败已强制断开，下次取连接就抛 IO Error: Connection reset。

推荐策略：应用层 max-lifetime 设为 sqlnet.expire_time × 2 左右，留出探测+断开+清理的时间差
JDBC Thin 驱动不支持 sqlnet.expire_time，要用 oracle.net.CONNECT_TIMEOUT 和 oracle.net.READ_TIMEOUT 替代
如果用的是 Oracle Wallet 或 SSL 连接，sqlnet.expire_time 仍有效，但 probe 包会走加密通道，延迟略高，建议值 ≥ 60

在容器化、Service Mesh 或云数据库（如 ADB、RDS）环境下，sqlnet.expire_time 往往失效或不可控。比如 Kubernetes 的 kube-proxy、NLB 的空闲连接超时、云厂商中间件的连接复用，都会在 Oracle 检测之前先掐断连接。

此时更靠谱的做法是：

在应用代码里加连接有效性校验，比如执行 SELECT 1 FROM DUAL 前先 isValid(2)
用数据库视图 v$session 定期查 status = 'INACTIVE' 且 last_call_et > 1800 的会话，配合 ALTER SYSTEM KILL SESSION 脚本清理
对长期运行的批处理任务，显式用 SET TIMED_STATISTICS = TRUE + DBMS_MONITOR.SESSION_TRACE_ENABLE 跟踪连接生命周期，而不是依赖被动探测