module和action需应用层显式设置才能对齐业务与数据库行为：module用set_module或setclientinfo设定，未设则为空；action标识操作粒度但易被覆盖，应结合sample_time和sql_id分析；where module = 'xxx'比like更准，且必须加时间范围过滤。
module 和 action 不是 oracle 自动填的字段，而是你唯一能靠它把数据库行为和业务逻辑对齐的锚点。
Module 字段必须由应用显式设置才有效
Oracle 从不自动识别“订单模块”或“支付服务”，V$ACTIVE_SESSION_HISTORY 里的 module 值全靠应用层调用：DBMS_APPLICATION_INFO.SET_MODULE（PL/SQL）或 conn.setClientInfo("OrderService", "createOrder")（JDBC）。没设就是 'sqlplus.exe' 或空字符串——查 WHERE module = 'Inventory' 永远返回零行。
- 检查当前会话是否已设：运行
SELECT module, action FROM v$session WHERE sid = SYS_CONTEXT('USERENV', 'SID') - JDBC 连接后必须立即调用
setClientInfo，连接串里加ApplicationName=xxx不生效 - PL/SQL 包中建议在异常处理块末尾补上
DBMS_APPLICATION_INFO.SET_MODULE(NULL, NULL)，避免残留
Action 字段适合标记操作粒度，但稳定性差
action 是比 module 更细的标识，比如 'loadCustomerData'、'rebuildIndex'，但它常被反复覆盖。一次 ASH 采样只捕获那一刻的值，所以单条记录的 action 不代表完整流程。
- 高频变更时更适合聚合分析：用
GROUP BY action统计最近一小时各动作出现次数 - 别在
DBA_HIST_ACTIVE_SESS_HISTORY上依赖action——AWR 快照每小时存一次，action值基本不可信 - 搭配
sample_time和sql_id才能定位真实瓶颈，例如：某action = 'processRefund'的样本集中出现在enq: TX - row lock contention事件上
用 MODULE 过滤 ASH 时，= 比 LIKE 更准也更快
module 是 VARCHAR2(48) 固定长度字段，未填满部分会补空格。用 LIKE '%Inv%' 既慢又不准，可能漏掉 'Inventory '（带尾部空格）。
- 正确写法：
WHERE module = 'Inventory'，Oracle 会自动忽略尾部空格做语义匹配 - 查多个模块用
IN ('Order', 'Payment', 'Inventory')，不用OR链式条件，后者容易让执行计划退化为全表扫描 - 时间范围一定要加：
sample_time > SYSDATE - 1/288（5 分钟），ASH 内存缓冲区是环形的，老数据随时被覆盖
真正难的不是写 SQL，而是确保所有服务、所有连接池、所有 PL/SQL 包都统一设置了 module 和 action；漏一个，那一片流量就从诊断视图里消失了。
