必须加 session_state = 'on cpu'，因为 module 仅标识应用模块，不区分会话状态；不加该条件会混入等待、空闲等无效样本，导致将“慢模块”误判为“cpu 模块”。
直接查 v$active_session_history 中 module 匹配 + session_state = 'on cpu' 的样本数，就能定位模块级 cpu 消耗；但 module 值易被应用覆盖、大小写敏感、且历史数据必须走 dba_hist_active_sess_history，不能只依赖内存视图。
为什么 MODULE 过滤要加 session_state = 'ON CPU'
MODULE 字段只是应用层打标（比如 Spring Boot 设置 setModule），它本身不区分会话状态。同一个模块可能大量时间在等待 I/O 或锁，真正在 CPU 上跑的只是其中一小部分。不加 session_state = 'ON CPU'，统计结果会混入大量无效等待样本，把“慢模块”误判成“CPU 模块”。
- 只过滤
MODULE = 'ORDER-SVC'：得到的是该模块所有活跃会话的总采样数，含等待、空闲、解析等全部状态 - 加
AND session_state = 'ON CPU'：才真正反映该模块在 CPU 上实际执行的时间占比 - 若模块名来自 JDBC 的
setClientInfo，注意 Oracle 默认截断为 48 字节，超长会被截断或丢弃
MODULE 值大小写与空格问题怎么处理
Oracle 对 MODULE 字段做精确匹配，不自动 trim 空格、不忽略大小写。常见坑是应用代码里写了 'payment-gw '（末尾带空格）或 'Payment-GW'，而查询时用 = 'payment-gw' 就查不到。
- 统一用
UPPER(TRIM(module)) = UPPER(TRIM('payment-gw'))做安全比对 - 先探查真实值：
SELECT DISTINCT TRIM(module) FROM v$active_session_history WHERE sample_time > SYSDATE - 1/1440 AND module IS NOT NULL AND ROWNUM - 避免用
LIKE '%payment%'全模糊——容易跨模块误命中，比如'PAYMENT-GW'和'REFUND-PAYMENT'都会被扫中
查历史模块 CPU 消耗必须用 DBA_HIST_ACTIVE_SESS_HISTORY
v$active_session_history 只保留约 1 小时内存数据，想看昨天下午 3 点的 MODULE = 'INVOICE-BATCH' 的 CPU 情况，必须切到磁盘归档视图。但这里有个硬限制：DBA_HIST_ACTIVE_SESS_HISTORY 的 MODULE 字段只存 AWR 快照时刻的值，不是每秒采样都记，所以精度下降——它只反映快照周期内（默认 60 分钟）该模块是否活跃过，不保证覆盖瞬时尖刺。
- 必须加时间条件：
sample_time BETWEEN TIMESTAMP '2026-06-12 15:00:00' AND TIMESTAMP '2026-06-12 16:00:00'，不能用SYSDATE - 1 - RAC 环境下该视图已聚合所有实例，无需手动
UNION ALL，但要注意instance_number字段可用于下钻单节点 - 如果发现某模块在历史视图中
MODULE为空，大概率是应用未设置，或设置了但被 LogMiner、JOB 等后台会话覆盖（后台会话常清空 MODULE）
如何关联 MODULE 和具体 SQL_ID 并排除干扰
一个模块可能跑几十条 SQL，光知道 MODULE = 'USER-PROFILE' 吃了 200 个 CPU 样本，没法定位根因。得把 MODULE、SQL_ID、PLAN_HASH_VALUE 三者绑在一起查，同时排除解析、递归调用等非业务 SQL 干扰。
- 加
sql_id IS NOT NULL过滤掉硬解析、PL/SQL 执行等无 SQL_ID 的行 - 排除系统 SQL：
AND sql_id NOT IN (SELECT sql_id FROM v$sql WHERE command_type IN (2, 3, 6))（2=INSERT, 3=SELECT, 6=UPDATE，其余多为递归） - 同一
sql_id可能对应多个执行计划，必须带sql_plan_hash_value分组，否则会把低效计划和高效计划混在一起统计 - 示例片段：
SELECT module, sql_id, sql_plan_hash_value, COUNT(*) cpu_samples FROM dba_hist_active_sess_history WHERE module = 'USER-PROFILE' AND session_state = 'ON CPU' AND sample_time BETWEEN ... GROUP BY module, sql_id, sql_plan_hash_value ORDER BY cpu_samples DESC
MODULE 是应用可观测性的入口，但它本身不携带执行上下文。查出高 CPU 模块后，下一步永远要落到 SQL_ID + 执行计划 + 绑定变量组合上——否则你优化的只是表象，不是执行逻辑。
