execute to parse %低于90%表明硬解析过高，oltp系统建议≥95%；持续低于85%常伴cpu争用，需重点检查绑定变量缺失、子游标爆炸或nls参数不一致。
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）对比。如果只有高峰段暴跌，说明压力触发了游标失效或子游标爆炸，不一定是代码问题
- 健康阈值：OLTP系统建议≥95%；低于90%就要警惕；持续低于85%通常已伴随明显CPU争用
- 注意排除DBA类SQL（如
SELECT * FROM v$session），它们本就不该进共享池，拉低整体比例但无实际影响
SQL ordered by Parse Calls里真正危险的是Parse Calls和Executions都高的语句
翻到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）。
- 这个查询比单纯看
Parse Calls排序更可靠，因为它排除了低频但单次高解析的干扰项 - 结果中若
sql_text大量出现字面量（如WHERE status = 'ACTIVE'），而非WHERE status = :b1，就是绑定变量缺失的铁证 - 如果
parse_ratio接近1且child_number在v$sql里持续增长（>10），说明子游标爆炸，常见于NLS参数漂移或绑定变量类型不一致
别只盯着AWR，v$sql_shared_cursor才是定位无法共享根因的关键
即使写了绑定变量，也可能因环境不一致导致游标无法重用。直接查v$sql_shared_cursor比猜更可靠：
SELECT * FROM v$sql_shared_cursor
WHERE sql_id = 'xxx'
AND (UNBOUND_CURSOR = 'Y'
OR EXPLAIN_PLAN_CURSOR = 'Y'
OR OPTIMIZER_MISMATCH = 'Y');
OPTIMIZER_MISMATCH = 'Y'常见于optimizer_features_enable设置不一致，或会话级ALTER SESSION SET optimizer_mode被误用；NLS_LENGTH_SEMANTICS、NLS_SORT等NLS参数漂移也会触发该标记，需统一客户端与数据库端设置。
-
bind_mismatch = 'Y'在v$sql里出现，说明绑定变量类型/长度不一致，比如一个传VARCHAR2(10)，另一个传VARCHAR2(30) -
cursor_bind_capture_destination参数必须为memory或both，否则v$sql_bind_capture为空不代表没用绑定变量 - 盲目增大
shared_pool_size只会让硬解析更隐蔽：执行计划淘汰变慢，但硬解析照旧发生，CPU消耗一点没少
复杂点在于：硬解析暴增常常是共享池碎片化与锁争用的复合故障，不是单靠改SQL就能解决。容易被忽略的是，v$latch中latch: shared pool的miss rate持续>0.5%，且v$sgastat的free memory长期低于5MB，往往比Execute to Parse %更早暴露真实瓶颈。
