隐式解析过多会抬高CPU消耗、共享池争用，并引发library cache lock等等待；需重点分析AWR中Parse CPU、Parse time elapsed、Top 5事件及Parse Calls/Executions比值，结合Version Count和DBA_HIST_SQLSTAT定位问题SQL。
隐式解析（soft parse）过多会显著抬高 cpu 消耗、共享池争用，甚至触发 library cache lock 或 cursor: pin s wait on x 等等待。oracle 11g 的 awr 报告中，解析统计分散在多个位置，不聚焦看容易漏掉关键信号。
怎么看 Load Profile 里的 Parse 相关指标
Load Profile 小节里有两行直接暴露解析压力：Parse CPU 和 Parse time elapsed。注意不是看 Executes 或 Logons —— 它们和解析无直接关系。
-
Parse CPU高（比如 >5% 的 DB CPU），说明 SQL 解析本身在消耗大量 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），反而要怀疑应用没绑定变量——每个执行都带新字面量，导致大量硬解析
Top 5 Foreground Events 里藏的解析线索
解析问题不会直接显示为 “parse” 事件，而是通过下游等待暴露：
- 出现
library cache: mutex X或library cache lock：说明多个会话在争抢同一个 cursor 的内存结构，典型于高频重用未绑定变量的 SQL - 出现
latch: shared pool：shared pool 内存分配/查找慢，往往伴随大量硬解析或 shared_pool 过小 - 出现
cursor: pin S wait on X：某个 session 正在硬解析或刷新 cursor，其他 session 在等它释放 pin，常与DBMS_SHARED_POOL.KEEP不当使用有关
SQL Statistics 里定位问题 SQL 的实操技巧
别只盯着 “CPU Time” 或 “Elapsed Time” 排名靠前的 SQL——隐式解析大户往往“单条不显眼，总量吓人”：
- 切换到
SQL ordered by Parse Calls子节：找Parse Calls/Executions比值接近 1 的 SQL（意味着几乎每次执行都重新 parse） - 检查该 SQL 的
Module和Action：如果是SQL*Plus或JDBC Thin Client，基本可断定没走绑定变量 - 对比
Version Count：>20 就危险；>50 基本确认存在严重的游标碎片，常见于 date 字符串拼接、TO_CHAR(SYSDATE, 'yyyymmddhh24miss')类写法
Shared Pool Size 和 Library Cache Hit Ratio 的误导性
这两个指标看似健康，却可能掩盖解析问题：
-
Library Cache Hit Ratio>99% 不代表没问题——它只算“找到已存在 cursor”的比例，不区分软/硬解析；即使全是软解析，命中率也接近 100% -
Shared Pool Size的 begin/end 值稳定，不代表够用；11g 默认启用 ASMM，shared_pool_size可被动态压缩，若报告中看到shared_pool缩小 +Parse time elapsed上升，就是 shared pool 被挤占的铁证 - 真正要看的是
DBA_HIST_LIBRARYCACHE视图里的GETS和PINS差值：差值越大，说明硬解析占比越高（因为硬解析需先 GET 再 PIN）
最易被忽略的一点：AWR 报告默认只展示 top-N SQL，而隐式解析问题 SQL 往往因单次执行快、不进 top-N，却在后台高频调用。必须手动查 DBA_HIST_SQLSTAT 中 PARSE_CALLS_TOTAL 累计值，才能揪出真正的“解析水蛭”。
