【转】ORA-04031 unable to allocate %s bytes of shared memory

诊断并解决 ORA-04031 错误

当我们在共享池中试图分配大片的连续内存失败的时候，Oracle 首先清除池中当前没使用的所有对象，使空闲内存块合并。如果仍然没有足够大单个的大块内存满足请求,就会产生 ORA-04031 错误。

当这个错误出现的时候你得到的错误解释信息类似如下:

04031, 00000, "unable to allocate %s bytes of shared memory ("%s","%s","%s","%s")"
// *Cause: More shared memory is needed than was allocated in the shared
// pool.
// *Action: If the shared pool is out of memory, either use the
// dbms_shared_pool package to pin large packages,
// reduce your use of shared memory, or increase the amount of
// available shared memory by increasing the value of the
// INIT.ORA parameters "shared_pool_reserved_size" and
// "shared_pool_size".
// If the large pool is out of memory, increase the INIT.ORA
// parameter "large_pool_size".

1.共享池相关的实例参数

在继续之前，有必要理解下面的实例参数:

• SHARED_POOL_SIZE
  这个参数指定了共享池的大小，单位是字节。可以接受数字值或者数 字后面跟上后缀"K" 或 "M" 。"K"代表千字节, "M"代表兆字节。

• SHARED_POOL_RESERVED_SIZE
  指定了为共享池内存保留的用于大的连续请求的共享池空间。当共享池碎片强制使 Oracle 查找并释放大块未使用的池来满足当前的请求的时候，这个参 数和 SHARED_POOL_RESERVED_MIN_ALLOC 参数一起可以用来避免性能下降。

• 这个参数理想的值应该大到足以满足任何对保留列表中内存的请求扫描而无需从共享池中刷新对 象。既然操作系统内存可以限制共享池的大小，一般来说，你应该设定这个参数为 SHARED_POOL_SIZE 参数的 10% 大小。

• SHARED_POOL_RESERVED_MIN_ALLOC 这个参数的值控制保留内存的分配。如果一个足 够尺寸的大块内存在共享池空闲列表中没能找到，内存就从保留列表中分配一块比这个值大的空 间。默认的值对于大多数系统来说都足够了。如果你加大这个值，那么 Oracle 服务器将允许从这 个保留列表中更少的分配并且将从共享池列表中请求更多的内存。这个参数在 Oracle 8i 和更高的版本中是隐藏的。提交如下的语句查找这个参数值:

  SELECT nam.ksppinm NAME, val.ksppstvl VALUE
  FROM xksppi nam, xksppsv val
  WHERE nam.indx = val.indx AND nam.ksppinm LIKE '%shared%'
  ORDER BY 1;

  10g 注释：Oracle 10g 的一个新特性叫做 "自动内存管理" 允许 DBA 保留一个共享内存池来分 shared pool,buffer cache, java pool 和 large pool。一般来说，当数据库需要分配一个大的对象到共享池中并且不能找到连续的可用空间，将自动使用其他 SGA 结构的空闲空间来增加共享池的大小 。既然空间分配是 Oracle 自动管理的，ora-4031 出错的可能性将大大降低。自动内存管理在初始化参数 SGA_TARGET 大于 0 的时候被激活。 当前设定可以通过查询 v$sga_dynamic_components 视图获得。请参考 10g 管理手册以得到更多内容 。

2.诊断 ORA-04031 错误

注：大多数的常见的 ORA-4031 的产生都和 SHARED POOL SIZE 有关，这篇文章中的诊断步骤大多都是关于共享池的。　对于其它方面如 Large_pool 或是 Java_pool，内存分配算法都是相似的，一般来说都是因为结构不够大造成。

ORA-04031 可能是因为 SHARED POOL 不够大，或是因为碎片问题导致数据库不能找到足够大的内存块 。

ORA-04031 错误通常是因为库高速缓冲中或共享池保留空间中的碎片。 在加大共享池大小的时 候考虑调整应用,使用共享的 SQL 并且调整如下的参数：

SHARED_POOL_SIZE,
SHARED_POOL_RESERVED_SIZE,
SHARED_POOL_RESERVED_MIN_ALLOC.

首先判定是否 ORA-04031 错误是由共享池保留空间中的库高速缓冲的碎片产生的。提交下的查询：

SELECT free_space, avg_free_size,used_space, avg_used_size, request_failures,
last_failure_size
FROM v$shared_pool_reserved;

