处理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博客 ” ，链接：https://blog.itpub.net/21256317/viewspace-1062802/ ，如需转载，请注明出处，否则将追究法律责任。
