标签:
杂谈 |
一、问题背景:
操作系统信息:Linux x86-64
数据库信息:ORACLE 11.2.0.3-64
问题出现前系统的变更:由于业务的需要,每天定时把本机的备份传输到本地的另外一台LINUX测试服务器,并在那台服务器上面实现自动恢复,实现测试库的数据保证和正式库的数据同步;
二、问题症状:
在检查alert报告的时候,发现了如下的报错:
http://s15/middle/001gpgelzy6J9e0Axe6ce&690
虽然数据库并没有宕机,但是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.conf
kernel.randomize_va_space=0
kernel.exec-shield=0
修改以上参数后,需要重新启动操作后生效。
总结:在alert中发现每次问题出现的时间都是在凌成的3点左右,出现问题的时候数据库的压力应该是很小的,所以应该是操作系统的压力导致的内存分配问题,而操作系统有可能的原因就是定时向测试机传输备份;
虽然问题通过修改参数后可以解决,但是修改该参数会不会导致系统其他bug的发生的,也要运行一段时间过后才能知道。
顺便发句牢骚:dba有时候工作看起来挺轻松的,但是一旦出现问题,就要从方方面面去考虑问题,保证系统的安全稳定运行。
参考文档、链接:
ORA-00445: Background Process "xxxx" Did Not Start After 120 Seconds (文档 ID 1345364.1)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
本文作者:JOHNORACLE
技术博客:ORACLE
猎人笔记
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

加载中…