查不到sql*net message from client长等待，先确认时间窗口和采样覆盖：v$active_session_history默认仅保留约1小时内存数据，需用sample_time > sysdate - 1/1440（最近1分钟）精准过滤；若问题发生更早，须查dba_hist_active_sess_history，并验证awr快照是否存在。
查不到 sql*net message from client 长等待？先确认时间窗口和采样覆盖
ash 默认只保留约 1 小时内存数据，java 连接池异常（比如连接泄漏、空闲连接被防火墙断开）引发的卡顿，若没在发生后立即查，v$active_session_history 很可能已覆盖。别用模糊时间范围如 sysdate - 1/24（一小时），改用 sample_time > sysdate - 1/1440（最近 1 分钟）缩小范围；如果目标问题发生在更早时段，必须切到磁盘视图：dba_hist_active_sess_history，但要注意它依赖 awr 快照——执行 select min(snap_id), max(snap_id) from dba_hist_snapshot where end_interval_time > sysdate - 1 确认快照存在，否则查不到任何历史。
看到大量 SQL*Net message from client 且 sql_id IS NULL？重点看 machine 和 program
Java 应用连接池异常最典型的 ASH 特征是：大量会话卡在 SQL*Net message from client，session_state = 'WAITING'，sql_id IS NULL，且 time_waited 持续超过 100ms（即 AVG(time_waited) > 100000）。这不是数据库慢，而是客户端没发 SQL、也没断开——极可能是连接池里的连接“假活”：
-
machine字段重复出现同一应用服务器名（如app01.prod），而其他机器正常 → 某台 JVM 的连接池配置异常或未 close -
program显示jdbc thin client但MODULE为空或为UNDEFINED→ JDBC 连接未设置setClientInfo()，无法关联业务逻辑 - 同一
machine下COUNT(*)在 1 分钟内持续 > 50 → 连接池 maxActive 被打满，新请求排队，后续触发connection-timeout
执行示例：SELECT machine, program, COUNT(*) cnt, AVG(time_waited)/1000 avg_ms FROM v$active_session_history WHERE event = 'SQL*Net message from client' AND session_state = 'WAITING' AND sql_id IS NULL AND sample_time > SYSDATE - 1/1440 GROUP BY machine, program HAVING AVG(time_waited) > 100000 ORDER BY avg_ms DESC;
SQL*Net break/reset to client 集中爆发？检查客户端连接池的 maxLifetime 和网络空闲超时
当 Java 连接池里的连接存活时间超过 Oracle 网络层或中间设备（如 F5、云负载均衡）的空闲超时阈值，连接会被单向断开，Oracle 侧表现为大量 SQL*Net break/reset to client，且 blocking_session 为空。常见原因：
- HikariCP 的
maxLifetime设为 30 分钟，但 OracleSQLNET.EXPIRE_TIME是 10 分钟 → 连接在池中“老化”前就被 Oracle 主动探测踢出 - 云厂商 SLB 默认空闲超时 900 秒（15 分钟），而 Druid 的
minEvictableIdleTimeMillis设为 600000（10 分钟）→ 连接在池中被回收前已断连，下次复用时报IO Error: Connection reset - 同一客户端 IP 出现多个会话同时进入该等待事件，且
SAMPLE_TIME时间戳高度集中 → 不是随机断连，而是批量心跳失败
此时不要只查等待事件，要关联 v$session 查真实连接状态：SELECT sid, serial#, status, server, osuser, machine, logon_time FROM v$session WHERE program LIKE '%jdbc%' AND status = 'INACTIVE' AND last_call_et > 600; —— last_call_et > 600 表示空闲超 10 分钟，大概率已被中间设备丢弃。
ASH 里找不到阻塞源，但应用报 ORA-00020？立刻查 v$process 和连接池实际占用
Java 连接池未正确 close 或连接泄漏，最终会耗尽 Oracle processes 资源，触发 ORA-00020。ASH 本身不记录进程数耗尽过程，但可通过两个视图交叉验证：
-
v$process中addr不为空但spid为空的进程 → 多为 JDBC Thin 连接创建的 shadow process，已无对应 OS 进程，但 Oracle 仍计数 -
v$session中status = 'INACTIVE'且server = 'SHARED'或'DEDICATED'，但program含jdbc且last_call_et > 300→ 极可能是连接池未 close 的“幽灵连接” - 对比
SELECT COUNT(*) FROM v$process和SHOW PARAMETER processes，差值
注意：v$active_session_history 只捕获活跃会话，这些泄漏的 INACTIVE 连接不会出现在 ASH 里——所以查不到等待事件不等于没有问题，得主动扫 v$session。
真正难定位的是那些“半死不活”的连接：既没发 SQL，也没被断开，还占着 processes 和游标资源。它们不会在 ASH 留下长等待，却会让后续所有新连接失败。盯住 v$session 的 last_call_et 和 v$process 的 spid 空缺状态，比等 ASH 报警更可靠。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
