關于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。
