Parse CPU to Parse Elapsed%是一个我们在分析AWR报告时常会看到的解析性能指标，该指标反映了 快照内解析CPU时间和总的解析时间的比值(Parse CPU Time/ Parse Elapsed Time)； 若该指标水平很低，那么说明在整个解析过程中 实际在CPU上运算的时间是很短的，而主要的解析时间都耗费在各种其他非空闲的等待事件上了(如latch:shared pool,row cache lock之类等)， 通过该指标我们可以了解是否有必要来调优Oracle的优化器Optimizer的解析(parse)工作， 调优的对象包括软、硬解析(soft and hard parse)，理论上我们的目标是有极少的硬解析，少量的软解析，以及Parse CPU to Parse Elapsed% 接近于100% 相当于解析时都是在CPU上运算 而不等待， 所以Parse CPU to Parse Elapsed%也同时给我们以调优方向的启示。
Soft Parse %是AWR中另一个重要的解析指标，该指标反应了快照时间内 软解析次数 和 总解析次数 (soft+hard 软解析次数+硬解析次数)的比值，若该指标很低，那么说明了可能存在剧烈的hard parse硬解析，大量的硬解析会消耗更多的CPU时间片并产生解析争用(此时可以考虑使用cursor_sharing=FORCE)； 理论上我们总是希望 Soft Parse % 接近于100%， 但并不是说100%的软解析就是最理想的解析状态，
通过设置 session_cached_cursors参数和反复重用游标我们可以让解析来的更轻量级，即通俗所说的利用会话缓存游标实现的软软解析(soft soft parse)。
其他一些对于tuning SQL parse调优SQL解析有帮助的指标信息：
Reloads:
Library Cache Activity -> SQL Area reloads 信息，该指标反映了 游标被重新加载到shared pool共享池中的次数，引起reload重新装载的原因可能是共享游标失效Invalidation (失效可能由DDL等操作引起),也可能由shared pool共享池Free memory空闲内存过少导致sql reloads；reloads往往意味着本来可能已经被解析好的SQL语句，需要再次经历硬解析才能使用。
Library Cache Activity
- "Pct Misses" should be very low
| Namespace |
Get Requests |
Pct Miss |
Pin Requests |
Pct Miss |
Reloads |
Invali- dations |
| BODY |
245 |
0.41 |
1,835 |
0.05 |
0 |
0 |
| CLUSTER |
665 |
0.00 |
155 |
0.00 |
0 |
0 |
| DBLINK |
1,020 |
0.00 |
0 |
|
0 |
0 |
| EDITION |
34 |
0.00 |
52 |
0.00 |
0 |
0 |
| INDEX |
308 |
3.90 |
244 |
10.66 |
14 |
0 |
| OBJECT ID |
273 |
100.00 |
0 |
|
0 |
0 |
| QUEUE |
5 |
0.00 |
762 |
0.00 |
0 |
0 |
| RULESET |
2 |
0.00 |
2 |
0.00 |
0 |
0 |
| SCHEMA |
1,077 |
0.00 |
0 |
|
0 |
0 |
| SQL AREA |
3,224 |
29.44 |
30,256 |
2.92 |
119 |
89 |
| SUBSCRIPTION |
1 |
0.00 |
1 |
0.00 |
0 |
0 |
| TABLE/PROCEDURE |
6,210 |
0.55 |
8,069 |
2.12 |
40 |
0 |
| TRIGGER |
182 |
0.00 |
188 |
0.00 |
0 |
0 |
High version Count:
在Oracle中同样的SQL语句可能被硬解析成不同的子游标(child cursor)，一句SQL statement拥有过多的child cursor(例如超过50个子游标)往往说明游标无法被共享，若游标无法被共享使用那么只好每一次都再次硬解析和生成更多的子游标了，
可以通过v$sql_shared_cursor来了解具体无法共享游标的原因。 实际引起SQL High Version Count的原因可能有很多，这里不再一一列举，特别需要注意的是以下2个Note涉及到的问题:
Note 296377.1 Handling and resolving unshared cursors/large version_counts Troubleshooting: High Version Count Issues
Note 261020.1 High Version Count with CURSOR_SHARING = SIMILAR or FORCE
Note 438755.1 High SQL Version Counts - Script to determine reason(s)
Note 377847.1 Unsafe Literals or Peeked Bind Variables
AWR中提供了SQL ordered by Version Count信息方便用户了解该指标
SQL ordered by Version Count
- Only Statements with Version Count greater than 20 are displayed
具体的high version count诊断步骤:
1 select sql_text, hash_value,address from v$sqlarea where sql_id ='{sql id
from AWR>}'
2 select * from v$sql_shared_cursor where address = <address returned above>
3 SELECT sql_text,version_count,address FROM V$SQLAREA order by version_count desc;
4 From step 3 , take the sql with highest version count and put in below
SELECT * FROM V$SQL_SHARED_CURSOR WHERE address = 'HERE';
5. 检查 参数 NLS_LENGTH_SEMANTICS What is the value of NLS_LENGTH_SEMANTICS ?
2群基础群 适合刚入门的同学，会共享最佳入门实践和资料 QQ群 # QQ群号:171092051 # 已经升级到 500人的超级群，空位多多，无需面试
