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

link:

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

关于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.