由于丢失OLR导致的节点无法启动

一、环境

os：

1. cat /etc/redhat-release

GI:

1. crsctl query crs softwareversion

RDBMS

1. SQL> select * from v$version;

二、问题描述

dba发现节点2的GI无法启动

三、分析过程

1、由于问题是节点2的GI无法启动，因此首先应该确定GI启动到了哪个阶段，使用以下命令确定GI启动到了哪个阶段

1. [grid@infirac2 ~]$ crsctl status res -t -init

截图是已经恢复了OLR的正常启动GI的截图，如果丢失OLR应该是如下报错：

CRS-4639 Could not contact Oracle High Availability Services

CRS-4000 Command Status failed,or completed with errors

注：ohasd不是一个实实在在的存在的进程，os上没有ohasd进程。所谓的启动ohasd实际上是通过ohasd.bin守护进程来启动对应的四个代理进程，然后由代理进程来启动相应的资源。

ohasd.bin启动的四个代理进程：oraagent_grid、orarootagent_root、cssdagent_root、cssdmonitor

这四个代理进程分别启动相应的资源：

ora.asm  ora.cluster_interconnect.haip  ora.crf  ora.crsd  ora.cssd  ora.cssdmonitor  ora.ctssd  ora.diskmon  ora.evmd  ora.gipcd  ora.gpnpd ora.mdnsd

也就是 crsctl status res -t  -init 命令显示的所有资源。

因此，判断ohasd服务是否启动成功的标识就是判断以上资源是否成功启动。

2、从以上程序可以看出ohasd层面没有成功启动，有可能是/etc/inittab中启动集群的init.ohasd脚本没有被调用，或者是ohasd.bin守护进程没有被启动成功，因此需要进一步验证

1. [grid@infirac2 ~]$ ps -ef | grep has

根据以上输出可以判断init.ohasd脚本被调用了，并且ohasd.bin守护进程也已经被成功启动。那么问题在于ohasd服务没有被成功启动，因此需要通过ohasd的日志文件来进行分析。

3、分析ohasd的日志文件

在11.2中，CRS相关的日志比较集中，都位于CRS_HOME/log/nodename下面

报如下错误：initializing OLR

fail in stat OCR file/disk /u01/11.2.0/grid/cdata/infirac2.olr no such file or directory

根据以上错误判断是OLR无法访问导致的，下面需要验证OLR是否存在

4、验证olr是否存在

4.1 定位olr

1. [grid@infirac2 ohasd]$ cat /etc/oracle/olr.loc

4.2 验证olr是否存在

截图是OLR已经恢复后的。

4.3 最终确定原因是OLR丢失了，导致GI无法启动。

四、解决方法

由于GI在安装时会默认产生OLR的备份，因此可以从默认备份位置恢复OLR

1、检查默认的备份OLR是否存在

2、默认备份OLR存在，接下来使用以下命令恢复OLR

2.1 root用户进入CRS_HOME目录

1. [root@infirac2 ~]# cd /u01/2.0/grid

2.2 进程bin目录下

1. [root@infirac2 grid]# cd bin

2.3 执行以下命令恢复OLR

1. [root@infirac2 bin]# ./ocrconfig -local -restore /u01/2.0/grid/cdata/infirac2/backup_20161213_230239.olr

3、最后重新启动GI，问题解决

1. [root@infirac2 bin]# crsctl start crs

注：该命令实际上是启动ohasd，所以重启ohasd也是使用该命令

本文由 虾米 首发于【路远网（http://www.luyuan.io）】未经允许不得以任何方式转载，违者必将追究法律责任