Oracle ORA-4031错误产生的原因详解

Oracle ORA-4031错误产生的原因首先这个错误发生时的表现如下：ORA-04031: unable to allocate XXXX bytes of shared memory （

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

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

趣问问AI

免费可用的国内版chat，AI写作和AI对话

91

查看详情

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的错误。