Know more about AWR Parse Statistics

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
Version Count Executions SQL Id SQL Module SQL Text
37 4 1nhkkuq1y13vm python.exe select * from www.askmaclean.com
32 0 6mvfay19q3v4n SELECT COUNT(CLIENT_INFO) FROM…
30 0 dqbhc9r7gz0a5 SELECT DECODE(COUNT(CLIENT_INF…
27 24 2nk2p4h18rbwf MMON_SLAVE select tablespace_id, rfno, al…
26 24 a1xgxtssv5rrp MMON_SLAVE select * from www.askmaclean.com
24 4 5s34t44u10q4g SELECT a.name task_name, nvl(e…
24 8 69k5bhm12sz98 SELECT dbin.instance_number, d…
24 4 c8gnrhxma4tas SELECT owner#, property FROM s…
24 4 gdn3ysuyssf82 SELECT advisor_id FROM sys.wri…
22 4 23nad9x295gkf SELECT (m.current_size / 10485…

 

具体的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 ?

Oracle中SQL解析的流程

Oracle中SQL解析的主要流程:
sql_parse_digram

我们说的游标概念比较复杂,它可以是客户端程序中的游标,服务进程中的私有游标,以及服务器端共享池里的共享游标。假设一个游标被打开了,一般来说它的共享游标信息(包括执行计划,优化树等)总是会在SQL AREA里,无需再次软/硬解析。

SESSION_CACHED_CURSORS是Oracle中的一个初始化参数(修改必须重启实例),指定了每个会话缓存的游标上限(保留在PGA中);客户端程序中open cursor的要求仍会被传递给服务进程,服务进程首先扫描自身缓存的游标信息,如果命中则可以避免软解析,也有人称它为“软软解析”。

HOLD_CURSOR是预编译程序中的一个参数,它指定了私有游标是否因该被缓存,这里不做展开。

在分析工具tkprof中hard parse与soft parse被同等对待,都被认为是parse;软解析即会造成parse总数上升。

软解析避免了硬解析过程中的几个步骤,但仍包括了初始化的语法,语义解析并计算语句HASH值与SQL AREA中已有语句进行对比;若匹配则查询优化等昂贵的操作得以避免。

另请注意,10053事件仅在硬解析过程中被触发。

沪ICP备14014813号

沪公网安备 31010802001379号