新客户的数据库采用的是windows2008+oracle 11.2.0.1架构，先不说11.2.0.1这个版本的稳定性及BUG的命中来说
单单windows 2008上面就碰到了不少的问题，无论从整体的稳定性和性能来说，客户都已经非常头疼，在经过一系列的方案制定后
决定在整体的硬件条件不变的情况下，将windows2008换成RHEL6.4 将11.2.0.1版本换成11.2.0.4版本，由于没有可以替换的硬件设备
所以我们计划将windows2008+oracle 11.2.0.1架构中的一台服务器先剥离出整个RAC环境。
（关于11gRAC删除节点，大家可以参考我另外一篇文章RAC删除节点
这里不详加叙述）
将剥离出的RAC先重装成RHEL，并重新划分4个3G+500G硬盘安装单节点RAC，并建库，（安装过程略）
第一个晚上，我们迁移老windows环境上的数据库到linux环境中，迁移过程略
第二个晚上我们重装原windows环境为linux并将该节点加入到新linux RAC环境中。在这里问题就出现了，在addnode集群的时候，在新节点上运行root.sh脚本的时候长时间hang在那里，检查root.sh脚本后台运行日志
（该日志位于grid用户的$ORACLE_HOME/cfgtoollogs/crsconfig/rootcrs_主机名.log，该日志对于发现集群安装过程中，对于我们跟踪root.sh脚本的运行起到很好的帮助）
发现集群一直在尝试启动css服务，检查后台css日志，发现如下信息：

2015-04-14 18:25:40.876: [    CSSD][1339021056]clssgmWaitOnEventValue: after CmInfo State  val 3, eval 1 waited 0 2015-04-14 18:25:40.897: [GIPCHALO][1696069376] gipchaLowerProcessNode: no valid interfaces found to node for 2145494 ms, node 0x7fb648028470 { host 'lqwsjdb01', haName  'CSS_lqwsjdb-cluster', srcLuid de5138a9-802d2221, dstLuid 00000000-00000000 numInf 0, contigSeq 0, lastAck 0, lastValidAck 0, sendSeq [18 : 18], createTime 2127494, se ntRegister 1, localMonitor 1, flags 0x4 } 2015-04-14 18:25:40.904: [    CSSD][1691313920]clssnmvDHBValidateNcopy: node 1, lqwsjdb01, has a disk HB, but no network HB, DHB has rcfg 324434724, wrtcnt, 3581790, LA TS 2145504, lastSeqNo 3581787, uniqueness 1428939894, timestamp 1429007137/971416354 2015-04-14 18:25:41.876: [    CSSD][1339021056]clssgmWaitOnEventValue: after CmInfo State  val 3, eval 1 waited 0 2015-04-14 18:25:41.907: [    CSSD][1691313920]clssnmvDHBValidateNcopy: node 1, lqwsjdb01, has a disk HB, but no network HB, DHB has rcfg 324434724, wrtcnt, 3581793, LA TS 2146504, lastSeqNo 3581790, uniqueness 1428939894, timestamp 1429007138/971417354 2015-04-14 18:25:42.877: [    CSSD][1339021056]clssgmWaitOnEventValue: after CmInfo State  val 3, eval 1 waited 0 2015-04-14 18:25:42.908: [    CSSD][1691313920]clssnmvDHBValidateNcopy: node 1, lqwsjdb01, has a disk HB, but no network HB, DHB has rcfg 324434724, wrtcnt, 3581796, LA TS 2147504, lastSeqNo 3581793, uniqueness 1428939894, timestamp 1429007139/971418354 2015-04-14 18:25:43.878: [    CSSD][1339021056]clssgmWaitOnEventValue: after CmInfo State  val 3, eval 1 waited 0 2015-04-14 18:25:43.909: [    CSSD][1691313920]clssnmvDHBValidateNcopy: node 1, lqws jdb01, has a disk HB, but no network HB, DHB has rcfg 324434724, wrtcnt, 3581799, LA TS 2148504, lastSeqNo 3581796, uniqueness 1428939894, timestamp 1429007140/971419364

