RAC数据库只能启动一个节点的故障

这个月实在是太忙了，几乎每天都是7点多起床，然后去客户现场，然后加班，回来就觉得累的不行啦！

所以一直没有更新，算是给自己找个借口吧～～

其实需要总结的东西还是挺多的，直到放假的最后一天晚上，我总算有心想去总结下了～！

先要总结的就是月初解决过的一个故障（其实算是未遂），现场描述如下：

双节点RAC数据库，只能启动一个节点，无论哪个节点先启动，另外一个节点就无法正常启动了！系统平台是AIX5L，使用hacmp 5管理共享磁盘，无法启动的表现就是可以mount，alter database open就hang在那不动，没有任何报错信息，只有后台进程QMNC进程无法启动，重新启动的信息，还有MMNL absent for 1474 secs; Foregrounds taking over的信息给出，查了些关于这两个进程的说明，都是因为数据库无法正常启动，所以有的正常反应！不能作为解决问题的根源和依据。

出现该问题前，客户进行了一下数据转换的操作，中间等待长时间无反应，所以最后选择重启数据库，然后hang住很长时间，然后shutdown abort关闭数据库，然后再启动就出现上述问题！

到达现场，开始尝试启动无法启动的数据库，发现就是hang在alter database open的过程，如果不做任何操作，就一直hang在这个过程不动，观察系统负载，没有任何变动，如果这时候关闭第一个启动的节点，第二个启动的节点就能完成正常启动。这个过程数据库中在做什么呢？

判断来判断去，在metalink中也搜索半天，发现有个两个bug可能导致这个问题，但是打相应patch后依然如故！两个patch分别为p5106909和p5190596，感兴趣可以去参考下！

分析从故障开始的日志，发现在alert日志中有Waiting for clusterware split-brain resolution，中文就是脑裂，怀疑网络存在问题，但是使用ping命令ping心跳地址，正常！！！

系统中errpt有：

4507DE58   0507180209 I H ent2           ETHERNET NETWORK RECOVERY MODE
DED8E752   0507180209 T H ent2           ETHERNET DOWN
4507DE58   0507180209 I H ent5          ETHERNET NETWORK RECOVERY MODE
DED8E752   0507180209 T H ent5           ETHERNET DOWN
系统工程师说是网卡模式问题，应该没什么影响！（我就相信了据说是IBM的工程师，结果后来……唉！）

所以下面我就又开始折腾这个数据库啊，各种方法尝试，折腾一天，没有什么眉目，回去休息，明天继续吧！

结果第二天一来，客户就告诉我，应用的工程师，把两个数据库节点都给起来了，方法就是：启动第二个节点的时候，在第一个节点执行命令：alter system flush buffer_cache;就是清空第一个启动节点的buffer cache，然后第二个节点就能正常启动了！不知道他是怎么想到的，但是这就说明，其实第二个节点启动时候hang在了同步buffer cache的过程了，清除了第一个节点buffer cache就好了！具体猜想应该是数据字典！

虽然是都启动了，但是这种方式绝对不是解决办法，因为如果再有需要同步cache的操作，数据库还是会出现问题，结果运行了大约1个多小时，数据库果然出现问题：又出现脑裂，日志如下：

Thu May  7 09:19:11 2009
IPC Send timeout detected. Receiver ospid 160682
Thu May  7 09:19:11 2009
Errors in file /oracle/app/admin/orcl/bdump/orcl2_lms0_160682.trc:
Thu May  7 09:19:12 2009
Trace dumping is performing id=[cdmp_20090507091857]
Thu May  7 09:20:52 2009
Waiting for clusterware split-brain resolution
Thu May  7 09:25:55 2009
Errors in file /oracle/app/admin/orcl/bdump/orcl2_lmon_114856.trc:
ORA-00600: Message 600 not found; No message file for product=RDBMS, facility=ORA; arguments: [kjxgrdecidemem1]
Thu May  7 09:25:56 2009
Trace dumping is performing id=[cdmp_20090507092556]
Thu May  7 09:25:56 2009
Errors in file /oracle/app/admin/orcl/bdump/orcl2_lmon_114856.trc:
ORA-00600: Message 600 not found; No message file for product=RDBMS, facility=ORA; arguments: [kjxgrdecidemem1]
Thu May  7 09:25:56 2009
LMON: terminating instance due to error 481
Instance terminated by LMON, pid = 114856

明天还要去客户现场，又是9点到，还在南城，睡觉～

未完待续～～～～～～～～～～

还是继续写完吧～～～～～～～

后来经过检查，发现在netstat -s查看时发现有丢包现象，但是还是没有引起我的足够注意，再后来我实在是找不到原因，只好建议客户从网络和系统方面都排查！正好这时候客户请来另一家的工程师解决，我觉得人家在两个方面做得比我好：

1、先是去看了现场硬件配置环境（我就没去看过）

2、从可能的原因一一排查（我就一直专注于找到比较可信的原因）

可能是在一家公司呆久了，也可能是经常一个人解决问题，行成了自己的固定思维模式，总之，最后是我没有找到比较可行的解决方法，而另一家公司的工程师建议客户排除网络（心跳线等原因）、系统等方面，再想起他方法，结果心跳线一换就ok啦～～～～～～～

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/122290/viewspace-604489/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/122290/viewspace-604489/