【不错】oracle内存管理之PGA之案例分析：ora

一：错误总述 1． ORA-04031 基本上，ORA-04031出现的问题有几个可能性 A. 没有绑定编量造成 shared_pool 碎片过多，同时 shared_pool_size 太小 . –这个应该是比较常见的，也是Oracle提的最多的。 –这个通常会建议使用绑定变量，或者简单的加大shared_poo

一：错误总述

1． ORA-04031
基本上，ORA-04031出现的问题有几个可能性
A. 没有绑定编量造成shared_pool碎片过多，同时shared_pool_size太小.

–这个应该是比较常见的，也是Oracle提的最多的。
–这个通常会建议使用绑定变量，或者简单的加大shared_pool.或者临时解决方法就是alter system flush shared_pool.

B. Large_pool,Java_pool太小造成的

–这个通过错误信息的提示很容易判断(Ora-04031 cannot allocate .. memeory in [large_pool])
–解决方法就是简单的加大 Large_pool or Java_pool

C. 过度的开CURSOR而不关闭。

–这个问题发生的越来越多，特别是在JAVA运行环境中，频频出现。加大Shared_pool或者flush shared_pool往往只能延迟问题出现的时间，而没法避免。
–判断方法：
select count(*) from v$open_cursor ;
select * from v$sysstat
where name = ‘opened cursors current’;
如果出来的值特大（以万为单位）时，基本就可以确定是这个原因了
–解决这个问题的方法就是检查程序，看是否没有正常的关闭cursor(对于JAVA来说，就是没有关闭Statement)。或者select sql_text from v$open_cursor,看看都是哪些cursor没关闭，再去检查车程序。
–也有的程序使用了保持一定量的cursor一直open,从而避免cursor过多次的开启，来提高性能。对于这种情况，则应该选择适当的shared_pool_size和控制keep_opening的cursor的量。
–也有可能Oracle参数session_cached_cursors太大，解决方法就是把它降低到适当的值

楼主的问题似乎有点象 session_cached_cursors 的问题，但是根据 opened cursors current判断，每个session开的cursor超过1000，已经超过session_cached_cursors，应该检查程序看看。

D. 当然，有时候一些BUG也可能引发ORA-04031,但是在高版本中已经很少出现(>=8174)

2。ORA-04030
ORA-04030出现的基本都是过多的使用memory造成的 。

ORA-04030的问题一般是PGA过度分配造成的（对应的操作是sort/hash_join）。在Oracle9i中pga_aggregate_target指定了所有session总共使用的最大PGA上限，如果该值被设定了则默认的workarea_size_policy=auto, sort_area_size/sort_area_retained_size将被忽略。那么直接减小pga_aggregate_target就能解决一部分ORA-04030问题。

A. 对于32 BIT系统，有SGA 1.7G限制
B. 某些OS系统本身也有一些内存参数限制
–运行 ulimit 看看
C. OS系统本身物理内存+Swap的限制

我们应该检查DB使用的
SGA + PGA 是否超过 上面的限制

SGA 包括 db_cache,shared_pool,large_pool,java_pool
session的PGA包括
sort_area_size/Hash_area_size/*_area_size 或者 pga_aggregate_target
还有执行的CODE以及一些data也会占用空间。

然后再根据情况降低里面的某些值了，比如 db_cache， sort_area_size 等

对于楼主来说，应该是sort_area_size（200M）/Hash_area_size(400M) 太大造成本文来源gao@daima#com搞(%代@#码网的，降成几十M或者几M 就可以了。

喜欢 (0)赏

[搞代码]

分享 (0)