墨墨导读：为了及时共享行业案例，通知共性问题，达成共享和提前预防，我们整理和编辑了《云和恩墨技术通讯》，通过对过去一段时间的知识回顾，故障归纳，以期提供有价值的信息供大家参考。同时，我们也希望能够将热点事件、新的产品特性及其他有价值的信息聚集起来，为您提供具有前瞻性的支持信息，保持对于当前最新的数据库新闻和事件的了解，其中包括重要数据库产品发布、警报、更新、新版本、补丁等。

数据技术嘉年华，十周年盛大开启，点我立即报名！大会以“自研·智能·新基建——云和数据促创新 生态融合新十年” 为主题，相邀数据英雄，总结过往十年历程与成绩，展望未来十年趋势与目标！近60场演讲，大咖云集，李飞飞、苏光牛、林晓斌、黄东旭...，快来pick你喜欢的嘉宾主题吧！

墨天轮文档：《云和恩墨技术通讯（10月刊）》：https://www.modb.pro/doc/6459（复制到浏览器中打开或者点击文末左下角“阅读原文”立即下载）

这里推荐一个常见的问题，希望对大家有借鉴作用。

故障：HAIP在两个私网网卡上发生互换，导致ASM实例启动失败-罗杨杰

ORACLE从11.2.0.2之后提供了HAIP来实现网络冗余和负载均衡。HAIP顾名思义就是一个（或多个）IP地址。Oracle会自动在集群的每一块私网网卡上绑定一个169.254.XX.XX 网段的IP地址，这个IP地址被称为HAIP，数据库实例（ASM 实例也同样适用）之间在进行通信时，会通过这个Oracle绑定的IP地址来完成。本文介绍的是由于HAIP在两个私网网卡上发生互换，导致ASM实例启动失败。

1. 问题概述

数据库的一节点在重启crs后发现ora.asmgroup资源无法正常启动。该数据库版本为19.8，此问题此前已经多次出现。一节点集群crsd和cssd等运行正常，但是ora.asmgroup资源出现offline现象。

2. 故障根源

ASM实例在9月21日17点32分58秒被LMON进程发起终止：

2020-09-21T17:32:58.644321+08:00No connectivity to other instances in the cluster during startup. Hence, LMON is terminating the instance. Please check the LMON trace file for details. Also, please check the network logs of this instance along with clusterwide network health for problems and then re-start this instance.LMON (ospid: 40805): terminating the instance due to ORA error 481Cause - 'Instance is being terminated by LMON'

查看查看ASM1_diag_40789.trc日志

Dumping the Process Summary1: PSEUDO process2: PMON ospid 40751 sid 463 ser 40704, waiting for 'pmon timer' (DEAD)…13: PMAN ospid 40797 sid 234 ser 18733, waiting for 'pman timer' (DEAD)14: DIA0 ospid 40801 sid 466 ser 32316, waiting for 'DIAG idle wait' (DEAD)15: LMON ospid 40805 sid 698 ser 47006,…

看得出来ASM实例都是空闲等待事件。综上，ASM实例被异常终止是由于关键进程LMON出现异常。

2.1 LMON出现异常原因

LMON进程为RAC的后台进程，监视整个集群，以管理全局资源。LMON管理任何失败实例的死亡和相关恢复。特别的是，LMON处理与全局资源相关的恢复部分。通过日志，看到LMON进程由于两个节点无法正常通讯而终止了ASM实例。

2.2 私网通信出现异常

检查一节点的集群日志

.....2020-09-21 17:25:01.016 [OCSSD(35350)]CRS-1601: CSSD Reconfiguration complete. Active nodes are issdb1 issdb2 ......2020-09-21 17:27:59.992 [ORAAGENT(36381)]CRS-5011: Check of resource "ora.asm" failed: details at "(:CLSN00006:)" in "/u01/app/oracle/diag/crs/issdb1/crs/trace/crsd_oraagent_grid.trc"2020-09-21 17:27:59.994 [ORAAGENT(36381)]CRS-5011: Check of resource "ora.asm" failed: details at "(:CLSN00006:)" in "/u01/app/oracle/diag/crs/issdb1/crs/trace/crsd_oraagent_grid.trc"

以上日志显示集群间通信正常，节点1能正常加入集群。但是启动ora.asm资源出现失败，这也与asm日志的报错相吻合，私网也能互通。

2.3 ASM日志为什么提示网络不通

注意到该数据库版本为19C，ORACLE从11.2.0.2之后提供了HAIP来实现网络冗余和负载均衡。HAIP被提供给ASM和RDBMS实例和ACFS进行通信。HAIP并不用于集群软件的网络通信。那ASM日志显示的网络问题是否是因为HAIP不通所导致的呢？

一节点IP

ens3f1:inet 169.254.17.120/20 brd 169.254.31.255 scope global ens3f1:1ens2f1:inet 169.254.15.85/20 brd 169.254.15.255 scope global ens2f1:1

二节点IP

