处理rac数据库一个节点监听异常
环境
linux 5.5
oracle 10.2.0.4 rac
asm
发现
2013年7月29日客户上午打电话给我,发现rac数据库的一个节点连不上了,因为从客户端无法加载数据了;要求马上去现场处理,听对方的描述,我初步分析应该是监听或网络出现了问题。
现象
打的到达现场后,检查了一圈关于系统、数据库的信息,内存、cpu、网络等资源都正常,告警日志和监听日志均没有报错,实例看起来也正常,进程都在,也能查询信息;
数据库集群crs_stat -t,该节点有两个应用inst和lsnr状态为offline,lsnrctl status|start|stop等命令都执行不成功,超时最后报错,srvctl start listener -n db01 CRS-0215无法启动资源,不正常;另一个节点crs_stat -t对方节点应用inst和lsnr状态为offline;tnsping不通监听异常的节点,其他正常;
还发现一个问题,两个节点时间相差了近9分钟,监听不正常的那个节点比另一个正常的节点慢9分钟;
分析
可能之一:
时间不同步导致集群通信异常,监听异常
可能之二:
检查集群日志,发现crsd.log日志有报错,另有一个日志有报错“timeout killed the spawned process”
上网google搜索,有几个文章都说是某个时间点资源不足导致进程分配失败,通常重启节点就能恢复正常。
处理
调整时间为同步,重启监听看看情况:
在监听不正常的节点上操作,将时间调整为和另一个节点一致
date 0729144013.00
时间调整成功,但还是无法对监听做任何操作,启动、停止、看状态都不响应
故排除该种可能性,应该是第二种情况
重启节点,看看情况:
和客户方沟通后,同意重启机器;
以oracle用户身份关掉crs及相关服务,/etc/init.dinit.crs stop,检查发现进程不复存在,操作成功;
uptime发现该机器已有300多天没有重启过,reboot重启,等待几分钟,检查一切正常,包括两个节点crs状态、监听情况等;
结果
检查一圈,发现一切正常,通知客户开启应用,加载数据,正常,问题处理完毕。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/21256317/viewspace-1062802/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/21256317/viewspace-1062802/