在Oracle中如何利用AWR报告识别硬解析过多的问题-Oracle-PHP中文网

execute to parse %低于90%表明硬解析严重，连续两份报告低于该值多因绑定变量缺失或nls参数漂移；应重点排查parse calls与executions比值接近1的sql，并结合parse_ratio、硬解析等待事件等综合诊断。

在oracle中如何利用awr报告识别硬解析过多的问题

看 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 字段，能间接反映游标复用程度。执行以下查询（替换快照范围）：

QuantOracle

63个确定性量化金融计算器 + 10个通过MCP的复合工作流。期权定价、Greeks、奇异衍生品、风险指标、投资组合优化……

下载

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。