Execute to Parse %低于90%表明硬解析严重，连续两份报告低于该值多因绑定变量缺失或NLS参数漂移；应重点排查Parse Calls与Executions比值接近1的SQL，并结合parse_ratio、硬解析等待事件等综合诊断。
看 Instance Efficiency Percentages 里的 Execute to Parse % 是否跌破 90%
这个值不是“执行一次再解析一次”，而是反向指标：95% 表示每执行 100 次只解析 5 次；80% 就意味着每 100 次执行要硬解析 20 次。AWR 报告里它就在 Instance Efficiency Percentages 表格中，不用自己算。
连续两份报告都低于 90%，基本可断定是绑定变量缺失或 NLS 参数漂移导致的系统性硬解析；如果仅高峰段暴跌（比如上午 9:30–10:30），则更可能是游标失效、子游标爆炸等瞬时压力触发，不一定是代码问题。
- 别信名字：它叫 “Execute to Parse %”，但实际反映的是软解析复用能力，数值越低，硬解析越猖獗
- 对比必须做：拿问题时段报告和前一小时“正常”报告并排看，差值比绝对值更有诊断价值
- 低于 85% 就该拉响警报，低于 70% 往往已伴随
latch: library cache等待飙升
查 SQL ordered by Parse Calls 并过滤 parse_calls ≈ executions 的语句
翻到 AWR 报告的 SQL Statistics → SQL ordered by Parse Calls 部分，重点不是找 Parse Calls 最高的那条 SQL，而是找那些 Parse Calls 和 Executions 数量接近的语句——比如 Parse Calls = 12000，Executions = 15000，比值接近 1，说明几乎每次执行都在重新硬解析。
这类语句在 v$sql 中表现为：executions = 1 但 parse_calls > 1（反复硬解析后被挤出共享池），或是 sql_text 里带 WHERE id = 123 这类字面量，而非 WHERE id = :b1。
- 跳过 DBA 工具类语句（如
SELECT * FROM v$session），它们本就不该进库缓存 - 注意 EXECUTIONS = 0 但 PARSE_CALLS > 0 的条目——多为异常终止或统计未刷新，不具代表性
- 复制
sql_id后立刻查v$sql验证：SELECT sql_text, executions, parse_calls FROM v$sql WHERE sql_id = 'xxx'
用 DBA_HIST_SQLSTAT 算 parse_ratio 排序定位高危 SQL
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 基本等于没重用游标——每执行一次，就解析一次。但要注意：这个比值在 OLTP 场景下比在报表类 SQL 中更具杀伤力，因为高频执行会把 CPU 快速榨干。
- 硬解析单次耗时 0.5–2ms，1000 tps 下若 90% 语句无绑定变量，光解析就吃掉 450ms+ CPU/秒
- 别急着调
shared_pool_size：盲目扩容只会让硬解析更隐蔽，不是解决，是掩盖 - 真正难的是让所有高频 SQL 都带绑定变量——哪怕 ORM 自动生成，也要确认没拼接字面量
交叉验证 Parse CPU to Parse Elapsd % 和 parse count (hard)
在 Instance Activity Stats 区域找 parse count (hard) 和 parse count (total)。若前者 / 后者 > 10%，就是硬解析严重；再看 Instance Efficiency Percentages 中的 Parse CPU to Parse Elapsd %：若低于 20%，说明解析过程大量卡在等待（如 latch: library cache），而非真正计算。
这两个指标组合起来，能区分问题是出在“CPU 狂转做解析”还是“CPU 被 latch 争用堵死”。后者往往伴随 library cache lock 或 cursor: pin S wait on X 等等待事件进入 Top 5。
- 查
v$session的nls_language、nls_territory是否一致：不一致会导致相同 SQL 被当成不同语句硬解析 - 检查
cursor_sharing是否设为FORCE（开发环境慎用，可能改执行计划） -
session_cached_cursors使用率若达 100%，也需调大（常见设为 400），否则会加剧硬解析压力
真实瓶颈往往藏在 parse_ratio > 0.9 的 SQL 里，而不是 top 1 的总 CPU 消耗语句；而最危险的，是那些你查不到执行计划突变、却持续稳定输出硬解析的语句——它们不报警，但每天悄悄吃掉几个核的 CPU 时间。
