Execute to Parse %≥95%为健康，低于90%需警惕；它位于AWR报告「Instance Efficiency Percentages」中，反映SQL执行与解析比率，值越低说明解析越频繁、游标复用越差。
怎么看 Execute to Parse % 是否达标
这个值直接反映 SQL 执行与解析的比率，位置在 AWR HTML 报告的「Instance Efficiency Percentages」表格里。健康阈值是 ≥95%；低于 90% 就该动手查了——它不是说“解析慢”，而是说明大量 SQL 每次执行都在重新解析，游标复用率极差。
计算逻辑是：(Executes - Parses) / Executes × 100%。值越低，代表 Parse 越频繁；等于 0 就是“每执行一次，就解析一次”，基本可断定没用绑定变量。
- OLTP 系统中长期
- 如果该值突然从 98% 掉到 70%，优先检查近期应用是否上线了拼接 SQL 的代码（比如 Java 中
String.format("SELECT * FROM t WHERE id = %d", id)） - 注意：该指标是快照区间内汇总值，不能定位具体 SQL，仅作全局趋势判断
Hard Parses/sec 超多少才算危险
去「Load Profile」小节找 Hard Parses 行，看单位为 “per second” 的数值。Oracle 官方建议 OLTP 场景下应 100，就要立刻干预——这不是“偏高”，是已触发 shared pool latch 争用的典型前兆。
更关键的是比值：Hard Parses / Parses。如果 >0.8，意味着 80% 以上的解析都是硬解析，几乎可 100% 确认未使用绑定变量或存在严重游标碎片（如 TO_CHAR(SYSDATE, 'yyyymmddhh24miss') 这类动态格式写法）。
- 不要只盯单次快照峰值，要看连续 3 个以上快照是否稳定高于阈值
-
Parses本身高不一定是问题，但如果Hard Parses占比同步升高，就是明确信号 - RAC 环境下该值需按节点单独评估，避免被平均值掩盖热点节点
为什么 Library Cache Hit Ratio 高 ≠ 解析健康
Library Cache Hit Ratio >99% 很常见，但它只统计“有没有找到 cursor”，不区分软/硬解析。即使全是硬解析，只要共享池没满、没发生 latch 等待，命中率照样接近 100%。
真正暴露问题的是下游等待事件和解析耗时指标：
- 出现
library cache: mutex X或latch: shared pool，说明硬解析正在抢资源 -
Parse time elapsed显著高于Parse CPU（差值 >100 ms/s），说明解析排队严重 -
SQL ordered by Parse Calls里有大量Parse Calls / Executions ≈ 1的 SQL，且Module是JDBC Thin Client或SQL*Plus
Soft Parse % 低于 95% 怎么办
Soft Parse % = Soft Parses / (Soft Parses + Hard Parses)，位置也在「Instance Efficiency Percentages」。低于 95% 就该怀疑绑定变量缺失；低于 80% 基本确认应用层存在系统性问题。
但注意：这个百分比本身不告诉你哪条 SQL 有问题。必须配合「SQL Statistics」里的两个子节交叉验证：
- 进
SQL ordered by Parse Calls，筛出Parse Calls > 1000且Version Count > 20的 SQL —— 游标碎片化严重 - 再切到
SQL ordered by Version Count，找Version Count > 50的语句，99% 是日期/ID 拼接导致 - 检查对应 SQL 的
SQL Text，重点看 where 条件是否含字面量（如WHERE status = 'ACTIVE'而非WHERE status = :b1）
最易被忽略的一点：PL/SQL 匿名块里动态 SQL（EXECUTE IMMEDIATE）若未显式使用 USING 绑定参数，也会导致硬解析，且不会出现在常规 SQL 列表里——得查 v$sqlarea 中 command_type = 47 的记录。