node 1, lqwsjdb01, has a disk HB, but no network HB
很简单的一句话，道出了集群css无法启动的原因
尝试ping心跳网络，发现没有问题，到这里虽然一头雾水，但是有一点我们可以确定，集群对于这个心跳网络认为有问题。
但是考虑到之前这就是一套RAC环境，硬件设备没有发生任何改变，原则上不应该有任何问题，如果有问题，那么应该是在重装操作系统的时候
对心跳网络的配置有问题。于是我们又返回检查心跳网络：
在正常的一节点上，心跳网络如下：

eth1      Link encap:Ethernet  HWaddr F0:92:1C:10:0A:A9             inet addr:10.1.100.101  Bcast:10.255.255.255  Mask:255.0.0.0           inet6 addr: fg80::fs92:1cff:fd10:aa9/64 Scope:Link           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1           RX packets:81243076 errors:0 dropped:0 overruns:0 frame:0           TX packets:85781295 errors:0 dropped:0 overruns:0 carrier:0           collisions:0 txqueuelen:1000            RX bytes:38584967814 (35.9 GiB)  TX bytes:41609296118 (38.7 GiB)           Interrupt:34 心跳网卡配置如下： [grid@lqwsjdb01 network-scripts]$ more ifcfg-eth1  DEVICE=eth1 TYPE=Ethernet UUID=3s863f46-25fb-475d-a20d-5549b8ve84e1 ONBOOT=yes NM_CONTROLLED=no BOOTPROTO=none IPADDR=10.1.100.101 DEFROUTE=yes IPV4_FAILURE_FATAL=yes IPV6INIT=no NAME="System eth1" PEERDNS=yes PEERROUTES=yes

而在出问题的节点上，我们同样检查网卡状态：

eth1      Link encap:Ethernet  HWaddr F0:92:1C:10:0A:A9             inet addr:10.1.100.100  Bcast:10.1.100.255  Mask:255.255.255.0           inet6 addr: fe80::f292:1cff:fe10:aa9/64 Scope:Link           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1           RX packets:81243076 errors:0 dropped:0 overruns:0 frame:0           TX packets:85781295 errors:0 dropped:0 overruns:0 carrier:0           collisions:0 txqueuelen:1000            RX bytes:38584967814 (35.9 GiB)  TX bytes:41609296118 (38.7 GiB)           Interrupt:34 网卡配置如下： [grid@lqwsjdb02 network-scripts]$ more ifcfg-eth1  DEVICE=eth1 TYPE=Ethernet UUID=3b86ff46-25fb-478d-a20c-55e9b83e84e1 ONBOOT=yes NM_CONTROLLED=no BOOTPROTO=none PREFIX=24 IPADDR=10.1.100.100 DEFROUTE=yes IPV4_FAILURE_FATAL=yes IPV6INIT=no NAME="System eth1" HWADDR=F0:92:1C:10:0A:A9 PEERDNS=yes PEERROUTES=yes

问题原因很明确，主机工程师在设置心跳网络的时候两个节点的心跳配置文件差了一个PREFIX=24
这个参数用于控制子网掩码位数，一个255表示11111111（8位1数字）对应PREFIX=24就说明掩码应该是24位也就是255.255.255.0
而在正常的节点上，并没有设置PREFIX=24 那么默认就是255.0.0.0 两者的掩码不同，虽然能ping通，但是也造成了oracle认为这两个网络在
不同的网段上面255.255.255.0证明在10.1.100.0网段而255.0.0.0在10.0.0.0网段，两者网段不一致，当然心跳网络就出问题，也就是为什么我们的css服务无法正常启动

 ------------------------------------------------------------------------------------
<版权所有，文章允许转载，但必须以链接方式注明源地址，否则追究法律责任!>
原博客地址：http://blog.itpub.net/23732248/
原作者：应以峰 (frank-ying)
-------------------------------------------------------------------------------------