	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。

關於Execute to Parse %:比例太低的最佳化思路

相關文章