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

AWR报告中Execute to Parse %:比例太低，如下所示：

Instance Efficiency Percentages (Target 100%)

Buffer Nowait %:	97.33	Redo NoWait %:	100.00
Buffer Hit %:	96.59	In-memory Sort %:	100.00
Library Hit %:	84.65	Soft Parse %:	93.10
Execute to Parse %:	2.60	Latch 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。