概述

前段时间使用的oracle 11g数据库，在用一段时间后（开始要较长时间才出现，后来较短时间就出现），频繁报ORA-04030错误，具体错误信息是 ORA-04030: 在尝试分配...字节(...)时进程内存不足。

根据异常信息，可以很容易的判断是由于内存使用过多，分配不足所致的，但是服务器本身内存并不小，由此可以说明oracle在分配内存时，应该是有限制的，当超出这个限制的时，就会出现这个错误。

网上说法很多，下面整理了下一般处理的一个思路和方法。

1、是否仍然有足够的可用内存？

主要使用操作系统特定的工具（top、topas、vmstat、swapon -s）来检查内存使用情况。如果有足够的内存可用，那么就需要检查操作系统是否存在强制限制。如果内存已被耗尽，那么就需要找出内存被用到了哪些地方。

2、是否设置了操作系统限制？

如果仍有足够的内存可用，那么有可能是进程需要使用的内存量是不被允许的。使用命令“ulimit -a”查看操作系统限制。尤其对于“data seg size”选项，应该设置为 unlimited。在 RAC 或 GRID 环境中，由于数据库监听是通过 CRS 进行启动，所以监听继承了 root 用户的 ulimit 限制。如果在 root 的 ulimit限制中 data(kbytes)的限制为 1310kb，那么表示每个通过监听连接的进程能分配的内存资源不能超过1310kb。

3、是否设置了 Oracle 限制？

查询参数 PGA_AGGREGATE_TARGET 的大小，该参数限制一个实例可以分配的 PGA 总量。以下查询用于查找分配给所有会话的 PGA 区的内存总量：

SELECT SUM(VALUE) / 1024 / 1024 PGA_SIZE_MB
FROM V$SESSTAT S, V$STATNAME N
WHERE N.STATISTIC# = S.STATISTIC#
AND NAME = 'session pga memory';

4、哪个进程需要的内存过多？

一些操作会需要大量的进程内存，例如，大型的 PL/SQL 表或大量的排序操作。

可以使用以下查询来查找所有 Oracle 进程的 PGA 和 UGA 大小：

SELECT SID, NAME, VALUE
FROM V$STATNAME N, V$SESSTAT S
WHERE N.STATISTIC# = S.STATISTIC#
AND NAME LIKE 'session%memory%'
ORDER BY 3 ASC;

通常，从操作系统的角度来确认进程内存使用情况，是一个好办法。毕竟，使用过多内存的不一定是 Oracle Server 进程。

5、如何收集有关进程实际正在执行的任务的信息？

可以做 heapdump，然后分析 dump 结果：

SQL> select PID from v$process p, v$session s where p.addr=s.paddr and sid=<SID>;
SQL> oradebug setorapid <PID>
SQL> oradebug unlimit
SQL> oradebug dump errorstack 3
SQL> oradebug dump heapdump 536870917
SQL> oradebug tracefile_name (shows the path and filename information)
SQL> oradebug close_trace

或者使用 event，如下所示：

设置系统级事件来产生 ORA-04030 错误时的 trace 文件，设置 event 如下：

alter system set events '4030 trace name errorstack level 3;name HEAPDUMP level 536870917';

得到报错的 dump 文件后，关闭生成 event：

alter system set events '4030 trace name errorstack off';
alter system set events '4030 trace name HEAPDUMP off';

实际上引起ORA-04030的原因，是不能分配更多的内存，解决办法有两种，其一是加大内存，其二是对oracle的内存控制参数进行调整，使其内存分配更适合于当前的应用程序。

后面会分享更多devops和DBA方面的内容，感兴趣的朋友可以关注下！！