处理rac数据库一个节点监听异常

 

处理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/