问题的原因
在metalink上面搜索了一下,找到了问题的原因及方法,现在和大家分享,原因如下:
Recent linux kernels have a feature called Address Space Layout Randomization (ASLR).ASLR is a feature that is activated by default on some of the newer linux distributions.It is designed to load shared memory objects in random addresses.In Oracle, multiple processes map a shared memory object at the same address across the processes.With ASLR turned on Oracle cannot guarantee the availability of this shared memory address.This conflict in the address space means that a process trying to attach a shared memory object to a specific address may not be able to do so, resulting in a failure in shmat subroutine.However, on subsequent retry (using a new process) the shared memory attachment may work.The result is a "random" set of failures in the alert log.
linux有个新特性Address Space Layout Randomization,该特性在最新的linux版本中都是激活的,oracle多个进程在进程上映射一个共享的内存对象,但是在ASLR中ORACLE并不能保证这些共享内存是有效的,在内存紧张的时候就会oracle就会出现相应的报警;
四、问题的解决
检查randomize参数值
# /sbin/sysctl -a | grep randomize
kernel.randomize_va_space = 1
关闭randomize特性add/modify this parameter in /etc/sysctl.confkernel.randomize_va_space=0kernel.exec-shield=0
修改以上参数后,需要重新启动操作后生效。
总结:在alert中发现每次问题出现的时间都是在凌成的3点左右,出现问题的时候数据库的压力应该是很小的,所以应该是操作系统的压力导致的内存分配问题,而操作系统有可能的原因就是定时向测试机传输备份;
虽然问题通过修改参数后可以解决,但是修改该参数会不会导致系统其他bug的发生的,也要运行一段时间过后才能知道。
顺便发句牢骚:dba有时候工作看起来挺轻松的,但是一旦出现问题,就要从方方面面去考虑问题,保证系统的安全稳定运行。
阅读(1653) | 评论(0) | 转发(0) |