记一次Oracle 12C 两节点rac无法运行的解决过程

服务器环境

*** 作系统：Linux 红旗7.4

数据库版本：Oracle12C

集群：两节点rac

客户例行重启服务器后，发现crs无法启动，发来两张图。

 

根据经验，导致crs无法正常启动的原因有多种情况，主要涉及到网卡配置，磁盘挂载失败，ssh失效等情况。之前这个客户也遇到过rac无法启动情况，最终排查是两台服务器心跳网卡配置错误导致。本次问题也是该问题，但由于解决问题时 *** 作失误，导致解决问题时路线有所偏移。

检查服务器IP配置时发现，两台服务器心跳网卡名称不对应，如图所示，RAC1的心跳adapter为enp4s0f1,RAC1的心跳adapter为enp4s0f0

发现该问题后，修改了网卡信息，启动crs，还是报错。进而发现rac2服务器每次修改后重启网卡服务，心跳信息会自动偏移。后来，发现网络信息中OnBoot=no，导致每次重启心跳信息会跳到enp4s0f0上。于是将OnBoot配置修改为yes。

至此，两台RAC的adapter都在0f1上，但是crs启动一直失败。远程查看后，发现了GPnP profile控制文件中心跳信息记录的adapter为0f2，将心跳IP改在了0f2上后，再次启动crs，就启动成功了。

 问题原因：通过沟通，发现在前一天晚，GPnP profile文件中心跳信息已经是0f2了，手动修改过该文件，修改为0f1,重新启动了crs，但是未能成功。（因为之前两台心跳网卡名称不一致导致crs启动失败）。未启动成功后又将该文件手动修改回0f2。

通过这一系列的 *** 作整理，我们可以判定距离上次rac正常运行时，心跳IP的adapter为0f2,该信息记录在GPnP profile文件中。重启服务器后，两台rac的心跳网卡由于未设置Onboot=yes导致心跳IP未能固定在0f2网卡上。

由于之前手动修改过GPnP profile文件，导致网卡修改为0f0后，再次启动crs，但是GPnP profile文件无法重新加载，心跳adapter的信息一直停留在0f2上。所以crs一直启动失败。

附摘录网上的知识点:

1、GPnP profile存储了整个集群的配置信息，它是一个XML文件，该文件中包括了集群名称、网络类型（public/private）、ASM和CSS的存储信息、数字签名，以及ASM实例的SPFILE文件位置等。在集群中，CSS、GPnP等服务的启动都依赖于GPnP profile文件，该文件引导节点加入集群。如果GPnP profile文件被破坏或丢失，那么集群将无法正常启动。在集群启动期间，CSS守护进程将使用GPnP profile文件中的DiscoveryString参数发现表决磁盘文件，所以，若DiscoveryString参数配置不正确，则CSS守护进程无法启动，进而导致整个CRS无法启动。

GPnP profile文件默认的保存位置是：

$GRID_HOME/gpnp/$HOSTNAME/profile/peer/profile.xml

$GRID_HOME/gpnp/profiles/peer/profile.xml  --全局备份

不能手动修改profile.xml文件，否则可能导致集群不能正常运行，可以使用命令gpnptool来修改该文件，使用命令“gpnptool get”可以获取profile.xml文件的内容。当集群配置发生变化时（例如，oifcfg改变网络信息、ASM添加存储等），所有节点的该文件会被自动更新（通过gpnpd.bin进程复制GPnP profile到所有的其它节点。注意：gpnpd是一个多线程的进程）。

2、在/etc/sysconfig/network-scripts/ifcfg-eth0(确认ONBOOT=yes),其中eth0是设备bai名；

ONBOOT是指明在系du统启动时zhi是否激活dao网卡，只有在激活状态的网卡才zhuan能去连接网络，进行网shu络通讯。

DEVICE：网卡名称(一定是写eth0)

ONBOOT=yes(相当于启动这个网卡的开关，你要用eth0这个一定要yes，表示开)

BOOTPROTO=none（这个是表示你使用什么样的路由协议，有三种不同写法，如果是none和static表示你用的是静态路由，那么你在接下来的项目里就必须填写IPADDR、NETMASK、GATEWAY这三个选项。如果是dhcp表示你使用动态路由协议，那IPADDR、NETMASK、GATEWAY这些选项就可以不必填写。如果填写了，就以你填写的值为准）

HWADDR：你网卡的物理地址（可以不用写，系统自动会生成）

IPADDR：ip地址  

NETMASK：子网掩码    

GATEWAY：网关