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

库缓存中主要存储了:
1,sql语句及其执行计划
2,pl/sql及编译结果：过程，函数，程序包，触发器，匿名块。

库缓冲区命中率 应至少在95%以上，如果低于95%那么首先要确定

1,确定命中率：
select round((sum(pinhits) / sum(pins)) * 100 ,2) || ‘%’ lhitratio
from v librarycachewhere(pinhits>0andpins>0);2,sharepoolsize大多是情况下300m可以满足一般数据库的要求selectvalue/1024/1024sharedsizefromv l i b r a r y c a c h e w h e r e ( p i n h i t s > 0 a n d p i n s > 0 ) ; 2 , s h a r e p o o l s i z e 大 多 是 情 况 下 300 m 可 以 满 足 一 般 数 据 库 的 要 求 s e l e c t v a l u e / 1024 / 1024 s h a r e d s i z e f r o m v parameter where name=’shared_pool_size’;
3,看是否有空闲空间
select bytes/1024/1024 freemb from v sgastatswheres.pool=′sharedpool′ands.name=′freememory′;有时有空闲也会出现对象被溢出的情况。4,重载率selectround((sum(reloads)/sum(pins))∗100,2)||′fromv s g a s t a t s w h e r e s . p o o l = ′ s h a r e d p o o l ′ a n d s . n a m e = ′ f r e e m e m o r y ′ ; 有 时 有 空 闲 也 会 出 现 对 象 被 溢 出 的 情 况 。 4 , 重 载 率 s e l e c t r o u n d ( ( s u m ( r e l o a d s ) / s u m ( p i n s ) ) ∗ 100 , 2 ) | | ′ f r o m 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来完成）

http://blog.sina.com.cn/s/blog_44916bcd0100okd8.html