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


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

相关内容