关于shared pool的深入探讨(二)

关于shared pool的深入探讨(二)

Sunday, 2004-08-22 21:23 Eygle

|

link:

http://www.eygle.com/internal/shared_pool-2.htm

我们继续把前面的问题展开一下.

其实我们可以从数据库内部监控shared pool的空间碎片情况.
这涉及到一个内部视图x$ksmsp

X$KSMSP的名称含义为: [K]ernal [S]torage [M]emory Management [S]GA Hea[P]
其中每一行都代表着shared pool中的一个chunk

首先记录一下测试环境：

|

> > SQL> select * from v$version; > > BANNER
> ----------------------------------------------------------------
> Oracle9i Enterprise Edition Release 9.2.0.3.0 - Production
> PL/SQL Release 9.2.0.3.0 - Production
> CORE 9.2.0.3.0 Production
> TNS for Linux: Version 9.2.0.3.0 - Production
> NLSRTL Version 9.2.0.3.0 - Production

我们看一下x$ksmsp的结构:

> >
> > > SQL> desc x$ksmsp > Name Null? Type > ----------------------------------------- -------- ---------------------------- > ADDR RAW(4) > INDX NUMBER > INST_ID NUMBER > KSMCHIDX NUMBER > KSMCHDUR NUMBER > KSMCHCOM VARCHAR2(16) > KSMCHPTR RAW(4) > KSMCHSIZ NUMBER > KSMCHCLS VARCHAR2(8) > KSMCHTYP NUMBER > KSMCHPAR RAW(4)
>
> >

我们关注以下几个字段:

KSMCHCOM是注释字段,每个内存块被分配以后，注释会添加在该字段中.
x$ksmsp.ksmchsiz代表块大小

x$ksmsp.ksmchcls列代表类型，主要有四类，说明如下:

free
Free chunks--不包含任何对象的chunk,可以不受限制的被分配.

recr
Recreatable chunks--包含可以被临时移出内存的对象,在需要的时候，这个对象可以
被重新创建.例如,许多存储共享sql代码的内存都是可以重建的.

freeabl
Freeable chunks--包含session周期或调用的对象,随后可以被释放.这部分内存有时候
可以全部或部分提前释放.但是注意，由于某些对象是中间过程产生的，这些对象不能
临时被移出内存(因为不可重建).

perm
Permanent memory chunks--包含永久对象.通常不能独立释放.

我们可以通过查询x$ksmsp视图来考察shared pool中存在的内存片的数量
不过注意:Oracle的某些版本(如:10.1.0.2)在某些平台上(如:HP-UX PA-RISC 64-bit)查
询该视图可能导致过度的CPU耗用,这是由于bug引起的.

我们看一下测试:

> >
> > > 初始启动数据库,x$ksmsp中存在2259个chunk >
> SQL> select count() from x$ksmsp; >
> COUNT() > ---------- > 2259 >
>
> 执行查询: >
> SQL> select count() from dba_objects; >
> COUNT() > ---------- > 10491 >
> 此时shared pool中的chunk数量增加 >
> SQL> select count() from x$ksmsp; >
> COUNT() > ---------- > 2358 >
>
>
>
> >

这就是由于shared pool中进行sql解析，请求空间，进而导致请求free空间,分配、分割
从而产生了更多，更细碎的内存chunk

由此我们可以看出，如果数据库系统中存在大量的硬解析，不停请求分配free的shred pool内存
除了必须的shared pool latch等竞争外，还不可避免的会导致shared pool中产生更多的内存碎片
(当然，在内存回收时，你可能看到chunk数量减少的情况)

我们看以下测试:

