Oracle的内存的分配、回收[final]

Oracle中的共享内存区的分配都是以chunk为最小单位的。Chunk不是一个固定值，它是一个扩展段（extent）中一块连续的内存。而Oracle的内存（其他存储，如磁盘也是）的增长是以扩展段为基础的。

1. 空闲列表和LRU链表
空闲的chunk按照大小来组织在相应的空闲列表（Free List）中。而未pin住的、可重建（unpinned recreatable）的chuck被维护在两个分别用于周期性chunk和短期chunk的LRU链表中。子堆还有一个包含少许空闲内存的主永久内存chunk。

2. 空闲内存分配和回收
空闲内存都是由空闲列表（free list）统一管理、分配的。每个空闲的chunk（大块）都会属于也只属于一个空闲列表。空闲列表上的chunk的大小范围是由bucket来划分的。Bucket直译为“桶”，在西方，往往用桶来盛装一定品质范围的物品，以便查找。比如，在采矿时，用不同的桶来装不同纯度的矿石，在桶上标明矿石的纯度范围，以便在提炼时可以采用不同工艺。在这里，我们也可以把bucket视为一种索引，使Oracle在查找空闲块时，先定位所需的空闲块在哪个bucket的范围内，然后在相应的空闲列表中查找。

一次内存的分配过程如下：当一个进程需要一个内存的大块（chunk）时，它会先扫描目标空闲列表（每个空闲列表对应有一个bucket，bucket是这个空闲列表的中chunk的大小范围）以查找最适合大小的chunk。如果找不到一个大小正好合适的chunk，则继续扫描空闲列表中更大的chunk。如果找到的可用chunk比所需的大小大24字节或者更多，则这个chunk就会被分裂，剩余的空闲chunk又被加到空闲列表的合适位置。如果空闲列表中没有一个chunk能满足要求的大小，则会从非空的相邻bucket的空闲列表中取最小的chunk。如果所有空闲列表都是空的，就需要扫描LRU链表释放最近最少使用的内存。当chunk空闲时，如果相邻的chunk也是空闲的，它们可能会结合（coalesce）起来。

当所有空闲列表都没有合适的空闲chunk可用时，就开始扫描LRU链表，将最近最少使用的chunk释放掉（如有空闲的相邻chunk，则结合），放到相应的空闲列表种去，直到找到合适的chunk或者达到最大查找数限制。如果在释放了LRU链表中最近最少使用的chunk后没没有找到合适空闲chunk，系统就抛4031错误。

如果找到了可用空闲chunk，就将它从空闲列表中移出，放到LRU链表中去。

下面介绍一下Shared Pool的分配和回收。

3. Shared Pool的分配和回收
在Shared Pool中，空闲列表扫描、管理和chunk分配的操作都是受到shared pool latch保护的。显然，如果shared pool含有大量的非常小的空闲chunk，则扫描空闲列表时间将很长，而shared pool latch则会要保持很久。这就是导致shared pool latch争用的主要原因了。有些DBA通过增加shared pool来减少shared pool latch争用，这种方法是没有用的，可能反倒会加剧争用（作为短期解决方法，可以flush shared pool；而要真正解决问题，可以采取在实例启动时keep住那些可能会断断续续使用的对象【这种对象最容易导致shared pool碎片】）。

只有执行了ALTER SYSTEM FLUSH SHARED_POOL才会使shared pool的空闲chunk全结合起来。因此，即使shared pool空闲内存之和足够大，也可能出现内存请求失败（空闲内存都是一些很小的碎片chunk）。

实际上，oracle实例启动时，会保留大概一半的Shared Pool，当有内存压力时逐渐释放它们。Oracle通过这种方法限制碎片的产生。Oracle的少量空袭内存（spare free memory）和X$表即其他持久内存结构一起，隐含在shared pool的主要持久内存chunk中。这些内存不在shared pool的空闲列表中，因此能够立即被分配。但是，却包含在视图V$SGASTAT的free memory的统计数据中。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/35489/viewspace-676656/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/35489/viewspace-676656/