Oracle的共享池从问世开始这几十年来，一直是十分考验DBA能力的存在，这涉及到Oracle内存堆HEAP的管理（KGL）算法问题、SQL解析问题、SQL共享问题、并发控制问题等多个领域。共享池出问题后分析与处理的复杂程度，如果没有经历过，绝对是不敢想象的。
阅读SHARED POOL HEAP DUMP是很多那个时代DBA都必须具备的能力。共享池是Oracle解决超高并发问题的关键，为了让共享池更加高效同时管理更加简单，Oracle不断地在优化其算法，甚至对复杂的数据结构做了多次调整。从最初把LARGE POOL采用独立的链表、留出独立的空闲空间Reserved Pool用于大内存分析，到9i开始引入的SubPool，都是为了让共享池更加高效并发，并且尽可能少出问题。自从10g引入了ASMM，并且服务器的物理内存越来越便宜之后，共享池出大问题，在业务高峰期影响业务系统运行的问题才少了很多。Oracle 11g之后，随着共享池管理的再优化，再加上针对cursor mutex的各种优化，DBA才离ORA-4031更远了一些。
关于Oracle的共享池的SUBPOOL的问题，大家讨论得比较多，大多数认真学习过OCP教材的朋友都烂熟于心了，今天不再讨论。有时候共享池太大，分成了多个SUBPOOL，如果碎片化比较严重，那么出现分配较大的CHUNK的时候，就很容易出现ORA-4031。不过有些时候好像有些时候每个SUBPOOL里好像也有充足的空闲空间，照样报ORA-4031,而且刷共享池都解决不了问题，必须重启数据库才行。
似乎我们所掌握的知识还不足以解释某些特殊的情况，一般遇到这种情况，我会认为一定是有我们所还没有掌握的一些技术细节让我们无法继续向下分析。今天我给大家科普一个小常识，subpool下面还有一层subpool,也就是官方所说的durations。当Oracle数据库启用AMM/ASMM的时候，shared sub pool会根据预期需要的持续时间对分配的内存进行分类，将SUBPOOL分成4个durations。4个分区分别是：
lduration 0 (instance)：实例级的永久性内存，只有实例shutdown才会释放。该部分内存无法通过flush shared pool等手段释放。包括：参数表、kgsp-heap,kglsim object batch等实例数据结构。
lduration 1:session
lduration 2:cursor
lduration 3:execution
图片
每个duration都是一个单独的存储桶，当内存分片分配给duration时，该分片中的内存不可用于子池中的任何其他duration。已经分配给duration的分片内存移动到另一duration的唯一方法是根据需要将分片转移到缓冲区缓存，然后返回共享池，不过这种情况实际上很少发生。因此分配给duration的granules通常会停留在那里。如果在较大的分片上分配较小的内存，可能导致大部分空闲内存未被使用，并且不可用于任何其他duration。这会增加共享池出现ORA-4031的机会。
图片
上面是一个Oracle 11.2.0.4的shared pool heap dump，其中sga heap(1,0)表示这是SUBPOOL1的duration 0的dump。我们可以看到在这个dump中显示duration是开启的。
将subpool再划分为多个duration会加大共享池碎片化的程度。特别是当duration 0无内存可分配时，哪怕其他duration还有很多空间，也无法再扩充空间，此时产生宕机的机会很大。Oracle提供了一个隐含参数来开启duration,默认情况，这个参数是true。通过设置"_enable_shared_pool_durations"=false可以关闭duration功能。不过要关闭duration要考虑清楚，因为perment空间可能会在关闭duration后 快速增长，导致必须重启数据库实例才能完全释放。甚至有些时候需要在重启实例前在spfile中去掉”__shared_pool_size”参数，确保实例启动后ASMM合理分配共享池的空间。
图片
Oracle 12.1之后，duration机制做了优化，0，1，2三个duration被合并为一个，只保留了0，3两个duration，这样的话出现因为内存使用不均匀而导致的ORA-4031被大大减少了。这个功能被backport到了11.2.0.2以后的版本中，被ORA-4031引发宕机困扰的11G用户，可以通过打补丁8857940来摆脱烦恼了。
今天和大家分享了Oracle shared pool duration的一些基本概念，希望大家遇到类似问题的时候，这篇文章能有所帮助。其实从Oracle 共享池subpool和duration的变迁，是不是也看出一个好的数据库产品不大可能被设计出来，而是要在用户场景中千锤百炼才能变得越来越好呢？
