欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

Oracle 缓存命中率问题一则(里面有个问题咨询大佬们)

程序员文章站 2024-01-28 17:06:46
近日,核心数据库频繁抱出数据库缓存命中率过低,于是开始进行排查。 1.监控软件告警信息 2.抓取告警时间段内的awr报告进行分析 3.execute与parse命中率过低,说明分析(硬解析与软解析)的比例比较大,快速解析较少。 涉及到session_cached_cursors和open_curso ......

近日,核心数据库频繁抱出数据库缓存命中率过低,于是开始进行排查。

1.监控软件告警信息

Oracle 缓存命中率问题一则(里面有个问题咨询大佬们)

2.抓取告警时间段内的awr报告进行分析

Oracle 缓存命中率问题一则(里面有个问题咨询大佬们)

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消耗。