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
关键词：对于shared pool的深入探讨(一)