聊聊Oracle共享池的Duration机制
ORA-4031疑问是咱们这代DBA经常会面对的灵魂拷问。每当出现疑问，用户都会问几个疑问：“为什么会出疑问？”、“疑问出在什么中央了？”、“为什么共享池还有那么多闲暇，就4031了”、“下回如何防止相似疑问出现？”。基于Oracle复杂的共享池结构和用户千差万别的运行场景。想要好好回答出这些疑问并不容易。关于二十多年前的那些DBA来说，ORA-4031疑问也是催促他们仔细学习Oracle Internal技术的主因之一。
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的变迁，是不是也看出一个好的数据库产品不大或者被设计进去，而是要在用户场景中千锤百炼才干变得越来越好呢？
