oracle 库缓冲区命中率低问题的解决

Oracle 库缓冲区命中率低问题的解决

库缓存中主要存储了: 1,sql语句及其执行计划 2,pl/sql及编译结果：过程，函数，程序包，触发器，匿名块。 库缓冲区命中率 应至少在95%以上，如果低于95%那么首先要确定 1,确定命中率： select round((sum(pinhits) / sum(pins)) * 100 ,2) || '%' lhitratio from v$librarycache where (pinhits>0 and pins>0); 2,share_pool_size 大多是情况下300m可以满足一般数据库的要求 select value/1024/1024 shared_size from v$parameter where name='shared_pool_size'; 3,看是否有空闲空间 select bytes/1024/1024 freemb from v$sgastat s where s.pool='shared pool' and s.name='free memory'; 有时有空闲也会出现对象被溢出的情况。 4,重载率 select round((sum(reloads)/sum(pins))*100,2)||'%' "reload%" from v$librarycache where (pinhits>0 and pins>0); 这个值要在1以内，这个就是sql被重新加载的次数，一般情况下我们只加载一次就够了，下次就直接从库缓存中直接读取，但有的时候需要重新加载，比如：表被分析，表被truncate，drop等，pl/sql被重新编译等。 还是要强调那句话，一味的增加大小不会解决质的问题，过大的shared_pool还会增加oracle的管理开销。 我们应该从sql语句中去找寻问题，如果库缓冲区命中率低的话，我遇到过一种情况（大多数都是这样）：绑定变量。 那我们怎么定位是否绑定变量呢 通过2个视图我们基本可以确定： 1,v$sqlarea视图 select count(*) ,PERSISTENT_MEM from v$sqlarea  group by PERSISTENT_MEM having count(*)>10  order by count(*) desc; COUNT(*) PERSISTENT_MEM ---------- --------------      2730           1808      1444           1856       337            904 count(*)是求的sql数量 PERSISTENT_MEM ：是占有稳定的内存数 persistent_mem 凡是我们因为没有绑定变量，sql语句一样只是where条件的值不一样，那么他的persistent_mem一定是一样的 这样我们就可以通过这个值的大小，和出现次数来判断有多少sql运行这个值是一样的，如果过多那么基本可以判断重复的sql过多，没有绑定变量。 我们可以select sql_text from v$sqlarea where PERSISTENT_MEM=1808;来看是否有许多重复，没有绑定变量运行的sql语句。 2,v$db_object_cache视图 SELECT owner, name, kept, loads FROM V$DB_OBJECT_CACHE WHERE loads >1 and owner= '用户名' ORDER BY loads DESC; OWNER                      NAME                       KEPT      LOADS ----------     -----------------------------------    --------- -------------- DC                          QUOTATION                   NO        1623 DC                          RATOR                       NO        1545 DC                          N_PARAS                     NO        1535 DC                          RAGE_REAL_COST              NO        1418 SD                          D_DETAIL                    NO        1405 SD                          TEMPARAMETER                NO        1399 LDC                         T_ENTRUST                   NO        1365 LDP                         TRACTSTATE                  NO        1293 LDP                         N_PARAS                     NO        1289 LDC                         VARIETY                     NO        1200 LDP                         RATOR                       NO        1181 可以看到 许多对象（表）被反复loads的次数很大，在v$db_object_cache表里被反复load多数是因为缓存不够，被挤出。而造成这种原因多数是因为没有绑定变量，大量重复加载一样的语句造成的。而通过增加share_pool不能解决根本问题 解决方法： 1，修改sql语句，改用变量代替常量（开发来完成） 2，可以keep一些经常用到的小表。dbms_shared_pool数据包，可以通过loads的次数和表的大小综合考虑要keep那些表（DBA来完成），关于这个包怎么用上网上找一下文章吧，还是很多的。