编者按：

本文作者系肖遥（花名），现任甲骨文技术支持工程师，目前专注于Oracle RAC领域。个人主页:

https://blog.csdn.net/weixin_50510978，经其本人授权发布。

【免责声明】本公众号文章仅代表个人观点，与任何公司无关。

之前我们提到过OHAS组件是集群启动的根守护进程。GI的启动必须首先启动 OHAS 组件。

但是并不是OHASD在没有前提条件的情况下一个命令就能启动的。GI的启动有两种途径，一种是伴随着OS的启动而自动启动GI，另外一种途径则是用crsctl start crs命令手动启动GI。但是不管哪一种途径启动GI，前提都需要有init.ohasd进程。

1.init.ohasd

init.ohasd是一个GI初始化脚本。在Linux环境中，它的路径是/etc/init.d/init.ohasd。这是一个shell脚本，会随着OS的启动而被拉起。在Linux5的时代，这个脚本是被定义在/etc/inittab中。

[root@node1 ~]#cat /etc/inittab|grep init.ohasdh1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null

而在Linux7里，随着OS的功能变更，init.ohasd则被systemd 以服务的形式启动。

[root@node1 ~]# cat /etc/systemd/system/oracle-ohasd.service# Copyright (c) 2016, 2018, Oracle and/or its affiliates. All rights reserved.## Oracle OHASD startup
[Unit]Description=Oracle High Availability ServicesAfter=network-online.target remote-fs.target autofs.serviceWants=network-online.target remote-fs.target

[Service]ExecStart=/etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/nullExecStop=/etc/init.d/init.ohasd stop >/dev/null 2>&1 </dev/nullTimeoutStopSec=60minType=simpleRestart=always

# Do not kill any processes except init.ohasd after ExecStop, unless the# stop command times out.KillMode=processSendSIGKILL=yes

# Allow continuous restartsStartLimitBurst=0

[Install]WantedBy=multi-user.target graphical.target

如果我们查看init.ohasd的代码就会发现，其主体部分是一个 while (true)无限循环。也就意味着init.ohasd 进程是个常驻OS的进程。即便集群被手动关闭，init.ohasd run进程应该是一直存在于OS中的。

[root@node1 ~]# ps -ef|grep init.ohasd|grep -v greproot      4321     1  0 Mar17 ?        00:00:02 /bin/sh /etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null

如果集群无法启动时，同学们应该要先去检查一下init.ohasd进程是不是存在。

2.S96ohasd

另外伴随着OS启动，GI也会自动启动。这实际上是由脚本S96ohasd实现的。这个脚本需要OS的 runlevel 3 或者 5的时候才会随着OS的启动而调用这个脚本。所以在Linux7中，这个脚本存在于etc/rc.d/rc3.d和etc/rc.d/rc5.d中。

[root@node1 ~]# locate S96ohasd/etc/rc.d/rc3.d/S96ohasd/etc/rc.d/rc5.d/S96ohasd

这就意味着，如果OS的runlevel不是3或者5的话，GI是不会随着OS的启动而自动启动的，因为S96ohasd脚本本身就不会被OS调用。

你以为这样GI就会被启动了吗？并不是。下面我们看一下S96ohasd的脚本内容。

AUTOSTARTFILE=$SCRBASE/$MY_HOST/$HAS_USER/ohasdstr...省略  if [ -r $AUTOSTARTFILE ]  then    case `$CAT $AUTOSTARTFILE` in      enable*)        $LOGINFO "Oracle HA daemon is enabled for autostart."        my_crsctl start has -nowait        ;;      disable*)        $LOGINFO "Oracle HA daemon is disabled for autostart."        ;;      *)...省略        ;;    esac  else

在脚本里我们可以看到，S96ohasd 会去读取配置文件ohasdstr 的内容。如果配置文件中被设定成了 enable 的值，那么才会用 crsctl start has -nowait 命令去启动 GI。

这个配置文件隐藏的如此隐秘，肯定不会支持客户手动去更改它了。实际上我们可以通过以下命令去更改这个配置文件，以此去设定该节点的GI是否会随着OS的启动而自动启动。

[root@node1 ~]# crsctl disable crsCRS-4621: Oracle High Availability Services autostart is disabled.[root@node1 ~]# cat /etc/oracle/scls_scr/node1/root/ohasdstrdisable

[root@node1 ~]# crsctl enable crsCRS-4622: Oracle High Availability Services autostart is enabled.[root@node1 ~]# cat /etc/oracle/scls_scr/node1/root/ohasdstrenable

