如何通过Oracle ASH定位异常应用模块-Oracle-PHP中文网

查不到module字段值是因为应用端未设置，需通过dbms_application_info.set_module或jdbc setclientinfo显式配置；module固定但行为异常时重点排查连接池泄漏；名称混乱时可用client_identifier辅助归因；rac环境必须用gv$视图并过滤inst_id。

如何通过oracle ash定位异常应用模块

查不到 MODULE 字段值？先确认客户端是否设置了它

Oracle 不会自动给每个连接填 MODULE，它完全依赖应用端调用 DBMS_APPLICATION_INFO.SET_MODULE 或 JDBC 的 setClientInfo("ApplicationName", "...")。没设就是空或 UNDEFINED，ASH 里自然查不到。常见于老旧 Java 应用、未规范接入的 Python 脚本、或直接用 sqlplus / sqlcl 连接的运维操作。

验证方式很简单：在疑似会话里执行 SELECT SYS_CONTEXT('USERENV', 'MODULE') FROM DUAL;。如果返回空，说明问题不在数据库侧，得回应用代码或连接池配置里补上。

JDBC 需显式启用：connection.setClientInfo("ApplicationName", "order-service-v2")
Spring Boot + HikariCP 可配 data-source-properties.oracle.jdbc.defaultRowPrefetch=100 并配合 spring.datasource.hikari.data-source-properties.v$session.module=xxx（需驱动支持）
PL/SQL 手动设：DBMS_APPLICATION_INFO.SET_MODULE('batch-job', 'daily-cleanup');，且必须在每次逻辑单元开始时重置

MODULE 值固定但行为异常？重点筛 `SQL*Net message from client` + 长空闲

当多个会话显示相同 MODULE（如 'payment-api'）且长期卡在 SQL*Net message from client，基本可判定是该模块的连接池泄漏或客户端未 close()。这不是数据库慢，是应用“忘了收线”。

执行这个查询快速定位：

SELECT module, machine, COUNT(*) cnt, AVG(last_call_et)/60 avg_min
FROM v$session 
WHERE status = 'INACTIVE' 
  AND event = 'SQL*Net message from client'
  AND module IN ('payment-api', 'inventory-sync')
  AND last_call_et > 3600
GROUP BY module, machine
HAVING COUNT(*) > 5;

last_call_et > 3600 表示空闲超 1 小时，生产环境可放宽到 > 7200
同一 machine 下数量突增，说明某台服务器上的 JVM 进程出问题，不是全局配置错误
若 module 是 'JDBC Thin Client' 这类泛化值，说明应用根本没设，得优先推动补全

MODULE 名称混乱或含随机后缀？用 `CLIENT_IDENTIFIER` 辅助归因

有些应用为规避连接复用问题，会给 MODULE 加时间戳或线程 ID（如 'report-engine-202607210145'），导致 GROUP BY 失效。这时要转向更稳定的 CLIENT_IDENTIFIER —— 它由应用调用 DBMS_SESSION.SET_IDENTIFIER 设置，常用于标识租户、用户 ID 或请求 traceID。

Crypto Sniper Oracle

机构级量化市场预言机，提供订单簿失衡（OBI）、VWAP分析、自动化报告及Telegram预警。

下载

关联查法：

SELECT s.module, s.client_identifier, s.sql_id, COUNT(*) cnt
FROM v$session s
JOIN v$active_session_history a 
  ON s.sid = a.session_id AND s.serial# = a.session_serial#
WHERE a.sample_time > SYSDATE - 1/1440
  AND s.client_identifier LIKE 'trace-%'
  AND a.event = 'db file sequential read'
GROUP BY s.module, s.client_identifier, s.sql_id
ORDER BY cnt DESC;

client_identifier 比 MODULE 更细粒度，适合排查单次请求级性能问题
注意：v$session.client_identifier 和 v$active_session_history.client_id 字段名不同，JOIN 时别写错
若 client_identifier 为空但 MODULE 有值，说明应用只设了前者；反之亦然 —— 二者不强制绑定

RAC 环境下 MODULE 分布不均？必须加 `INST_ID` 过滤

RAC 多节点时，v$session 和 v$active_session_history 默认只查当前实例。如果只在一个节点看到大量 MODULE = 'sync-worker' 的等待，不代表全局如此 —— 其他节点可能更严重，也可能完全正常。漏掉 INST_ID 会导致误判根因位置。

安全写法：

SELECT inst_id, module, COUNT(*) cnt
FROM gv$session 
WHERE status = 'ACTIVE' 
  AND module = 'sync-worker'
  AND event = 'enq: TX - row lock contention'
GROUP BY inst_id, module;

用 gv$ 视图而非 v$，并显式 SELECT inst_id
不要在 WHERE 里写 inst_id = USERENV('INSTANCE') 来“假装跨节点”，这毫无意义
如果某节点 cnt 显著高于其他节点，优先检查该节点的网络延迟、存储 IO 或本地缓存压力

真正难的不是查出 MODULE，而是判断哪个 MODULE 的行为偏离了基线 —— 比如平时每分钟最多 3 个 MODULE = 'notification-sender' 会话，突然变成 80 个且都卡在 library cache lock，这时候才需要深挖。别一上来就按 MODULE 统计，先看等待事件和时间窗口是否异常。