如果:

REQUEST_FAILURES > 0 并且 LAST_FAILURE_SIZE > SHARED_POOL_RESERVED_MIN_ALLOC

那么 ORA-04031 错误就是因为共享池保留空间缺少连续空间所致。要解决这个问题,可以考虑加大 SHARED_POOL_RESERVED_MIN_ALLOC 来降低缓冲进共 享池保留空间的对象数目，并增大 SHARED_POOL_RESERVED_SIZE 和 SHARED_POOL_SIZE 来加大共享池保留空间的可用 内存。

如果：

REQUEST_FAILURES > 0 并且 LAST_FAILURE_SIZE < SHARED_POOL_RESERVED_MIN_ALLOC

或者

REQUEST_FAILURES 等于 0 并且 LAST_FAILURE_SIZE < SHARED_POOL_RESERVED_MIN_ALLOC

那么是因为在库高速缓冲缺少连续空间导致 ORA-04031 错误。

第一步应该考虑降低 SHARED_POOL_RESERVED_MIN_ALLOC 以放入更多的对象到共享池 保留空间中并且加大 SHARED_POOL_SIZE。

3.解决 ORA-04031 错误

• ORACLE BUG

  Oracle 推荐对你的系统打上最新的 PatchSet。大多数的 ORA-04031 错误都和 BUG 相关，可以通过使用这些补丁来避免。

  下面表中总结和和这个错误相关的最常见的 BUG、可能的环境和修补这个问题的补丁。

  

• 编译 Java 代码时出现的 ORA-4031

  在你编译 Java 代码的时候如果内存溢出，你会看到错误：

  A SQL exception occurred while compiling: :
  ORA-04031: unable to allocate bytes of shared memory
  ("shared pool","unknown object","joxlod: init h", "JOX: ioc_allocate_pal")

  解决办法是关闭数据库然后把参数 JAVA_POOL_SIZE 设定为一个较大的值。这里错误信息中提到的 "shared pool" 其实共享全局区(SGA)溢出的误导，并不表示你需要增加 SHARED_POOL_SIZE，相反，你必须加大 JAVA_POOL_SIZE 参数的值，然后重启动系统，再试一下。参考: 。

• 小的共享池尺寸

  很多情况下，共享池过小能够导致 ORA-04031 错误。下面信息有助于你调整共享池大小：

  • 库高速缓冲命中率

    命中率有助于你衡量共享池的使用，有多少语句需要被解析而不是重用。下面的 SQL 语句有助于你计算库高速缓冲的命中率：

    SELECT SUM(PINS) "EXECUTIONS",
    SUM(RELOADS) "CACHE MISSES WHILE EXECUTING"
    FROM V$LIBRARYCACHE;

    如果丢失超过 1%,那么尝试通过加大共享池的大小来减少库高速缓冲丢失。

  • 共享池大小计算

    要计算最适合你工作负载的共享池大小，请参考：

    : HOW TO CALCULATE YOUR SHARED POOL SIZE.

