ORA-4031 错误是什么？

刘泽宇

SGA 中的内存池由不同大小的内存块组成。当数据库实例启动时，大量的内存块分配到不同的池中并且由空闲列表哈希 bucket 追踪。随着时间推移，由于内存块被分配和回收，内存块会根据它们的大小在池中的不同空闲列表 Bucket 中移动。当 Oracle 不能找到一个足够大的内存块来满足用户操作所带来的内部分配请求的时候，ORA-4031 错误就可能在 SGA 的任何一个池中出现。

共享池的管理与其它内存池不同。共享池存储数据字典和库缓存相关的信息。然而，这些内存区域使用空闲列表和最少最近使用（LRU）算法管理。在搜索所有的空闲列表，老化 LRU 列表上所有可能的对象，并且扫描空闲列表多次之后，共享池上才会发出 ORA-4031 错误。这意味着 ORA-4031 很难预测。可能有很多的因素一起导致了 ORA-4031，错误发生时的 trace 信息是有关于当时内存条件下“受害者会话”，而不是原因。分配的算法非常复杂，下面是一个内存分配算法的简化版本：

scan regular free list for match, if not found
large request, scan reserved list
   if (chunk found)
      check chunk size and perhaps truncate
   if (chunk is not found)
      scan regular free list
          if (chunk found)
             check chunk size and perhaps truncate
             all done
          if (chunk is not found)
              do LRU operations and repeat

small request, scan regular free list
   do LRU operations and repeat search
    if (chunk found)
       check chunk size and perhaps truncate
       all done
    if (chunk is not found)
   do LRU operations and repeat

注意：有内部检查来限制报出 ORA-4031 错误前所进行搜索的次数。

空闲空间的总数可以从 v$sgastat 中获得，但这是不重要的。重要的是，通过 LRU 操作可以释放或者融合的最大的块的大小。从 heapdump 我们可以看到空闲列表 Bucket 和每个 Bucket 中内存块的信息。

Free List Bucket Summary :
Bucket 0 [size=32 ] Count= 0 Av.Size= 0.00 Max= 0
Bucket 1 [size=40 ] Count= 443 Av.Size= 40.00 Max= 40
Bucket 2 [size=48 ] Count= 1850 Av.Size= 48.00 Max= 48

这里显示 bucket1 有 443 个内存块（chunk），其中最大的是 40byte，平均是 40byte。Bucket 2 包含的内存块的大小是 40 到 48byte 之间。在这个例子中平均大小是 40byte，最大是 40byte。找到在内存池中什么导致了碎片并不总是可行的。有时问题是Oracle 功能导致的，但是很大一部分的情况中，低效的应用代码才是根本原因。

ORA-4031 错误可以发生在 Large Pool，Java Pool，Streams Pool （10g 新增），或者 Shared Pool 中。错误信息会指出哪个池出了问题。如果错误指出问题不在共享池中，这通常意味着对应用环境来说，出问题的池配置的太小了。将出问题的池增大 15%，然后观察后续的问题。如果使用 10g ，Automatic Shared Memory Management （ASMM）功能，MMAN进程会随着时间推移，尝试根据内存需要收缩或者增长 SGA 中不同的组件。如果你在 Large Pool，Streams Pool 或者 Java Pool 中遇到了 ORA-4031 错误， 那么您可能需要增长 SGA_TARGET，使 MMAN 可以在背后管理更多的内存。