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的错误。
©著作权归作者所有：来自51CTO博客作者andylhz的原创作品，如需转载，请注明出处，否则将追究法律责任
ORACLE内存休闲Oracle数据库
随时随地看视频
