建站
咨询
售后
建站咨询
关于ExecutetoParse%:比例太低的优化思路
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。
综上所述可以确定需要加大参数session_cached_cursors来提高oracle数据库的性能，但是参数session_cached_cursors并不是越大越好，太大会引起pga缓存碎片，消耗内存，然后session cursor cache的管理也是使用LRU。
当前文章：关于ExecutetoParse%:比例太低的优化思路
转载源于：http://scyingshan.cn/article/psghso.html