ens3f1:inet 169.254.4.9/20 brd 169.254.15.255 scope global ens3f1:1ens2f1:inet 169.254.27.4/20 brd 169.254.31.255 scope global ens2f1:2

这里可以清晰看到两个haip的广播地址不在对应网卡上。169.254.31.255这个地址在节点1的ens3f1网卡上，而在节点2就变成了ens2f1网卡。这时候169.254.15.255这个地址也同样不一致了。尝试从节点1去ping 下节点2的haip，发现ping不通。

查看两个节点的路由情况

一节点

169.254.0.0     0.0.0.0         255.255.240.0   U         0 0          0 ens2f1169.254.16.0    0.0.0.0         255.255.240.0   U         0 0          0 ens3f1

二节点

169.254.0.0     0.0.0.0         255.255.240.0   U         0 0          0 ens3f1169.254.16.0    0.0.0.0         255.255.240.0   U         0 0          0 ens2f1

发现两个HAIP所在网卡的目标路径不一致，两个HAIP的地址在两个私网网卡上发生了互换，导致HAIP不通。这个时候两个节点的ASM实例无法进行通信，也就出现了前面提到的LMON进程发出终止实例的现象。

2.4 为什么HAIP出现互换现象

当集群启动时，会去读取OLR的信息来分配每个私网网卡上的HAIP地址，而且没办法手动执行命令实现HAIP的故障转移和故障返回。只有当私网网卡出现故障时，集群会自动进行HAIP的故障转移。检查一节点操作系统日志,发现在9月15日私网网卡出现多次重启现象。

grep "f1: NIC Link is" messages-20200920     Sep 15 10:08:10 issdb1 kernel: i40e 0000:37:00.1 ens2f1: NIC Link is DownSep 15 10:08:31 issdb1 kernel: i40e 0000:37:00.1 ens2f1: NIC Link is Up, 10 Gbps Full Duplex, Flow Control: NoneSep 15 10:08:33 issdb1 kernel: i40e 0000:13:00.1 ens3f1: NIC Link is DownSep 15 10:08:58 issdb1 kernel: i40e 0000:13:00.1 ens3f1: NIC Link is Up, 10 Gbps Full

既然网卡多次重启，那HAIP必然会出现故障转移。那有没有可能在发生多次转移之后，此时HAIP所在网卡与OLR记录的HAIP信息不一致，导致节点在重启后HAIP不通呢？

通过在MOS查询相关资料显示在11G版本中当私网网卡恢复正常后，对应的HAIP会重新转移到该网卡上。

按照mos上的说法根本不会出现这次的故障才对，但是现在的数据库版本是19.8，有没有可能HAIP的故障转移机制发生了改变。通过模拟测试印证了之前的猜测，HAIP所在网卡与OLR记录的HAIP信息不一致，导致节点在重启后HAIP不通

3. 解决方案

综合上述分析，此次故障是由于节点2的HAIP在两个私网网卡上发生了互换，导致节点1在重启后HAIP不通，ASM实例启动失败。

经过在MOS上查询发现这是个在19.3上面的BUG：

Bug 29379299 - On ODA The HAIP IP Addresses Are Swapped Between the Network Interfaces (Doc ID 29379299.8)

查看数据库版本

[grid@xxxxx2 trace]$ opatch lspatches31335188;TOMCAT RELEASE UPDATE 19.0.0.0.0 (31335188)31281355;Database Release Update : 19.8.0.0.200714 (31281355)31304218;ACFS RELEASE UPDATE 19.8.0.0.0 (31304218)31305087;OCW RELEASE UPDATE 19.8.0.0.0 (31305087)OPatch succeeded.

看来该bug在19.8版本仍然存在， 且one-off patch只在18.3和18.5上提供，其他版本部分在MOS上提供了merge patch, 需要根据不同版本下载。

解决方案

既然节点2的OLR是正确的，那么只需要重启节点2，让两个节点的HAIP相对应即可。

[root@xxxx2 olr]# /u01/app/grid/product/19.0.0/grid/bin/crsctl stop crs[root@xxxx2 olr]# /u01/app/grid/product/19.0.0/grid/bin/crsctl start crs

重启节点2的集群后两个节点恢复正常。

墨天轮文档：《云和恩墨技术通讯（10月刊）》：https://www.modb.pro/doc/6459（复制到浏览器中打开或者点击文末左下角“阅读原文”立即下载）

- 活动推荐 -

数据技术嘉年华，汇聚业内多种数据库最佳实践和顶级技术专家，只为总结 2020 ，与您尽享技术前沿，领先一步卓立变革潮头！

2020 数据技术嘉年华，现在加入，尽享超低票价优惠：

数据和云

ID：OraNews

如有收获，请划至底部，点击“在看”，谢谢！

点击下图查看更多 ↓

云和恩墨大讲堂 | 一个分享交流的地方

长按，识别二维码，加入万人交流社群

请备注：云和恩墨大讲堂

  点个“在看”

你的喜欢会被看到❤