最近有朋友和小 y 反馈：
他们的一台 IBM 的 X86 服务器（现在属于联想）出现硬件损坏，维护人员通过管理口收集诊断日志给厂商时，服务器上运行的好好的一套 ORACLE 11.2 的 RAC 数据库，
突然有一个节点重启了 .. 这是是什么情况 ?
听到这里，小 y 基本上猜到了原因，类似的问题，以前分析和处理过几次，分析过程也不复杂， 但是没想到，类似的故障现在居然还在发生 .
因此有必要把这个 风险提示出来 !
这里，小 y 为大家分享一个过去处理的案例 , 文章最后会给出 X86 服务器与 RAC 结合的具体的风险提示，希望大家早了解，早预防，避免踩坑，伤人伤己。
问题来了！！
周五，晚上十一点，电话响了，是一位服务商的电话，看来出大事了，一下来了精神;
|
“小y,一套linux上的11.2.0.3 2节点的RAC， 节点2数据库今天下午自己重启了一次，后来自己起来了。 几个小时前，又挂了，到现在还没起来！ 两个节点私网IP互相ping了一下,可以ping通！ 你赶紧远程连上来处理下吧” |
BTW：
是的，大家没看错，是服务商而不是最终客户的电话。
小y所在的公司不仅直接面向客户提供数据库专家服务，也为其他服务商、软件开发商提供三线支持，不过小y最近业绩压力大的晚上睡不着觉，还请各位兄弟多多帮忙推荐和介绍啊。
分析与恢复故障
时间紧急，远程连入后，发现节点 2 确实挂掉了，那就直接 startup 启动数据库看看
照理来说，startup命令下去后，这里很快就可以看到SGA分配并启动到mount的信息，
但命令下去已经一分钟了，还没任何输出，确实不妙。
最终，startup命令在敲入后长时间依然无响应，大概10分钟后后报ORA-03113错误后退出。
如下图所示：
看来，数据库启动过程中遇到了异常，需要继续分析alert日志。
截取altert日志关键信息，如下图所示：
可以看到：
由于节点 2 的 Lmon 进程通过 ipc 与节点 1 的 LMON 进程通讯超时，简单来说，两个节点的 RAC 无法通讯，因此无法加入集群。因此需要进一步检查两个节点的私网通讯是否正常。
之前他们提到两个节点的私网 IP 是可以 ping 通的，我估计他们是 ping 错 IP 了。
因为，从 11.2.0.2 （含）开始， ORACLE 私网通讯不再直接采用“我们在私网网卡上所配置的地址（例如 192.168 这样的地址）”，而是采用 GRID 启动后， ORACLE 在私网网卡上绑定的 169.254 这个网段的地址。确认了一下，他们果然 ping 的是 192.168 这个 IP ，这个 IP 能 PING 通是不够的 …
发出下列命令获得，两个节点私网通讯采用的 IP 地址如下所示:
也就是说， RAC 两个节点用于私网通讯的真实地址是：
节点 1 采用的私网通讯地址是 169.254.220.75 ，而不是 192.168.x.x
节点 2 采用的私网通讯地址是 169.254.106.133 ，而不是 192.168.x.x
也就是说， GRID 启动前后的 IP ，如下所示：
|
|
Node1 |
Node2 |
备注 |
|
Bond0 |
192.168.1.1 |
192.168.1.2 |
GRID 启动前、启动后都存在的 IP |
|
Bond0:1 |
169.254.220.75 |
169.254.106.133 |
GRID 启动后才存在的 IP RAC 和 ASM 通讯使用 |
从上图可以看到：
两个节点之间互相 ping 不通 169.254 这个实际的私网通讯地址！这就是为什么节点 2 的数据库实例加不到集群的原因！
到这里，我们不妨用一张表表格小结一下：
其中 bond0 是私网网卡， 192.168 是手工配置的， 169.254 这个 IP 是 GRID 起来后绑上去的:
|
|
Node1 |
Node2 |
|
|
Bond0 |
192.168.1.1 |
192.168.1.2 |
可以互相 ping 通 |
|
Bond0:1 |
169.254.220.75 |
169.254.106.133 |
互相 ping 不通 |
这是什么情况呢？
其实很简单，别着急，问题原因就在后面，什么时候往下翻，由你决定…
……
……
……
……
……
……
……
……
……
……
……
……
……
……
……
……
那是什么原因导致两个地址不通呢？
我们进一步检查两个节点的路由情况，发现了异常。如下所示
检查，发现节点 1 上的私网路由丢失，导致两个节点之间的私网无法正常通讯，继而无法正常加入集群。
而节点 2 上是存在 169.254 这个路由的！
在节点 1
#route add -net 169.254.0.0 netmask 255.255.0.0 dev bond1
