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

关于shared pool的设置一直是一个争议较多的内容.
很多文章上说,shared pool设置过大会带来额外的管理上的负担，从而在某些条件下会导致性能的下降.
那么这个管理上的负担指的是什么内容呢?
本文对这个内容作一定的深入探讨.
本文只涉及一个方面,后续的文章将从其他方面继续讨论.
基础知识:
我们可以通过如下命令转储shared pool共享内存的内容:
SQL> alter session set events ’immediate trace name heapdump level 2’; 
Session altered.
本测试中引用的两个trace文件:
9i:
SQL> @gettrcname
TRACE_FILE_NAME
--------------------------------------------------------------------------------
/opt/oracle/admin/hsjf/udump/hsjf_ora_24983.trc
8i:
SQL> @gettrcname
TRACE_FILE_NAME
--------------------------------------------------------------------------------
/usr/oracle8/admin/guess/udump/guess_ora_22038.trc
Shared Pool通过free list管理free块,Free List按不同size划分Bucket
在Oracle8i中,不同bucket的size范围如下所示(size显示的是下边界):
oracle:/usr/oracle8/admin/guess/udump>cat guess_ora_22038.trc|grep Bucket
 Bucket 0 size=44 
 Bucket 1 size=76 
 Bucket 2 size=140
 Bucket 3 size=268
 Bucket 4 size=524
 Bucket 5 size=1036
 Bucket 6 size=2060
 Bucket 7 size=4108
 Bucket 8 size=8204
 Bucket 9 size=16396
 Bucket 10 size=32780

我们注意,在这里，小于76的块都位于Bucket 0上;大于32780的块,都在Bucket 10上
初始的,数据库启动以后,shared pool多数是连续内存块
当空间分配使用以后,内存块开始被分割,碎片开始出现，Bucket列表开始变长
Oracle请求shared pool空间时，首先进入相应的Bucket进行查找
如果找不到,则转向下一个非空的bucket,获取第一个chunk
分割这个chunk,剩余部分会进入相应的Bucket,进一步增加碎片
最终的结果是,Bucket 0上的内存块会越来越多,越来越碎小
(在我这个测试的小型的数据库上,Bucket 0上的碎片已经达到9030个
而shared_pool_size设置仅为150M)
通常如果每个Bucket上的chunk多余2000个，就被认为是share pool碎片过多
而在大多数情况下,我们请求的都是相对小的chunk,这样搜索Bucket 0往往消耗了大量的时间以及资源
这可能导致share pool Latch被长时间的持有,导致更多的share pool竞争
所以在Oracle9i之前,如果盲目的增大shared_pool_size或设置过大的shared_pool_size，往往会适得其反

我们看一下Oracle9i中的处理方式:
[oracle@jumper oracle]$ sqlplus "/ as sysdba"
SQL*Plus: Release 9.2.0.3.0 - Production on Wed Aug 18 22:13:07 2004
Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.

Connected to:
Oracle9i Enterprise Edition Release 9.2.0.3.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.3.0 - Production
SQL> alter session set events ’immediate trace name heapdump level 2’; 
Session altered.
SQL> @gettrcname
TRACE_FILE_NAME
--------------------------------------------------------------------------------
/opt/oracle/admin/hsjf/udump/hsjf_ora_24983.trc
SQL> 
SQL> !
[oracle@jumper oracle]$ cd $admin
[oracle@jumper udump]$ cat hsjf_ora_24983.trc|grep Bucket
 Bucket 0 size=16
 Bucket 1 size=20
 Bucket 2 size=24
 Bucket 3 size=28
 Bucket 4 size=32
 Bucket 5 size=36
 Bucket 6 size=40
 Bucket 7 size=44
 Bucket 8 size=48
 Bucket 9 size=52
 Bucket 10 size=56
 Bucket 11 size=60
 Bucket 12 size=64

[1] [2] [3]  下一页