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

賀子_DBA時代發表於2017-03-27
優化
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。


來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/29654823/viewspace-2136105/，如需轉載，請註明出處，否則將追究法律責任。

相關文章