近日，核心数据库频繁抱出数据库缓存命中率过低，于是开始进行排查。
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消耗。
经验首页