shared pool深入剖析（一）

参考：  

关于shared pool的设置一直是一个争议较多的内容.
很多文章上说,shared pool设置过大会带来额外的管理上的负担，从而在某些条件下会导致性能的下降.

那么这个管理上的负担指的是什么内容呢?
本文对这个内容作一定的深入探讨.
本文只涉及一个方面,后续的文章将从其他方面继续讨论.

基础知识:

我们可以通过如下命令转储shared pool共享内存的内容:

SQL> alter session set events 'immediate trace name heapdump level 2';
Session altered.

Shared Pool通过free list管理free块,Free List按不同size划分Bucket
在Oracle8i中,不同bucket的size范围如下所示(size显示的是下边界):

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碎片过多

Shared Pool的碎片过多，是Shared pool产生性能问题的主要原因。
碎片过多会导致Search Free List的时间过长，从而使shared pool latch被长时间持有，导致更多的Latch竞争。

而在大多数情况下,我们请求的都是相对小的chunk,这样搜索Bucket 0往往消耗了大量的时间以及资源
这可能导致share pool Latch被长时间的持有,导致更多的share pool竞争

所以在Oracle9i之前,如果盲目的增大shared_pool_size或设置过大的shared_pool_size，往往会适得其反

我们看一下Oracle10g中的处理方式:

SQL> select spid from v$session s inner join v$process p on s.paddr=p.addr
        inner join v$mystat m on s.sid=m.sid and m.statistic#=0;
SPID
------------
26502
SQL> exit
[oracle@redhat4 udump]$ cd $ORACLE_BASE
[oracle@redhat4 oracle]$ pwd
/u01/app/oracle
[oracle@redhat4 oracle]$ cd admin/jiagulun/udump/
[oracle@redhat4 udump]$  ls *26502*
jiagulun_ora_26502.trc
[oracle@redhat4 udump]$ cat jiagulun_ora_26502.trc | grep Bucket 

(************* increment by 4 ****************)
 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 174 size=712
 Bucket 175 size=716

(************* increment by 8 ****************)
 Bucket 176 size=724
 Bucket 177 size=732
 Bucket 178 size=740
... ...
 Bucket 185 size=796
 Bucket 186 size=804
 Bucket 187 size=812

(************* increment by 64 ****************)
 Bucket 188 size=876
 Bucket 189 size=940
 Bucket 190 size=1004
 Bucket 191 size=1068

(************* increment by 4 ****************)
 Bucket 192 size=1072
 Bucket 193 size=1076

(************* increment by 56 ****************)
 Bucket 194 size=1132
 Bucket 195 size=1196

(************* increment by 64 ****************)
 Bucket 196 size=1260
 Bucket 197 size=1324
 Bucket 198 size=1388
 Bucket 199 size=1452
 ... ...
 Bucket 238 size=3948
 Bucket 239 size=4012

(************* increment by 84 ****************)
 Bucket 240 size=4096

(************* increment by 4 ****************)
 Bucket 241 size=4100

(************* increment by 8 ****************)
 Bucket 242 size=4108

(************* increment by 4096 ****************)
 Bucket 243 size=8204

(************* increment by 256 ****************)
 Bucket 244 size=8460

(************* increment by 4 ****************)
 Bucket 245 size=8464
 Bucket 246 size=8468
 Bucket 247 size=8472

(************* increment by 824 ****************)
 Bucket 248 size=9296

(************* increment by 4 ****************)
 Bucket 249 size=9300

(************* increment by 3020 ****************)
 Bucket 250 size=12320

(************* increment by 4 ****************)
 Bucket 251 size=12324

(************* increment by 4072 ****************)
 Bucket 252 size=16396

(************* increment by 16384 ****************)
 Bucket 253 size=32780

(************* increment by 32768 ****************)
 Bucket 254 size=65548
[oracle@redhat4 udump]$

我们看到,在Oracle10g中,Free Lists被划分为0~254,共255个Bucket
每个Bucket容纳的size范围

Bucket 0~175 容纳size以 4 递增
Bucket 175~187 容纳size以 8 递增
Bucket 187~191 容纳size以 64 递增
.......
Bucket 254: >=65548

如下所示：
0~175   increment by 4
175~187 increment by 8
187~191 increment by 64
191~193 increment by 4
193~195 increment by 56
195~239 increment by 64
239~240 increment by 84
240~241 increment by 4
241~242 increment by 8
242~243 increment by 4096
243~244 increment by 256
244~247 increment by 4
247~248 increment by 824
248~249 increment by 4
249~250 increment by 3020
250~251 increment by 4
251~252 increment by 4072
252~253 increment by 16384
253~254 increment by 32768

通过上面的分析，可以知道Oracle10g对shared pool中的free list的安排可谓匠心独具啊。在Oracle10g中对Free list链表的加强管理，改进Oracle8i中,过大shared pool带来的栓锁争用等性能问题在某种程度上得以解决.