暂无图片
暂无图片
暂无图片
暂无图片
暂无图片
首页 / X$视图与共享池分析

X$视图与共享池分析

白鳝的洞穴 2020-06-16
1217
前两天一个客户的系统出问题HANG住了，RAC两个节点都HANG住，当时情况紧急只能重启数据库实例。重启后一切正常。后来客户把一些资料发给我，我简单看了看，最终定位是一条语句导致了系统的hang死。

SELECT KSMCHCLS CLASS, COUNT(KSMCHCLS) NUM, SUM(KSMCHSIZ) SIZ,

To_char( ((SUM(KSMCHSIZ)/COUNT(KSMCHCLS)/1024)),'999,999.00')

FROM X$KSMSP GROUP BY KSMCHCLS; 

这是一条十分著名的共享池监控语句，它的执行结果是这样的：

这个数据对于分析我们的共享池有没有问题十分有价值，十多年前老白经常使用这条语句帮助客户分析共享池的问题，发现共享池碎片的情况，判断共享池可能存在的风险。因此老白也在多个帖子上推荐过这条语句。没想到这条语句居然被某个厂商的数据库监控软件使用了。近些年，随着老白对Oracle内部原理的研究的深入，对此类的查询语句可能存在的风险认知也越来越全面，因此也在多个场合提醒用户，针对X$KSMSP视图的使用一定要谨慎。在对共享池进行监控的时候，最好不要定期采集X$视图的数据，如果非要采集，最好选择X$HGHLU而尽可能避免使用X$KSMSP。这是为什么呢？
X$KGHLU是共享池分析经常会用到的一个内部视图，实际上X$的表都不是真正的表，而是SGA中的ORACLE的内存对象。访问X$KGHLU是需要访问Oracle内部的数据结构的。共享池是数据库最为脆弱的部分，一旦出问题，整个数据库都会出现严重故障，轻则数据库变慢,重则数据库HANG死甚至宕机，所以访问共享池相关的统计数据都要十分小心。X$KGHLU是一个内部的统计数据区，所以访问这个数据结构不需要对共享池的HEAP做扫描和遍历，因此访问这个内部表的风险较小，所以这个表也经常被DBA用于分析共享池可能存在的问题。今天我们以Oracle 10g为例，介绍一下KGHLU数据结构。Oracle 11g的变化很小。我们先来看看X$KGHLU系统表：

SQL> desc x$kghlu

 Name                                      Null?    Type

 ----------------------------------------- -------- -------------------------

 ADDR                                                RAW(8)

 INDX                                                 NUMBER

 INST_ID                                            NUMBER

 KGHLUIDX                                        NUMBER

 KGHLUDUR                                       NUMBER

 KGHLUSHRPOOL                               NUMBER

 KGHLUFSH                                        NUMBER

 KGHLUOPS                                        NUMBER

 KGHLURCR                                        NUMBER

 KGHLUTRN                                        NUMBER

 KGHLUMXA                                        NUMBER

 KGHLUMES                                        NUMBER

 KGHLUMER                                        NUMBER

 KGHLURCN                                        NUMBER

 KGHLURMI                                         NUMBER

 KGHLURMZ                                        NUMBER

 KGHLURMX                                        NUMBER

 KGHLUNFU                                        NUMBER

 KGHLUNFS                                        NUMBER

实际上对应Oracle的内部数据结构是KGHLU结构：

kghlusep指针放置在LRU链的冷热交会的地方，新的CHUNK链入LRU链的时候会插入到这个位置。右侧是热端对象，希望这些对象尽可能被重用。左侧是冷端，这些对象重用较少，随时可以释放。这两部分都属于RECREATEABLE的CHUNK ,最终都可以被重用，只是热端的数据尽可能要保留更多的时间。于是当某个CHUNK被访问次数达到阈值（比如缺省的2次），就会被移到热端。
这个数据结构的一个最为著名的脚本就是：

column indx heading "indx|indx num"

column kghlurcr heading "RECURRENT|CHUNKS"

column kghlutrn heading "TRANSIENT|CHUNKS"

column kghlufsh heading "FLUSHED|CHUNKS"

column kghluops heading "PINS AND|RELEASES"

column kghlunfu heading "ORA-4031|ERRORS"

column kghlunfs heading "LAST ERROR|SIZE"

select

  indx,

  kghlurcr,

  kghlutrn,

  kghlufsh,

  kghluops,

  kghlunfu,

  kghlunfs

from

  sys.x$kghlu

where

  inst_id = userenv('Instance')

/

下面是一个例子：

ORA-4031方面的数据就不多解释了，大家很容易理解。关于RECURRENT和TRANSIENT的数量，如果前者总是很多，TRANSIENT的数量总是很小，那么当前共享池存在的风险相对就大一些了。当然实际上共享池的问题要更为复杂一些。不同的系统也有不同的特点。
老白经常在给客户做故障处理的时候发现很多用户都用一些访问X$的脚本去监控共享池，实际上如果你不了解这些视图的特点，那么是很容易出问题的。甚至我经历过的不少宕机案例，最终定位就是因为监控脚本中的共享池查询导致的系统HANG死。所以针对共享池监控，一定要十分小心。
下面这个脚本是十分著名的脚本，很多DBA在使用：

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');

结果类似这样：

这个脚本确实可以让我们很清晰的看出共享池碎片情况，但是如果我们知道ksmsp的内部结构：

可以看出，这个结构实际上是扫描kghds链表。这种扫描是开销十分巨大的，在扫描的这段时间内，会持有共享池相关的闩锁。如果共享池碎片十分严重，同时争用也十分严重，这种扫描操作可能会HANG死数据库。如果我们对这个视图的监控做成定时任务去跑，那么早晚是会搞出事情来的。
这种脚本一定是DBA在现场的时候去查询，而且一定要随时掌握执行情况，一旦很长时间都没有结果出来，数据库也出现了HANG的现象，那么赶紧杀掉相关会话。
最后修改时间：2020-06-16 09:16:36
文章转载自白鳝的洞穴，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

评论