• 共享池碎片

  每一次，需要被执行的 SQL 或者 PL/SQL 语句的解析形式载入共享池中都需要一块特定的连续 的空间。数据库要扫描的第一个资源就是共享池中的空闲可用内存。一旦空闲内存耗尽，数据库 要查找一块已经分配但还没使用的内存准备重用。如果这样的确切尺寸的大块内存不可用，就继 续按照如下标准寻找：

  • 大块(chunk)大小比请求的大小大
  • 空间是连续的
  • 大块内存是可用的(而不是正在使用的)

  这样大块的内存被分开，剩余的添加到相应的空闲空间列表中。当数据库以这种方式操作一段时 间之后，共享池结构就会出现碎片。

  当共享池存在碎片的问题,分配一片空闲的空间就会花费更多的时间,数据库性能也会下降(整个操 作的过程中，"chunk allocation"被一个叫做"shared pool latch" 的闩所控制) 或者是出现 ORA-04031 错误 errors (在数据库不能找到一个连续的空闲内存块的时候)。

  参考 : 可以得到关于共享池碎片的详细讨论。

  如果 SHARED_POOL_SIZE 足够大，大多数的 ORA-04031 错误都是由共享池中的动态 SQL 碎片导致的。可能的原因如下：

  • 非共享的 SQL
  • 生成不必要的解析调用 (软解析)
  • 没有使用绑定变量

  要减少碎片的产生你需要确定是前面描叙的几种可能的因素。可以采取如下的一些方法，当然不 只局限于这几种: 应用调整、数据库调整或者实例参数调整。

  请参考 ，描述了所有的这些细节内容。这个注释还包括了共享池如何工作的细节。

  下面的视图有助于你标明共享池中非共享的 SQL/PLSQL：

  • V$SQLAREA 视图

    这个视图保存了在数据库中执行的 SQL 语句和 PL/SQL 块的信息。下面的 SQL 语句可以 显示给你带有 literal 的语句或者是带有绑定变量的语句：

    SELECT SUBSTR (sql_text, 1, 40) "SQL", COUNT (),
    SUM (executions) "TotExecs"
    FROM v$sqlarea
    WHERE executions < 5
    GROUP BY SUBSTR (sql_text, 1, 40)
    HAVING COUNT () > 30
    ORDER BY 2;

    注: Having 后的数值 "30" 可以根据需要调整以得到更为详细的信息。

  • X$KSMLRU 视图

    这个固定表 x$ksmlru 跟踪共享池中导致其它对象换出(age out)的应用。这个固定表可 以用来标记是什么导致了大的应用。

    如果很多对象在共享池中都被阶段性的刷新可能导致响应时间问题并且有可能在对象重载 入共享池中的时候导致库高速缓冲闩竞争问题。

    关于这个 x$ksmlru 表的一个不寻常的地方就是如果有人从表中选取内容这个表的内容就 会被擦除。这样这个固定表只存储曾经发生的最大的分配。这个值在选择后被重新设定这 样接下来的大的分配可以被标记，即使它们不如先前的分配过的大。因为这样的重置，在 查询提交后的结果不可以再次得到，从表中的输出的结果应该小心的保存。 监视这个固定表运行如下操作：

    SELECT * FROM X$KSMLRU WHERE ksmlrsiz > 0;

    这个表只可以用 SYS 用户登录进行查询。

  • X$KSMSP 视图 (类似堆 Heapdump 信息)

    使用这个视图能找出当前分配的空闲空间，有助于理解共享池碎片的程度。如我们在前面的描述，查找为游标分配的足够的大块内存的第一个地方是空闲列表( free list)。 下面的语句显示了空闲列表中的大块内存:

    SELECT '0 (<140)' bucket, ksmchcls, 10 * TRUNC (ksmchsiz / 10) "From",
    COUNT () "Count", MAX (ksmchsiz) "Biggest",
    TRUNC (AVG (ksmchsiz)) "AvgSize", TRUNC (SUM (ksmchsiz)) "Total"
    FROM x$ksmsp
    WHERE ksmchsiz < 140 AND ksmchcls = 'free'
    GROUP BY ksmchcls, 10 * TRUNC (ksmchsiz / 10)
    UNION ALL
    SELECT '1 (140-267)' bucket, ksmchcls, 20 * TRUNC (ksmchsiz / 20),
    COUNT (), MAX (ksmchsiz), TRUNC (AVG (ksmchsiz)) "AvgSize",
    TRUNC (SUM (ksmchsiz)) "Total"
    FROM x$ksmsp
    WHERE ksmchsiz BETWEEN 140 AND 267 AND ksmchcls = 'free'
    GROUP BY ksmchcls, 20 * TRUNC (ksmchsiz / 20)
    UNION ALL
    SELECT '2 (268-523)' bucket, ksmchcls, 50 * TRUNC (ksmchsiz / 50),
    COUNT (), MAX (ksmchsiz), TRUNC (AVG (ksmchsiz)) "AvgSize",
    TRUNC (SUM (ksmchsiz)) "Total"
    FROM x$ksmsp
    WHERE ksmchsiz BETWEEN 268 AND 523 AND ksmchcls = 'free'
    GROUP BY ksmchcls, 50 * TRUNC (ksmchsiz / 50)
    UNION ALL
    SELECT '3-5 (524-4107)' bucket, ksmchcls, 500 * TRUNC (ksmchsiz / 500),
    COUNT (), MAX (ksmchsiz), TRUNC (AVG (ksmchsiz)) "AvgSize",
    TRUNC (SUM (ksmchsiz)) "Total"
    FROM x$ksmsp
    WHERE ksmchsiz BETWEEN 524 AND 4107 AND ksmchcls = 'free'
    GROUP BY ksmchcls, 500 * TRUNC (ksmchsiz / 500)
    UNION ALL
    SELECT '6+ (4108+)' bucket, ksmchcls, 1000 * TRUNC (ksmchsiz / 1000),
    COUNT (*), MAX (ksmchsiz), TRUNC (AVG (ksmchsiz)) "AvgSize",
    TRUNC (SUM (ksmchsiz)) "Total"
    FROM x$ksmsp
    WHERE ksmchsiz >= 4108 AND ksmchcls = 'free'
    GROUP BY ksmchcls, 1000 * TRUNC (ksmchsiz / 1000);

