必须限定SAMPLE_TIME > SYSDATE - INTERVAL '5' MINUTE且module IS NOT NULL来抓ASH中in_hard_parse = 'Y'样本；module和action需结合应用设置与默认值识别业务模块；聚合应按module, sql_id, in_hard_parse分组，重点关注sql_id离散度、RAC下用gv$active_session_history并检查inst_id，避免依赖DBA_HIST_ACTIVE_SESS_HISTORY。
查 in_hard_parse = 'Y' 必须加时间窗口和模块过滤
ASH 中识别频繁解析，核心是抓 in_hard_parse = 'Y' 的样本，但直接查全表等于在噪音里捞针。必须限定 SAMPLE_TIME > SYSDATE - INTERVAL '5' MINUTE（19c 推荐），且加 module IS NOT NULL 过滤——很多解析来自 PL/SQL 匿名块或 JDBC 默认 module，不筛掉会淹没真实业务模块。
module 和 action 字段怎么用才准
module 通常由应用设置（如 Spring Boot 的 spring.datasource.hikari.data-source-properties.oracle.jdbc.module），action 常用于标记逻辑单元（如 'ORDER_PROCESS'）。但注意：
- 未显式设置时，JDBC 默认为
'JDBC Thin Client'，OCI 可能是'oracle@host'，这类值无法定位到业务模块 - PL/SQL 匿名块的
module多为'SQL*Plus'或'PL/SQL Developer'，需结合client_id或program辅助判断 -
action在 DBMS_APPLICATION_INFO.SET_ACTION 中动态设置，若应用没调用，该字段为空，不能依赖它做主过滤
聚合时别只看 module，要带上 sql_id 和解析类型
同一 module 下可能混着硬解析、软解析甚至 PL/SQL 解析，只按 module 统计会掩盖问题根源：
- 用
GROUP BY module, sql_id, in_hard_parse，能看清是某个 SQL 在特定模块里反复硬解析，还是多个 SQL 共同导致 -
in_hard_parse = 'Y'且sql_id IS NULL的样本，大概率是动态 SQL 解析失败或 PL/SQL 编译阶段卡住，不是普通 SQL 硬解析 - 如果某
module的in_hard_parse = 'Y'样本中，sql_id高度离散（上百个不同值），基本可断定是绑定变量缺失
RAC 环境下必须用 gv$active_session_history，且不能漏 inst_id
解析争用常集中在某节点（比如 node2 的 shared pool latch 严重），只查本地 v$active_session_history 会完全看不到问题：
- 必须用
gv$active_session_history，并显式SELECT inst_id, module, ... - 聚合前先按
inst_id分组，确认是不是单节点异常；如果是，再深入该实例查v$sql中UNBOUND_CURSOR = 'Y'或LOADS > EXECUTIONS的语句 - 别用
DBA_HIST_ACTIVE_SESS_HISTORY替代——它延迟高，解析风暴往往在几十秒内爆发又消失，历史表根本抓不到
真正难的是区分“模块本身有问题”和“模块只是载体”。比如 module = 'WebAPI' 解析高，可能是所有接口共用一个连接池配置错误，也可能是某个新上线的订单接口写了拼接 SQL。这时候得往下挖 sql_id 对应的 sql_text，而不是停留在模块名上。
