问题的原因
在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有时候工作看起来挺轻松的，但是一旦出现问题，就要从方方面面去考虑问题，保证系统的安全稳定运行。
阅读(1625) | 评论(0) | 转发(0) |
