通过内存锁定，解决ORA-4031错误

   这两天一个市州的数据库频繁遇到了ORA-4031错误， 连执行shutdown immediate关闭数据库都不行，提示如下类似错误：ORA-04031: unable to allocate 4064 bytes of shared memory ("shared pool","unknown object","sga heap(1,0)","kglsim heap"),经过查看，发现系统的内存几乎已经被耗尽了，同时还使用了大量的交换分区，由于任何语句都无法执行，因此先停掉了监听，然后杀掉了所有的会话
$ ps -ef |grep LOCAL=NO|grep -v grep|awk '{print $2}'|xargs kill -9

杀掉之后，数据库的资源得到了释放，就可以正常执行查询了，为了保险起见对数据库进行了重启，重启之后暂时正常了，不想不到一周时间又出现了4031错误，于是让值班的同事又重启了数据库，看这个情况，基本上是每隔一段时间就会出现内存使用紧张的情况，然后导致数据库出现4031错误。感觉可能是由于内存的大量换页造成的， 于是考虑使用内存锁定能不能解决这个问题，首先备份spfile文件，然后对内存参数进行了调整

alter system set lock_sga=true scope=spfile;

alter system set pre_page_sga=true scope=spfile;

alter system set sga_max_size=4224M scope=spfile;

alter system set sga_target=4224M scope=spfile;

alter system set java_pool_size=48M scope=both;

按照系统字典当中相关的advice视图对没有使用过的java pool进行调整，启用lock_sga和pre_page_sga参数然后关闭数据库,关闭之后用root用户 修改/etc/security/limits.conf ,增加 oracle - memlock unlimited

然后修改 /etc/sysctl.conf 修改

 kernel.shmall = 7516192768
kernel.shmmax = 7516192768

sysctl -p 让设置生效

root执行 ulimit -a   查看
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 71680
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 2047
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

还要修改max locked memory参数

ulimit -l unlimited

由于设置之后只是当前环境生效，退出再连接之后查看依然是 64，还要把这一句加入到/etc/profile文件中
然后启动数据库，接着观察一段时间看内存的使用情况再来做微调了。

 

后记:
  经过进一周的观察，4031没有再次出现，alert log里面也没有什么特别的错误，基本上达到了本次调整的目的。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/12216142/viewspace-710795/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/12216142/viewspace-710795/