【江枫】Shared Pool空间管理算法的演进(三)

前面说到，Oracle9i中每个sub pool的空间下边界是128M，实践证明是偏小的，所以在Oracle10g中，这个边界被调整为256M，在Metalink的一篇文章(Note 396940.1)中还有一种说法，可能500M左右一个sub pool在10.2以后的版本中更加合适，不知道在Oracle11g中是不是对这个设置再次做出调整，因为没有足够的测试环境，我也没有试验。大家如果谁有试验出Oracle11g的sub pool边界大小，欢迎留言给出。Oracle10g的另外一个改进，就是为某些共享对象搜索可用空间的时候，如果在一个sub pool中找不到可用的chunk，可以切换到其他sub pool了，不过还不能做到所有类型的内存请求都能切换。而可以做到在不同子池间切换，对于单个子池空间不够的情况，应该算是比较彻底的解决方案，希望在以后的版本中能更进一步了。

最后介绍一个内部视图X$KSMSP，这个视图保存了每个chunk的详细信息，chunk可以分成四种类型(KSMCHCLS)：

• free：free chunks–未分配的可用chunk。
• recr：recreatable chunks–包含可以被临时移出内存的对象，在需要的时候对象可以被重新创建，如共享sql代码的内存。
• freeabl：freeable chunks–包含session周期或调用的对象，随后可以被释放。但是注意，由于某些中间过程产生的对象不能临时被移出内存(因为不可重建)。
• perm：Permanent memory chunks–包含永久对象.通常不能独立释放，像processes/sessions参数指定的数组控制结构。

如果是R-开头的如R-free类型，则表示该chunk是Shared Reserverd Pool中的内存片。

查看目前Share Pool中各类chunk的空间总体情况：

查看各个大小范围的free chunk的情况：

监控系统中ora-04031的报错情况(有些错不会在alert中报出来)：

X$KSMP视图在HP平台的某些版本中有bug，查询时可能导致系统挂起，慎用。也可以通过转储level 2级别的heapdump来获得类似的信息：

--EOF--