[重发]ORA-04030的一种原因
旧文新发，原文发表于2007年4月6日。
4030的错误往往也挺吓人的，一看就涉及内存问题啊。今天在一个内部使用的数据库上遇到了。往往4030的解决方法都是增加PGA，或者反之，减少SORT_AREA_SIZE/HASH_AREA_SIZE。根本原因其实就是当Oracle试图向OS申请会话内存（session memory）时，OS返回错误，一般是内存不足之类。所以上来就提高PGA_AGGREGATE_TARGET也是不合适的。今天就是这个情况。
在客户端跑一个稍微复杂点的查询时候，出现了ORA-04030，其它同事也反映这个情况出现几天了，即便程序可以运行也慢得像头牛。今天我是忍无可忍了，决心花点时间了解一下。连上服务器，alert.log里果然不少报错。show parameter pga一看，600M，作为这个数据库倒也挺合适。再查询V$PGASTAT，真正花费的内存空间都是150M左右，并不大啊。仔细查查V$SESSTAT，只有三四个占内存超过10M的会话，实时统计总共也就是120M。看来并不是PGA设置太小。忽然想到这台服务器是Win2000 32bit，配置8G内存，联想到了1.7G的限制。不过当初装机器的同事已经设置了AWE，应该可以用到3G啊。
又是一阵show parameter，终于发现了问题，猜想是对的。DB_BLOCK_BUFFERS设置了307000+，也就是2.4G的DB_CACHE，然后SHARED_POOL_SIZE=100M，这加起来都3.1G，突破限制了，居然还不知道为什么设置了JAVA_POOL_SIZE=100M。赶紧改……于是将DB_CACHE调整到了2G（调低DB_BLOCK_BUFFERS），由于没有Java程序或过程，所以JAVA_POOL_SIZE=0，顺手又将SGA_MAX_SIZE降到2.2G，这样数据库就不会盲目相信参数，突破OS进程限制申请空间了。通知同事重新启动数据库，果然再没出现错误了，查V$PGASTAT果然可以分配更多空间了，一般都稳定在200-300M了，程序运行快了不少。