4. ORA-04031 错误与 Large Pool

大池是个可选的内存区，为以下的操作提供大内存分配：

• MTS 会话内存和 Oracle XA 接口
• Oracle 备份与恢复操作和 I/O 服务器进程用的内存(缓冲)
• 并行执行消息缓冲

大池没有 LRU 列表。这和共享池中的保留空间不同，保留空间和共享池中其他分配的内存使用同样的 LRU 列表。大块内存从不会换出大池中，内存必须是显式的被每个会话分配并释放。一个请求如果没有足够的内存，就会产生类似这样的一个 ORA-4031 错误：

ORA-04031: unable to allocate XXXX bytes of shared memory
("large pool","unknown object","session heap","frame")

这个错误发生时候可以检查几件事情：

• 1- 使用如下语句检查 V$SGASTAT ，得知使用和空闲的内存：

  SELECT pool,name,bytes FROM v$sgastat where pool = 'large pool';

• 2- 你还可以采用 heapdump level 32 来 dump 大池的堆并检查空闲的大块内存的大小

  从大池分配的内存如果是 LARGE_POOL_MIN_ALLOC 子节的整块数有助于避免碎片。任何请求分配小于 LARGE_POOL_MIN_ALLOC 大块尺寸都将分配 LARGE_POOL_MIN_ALLOC 的大小。一般来说，你会看到使用大池的时候相对共享池来说要用到更多的内存。 通常要解决大池中的 ORA-4031 错误必须增加 LARGE_POOL_SIZE 的大小。

5. ORA-04031 和共享池刷新

有一些技巧会提高游标的共享能力，从而共享池碎片和 ORA-4031 都会减少。最佳途径是调整应用使用绑定变量。另外在应用不能调整的时候考虑使用 CURSOR_SHARING 参数和 FORCE 不同的值来做到 (要注意那会导致执行计划改变，所以建议先对应用进行测试)。当上述技巧都不可以用的时候，并且碎片问题在系统中比较严重，刷新共享持可能有助于减轻碎片问题。但是，必须加以如下考虑：

• 刷新将导致所有没被使用的游标从共享池删除。这样，在共享池刷新之后，大多数 SQL 和 PL/SQL 游标必须被硬解析。这将提高 CPU 的使用，也会加大 Latch 的活动。
• 当应用程序没有使用绑定变量并被许多用户进行类似的操作的时候(如在 OLTP 系统中) ，刷新之后很快还会出现碎片问题。所以共享池对设计糟糕的应用程序来说不是解决办法。
• 对一个大的共享池刷新可能会导致系统挂起，尤其是实例繁忙的时候，推荐在非高峰的时候刷新

6. ORA-04031 错误的高级分析

如果前述的这些技术内容都不能解决 ORA-04031 错误，可能需要额外的跟踪信息来得到问题发生的共享池的快照。

调整 init.ora 参数添加如下的事件得到该问题的跟踪信息：

event = "4031 trace name errorstack level 3"
event = "4031 trace name HEAPDUMP level 3"

如果问题可重现，该事件可设定在会话层，在执行问题语句之前使用如下的语句：

SQL> alter session set events '4031 trace name errorstack level 3';
SQL> alter session set events '4031 trace name HEAPDUMP level 3';

把这个跟踪文件发给 Oracle 支持人员进行排错。

重要标注: Oracle 9.2.0.5 和 Oracle 10g 版本中，每次在发生 ORA-4031 错误的时候会自动创建一个跟踪文件，可以在 user_dump_dest 目录中找到。如果你的系统是上述的版本，你不需要再进行前面描述中的步骤。

参考信息

Metalink - http://metalink.oracle.com
How to Calculate Your Shared Pool Size
Understanding and Tuning the Shared Pool
Tuning Library Cache Latch Contention
Resolving Shared Pool Fragmentation
Diagnosing and Resolving Error ORA-04031

转自：http://www.dbanotes.net