一个网友咨询一个问题，他的11.2.0.2 RAC(for Aix),没有安装任何patch或PSU。其中一个节点重启之后无法正常启动，查看ocssd日志如下：

从上面的信息，很容易给人感觉是心跳的问题。这么理解也不错，只是这里的心跳不是指的我们说理解的传统的心跳网络。我让他在crs正常的一个节点查询如下信息，我们就知道原因了，如下：

大家可以看到，这里心跳IP为什么是169网段呢？很明显跟我们的/etc/hosts设置不匹配啊？why ？

这里我们要介绍下Oracle 11gR2 引入的HAIP特性，Oracle引入该特性的目的是为了通过自身的技术来实现心跳网络的冗余，而不再依赖于第三方技术，比如Linux的bond等等。

在Oracle 11.2.0.2版本之前，如果使用了OS级别的心跳网卡绑定，那么Oracle仍然以OS绑定的为准。从11.2.0.2开始，如果没有在OS层面进行心跳冗余的配置，那么Oracle自己的HAIP就启用了。所以你虽然设置的192.168.1.100，然而实际上Oracle使用是169.254这个网段。关于这一点，大家可以去看下alert log，从该日志都能看出来，这里不多说。

我们可以看到，正常节点能看到如下的169网段的ip，问题节点确实看不到这个169的网段IP：

Oracle MOS提供了一种解决方案，如下：

crsctl start res ora.cluster_interconnect.haip -init

经过测试，使用root进行操作，也是不行的。针对HAIP的无法启动，Oracle MOS文档说通常是如下几种情况：

1） 心跳网卡异常

2)   多播工作机制异常

3）防火墙等原因

4）Oracle bug

对于心跳网卡异常，如果只有一块心跳网卡，那么ping其他的ip就可以进行验证了，这一点很容易排除。

对于多播的问题，可以通过Oracle提供的mcasttest.pl脚本进行检测(请参考Grid Infrastructure Startup During Patching, Install or Upgrade May Fail Due to Multicasting Requirement (ID 1212703.1)，我这里的检查结果如下：

虽然这里通过脚本检查，发现对于230和224网段都是不通的，然而这不见得一定说明是多播的问题导致的。虽然我们查看ocssd.log，通过搜索mcast关键可以看到相关的信息。

实际上，我在自己的11.2.0.3 Linux RAC环境中测试，即使mcasttest.pl测试不通，也可以正常启动CRS的。

由于网友这里是AIX，应该我就排除防火墙的问题了。因此最后怀疑Bug 9974223的可能性比较大。实际上，如果你去查询HAIP的相关信息，你会发现该特性其实存在不少的Oracle bug。

其中 for knowns HAIP issues in 11gR2/12c Grid Infrastructure (1640865.1)就记录12个HAIP相关的bug。

由于这里他的第1个节点无法操作，为了安全，是不能有太多的操作的。

对于HAIP，如果没有使用多心跳网卡的情况下，我觉得完全是可以禁止掉的。但是昨天查MOS文档，具体说不能disabled。最后测试发现其实是可以禁止掉的。如下是我的测试过程：

不过需要注意的是：当修改之后，两个节点都必须要重启CRS，否则仅仅重启一个节点的CRS是不行的，ASM实例是无法启动的。

对于HAIP异常，为什么会导致节点的CRS无法正常启动呢？关于这一点，我们来看下该资源的属性就知道了，如下：

可以看到，如果该资源有异常，现在gpnpd,cssd都是有问题的。

备注：实际上还可以通过在asm 层面指定cluster_interconnects来避免haip的问题。