关于Execute to Parse %:比例太低的优化思路

AWR报告中Execute to Parse %:<span color:#ff0000;"="" style="font-size: 16px;">比例太低,如下所示:

Instance Efficiency Percentages (Target 100%)
Buffer Nowait %:97.33Redo NoWait %:100.00
Buffer Hit %:96.59In-memory Sort %:100.00
Library Hit %:84.65Soft Parse %:93.10
Execute to Parse %:2.60Latch Hit %:99.32
Parse CPU to Parse Elapsd %:75.73% Non-Parse CPU:99.03
Execute to Parse %
表示 SQL 语句解析后被重复执行命中率 计算公式 =100*(1-Parses/Executions)
如果该值偏小,说明分析 ( 硬解析与软解析  ) 的比例较大,快速解析(即软软解析)较少。
关于 session_cached_cursors 参数的调整:
open_cursors: 该参数含义是同一个 session 同时打开最多在使用的游标数。在 Oracle10.2.0.1.0 版本中默认为 300
session_cached_cursors SESSION_CACHED_CURSORS, 就是说的是一个 session 可以缓存多少个 cursor ,让后续相同的 SQL 语句不再打开游标 , 从而避免软解析的过程来提高性能。 ( 绑定变量是解决硬解析的问题 ) ,软解析同硬解析一样 , 同样消耗资源 . 所以这个参数非常重要。在 Oracle10.2.0.1.0 版本中默认为 20
现在需要改大这个参数,以便于进行更多的软软解析,这样可以省去 open 一个新的 session cursor close 一个现有 session cursor 所需要消耗的资源和时间。
通过下面语句查看验证了 session_cached_cursors 的使用率确实为 100%, (这是我当时查看验证的)
SQL> Select 'session_cached_cursors' Parameter,  
       Lpad(Value, 5) Value,  
      Decode(Value, 0, ' n/a', To_Char(100 * Used / Value, '990') || '%') Usage  
   From (Select Max(s.Value) Used  
       From V$statname n, V$sesstat s  
      Where n.Name = 'session cursor cache count'  
         And s.Statistic# = n.Statistic#),  
       (Select Value From V$parameter Where Name = 'session_cached_cursors')  
  Union All  
 Select 'open_cursors',  
     Lpad(Value, 5),  
     To_Char(100 * Used / Value, '990') || '%'  
 From (Select Max(Sum(s.Value)) Used  
         From V$statname n, V$sesstat s  
      Where n.Name In  
         ('opened cursors current', 'session cursor cache count')  
         And s.Statistic# = n.Statistic#  
        Group By s.Sid),  
       (Select Value From V$parameter Where Name = 'open_cursors');  
 
PARAMETER              VALUE      USAGE
---------------------- ---------- -----
session_cached_cursors    50       100%
open_cursors             300        22%
 
再次验证 session_cached_cursors 是否合理:
session_cached_cursors 的值也不是越大越好,我们可以通过下面两条语句进一步验证该参数是否合理:
SQL> SELECT NAME, VALUE FROM V$SYSSTAT WHERE NAME LIKE '%cursor%';  
 
NAME                                                                  VALUE
---------------------------------------------------------------- ----------
opened cursors cumulative                                        1075158364
opened cursors current                                                 1578
pinned cursors current                                                  458
session cursor cache hits                                         140287938
session cursor cache count                                         20425458
cursor authentications                                             18472351
SQL> SELECT NAME, VALUE FROM V$SYSSTAT WHERE NAME LIKE '%parse%';  
 
NAME                                                                  VALUE
---------------------------------------------------------------- ----------
ADG parselock X get attempts                                              0
ADG parselock X get successes                                             0
parse time cpu                                                     13211356
parse time elapsed                                                 19331036
parse count (total)                                              1020611015
parse count (hard)                                                 83024992
parse count (failures)                                               504137
parse count (describe)                                                20927
Session   cursor cache hits 就是系统在高速缓存区中找到相应 cursors 的次数, parse count(total) 就是总的解析次数,二者比值越高,性能越好。如果比例比较低,并且有较多剩余内存的话,可以考虑加大该参数。如下所示二者的比例比较低,
SQL> select 140289159/1020611015*100  from dual;
 
140289159/1020611015*100
------------------------
               13.745605
 
通过下面的语句来判断 open_cursors 的大小是否合理,如下所示,我的是合理的。
SQL>SELECT MAX(A.VALUE) AS HIGHEST_OPEN_CUR, P.VALUE AS MAX_OPEN_CUR FROM V$SESSTAT A, V$STATNAME B, V$PARAMETER P WHERE A.STATISTIC# = B.STATISTIC#  AND B.NAME = 'opened cursors current'  AND P.NAME = 'open_cursors'  GROUP BY P.VALUE;
HIGHEST_OPEN_CUR    MAX_OPEN_CUR
--------------------------------------------------------------------------------
      34               300
综上所述可以确定需要加大参数 session_cached_cursors 来提高 oracle 数据库的性能,但是参数 session_cached_cursors并不是越大越好,太大会引起pga缓存碎片,消耗内存, 然后session cursor cache的管理也是使用LRU。
  • 0
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值