AIX+ORACLE10g RAC ORA-04030 问题解决过程

问题描述：

 

生产环境由单实例的AIX+ORACLE10G切换到2节点的AIX+ORACLE10g RAC库后，
应用程序日志中出现如下错误：
java.sql.SQLException: ORA-04030: out of process memory
when trying to allocate 4194344 bytes
(QERHJ hash-joi,QERHJ list array)
在切库期间程序未做过改动和升级。基本上可以判断是库的原因引起的。

表面上看诱发错误的原因是由于不能分配足够的内存引起的。

 

解决过程：痛苦而漫长

1.检查操作系统资源限制
ulimit -a
/home/oracle$ulimit -a
time(seconds)        unlimited
file(blocks)         unlimited
data(kbytes)         unlimited
stack(kbytes)        unlimited
memory(kbytes)       unlimited
coredump(blocks)     unlimited
nofiles(descriptors) unlimited

2.检查oracle参数设置
SQL> show parameter sga;

NAME              TYPE        VALUE
--------------- -----------   -------
lock_sga        boolean       FALSE
pre_page_sga    boolean       FALSE
sga_max_size    big integer   8000M
sga_target      big integer   8000M

 

SQL> show parameter pga;

NAME                    TYPE        VALUE
---------------------- ----------- ------
pga_aggregate_target    big integer 3G

3.topas分析当前系统资源使用情况

Topas Monitor for host:    cadb11               EVENTS/QUEUES    FILE/TTY
Thu Feb 02 23:08:52 2010   Interval:  2         Cswitch    7620  Readch   185.4K
                                                Syscall   34463  Writech  146.2K
Kernel    2.0   |#                           |  Reads       448  Rawin         0
User      3.4   |##                          |  Writes      419  Ttyout      356
Wait      0.1   |#                           |  Forks         4  Igets         0
Idle     94.5   |########################### |  Execs         4  Namei       150
                                                Runqueue    1.5  Dirblk        0
Network  KBPS   I-Pack  O-Pack   KB-In  KB-Out  Waitqueue   0.0
en2      13.6K  2395.0    11.0K 1384.6    12.2K
en5     235.6    413.0   404.0    69.5   166.1  PAGING           MEMORY
lo0       0.5      2.5     2.5     0.2     0.2  Faults      556  Real,MB   15552
                                                Steals        0  % Comp     79.9
Disk    Busy%     KBPS     TPS KB-Read KB-Writ  PgspIn        0  % Noncomp   3.3
hdisk1    0.0     0.0     0.0     0.0     0.0   PgspOut       0  % Client    3.3
dac0      0.0    30.8     6.0    16.0    14.8   PageIn        0
dac0utm   0.0     0.0     0.0     0.0     0.0   PageOut       0  PAGING SPACE
dac2      0.0   107.5    23.0    74.0    33.5   Sios          0  Size,MB   16384
dac2utm   0.0     0.0     0.0     0.0     0.0                    % Used      0.0
hdisk2    0.0    91.5    21.0    62.0    29.5   NFS (calls/sec)  % Free    100.0
hdisk0    0.0     0.0     0.0     0.0     0.0   ServerV2       0
hdisk3    0.0    10.8     3.5     0.0    10.8   ClientV2       0   Press:
cd0       0.0     0.0     0.0     0.0     0.0   ServerV3       0   "h" for help
                                                ClientV3       0   "q" to quit
Name            PID  CPU%  PgSp Owner
oracle       197060   1.4   5.4 oracle
oracle       430468   0.8   8.3 oracle
oracle        90208   0.6  18.5 oracle
oracle       144178   0.3  18.5 oracle
oracle       140094   0.3  18.5 oracle
oracle       127794   0.3  18.5 oracle
oracle       152420   0.1   7.5 oracle
oracle       381894   0.1   8.5 oracle
oracle       422538   0.1   4.8 oracle
crsd.bin      99126   0.0  45.8 root 
Signal 2 received

 

 

4.检查alert<sid>.log也未发现任何异常。

 

5.去metalink查关于ORA-04030的错误

 

6.检查AIX kernel参数 mbuf_heap_psize
cadb12:/#>vmo -a |grep mbuf_heap_psize
       mbuf_heap_psize = 65536
      
cadb11:/#>vmo -a |grep mbuf_heap_psize

       mbuf_heap_psize = 65536

 

7.临时解决方案

夜里两点多了，问题依旧是没解决。虽然甲方的老总同意让我回家了，明天在弄。但心里依旧很着急。

因为这个问题不解决。将影响到一个报数问题。如果不能及时报送后果会很严重。

无奈之中只能带着遗憾回去睡觉了。。。。。。

 

 

第二天上班后，仔细整理了一下思路。把原来单节点的数据库参数设置与现在RAC的参数设置比较了

一下。基本一样。于是想到把只用RAC中的一个节点，也就是把RAC当作单实例的库来用。调整应用

中数据源连接库的方式，改为连单个节点。

重启应用，问题居然解决。暂时没出现ORA-04030。高兴啊。终于可以缓解一下眼前的燃煤之急了。

 

8.经过两天的网上查资料，请教周围的高手问题依旧没有解决。仔细分析操作硬件资源，操作系统，

集群件，存储，网络，数据库之间的关系。又重新检查了一遍root的的资源限制，终于发现问题。

root的内存有限制，改为unlimited。

重启库后，经过若干天的测试，在没有出现此问题。至此，ORA-04030的问题告一段落。

 

特写此文，以示纪念。