早上刚刚处理完因为存储故障导致不断重启的rac,把应用切换到异地的容灾集群,下午居然数据管理中心的8节点集群又挂了.不过不是不断重启,而是压根起不来.....
没办法帮忙把,早让他们找DBA的....现在也只能帮忙到底了.上去一检查,之前故障发生后,已经有人重启了所有机器,看了重启前的db和os日志,除了类似：
th_select_handler: Failed to retrieve procctx from ht. constr = [-1733291968] retval lht [-27] Signal CV.
没有什么特别的报错.要问问重启前的情况，人都不在。。。。
好累啊....8台的日志阿....
最后在一台的crs.log上发现不断重复这段错误：
2009-01-06 13:25:26.017: [ CSSCLNT][2541047328]clsssInitNative: connect failed, rc 9
2009-01-06 13:25:26.017: [ CRSRTI][2541047328]0CSS is not ready. Received status 3 from CSS. Waiting for good status ..
2009-01-06 13:25:27.423: [ COMMCRS][1084229984]clsc_connect: (0xb4c840) no listener at (ADDRESS=(PROTOCOL=ipc)(KEY=OCSSD_LL_dc-cs-01
_crs))
上metalink看看没啥特别相关的问题。
基本定位问题到：
1.ocr,voting disk的访问也就是共享存储
2.网络问题
看了下存储状态和权限，各台机器都没什么问题
尝试重启了下其他7台机器，发现重启后都正常了，唯独这台不一样。
检查网络设置，果然心跳网络的访问被改动了。。。改回来，重启，一切ok了，启动后发现有问题的那台只能注册自己的实例而无法注册别的节点的实例，估计又是防火墙策略的问题，果然调整好重启了监听就恢复正常了。等他们人来了一问，原来新加了别的机器，结果DHCP自动设置到这个网段造成网络冲突，至于那台改设置的机器么就不知道谁动咯。。。所以rac的心跳网络和共享存储一定要与别的环境隔离开，如同你可以在一台机器上起2个名字一样的实例但是生产环境没人会这样做一样，这也是规范。现在只能告诫他们别乱动了。。。。还有快点帮他们找个好的DW DBA。。。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/79686/viewspace-1015776/ ，如需转载，请注明出处，否则将追究法律责任。
