Oracle-DBA应知应会-进一步了解共享池.docx

?

?

OracleDBA应知应会--进一步了解共享池

?

?

顾名思义，共享池是Oracle数据库的所有会话所共享的缓冲池。共享池里方的也是需要给所有会话共享的数据。前面已经简单介绍了一些共享池的内容，以及内存分配释放的算法。这些内容在本节中就不多做描述了。本节主要介绍一下共享池的一些基本的构造，以及相关的算法。通过对这些知识的了解，我们可以掌握一些共享池分析和优化的思路。

一般情况下，学习共享池的知识，以及优化的技巧，我们不一定需要去DUMP共享池。不过对于想更加深入的了解共享池的朋友，DUMP共享池是在学习共享池内部结构过程中必不可少的步骤。老白要事先声明的是，共享池的结构十分复杂，不建议初学者就去分析共享池的DUMP，因为如果你对共享池还缺乏深入的了解，甚至不知道共享池的主要用途是什么，那么面对几百兆甚至几十G的DUMP文件，只有“崩溃”这两个字可以形容你了。如果想要深入了解共享池，就需要了解把共享池的内容DUMP到文件的基本命令，以下命令可以把LIBRARY_CACHE的内容DUMP到TRACE文件中：

ALTERSESSIONSETEVENTSimmediatetracenameLIBRARY_CACHElevelLL;

其中LL代表Level级别,对于9.2.0及以后版本,不同Level含义如下:

lLevel=1,转储Librarycache统计信息

lLevel=2,转储hashtable概要

lLevel=4,转储Librarycache对象，只包含基本信息

lLevel=8,转储Librarycache对象，包含详细信息(包括childreferences,pinwaiters等)

lLevel=16,增加heapsizes信息

lLevel=32,增加heap信息

正如前一节我们介绍的HEAP管理一样，共享池通过freelist管理空闲块,FreeList按不同大小划分Bucket。在Oracle8i中,Oracle把所有的空闲内存链接在10个Bucket上，在Oracle9i中，Oracle把空闲的内存链接在255个Bucket上。

ORACLE8i管理FreeList的方法是，把所有的空闲块都放在10个BUCKET中，小于76字节的块都位于Bucket0上;大于32780的块,都在Bucket10上。数据库启动以后,共享池中大多数是连续内存块，当空间分配使用以后,内存块开始被分割,碎片开始出现，BUCKET对应的CHUNK链表表开始变长。当数据库中请求分配共享池空间时，首先进入相应的Bucket进行查找，如果找不到,则转向下一个（内存块大小更大的）BUCKET,获取第一个chunk，分割这个chunk,剩余部分会进入相应的Bucket,进一步增加碎片。最终的结果是,Bucket0上的内存块会越来越多,越来越碎小。通常如果每个Bucket上的chunk多余2000个，就被认为是sharepool碎片过多。而在大多数情况下,我们请求的都是相对小的chunk,这样搜索Bucket0往往消耗了大量的时间以及资源。这可能导致sharepoolLatch被长时间的持有,导致更多的sharepool竞争。对于Oracle9i之前的数据库，由于BUCKET的数量太少，因此如果共享池比较大，实例启动一定时间后，BUCKET0的CHUNK数量会变得十分巨大，共享池的效率会有所下降，闩锁争用也会越来越严重。这个时候，如果刷新一下共享池，系统性能会有很大的回升。实际上，很多Oracle9i的系统也存在这样的问题，共享池碎片化的程度会相当的高，系统运行一段时间后就必须刷新共享池了。特别是那些会话数量很多，并发量大的系统。几年前，老白就碰到过这样一个案例，这个系统有上千个会话，业务高峰期ACTIVE的会话数量高达200－300个，而数据库服务器的配置很低，仅有16G，因此能够给共享池分配的空间也十分有限。这个系统运行一段时间后性能就会明显的下降。经过分析，我们发现了是共享池碎片化导致的性能下降，于是建议客户每天晚上业务不忙的时候手工刷新一下共享池，于是系统就变得比较稳定了。

在ORACLE9i中,FreeLists被划分为0~254,共255个Bucket。每个Bucket容纳的size范围如下：

lBucket0~199容纳size以4递增

lBucket200~249容纳size以64递增

lBucket249:4012~4107=96

lBucket250:4108~8203=4096

lBucket251:8204~16