如何利用ASH排查Oracle 12c中的监听连接风暴_分析SESSION

ASH虽不直接记录监听层连接风暴，但能捕获其数据库侧痕迹：短连接会话集中注册与快速消亡，表现为特定MODULE高频出现、SESSION_STATE='ON CPU'或EVENT='SQL*Net message from client'异常堆积，结合SAMPLE_TIME窗口、session_state过滤及sql_opname=LOGON可精准识别。

ash 本身不记录监听层连接风暴，但能暴露风暴在数据库侧的后果——大量短连接会话集中注册、快速消亡，表现为特定 module 高频出现、session_state = 'on cpu' 或 event = 'sql*net message from client' 异常堆积。

为什么查 `V$ACTIVE_SESSION_HISTORY` 能抓到连接风暴痕迹

监听层的连接风暴（如每秒数百次短连接）不会直接写入 ASH，但每个成功连入的会话只要执行了哪怕一条 SQL、或处于“刚连上等客户端发包”的空闲状态，就可能被采样到。关键不是“连接动作”，而是连接后留下的会话行为特征。

短连接通常不做复杂操作，很快执行 SELECT 1 FROM DUAL 或简单查询后断开，这类会话在 ASH 中表现为 sql_id 固定、event 长期是 SQL*Net message from client、session_state 为 WAITING
若应用未设 MODULE，大量会话的 program 可能都是 oracle@host (TNS V1-V3)，但真实 Web 应用一般会通过 JDBC/ODBC 设置 MODULE 字段，比如 WebAPI-Auth 或 SpringBatch-Job
连接风暴发生时，SAMPLE_TIME 密集区间内会出现同一 MODULE 占据极高比例（>70%），且 SESSION_SERIAL# 变化极快——说明会话生命周期极短

查 `MODULE` 分布必须加时间窗口和状态过滤

不加约束直接 GROUP BY MODULE 会淹没在历史噪音里，尤其当数据库长期运行、后台任务多时。真正有效的查询要锁定“最近活跃窗口”并排除无效状态。

用 SAMPLE_TIME > SYSDATE - 5/1440（最近 5 分钟），比 1 分钟更稳——避免因采样点偏移漏掉峰值
必须加 session_state IN ('ON CPU', 'WAITING')，否则包含大量已断开但尚未被清理的“僵尸会话”（INACTIVE 状态不进 ASH）
排除 event = 'SQL*Net message to client'（这是响应发送阶段，非连接建立阶段）
示例语句：

SELECT module, COUNT(*) cnt, COUNT(DISTINCT session_id) uniq_sess
FROM v$active_session_history
WHERE sample_time > SYSDATE - 5/1440
  AND session_state IN ('ON CPU', 'WAITING')
  AND event != 'SQL*Net message to client'
GROUP BY module
ORDER BY cnt DESC
FETCH FIRST 10 ROWS ONLY;

`MODULE` 高频但 `SQL_ID` 为空？重点看 `sql_opname` 和 `client_identifier`

连接风暴中的会话常只做登录、认证、简单查询，甚至卡在解析前。此时 sql_id 是 0000000000000000，但仍有线索可挖。

Remix V2 Meta Sessions Review

审查 Remix v2 代码中的 v1 形态 meta 导出（v2 中为破坏性变更），cookie 安全漏洞（httpOnly、secure、密钥轮换），认证门位于错误层级，以及其他

下载

sql_opname 字段会显示 LOGON、PARSE、EXECUTE 等操作类型，若高频出现 LOGON，基本坐实是连接风暴
client_identifier 若被应用设置（如 DBMS_SESSION.SET_IDENTIFIER('web-192.168.1.100')），可直接定位来源 IP 或服务实例
若 module 是 TOAD% 或 PL/SQL Developer，大概率是人工工具批量重连，不是生产问题；若是 Apache-HttpClient 或 okhttp，就得查上游服务是否在重试熔断

别只信 `MODULE`，交叉验证 `V$SESSION` 的实时连接数趋势

ASH 是采样，V$SESSION 是快照，两者结合才能确认是否真有风暴。单靠 ASH 的 COUNT(*) 容易高估——因为同一会话可能在多个采样点被捕获。

执行 SELECT COUNT(*) FROM v$session WHERE status = 'ACTIVE' AND module LIKE 'WebAPI%';，对比过去 5 分钟内该值是否从个位数突增至几百
查 V$SESSION_CONNECT_INFO 中相同 module 的 client_charset 或 network_service_banner，若大量会话显示 TCP/IP NT Protocol Adapter + 相同 CLIENT_CHARSET，说明是同一批客户端 SDK 发起
最硬证据：在疑似风暴时段，用 lsnrctl services 查监听器当前服务统计，输出中 Service "xxx" has 120 instance(s) 后面跟着密密麻麻的 Handler(s): 列表——这表示监听层已感知到大量并发连接请求