一、问题背景：
操作系统信息：Linux x86-64
数据库信息：ORACLE 11.2.0.3-64
问题出现前系统的变更：由于业务的需要，每天定时把本机的备份传输到本地的另外一台LINUX测试服务器，并在那台服务器上面实现自动恢复，实现测试库的数据保证和正式库的数据同步；
二、问题症状：
在检查alert报告的时候，发现了如下的报错：
虽然数据库并没有宕机，但是MMON停止了工作82800s，停止了AWR报告和ASH的收集的工作，调优一下就抓瞎了。
三、问题的原因
在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有时候工作看起来挺轻松的，但是一旦出现问题，就要从方方面面去考虑问题，保证系统的安全稳定运行。
参考文档、链接：
ORA-00445: Background Process "xxxx" Did Not Start After 120 Seconds (文档 ID 1345364.1)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++本文作者：JOHNORACLE
技术博客：ORACLE 猎人笔记 数据库技术群：367875324 （请备注ORACLE管理 ）
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
