Parse CPU to Parse Elapsd%是解析CPU时间占总解析耗时的百分比，越高越好；低于20%表明解析严重等待，接近或超100%说明解析顺畅，超100%属四舍五入误差。
Parse CPU to Parse Elapsd% 是什么，怎么看数值是否异常
这个指标不是“越高越好”或“越低越好”，而是用来判断解析过程是否被卡在等待上。Parse CPU to Parse Elapsd% 算的是 parse time cpu / parse time elapsed × 100。它本质反映：CPU真正在干活的时间，占整个解析耗时的比例。
如果数值 低于 20%，基本说明解析过程大量时间花在等资源上，不是真正在解析；如果 接近或超过 100%，说明解析本身很顺，没明显排队——但注意，Parse CPU to Parse Elapsd% 超过 100% 是四舍五入误差导致的，不算故障。
-
parse time cpu来自v$sysstat，单位是厘秒（centiseconds），按每次 parse call 累加，精度有限 -
parse time elapsed是整次 parse 的 wall-clock 时间，记录方式不同，两者相除可能失真 - 别只看单次报告的绝对值，重点看趋势：同一业务时段该值从 85% 掉到 12%，比固定 15% 更值得警惕
数值偏低时，该查哪些等待事件和参数
当 Parse CPU to Parse Elapsd% 明显偏低（比如
- 出现
library cache: mutex X或library cache lock→ 多个会话抢同一个 SQL 的 cursor 内存结构，典型于未绑定变量、SQL 文本微小变化（如日期硬编码） - 出现
latch: shared pool→ shared pool 内存分配/查找慢，常因 shared_pool_size 过小，或大量硬解析把 pool 撑满 - 出现
cursor: pin S wait on X→ 某个 session 正在硬解析或刷新 cursor，其他 session 在等它释放 pin，注意排查是否误用了DBMS_SHARED_POOL.KEEP - 检查
parse count (hard)/parse count (total)比值：>10% 就确认硬解析泛滥，根源几乎一定是没用绑定变量
为什么 Library Cache Hit Ratio 高不代表解析没问题
很多人看到 Library Cache Hit Ratio >99% 就放心，这是个典型误区。这个指标只统计“有没有找到已存在的 cursor”，不区分软解析还是硬解析——哪怕全是硬解析，只要每次都能新建成功，命中率照样接近 100%。
真正暴露问题的是 SQL ordered by Parse Calls 子节：
- 找
/Executions比值接近 1 的 SQL：意味着几乎每次执行都重新 parse，不是软解析，是硬解析 - 看
Module字段：如果是SQL*Plus、JDBC Thin Client或python类应用名，基本坐实没走绑定变量 - 看
Version Count：>20 就危险，>50 基本可断定存在严重游标碎片，常见于TO_CHAR(SYSDATE, 'yyyymmddhh24miss')这类动态拼接写法
Load Profile 里 Parse 相关指标怎么交叉验证
别只盯着 Executes 或 Logons，它们和解析压力无关。Load Profile 中真正有用的只有两行：
-
Parse CPU高（比如 >5% DB CPU）→ 解析本身吃 CPU，常见于硬解析频繁或 shared pool latch 争用 -
Parse time elapsed明显大于Parse CPU（差值 >100 ms/s）→ 解析排队严重，大概率是 library cache mutex 或 shared pool latch 等待 - 如果
Parse CPU和Parse time elapsed都低，但Executes极高（如 >1000/s）→ 反而更要怀疑应用没绑定变量，导致大量轻量级硬解析
复杂点在于：这些指标背后没有直接报错，也不会单独成行说“你解析有问题”，得靠组合信号交叉印证——比如 Parse CPU to Parse Elapsd% 低 + library cache: mutex X 排第一 + SQL ordered by Parse Calls 里某条 SQL 的 Version Count 突然飙到 127，这三者同时出现，基本不用再查别的了。
