Oracle  ORA-4031错误产生的原因

    首先这个错误发生时的表现如下：

    ORA-04031: unable to allocate XXXX bytes of shared memory

    （“shared pool，“unknown object”，”sga heap（1，0）”，”obj stat memor“）

    就是最基本的查询简单的动态性能视图都无法完成：

    下面来细细的分析一下原因：

    这就需要从shared pool 的内存结构来分析了， 首先shared pool 有许多的内存块组成，这些内存块通常叫做chunk

    chunk是 shared pool这是内存分配的最小单位，其中的内存都是连续的。

    chunk 分为四个类型，可以从 X$ksmsp中的 ksmchcls列看到 ，X$ksmsp视图中的每条记录都表示在当前shared pool 中的一个chunk

    1） free 这种类型的chunk不包含有有效的对象，可以被分配。

    2）  recr 表示recreatable，这种类型的chunk 里面包含的对象可以在需要的时候被临时移走，并且在需要的时重新创建。

    比如对于很多的共享SQL的chunk就是recreatable的。

    3） freeabl 这种类型的chunk 包含的对象是曾经被session 使用过的。并且随后会被完全或者部分释放。这种chunk

    不能被临时从内存中移走，因为他们是在处理过程中产生的，如果移走就不能被重建。

    4） perm 意味着永久性，这种类型的chunk包含永久的对象，大型的permanent类型的chunk也可能包含有用的空间，

    这部分可用空间可以在需要的时候释放。

    在shared pool 中可用的chunk（也就是free类型的）会被连接起来成为 free list 或者叫bucket（一个free list就是一个bucket）

    每个backet中的chunk的大小是不同的。

    当某个进程需要shared pool 里面的一个chunk，该进程首先倒伏后所需空间大小的backet上去扫描，以找到最合适的chunk，扫描持续到backet

    的最末端，值到找到尺寸符合的chunk为止，如果找到的chunk尺寸必须要的要大，则这个被找到的chunk就会被拆分一个用来存储数据

    另一个成为free类型的chunk 并成为当前的bucket。

    当某个bucket不包含有任何尺寸的chunk，那么就从下一个非空的backet上获得一个最小的chunk，如果在剩下的所有的backet中都找不到可用的chunk

    则需要扫描已经使用的recreatable类型的chunk。从该链表上释放出部分chunk，因为只有recreatable类型的chunk才是可以被临时一处内存的。

    但某个chunk正在被使用时该chunk是不能被移除内存的。比如某个SQL语句正在执行，那么该语句所使用的chunk就不能被移除内存。该SQL所引用的表，索引

    等对象占用的chunk也不能够被移除内存，当shared pool中无法找到满足大小的所需内存时就会出现ORA-4031的错误。

    当出现ORA-4031的错误的时候，我们查询V$SGSTAT中的可用shared pool空间时，可能发现可用的内存足够大了，为什么还是出现ORA-4031错误呢？

    事实上，在oracle发出错误之前已经释放出大量的recreatable类型的chunk了因此会产生不少的可用内存。但是这些可用的chunk中没有一个是连续的从而

    才发出ORA-4031的错误。

　相关推荐：

　Oracle发力Java开发工具

　Oracle Partition分区详细总结

　sqlplus连接Oracle的经历

　温馨提示：本内容来源于网络，仅代表作者个人观点，与本站立场无关，仅供您学习交流使用。其中可能有部分文章经过多次转载而造成文章内容缺失、错误或文章作者不详等问题，请您谅解。如有侵犯您的权利，请联系我们，本站会立即予以处理。