ORA-04031这个错误，几乎每一个专业的DBA都遇到过。这是一个相当严重的错误，Oracle进程在向SGA申请内存时，如果申请失败，则会报这个错误。大部分情况下是在向SGA中的shared pool申请内存时失败，而少有向large pool等池中申请内存失败。比如下面的报错：
Wed Apr 27 16:00:25 2011
Errors in file /oracle/app/oracle/admin/zxin/bdump/zxin1_ora_2052294.trc:
ORA-04031: unable to allocate 4128 bytes of shared memory
("shared pool","unknown object","sga heap(3,0)","kgllk hash table")
这里很清楚地表示出来，是在向shared pool申请内存时失败。
shared pool内存申请（分配）失败，通常有如下的几种可能：
- shared pool过小，比如在SGA Manual Management方式下，shared pool设置过小。比如一套数千连接的大系统，shared pool只设置了几百M。这种情况下，要解决问题很解单，增加shared pool的大小即可。
- 应用没有使用绑定变量，硬解析非常多，导致shared pool内存碎片严重，分配大块内存时不能获得连续的内存空间。硬解析多的一个变种是虽然使用了绑定变量，但是由于某种原因，Cursor不能共享，导致Child Cursor非常多。实际上，如果shared pool较大（比如数GB大小），这种问题还是很少出现的，并且出现也通常出现在申请大块内存时。这种情况如果使用alter system flush shared_pool可以暂时缓解问题。但是这条命令又通常不适用于shared pool较大而且比较繁忙的系统。使用绑定变量
- Cache的cursor很多，同时cursor_space_for_time这一参数设置为TRUE，可能会使shared pool碎片化严重，导致不能分配到大块的连续内存。
- Oracle的BUG导致内存泄露，比如在一些版本中查询v$segment_statistics这样的视图导致内存泄露，使shared pool内存耗光。同样的情形还有类似于“obj stat memory”,"gcs resources","ges resources"等。通常这类内存为perm类型（permanet），这类内存通常是在分配时就确定了固定的用途，不能用于其他用途，因此极容易产生碎片。
- Oracle从9i开始，根据shared pool的大小将shared pool分为多个子池（subpool)，每个子池有独立的free list，同时在分配时单独管理（有其独立 的shared pool latch）。Oracle的BUG或者说是内存分配策略缺陷导致某一类shared pool的内存分配只在一个子池(subpool)中，即多个子池的使用极不均衡，导致向那个使用得最多的子池申请内存时失败。报错信息中的"sga heap(3,0)"即指明是在第3个子池申请内存时失败。本文案例中的ORA-04031错误其产生的原因可以归结为Oracle对shared pool的分配/使用策略问题。
- 操作系统内存不足，这只会出现在shared pool的使用还没有达到最大值时才会出现，并且在操作系统都有swap的情况下，只有部分操作系统才可能有这种情况，比如在HP-UX下，reserved 内存过多导致swap满。
- 其他原因，多数是因为BUG。请参考下面提及的MOS参考文档。
本文中的案例，其数据库是运行在AIX 5.3系统中的10.2.0.4 RAC，RAC节点数为2。数据库是从9i升级到10g，而目前处于正式升级前的测试阶段。数据库报的ORA-04031错误信息如本文前面所示（其中的数据库名称已经做了处理）。
在继续讲解案例之前，不得不提到MOS上的几篇关于ORA-04031错误的文档：
- Master Note for Diagnosing ORA-4031 [ID 1088239.1]
- Diagnosing and Resolving Error ORA-04031 on the Shared Pool or Other Memory Pools [Video] [ID 146599.1]
- Interpreting the automatically generated ORA-4031 diagnostic trace. [ID 809560.1]
- Troubleshooting and Diagnosing ORA-4031 Error [Video] [ID 396940.1]
- ORA-4031 Common Analysis/Diagnostic Scripts [Video] [ID 430473.1]
其实分析ORA-04031错误，通常有以下几个要点：
- 判断错误发生所有的内存区域，是shared pool,large pool还是streams pool等。这个很容易从错误信息中判断出来，本文主要描述shared pool的ORA-04031错误，这也是最常见的。
- 检查Shared Pool的总大小以及free memory的大小。如果free memory看上去挺多，以subpool为单位检查是否存在是由于碎片导致没有足够的连续内存以供分配，特别是关注报错信息中提及的子池。
- 如果Shared Pool相较于系统规模来说足够大（通常数GB都已经是很大的了），检查Shared Pool中有没有占用非常多的内存类型或内存组件，如果有，是什么样的类型的内存，在各个子池之间是否分布均匀。如果有异常占用较多的内存类型，根据此类型在MOS上搜寻是否是会有相应的BUG引起，或者分析这种类型的内存消耗较多的原因。比如如果是sql area很大，检查是不是硬解析特别多，或者是不是child cursor特别多引起。
- 基于以上分析的数据，来判断shared pool内存分配失败的原因。
上面的步骤写得比较粗略，关于分析和解决ORA-04031问题，这里也有一篇不错的文章：Simplified Approach to Resolve ORA-4031
这里关键的是分析Shared Pool的内存数据。ORA-04031错误发生后如果有条件可以马上连接到数据库中查询相应的x$表和v$视图得到相应的数据，否则只能通过ORA-4031错误发生时产生的trace文件。_4031_dump_bitvec这个隐含参数用于控制发生ORA-04031错误时对SGA的dump行为，而trace文件的分析就不像使用SQL那样简单了。
下面再来详细地分析案例： Read the rest of this entry
从错误信息来看，很显然，是向shared pool的第3个subpool申请内存时出错。
以下的数据是shared pool的数据：