awr中execute to parse%低于90%表明绑定变量使用不足，需结合ash验证是否真实争用latch:shared pool；高parse_ratio（>0.9）sql应检查绑定变量缺失、字面量变化或nls参数漂移。
直接看 awr 里的 execute to parse % 是否跌破 90%
这个百分比在 awr 报告的 instance efficiency percentages 表格里，不用算——oracle 已经帮你算好了。数值越低，说明解析占比越高，绑定变量用得越差。连续几份报告都低于 90%，基本可以锁定是应用层漏了绑定变量，不是偶然抖动。
别被名字误导：Execute to Parse % 不是“执行一次再解析一次”，而是「平均每执行 100 次，只解析几次」的倒推值。95% 意味着每 100 次执行只解析 5 次；80% 就意味着每 100 次执行要解析 20 次。
重点对比时段：比如业务高峰段（如上午 9:30–10:30）的报告，和非高峰段（如凌晨 2:00–3:00）对比。如果只有高峰段暴跌，说明压力触发了游标失效或子游标爆炸，不一定是代码问题。
从 SQL ordered by Parse Calls 找高频解析语句
翻到 AWR 报告的 SQL Statistics → SQL ordered by Parse Calls 部分，盯住前 5 条。真正危险的不是 Parse Calls 最高的那条，而是那些 Parses 和 Executions 都很高的 SQL——比如 Parse Calls = 12000，Executions = 15000，比值接近 1，说明几乎每次执行都在解析。
快速验证方法：
- 复制该
sql_id，查v$sql：SELECT sql_text, executions, parse_calls FROM v$sql WHERE sql_id = 'xxx' - 如果
executions = 1但parse_calls > 1，说明这条语句反复硬解析后又被挤出共享池，是典型碎片化信号 - 如果
sql_text里有WHERE id = 123这类写死值，而不是WHERE id = :b1，就是绑定变量缺失的铁证
用 DBA_HIST_SQLSTAT 算 parse_ratio 排序
AWR 本身不存解析类型标记，但 DBA_HIST_SQLSTAT 里有 parse_calls 和 executions 字段，能间接反映复用程度。执行以下语句（注意替换快照范围）：
SELECT sql_id, sql_text, parse_calls, executions,
ROUND(parse_calls / NULLIF(executions, 0), 2) parse_ratio
FROM dba_hist_sqltext t
JOIN dba_hist_sqlstat s USING (sql_id)
WHERE s.snap_id BETWEEN &begin_snap AND &end_snap
AND s.parse_calls > 50
AND s.executions > 0
ORDER BY parse_ratio DESC, s.parse_calls DESC;
parse_ratio > 0.9 的 SQL 基本等于没重用游标。但要注意过滤掉 DBA 工具类语句（如 SELECT * FROM v$session），它们本就不该进库缓存。
常见干扰项：
-
INSERT INTO ... VALUES (:1, :2, to_date(:7, 'yyyymmddhh24miss'))—— 看似用了绑定变量，但如果:7的字符串长度每次不同（比如 '20260612123456' vs '20260612123'），Oracle 会认为字面量不等价，强制新建子游标 -
UNBOUND_CURSOR = 'Y'在v$sql_shared_cursor中为真，说明 Oracle 明确拒绝复用，不是你代码写错了，而是环境参数（如NLS_LENGTH_SEMANTICS）漂移了
别只盯着 AWR，配合 ASH 抓正在抢 latch 的活体 SQL
AWR 是历史汇总，ASH 才是实时快照。latch: shared pool 高，本质是硬解析卡在获取 latch 上，不是结果，是正在发生的争抢。用下面语句抓最近 1 分钟的活体：
SELECT sql_id, sql_opname, COUNT(*) cnt FROM v$active_session_history WHERE event = 'latch: shared pool' AND sample_time > SYSDATE - 1/1440 GROUP BY sql_id, sql_opname ORDER BY cnt DESC FETCH FIRST 10 ROWS ONLY;
关键点：
- 必须加
SAMPLE_TIME > SYSDATE - 1/1440，否则默认查全历史，慢且噪声大 - 按
sql_opname分组（如SELECT、INSERT），避免把 DML 和查询混在一起误判 - 拿到
sql_id后，立刻查v$sql的loads和executions：如果executions = 1但loads > 5，说明每次换值都重编译
最易忽略的一点：很多人查到高 parse_ratio SQL 就去改代码，却没确认它是否真的在抢 latch: shared pool。可能只是统计信息过期导致优化器反复生成新计划，而 latch 争用来自另一批完全不同的语句——ASH 才是唯一能交叉验证的来源。
