如何排查Oracle中的JDBC僵尸会话-Oracle-PHP中文网

查v$session时status='INACTIVE'但tempseg_used>0的会话实为JDBC僵尸，需连查v$sort_usage确认TEMP占用；若mb_used>0且blocks不降，应强杀OS进程并执行ALTER TABLESPACE temp COALESCE。

如何排查oracle中的jdbc僵尸会话

查v$session时status=INACTIVE但tempseg_used > 0

这种会话看着“安静”，其实还在占临时表空间——v$session.status = 'INACTIVE'不等于资源已释放。真正要盯的是它是否还在用TEMP段，否则杀掉后TEMP空间不回收，后续大排序照样报ORA-01652。

必须连查v$sort_usage确认：

SELECT s.sid, s.serial#, u.tablespace, u.blocks * 8 / 1024 AS mb_used
FROM v$sort_usage u
JOIN v$session s ON u.session_addr = s.saddr
WHERE u.tablespace = 'TEMP' AND s.status = 'INACTIVE';

如果mb_used > 0，说明该会话的排序/哈希结果还没被PMON清理，属于典型JDBC僵尸
blocks值长时间不降（比如持续5分钟以上），基本可判定客户端已断开但连接未归还给连接池
注意：某些ORM框架（如MyBatis）在异常分支里漏写connection.close()，就会制造这类会话

ALTER SYSTEM KILL SESSION后状态卡在KILLED

执行ALTER SYSTEM KILL SESSION 'sid,serial#' IMMEDIATE后，v$session.status变成KILLED但TEMP没释放、OS进程还在，这是JDBC僵尸最顽固的表现。根本原因是JDBC驱动层没收到断连通知，或应用没触发连接池的失效检测逻辑。

此时不能等PMON自动清理——它可能卡住。得立刻做两件事：

查对应OS进程：SELECT p.spid FROM v$session s JOIN v$process p ON s.paddr = p.addr WHERE s.sid =
在数据库所在服务器上执行：kill -9 （Linux）或orakill ORACLE_SID （Windows）
强杀后观察v$sort_usage是否清空；若仍有残留，需对TEMP表空间执行ALTER TABLESPACE temp COALESCE

JDBC连接池配置不当导致会话堆积

很多“僵尸”不是数据库问题，而是连接池把断开的连接当活跃连接反复复用。典型配置坑点：

QuantOracle

63个确定性量化金融计算器 + 10个通过MCP的复合工作流。期权定价、Greeks、奇异衍生品、风险指标、投资组合优化……

下载

HikariCP的connection-timeout设太长（如30秒），导致网络闪断后连接迟迟不标记为dead
没开leak-detection-threshold（建议设60000毫秒），无法捕获应用层忘记close()的连接
Oracle JDBC URL里加了characterEncoding=utf8这类无效参数，某些旧驱动会静默忽略，但影响连接健康检查逻辑
Spring Boot中spring.datasource.hikari.auto-commit=false没生效——得确认底层ojdbc8实际读到了该值，可用Connection.getAutoCommit()运行时验证

区分JDBC僵尸和RAC实例定位错误

RAC环境下，看到GV$SESSION里有会话，但ALTER SYSTEM KILL SESSION报ORA-00030: User session ID does not exist，大概率是命令没指定实例。JDBC连接可能连在节点2，你却在节点1上执行Kill。

必须用带实例ID的语法：

ALTER SYSTEM KILL SESSION 'sid,serial#,@inst_id';

其中@inst_id来自GV$SESSION.inst_id字段。漏掉@符号，Oracle默认操作当前实例，自然找不到目标会话。

更隐蔽的问题：某些负载均衡代理（如F5）会把JDBC连接随机分发到不同节点，而应用日志只记录SQL执行时间，不记录实际连接节点——这时得靠client_addr和program字段交叉比对，才能准确定位源头节点。