前段时间使用的oracle 11g数据库，在用一段时间后（开始要较长时间才出现，后来较短时间就出现），频繁报ORA-04030错误，具体错误信息是 ORA-04030: 在尝试分配...字节(...)时进程内存不足。
根据异常信息，可以很容易的判断是由于内存使用过多，分配不足所致的，但是服务器本身内存并不小，由此可以说明oracle在分配内存时，应该是有限制的，当超出这个限制的时，就会出现这个错误。
网上说法很多，下电脑面整理了下一般处理的一个思路和方法。
1、是否仍然有足够的可用内存？主要使用操作系统特定的工具（top、topas、vmstat、swapon -s）来检查内存使用情况。如果有足够的内存可用，那么就需要检查操作系统是否存在强制限制。如果内存已被耗尽，那么就需要找出内存被用到了哪些地方。
如果仍有足够的内存可用，那么有可能是进程需要使用的内存量是不被允许的。使用命令“ulimit -a”查看操作系统限制。尤其对于“data seg size”选项，应该设置为 unlimited。在 RAC 或 GRID 环境中，由于数据库监听是通过 CRS 进行启动，所以监听继承了 root 用户的 ulimit 限制。如果在 root 的 ulimit限制中 data(kbytes)的限制为 1310kb，那么表示每个通过监听连接的进程能分配的内存资源不能超过1310kb。
查询参数 PGA_AGGREGATE_TARGET 的大小，该参数限制一个实例可以分配的 PGA 总量。以下查询用于查找分配给所有会话的 PGA 区的内存总量：
SELECT SUM(VALUE) / 1024 / 1024 PGA_SIZE_MBFROM V$SESSTAT S, V$STATNAME NWHERE N.STATISTIC# = S.STATISTIC#AND NAME = 'session pga memory';
一些操作会需要大量的进程内存，例如，大型的 PL/SQL 表或大量的排序操作。
可以使用以下查询来查找所有 Oracle 进程的 PGA 和 UGA 大小：
SELECT SID, NAME, VALUEFROM V$STATNAME N, V$SESSTAT SWHERE N.STATISTIC# = S.STATISTIC#AND NAME LIKE 'session%memory%'ORDER BY 3 ASC;
通常，从操作系统的角度来确认进程内存使用情况，是一个好办法。毕竟，使用过多内存的不一定是 Oracle Server 进程。
可以做 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 unlimitSQL> oradebug dump errorstack 3SQL> oradebug dump heapdump 536870917SQL> 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方面的内容，感兴趣的朋友可以关注下！！
电脑
