ora-04030 错误

04031直接原因是shared_pool的碎片所致，临时应急的话可以发出以下命令：ITPUB个人空间0PX&P4@iS-l3G
alter system flush shared_pool;ITPUB个人空间 ~;b"f Yv S(x9?
解决办法：ITPUB个人空间o}:IC$ZE:Q?
1.有类似的bug补丁，找到它，打上它；ITPUB个人空间j3F2h2H}6v\
2.调整部分参数，如cursor_sharing为force（8i下）或similar（9i下），可以加大shared_pool_size参数值 ，但不要过大，同时考虑加大shared_pool_reserved_size参数值，还有可参考如下:ITPUB个人空间a ?$~W?.J
Cause: More shared memory is needed than was allocated in the shared pool.ITPUB个人空间vKQv}Md1Sd
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 initialization parameters SHARED_POOL_RESERVED_SIZE and SHARED_ POOL_SIZE. If the large pool is out of memory, increase the initialization parameter LARGE_POOL_SIZE.
mp+qE\N0最有可能的原因：你们使用的是mts方式，但是large pool才4M，导致4031
izS+v&z5G1]Ph0很有可能的原因：应用程序没有使用bind variable绑定变量（），导致share poo到了一定时间就用光了，于是开始刷新，又由于share pool实在太大，导致down机ITPUB个人空间.u'?d0O)MF&J B$d
比较有可能的原因，oracle内存泄漏，打patch试试看？
(b%LXh"Kw4tz}C0最后，8得8指出，2G的shared pool，是我有史以来见到的最疯狂的配置，200M已经算多得了。ITPUB个人空间!wE#Cy8BCH l!]}*l
1.楼主是否使用MTS？如果不使用，large pool 设置为几十M就可以了 2.shared_pool 你设置的太大了， shared_pool 设置大的话，会出现 latch 争用的现象，尤其的是在8i 中，建议在 1.5G 一下(我的经验)，9i没有这个问题，因为9i的 latch 是自动管理的，8i需要自己调整。 2.看看v$sql 中是不是有很多相似的sql，如果有的话，建议进行sql参数话，减少shared pool 的碎片。 3.你的 shared_pool_reserved_size 已经够大了，应该不用修改 4.你可以添加一个 job ，每隔几天，在业务不忙的时候，执行 alter system flush shared_pool,清理一下 shared pool 中的碎片。ITPUB个人空间y.GAr4O6m_
ref:biti_rainy= 4030 不是 4031 ! 4031 是 DB 内部的分配 4030 是 os 上内存的分配
v:Obi2D+z C0ORA-04030 out of process memory when trying to allocate string bytes (string,string)
6Ml(a-@0HK+hZ0Cause: Operating system process private memory has been exhausted.

~T's)h,U
\l,x"s0Action: See the database administrator or operating system administrator to increase process memory quota. There may be a bug in the application that causes excessive allocations of process memory space.
bY CeoLC6bI3L0ORA-04031 unable to allocate string bytes of shared memory ("string","string","string","string")ITPUB个人空间vW-nasm4b
Cause: More shared memory is needed than was allocated in the shared pool.ITPUB个人空间yH/E*h3z)kQp
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 initialization parameters SHARED_POOL_RESERVED_SIZE and SHARED_ POOL_SIZE. If the large pool is out of memory, increase the initialization parameter LARGE_POOL_SIZE.

Ref:http://www.dbanotes.net/Oracle/Ora-04031.htm

诊断并解决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_SIZEITPUB个人空间7H [*Wwg XL"`\
  这个参数指定了共享池的大小，单位是字节。可以接受数字值或者数字后面跟上后缀"K" 或 "M" 。"K"代表千字节, "M"代表兆字节。
• SHARED_POOL_RESERVED_SIZEITPUB个人空间nKaF:H
  指定了为共享池内存保留的用于大的连续请求的共享池空间。当共享池碎片强制使 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 x$ksppi nam, x$ksppsv 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 错误

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 和共享池刷新

4\pGm3u.C0有一些技巧会提高游标的共享能力，从而共享池碎片和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 目录中找到。如果你的系统是上述的版本，你不需要再进行前面描述中的步骤。