1、环境说明
一套RedHat7.5上安装的11.2.0.4 RAC，进行正常的系统维护，重启主机后发现GI集群一直无法启动。
2、问题分析
（1）、查看GI集群的OHASD进程的日志，发现操作系统重启后没有任何的日志输出。
（2）、查看OHASD进程，发现只有init.ohasd run进程，而ohasd.bin reboot进程没有起来。
[root@snyxdb1 system]# ps -ef |grep ohasd root 3075 1 0 Apr23 ? 00:00:00 /bin/sh /etc/init.d/init.ohasd run >/dev/null 2>&1 Type=simple root 133358 111218 0 16:47 pts/1 00:00:00 grep --color=auto ohasd [root@snyxdb1 system]# |
（3）、查看CRS是否配置为enable。
[root@snyxdb1 system]# crsctl config crs CRS-4622: Oracle High Availability Services autostart is enabled. [root@snyxdb1 system]#
[root@snyxdb1 root]# more ohasdstr enable [root@snyxdb1 root]# more crsstart enable [root@snyxdb1 root]# more ohasdrun restart [root@snyxdb1 root]# |
（4）、查看/etc/systemd/system目录下是否存在ohasd.service服务，发现已经存在ohasd.service服务，内容如下所示。
[Unit] Description=Oracle High Availability Services After=syslog.target
[Service] ExecStart=/etc/init.d/init.ohasd run >/dev/null 2>&1 Type=simple Restart=always
[Install] WantedBy=multi-user.target |
（5）、问题似乎无解了，我们知道在Linux 7环境中安装11.2.0.4 RAC时，存在一个著名的问题，需要在运行root.sh之前安装一个patch（18370031），否则root.sh脚本会失败。询问当初安装该RAC集群的同事，得知该环境中没有安装patch（18370031），而只是执行了一个workaround（在/etc/systemd/system目录下创建ohasd.service服务），该workaround可以解决root.sh脚本执行失败的问题。
（6）、至此，我非常怀疑是该workaround仍然存在某些缺陷，最终，在MOS库中搜索到解决方案，该workaround的确存在缺陷，它可以解决root.sh脚本执行失败的问题，但在有些情况下，有可能存在CRS无法随操作系统自动启动，ohasd.bin reboot进程无法启动的问题。
（7）、最终的解决办法是在/etc/systemd/system目录下另外创建一个名为autohas.service服务，内容如下所示：
[Unit] Description=Auto Oracle High Availability Services After=syslog.target
[Service] ExecStart=/etc/init.d/ohasd start >/dev/null 2>&1 Type=forking
[Install] WantedBy=multi-user.target |
[root@snyxdb1 system]# systemctl daemon-reload [root@snyxdb1 system]# systemctl enable autohas.service Created symlink from /etc/systemd/system/multi-user.target.wants/autohas.service to /etc/systemd/system/autohas.service. [root@snyxdb1 system]# systemctl start autohas.service [root@snyxdb1 system]# |
3、建议
在Linux 7环境中安装11.2.0.4 RAC时，建议还是安装patch（18370031）的方式来处理root.sh脚本执行失败的问题，而不要使用workaround。