从如何更好的监控Oracle共享池谈起( 二 ) _Oracle

文章插图
为什么这样说呢？kghlu中的kghlusep指针是一个十分重要的指针，它指向了共享池LRU链上的一个关键位置，那个位置分割了共享池LRU链的冷热区。当新的CHUNK要加入LRU链的时候，是添加在该指针左侧的冷区尾部。而冷区中的CHUNK被多次访问时会迁移到LRU链的热端，以便于被重用。因此这个指针是访问十分频繁的，采集该结构的数据要格外谨慎。
x$kghlu经常被某些数据库监控软件用来监控共享池问题，不过频繁的访问这个数据结构还是会对数据库产生影响的，特别是数据库并发比较大，共享池存在性能问题的时候，如果过于频繁的监控这个数据结构，可能会产生一些相当严重的问题。如果知道了这一点，我想大家应该理解为什么我会对共享池的监控数据采集如此谨慎了。
col "avg size" format a30 truncate;
col siz format 999999999999
SELECT KSMCHCLS CLASS, COUNT(KSMCHCLS) NUM, SUM(KSMCHSIZ) SIZ,To_char( ((SUM(KSMCHSIZ) /COUNT(KSMCHCLS) /1024)), '999,999.00')||'k' "AVG SIZE" FROM X$KSMSP GROUP BY KSMCHCLS;

文章插图
实际上要分析shared pool的风险，上面的语句具有更好的效果，如果发现perm内存不断增长，free的平均大小不断下降，甚至低于4KB，那么说明共享池出现了较大的碎片化风险。而下面的语句可以作更细致的分析。
col sga_heap format a15
col size format a10
select KSMCHIDX "SubPool", 'sga heap('||KSMCHIDX||',0)'sga_heap,ksmchcom ChunkComment,decode(round(ksmchsiz/1000),0,'0-1K', 1,'1-2K', 2,'2-3K',3,'3-4K',4,'4-5K',5,'5-6k',6,'6-7k',7,'7-8k',8,'8-9k', 9,'9-10k','> 10K') "size" ,count(*),ksmchcls Status, sum(ksmchsiz) Bytes from x$ksmsp where KSMCHCOM = 'free memory' group by ksmchidx, ksmchcls,'sga heap('|| KSMCHIDX||',0)',ksmchcom, ksmchcls,decode(round(ksmchsiz/1000),0,'0-1K',1,'1-2K', 2,'2-3K', 3,'3-4K',4,'4-5K',5,'5-6k',6,'6-7k',7,'7-8k',8,'8-9k', 9,'9-10k','> 10K');

文章插图
这条SQL可以采集到共享池中free内存的详细情况，如果较大的heap比较少时，共享池的碎片化就很严重了。
似乎我们可以直接对x$ksmsp直接做采集，从而获得对共享池分析的更有效的数据。不过真的如此吗？我们如果看一下x$ksmsp的实际结构，就会明白为什么我们不想把这个采集放到自动化采集的脚本中，更好的采集共享池的信息了。

文章插图
我们可以看到ksmsp实际上指向了一个kghds的链表，而这个链表实际上是指向真实的heap链，对x$ksmsp的统计实际上会遍历heap链表，对于共享池很大，并且共享池并发访问很重，特别是共享池存在性能问题的场景，这种访问无疑会加重共享池的负担，甚至成为压垮骆驼的最后一根稻草。如果这种采集放到不受控的自动化采集中去，那可能会带来不可知的影响。因此这种分析我们只是在手工点击的工具中提供，而不会做成自动化采集的一部分。
监控与诊断实际上也是一种运维知识，开发监控与诊断工具，产品经理中应该有资深的运维专家，仅仅依靠高水平的研发人员是开发不出一套真正高水平的运维监控与诊断工具的。而对于一些比较脆弱的数据库模块的监控采集，也需要十分谨慎的做设计，否则监控软件会成为伪装成天使的恶魔。