> >
> > > 首先重新启动数据库: >
> SQL> startup force; > ORACLE instance started. >
> Total System Global Area 47256168 bytes > Fixed Size 451176 bytes > Variable Size 29360128 bytes > Database Buffers 16777216 bytes > Redo Buffers 667648 bytes > Database mounted. > Database opened. >
> 创建一张临时表用以保存之前x$ksmsp的状态: >
> SQL> CREATE GLOBAL TEMPORARY TABLE e$ksmsp ON COMMIT PRESERVE ROWS AS > 2 SELECT a.ksmchcom, > 3 SUM (a.CHUNK) CHUNK, > 4 SUM (a.recr) recr, > 5 SUM (a.freeabl) freeabl, > 6 SUM (a.SUM) SUM > 7 FROM (SELECT ksmchcom, COUNT (ksmchcom) CHUNK, > 8 DECODE (ksmchcls, 'recr', SUM (ksmchsiz), NULL) recr, > 9 DECODE (ksmchcls, 'freeabl', SUM (ksmchsiz), NULL) freeabl, > 10 SUM (ksmchsiz) SUM > 11 FROM x$ksmsp GROUP BY ksmchcom, ksmchcls) a > 12 where 1 = 0 > 13 GROUP BY a.ksmchcom; >
> Table created. >
> 保存当前shared pool状态: >
> SQL> INSERT INTO E$KSMSP > 2 SELECT a.ksmchcom, > 3 SUM (a.CHUNK) CHUNK, > 4 SUM (a.recr) recr, > 5 SUM (a.freeabl) freeabl, > 6 SUM (a.SUM) SUM > 7 FROM (SELECT ksmchcom, COUNT (ksmchcom) CHUNK, > 8 DECODE (ksmchcls, 'recr', SUM (ksmchsiz), NULL) recr, > 9 DECODE (ksmchcls, 'freeabl', SUM (ksmchsiz), NULL) freeabl, > 10 SUM (ksmchsiz) SUM > 11 FROM x$ksmsp > 12 GROUP BY ksmchcom, ksmchcls) a > 13 GROUP BY a.ksmchcom > 14 / >
> 41 rows created. >
> 执行查询: >
> SQL> select count() from dba_objects; >
> COUNT() > ---------- > 10492 >
> 比较前后shared pool内存分配的变化: >
> SQL> select a.ksmchcom,a.chunk,a.sum,b.chunk,b.sum,(a.chunk - b.chunk) c_diff,(a.sum -b.sum) s_diff > 2 from > 3 (SELECT a.ksmchcom, > 4 SUM (a.CHUNK) CHUNK, > 5 SUM (a.recr) recr, > 6 SUM (a.freeabl) freeabl, > 7 SUM (a.SUM) SUM > 8 FROM (SELECT ksmchcom, COUNT (ksmchcom) CHUNK, > 9 DECODE (ksmchcls, 'recr', SUM (ksmchsiz), NULL) recr, > 10 DECODE (ksmchcls, 'freeabl', SUM (ksmchsiz), NULL) freeabl, > 11 SUM (ksmchsiz) SUM > 12 FROM x$ksmsp > 13 GROUP BY ksmchcom, ksmchcls) a > 14 GROUP BY a.ksmchcom) a,e$ksmsp b > 15 where a.ksmchcom = b.ksmchcom and (a.chunk - b.chunk) <>0 > 16 / >
> KSMCHCOM CHUNK SUM CHUNK SUM C_DIFF S_DIFF > ---------------- ---------- ---------- ---------- ---------- ---------- ---------- > KGL handles 313 102080 302 98416 11 3664 > KGLS heap 274 365752 270 360424 4 5328 > KQR PO 389 198548 377 192580 12 5968 > free memory 93 2292076 90 2381304 3 -89228 > library cache 1005 398284 965 381416 40 16868 > sql area 287 547452 269 490052 18 57400 >
> 6 rows selected.
>
>
>
>
> >

我们简单分析一下以上结果:
首先free memory的大小减少了89228(增加到另外五个组件中),这说明sql解析存储占用了一定的内存空间
而chunk从90增加为93，这说明内存碎片增加了.

在下面的部分中,我会着手介绍一下KGL handles, KGLS heap这两个非常重要的shared pool中的内存结构.