O RA-04031故障分析处理精品参考资料.docVIP

ORA-04031故障分析处理 当任何试图分配一个大的连续的共享池中的内存失败，Oracle首先会刷新掉共享池中所有目前不在使用的对象，然后使得内存块被合并在一起。如果内存块仍然不够满足需求，那么就会出现ORA- 04031错误。这些错误同样可能发生在ASM的实例中。默认的共享池的大小基本能够满足大部分的环境，但是如果遇到ORA-04031错误的时候可能就需要增大。 当遇到这个错误的时候，往往会出现如下的消息显示： 04031, 00000, unable to allocate %s bytes of shared memory (%s,%s, %s,%s) 先来了解一下跟共享池相关的实例参数： a) SHARED_POOL_SIZE --– 这个参数指定共享池的大小，以字节为单位。 b) SHARED_POOL_RESERVED_SIZE --– 指定为大的连续的共享池内存请求预留的共享池的大小。这个参数连同 SHARED_POOL_RESERVED_MIN_ALLOC参数，可以用于避免消除由于共享池碎片太多导致迫使Oracle搜寻空闲的共享池空间而产生ORA-04031错误。 c) _SHARED_POOL_RESERVED_MIN_ALLOC --– 这个参数用于控制预留内存的分配。大于这个参数的内存分配可以使用预留内存的列表。这个参数的默认值适合 绝大多数的系统，如果增加这个参数值，那么Oracle将允许分配越少的预留内存列表而更多的请求共享池列表。这个参数在Oracle8i和之后的版本都是隐含参数，但是可以通过执行如下SQL查到： 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; 对于Oracle10g， 具有一个新特性自动内存管理，允许dba保留用于分配给Oracle内存区域使用的共享内存。通常来说，当Oracle需要分配一个大对象到共享池中却无 法找到 一段连续可用的内存空间时候，Oracle10g将会从其他SGA结构中使用自由内存来自动增大共享池的大小。自从10g数据库中内存空间分配被 Oracle自动管理之后，出现ORA-04013错误的可能性大大降低了，当SGA_TARGET参数大于0的时候，就启用了自动内存管理特性，当前 SGA的设置可以查询视图v$sga_dynamic_components。 现在可以开始诊断ORA-04013错误了。 大部分的ORA- 4031错误都和共享池大小有关，因此我们诊断这个错误一般都由共享池开始。当然，large_pool和java_pool的内存分配机制比较的简单， 一般错误都是由于不够大引起的。由于设置共享池大小不合理或者是共享池碎片太多都会导致Oracle无法找到一个足够大的内存段来容纳数据对象从而产生 ORA-04013错误。已经有很多的例子说明对于ASM实例，默认的共享池大小是远远不够的，如果 对于一个ASM实例出现这个错误，首先应该查看共享池大小，如果太小了，增大到不出现错误为止。不适当的大小：首先决定出现ORA-04031错误的的原因是在library cache中缺乏连续的内存空间，可以通过查询视图v$SHARED_POOL_RESERVED，满足如下的条件： REQUEST_FAILURES 0 并且 LAST_FAILURE_SIZE SHARED_POOL_RESERVED_MIN_ALLOC REQUEST_FAILURES=0 并且 LAST_FAILURE_SIZE SHARED_POOL_RESERVED_MIN_ALLOC 如果出现上述情况，可以认为是由于设置了较小的SHARED_POOL_RESERVED_MIN_ALLOC使得数据库把更多的对象放到共享池保留空间中，增大共享池大小可以解决这种问题的出现。但是如果当使用了多个池的时候, LAST_FAILURE_SIZE会显示错误,会显示出所有池失败大小的总和,这个是个bug（3669074）,在Oracle的9.2.0.7,10.1.0.4和10.2.x版本中被修正。 共享池碎片：如果是由于共享池碎片引起的ORA-04031错误，那么需要判断是由于library cache的碎片导致的还是共享池保留空间中的碎片太多导致的，可以用下面的规则来判定： REQUEST_FAILURES 0 并且LAST_FAILURE_SIZE SHARED_POOL_RESE