查module分布必须加时间窗口和session_state过滤，否则历史噪音会掩盖连接风暴；需用sample_time > sysdate - 5/1440和session_state in ('on cpu','waiting')，排除inactive及sqlnet message to client等干扰；短连接特征为sql_id为空、event固定为sqlnet message from client、session_serial#高频轮换；定位ip应查v$session_connect_info而非ash；rac环境须用gv$ash并按inst_id分组，避免module统计偏差。
查MODULE分布必须加时间窗口和session_state过滤
直接GROUP BY MODULE会淹没在历史噪音里，尤其数据库长期运行时后台任务多。连接风暴的痕迹只在活跃窗口内集中爆发，不加约束等于大海捞针。
- 时间范围用
SAMPLE_TIME > SYSDATE - 5/1440（最近5分钟），比1分钟更稳——ASH采样是每秒一次，但可能因偏移漏掉峰值 - 必须加
session_state IN ('ON CPU', 'WAITING')，否则会混入大量已断开但尚未清理的INACTIVE会话（ASH根本不采INACTIVE） - 排除
event = 'SQL*Net message to client'，这是响应发送阶段，不是连接建立行为
识别短连接特征：看SQL_ID空、EVENT固定、SESSION_SERIAL#高频轮换
连接风暴本质是大量短生命周期会话快速注册又退出，ASH里不会记录“连接动作”，但会留下典型行为指纹。
-
SQL_ID为空或为0000000000000000：说明还没执行SQL就断开，或只执行了SELECT 1 FROM DUAL这类轻量语句 -
EVENT长期是SQL*Net message from client：会话处于等待客户端发包状态，但迟迟没后续操作 -
SESSION_SERIAL#在短时间窗口内变化极快：同一MODULE下COUNT(DISTINCT session_id)远高于COUNT(*)，说明会话存活时间极短
定位源头IP不能靠ASH直接查client_ip字段
V$ACTIVE_SESSION_HISTORY压根没有CLIENT_IP字段，硬查会返回空或报错。Oracle不采集TCP层源地址到ASH，这是设计使然，不是配置问题。
- 优先查
V$SESSION_CONNECT_INFO，用SESSION_ID和SESSION_SERIAL#反向关联ASH记录，该视图含NETWORK_SERVICE_BANNER等线索 - 如果应用可控，在连接时调用
DBMS_SESSION.SET_IDENTIFIER('192.168.1.100')，这样CLIENT_ID字段就能对上 - 监听日志
$ORACLE_HOME/network/log/listener.log里有HOST=192.168.x.x原始记录，但需提前开启详细日志
RAC环境下MODULE分布要查GV$ACTIVE_SESSION_HISTORY
单实例查V$ACTIVE_SESSION_HISTORY没问题，但在RAC中，连接可能分散在多个节点，只查本地视图会漏掉70%以上流量。
- 必须用
GV$ACTIVE_SESSION_HISTORY，否则MODULE统计严重偏低 - 注意
BLOCKING_INSTANCE字段——若阻塞链跨节点，忽略它会导致找不到真正根因会话 - 聚合时加
INST_ID分组，避免不同节点同名MODULE被错误合并
真实场景里最容易卡住的地方，是以为MODULE字段天然可靠——其实很多老旧应用根本没设，PROGRAM字段又常是oracle@host这种通用值。得先确认应用是否真写了MODULE，再决定要不要切到监听日志或netstat抓包验证。
