近日，核心數據庫頻繁抱出數據庫緩存命中率過低，於是開始進行排查。
1.監控軟件告警信息
2.抓取告警時間段內的awr報告進行分析
3.execute與parse命中率過低，說明分析（硬解析與軟解析）的比例比較大，快速解析較少。
涉及到session_cached_cursors和open_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。
現在需要改大這個參數，以便於進行更多的快速解析，這樣可以省去打開一個新的 session cursor和關閉一個現有session cursor所需要消耗的資源和時間。
4.使用下面的sql判斷'session_cached_cursors' 的使用情況。如果使用率為100%則增大這個參數值。
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 144% open_cursors 300 25%
由以上查詢可以看出，session_cached_cursors使用率已經高達 144%。可以推斷出，目前參數 session_cached_cursors 配置是不合理的。
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
再次驗證session_cached_cursors 配置是否合理：
SQL> SELECT NAME, VALUE FROM V$SYSSTAT WHERE NAME LIKE '%cursor%'; NAME VALUE ---------------------------------------------------------------- ---------- opened cursors cumulative 4933498 opened cursors current 320 pinned cursors current 67 session cursor cache hits 3878621 session cursor cache count 1319545 cursor reload failures 372 cursor authentications 9323 7 rows selected. 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 207094 parse time elapsed 483163 parse count (total) 3883754 parse count (hard) 39295 parse count (failures) 3106 parse count (describe) 294 8 rows selected.
session cursor cache hits就是系統在高速緩存區中找到相應cursors的次數，parse count(total)就是總的解析次數，二者比值越高，性能越好。如果比例比較低，並且有較多剩余內存的話，可以考慮加大該參數。
SQL> select 3878621/3883754*100 from dual; 3878621/3883754*100 ------------------- 99.8678341
但是查詢出來發現比值還是比較高的。
先執行：
alter system set session_cached_cursors=100 scope=both;
觀察效果。
看來在如此高的使用率之下，命中率還有如此之低，到底是為什么呢？
（我只能這么解釋，歡迎大佬來幫着解釋一下，我也去翻閱資料繼續查）
--最新動態，有一個大佬建議我多跑幾遍大查詢，將命中率提上去，因為我這個庫的查詢操作很少很少！
注： session_cached_cursor是占用內存的，所以不能給太大值，之前看一個參考例子，設置為100，每個session PGA會多消耗64k，也就是說，如果此時有50個session，會消耗50*64k的內存，如果設置session_cached_cursor為50，每個session會消耗32k，同理計算總的session消耗。