实际上，调查GI无法启动的问题，查看OS日志是非常必要的。因为init.ohasd也好，s96ohasd也好，他们的很多信息都是打印到了OS日志中。

3.crsctl start crs

我们从上面的脚本里可以看到，伴随着OS启动自动启动GI的调用命令是 crsctl start has -nowait。但实际上如果这不是一个Oracle Restart的环境的话，我们通常使用的启动命令则是crsctl start crs。执行的用户必须是root用户。为了能够确认到启动过程，我们通常会在后面加-wait。这部分内容在前面的博客里提到过。

实际上OHASD守护进程是在这个阶段才被启动的。

4.如何确认GI正常启动

好了，我们上面介绍完GI的自动启动和手动启动的基本知识。如何去查看GI是否正常启动完成呢。

我们通常可以使用下面的命令。

[root@node1 ~]# crsctl check clusterCRS-4537: Cluster Ready Services is onlineCRS-4529: Cluster Synchronization Services is onlineCRS-4533: Event Manager is online

通过这个命令，我们可以确认到CRSD，CSSD 和 EMD是否正常启动而处于online的状态。

但是这个命令只能确认GI的大框架是否正常启动，而无法确认被GI管理的资源是否正常启动完成。所以我们通常需要使用 crsctl stat res -t 和crsctl stat res -t -init命令来确认各个资源是否都处于online的状态。

crsctl stat res -t可以确认到CRSD管理的资源状态，crsctl stat res -t -init则可以确认到OHASD管理的资源的状态。

下面我们以crsctl stat res -t -init的输出例子来讲解一下如何查看结果。

[root@node1 ~]# crsctl stat res -t -init--------------------------------------------------------------------------------Name           Target  State        Server                   State details--------------------------------------------------------------------------------Cluster Resources--------------------------------------------------------------------------------ora.asm      1        ONLINE  ONLINE       node1                    STABLEora.cluster_interconnect.haip      1        ONLINE  ONLINE       node1                    STABLEora.crf      1        ONLINE  ONLINE       node1                    STABLEora.crsd      1        ONLINE  ONLINE       node1                    STABLEora.cssd      1        ONLINE  ONLINE       node1                    STABLEora.cssdmonitor      1        ONLINE  ONLINE       node1                    STABLEora.ctssd      1        ONLINE  ONLINE       node1                    OBSERVER,STABLEora.diskmon      1        OFFLINE OFFLINE                               STABLEora.drivers.acfs      1        ONLINE  ONLINE       node1                    STABLEora.evmd      1        ONLINE  ONLINE       node1                    STABLEora.gipcd      1        ONLINE  ONLINE       node1                    STABLEora.gpnpd      1        ONLINE  ONLINE       node1                    STABLEora.mdnsd      1        ONLINE  ONLINE       node1                    STABLEora.storage      1        ONLINE  ONLINE       node1                    STABLE--------------------------------------------------------------------------------

从上面的输出结果中我们看到了以下列名。

Name              资源名Target            资源的期待状态State             资源的实际的状态Server            资源所在的节点      State details     资源的实际状态的详细

这里面Target显示的信息其实是GI记录的资源该有的状态。这个信息是记录在OCR中的(OCR是记录集群所有重要信息的文件，位于共享磁盘上，被所有节点访问)。

如果Target是ONLINE，而State是OFFLINE的话，代表该资源启动失败。如果Target是OFFLINE，则代表该资源不会被自动启动。如果用户想启动该资源，则需要执行相关的资源启动命令。

今天我们简单的讲了一下crsctl start crs之前的GI的启动逻辑，这部分内容其实对于绝大多数同学来讲是不太去关注的。但是一旦在处理集群无法启动的问题时，这部分内容就显得尤为必要了。

其实GI启动的知识远比上面的内容要多的多，比如OHASD的启动需要读取OLR的信息，CSSD的启动需要读取OCR的信息等等。但是我想这些内容对于一般的同学而言先不用深入的了解，这部分内容属于更专业更深层次的知识，等我们有时间的时候可以写专题研究。浅谈 Oracle RAC 系列还是本着带大家初步了解 Oracle RAC 的初衷来跟大家分享。

后续文章更加精彩，欢迎关注本公众号或访问【阅读原文】。

——End——

专注于技术不限于技术！

用碎片化的时间，一点一滴地提高数据库技术和个人能力。

欢迎关注！

数据库基础系列（从基础了解数据库）：

数据库性能问题分析和诊断方法概论

一图了解Oracle数据库简史

数据库的“黑匣子”--故障诊断日志基础

通过寄存服务来“理解”Oracle数据库基本体系结构和动作流程

Oracle优化器架构变化和特定行为

浅谈RAC系列：