之所以要分享这个主题，是因为当我第一次遇见 CRS 无法正常启动的故障时，那种无从下手的无力感，找不到头绪的慌乱感，我至今记忆犹新。我想很多初学者也和那时的我一样，面对 CRS 的问题可能会没有什么头绪，其实任何故障的分析都是类似的，如果你能知道它内部的运行原理与机制，相信故障分析对你也会犹如翻掌般轻而易举。
今天我们就通过相关的日志文件来分析一下 CRS 的启动过程，希望通过这种方法让大家了解 CRS 的启动过程，以便将来能够对初学者分析 CRS 的问题时有所帮助。”
首先我们得明确一个概念，CRS 是什么？
在这里解释一下，这里所说的 CRS 并不是指 CRSD 进程，而是为了 RAC 高可用数据库所提供一套集群软件 The Oracle Clusterware。
那么，下面我们正式开始今天的主题，首先我们来看一下下面的“RAC 组件启动关系图”。由于 oracle 各个版本之间存在差异，本次所使用的版本为 11g R2。之后会通过相关 trace 与 log 文件的内容让大家更加清晰的看到这些组件的启动过程以及他们都做了什么。
通过上面的 RAC 组件启动关系图，我们可以大致的了解到 CRS 的各个组件启动的关系。
整个启动流程看起来还是很复杂的，同时层次也很鲜明。当然，这里面最重要的主要是 OHASD 到 CSSDAGENT，OHASD 到 ORAROOTAGENT 再到 CRSD，最后 CRSD 启动所管理的应用程序（或者叫做应用程序资源）启动这几大步。
仅仅是看这幅图，对于初学者来说很难记得住，没有关系，图可以保留下来慢慢看，我们换个思路，从这些进程的相关日志文件内容，来了解上图所表达的含义。
当然，想查看 RAC 相关日志，首先得找到他们，下面列出了 RAC 的 CRS 相关日志文件的位置：
Clusterware daemon logs are all under <GRID_HOME>/log/<nodename>. Structure under <GRID_HOME>/log/<nodename>:
alert<NODENAME>.log - look here first for most clusterware issues
./admin:
./agent:
./agent/crsd:
./agent/crsd/oraagent_oracle:
./agent/crsd/ora_oc4j_type_oracle:
./agent/crsd/orarootagent_root:
./agent/ohasd:
./agent/ohasd/oraagent_oracle:
./agent/ohasd/oracssdagent_root:
./agent/ohasd/oracssdmonitor_root:
./agent/ohasd/orarootagent_root:
./client:
./crsd:
./cssd:
./ctssd:
./diskmon:
./evmd:
./gipcd:
./gnsd:
./gpnpd:
./mdnsd:
./ohasd:
./racg:
./racg/racgeut:
./racg/racgevtf:
./racg/racgmain:
./srvm:
在知道了日志文件的位置之后，我们将沿着启动日志来观察整个 CRS 启动的过程。
这里启动环境为2节点 rac，版本是11.2.0.4，操作系统是 RedHat 6，同时第二节点的 CRS软件是关闭的，这样使得分析启动过程会简单明了些。
在 CRS 启动时，第一个被记录的就是告警日志，那么我们就从告警日志开始看起，RAC 的告警日志是一个被放在 <GRID_HOME>/log/<nodename> 目录下的，名为 alert<NODENAME>.log 的文本文件：
从告警中的红字部分可以看出，第一步需要完成 OLR 服务与 OHAS 服务的启动。简单介绍下这两个服务的作用：
OLR 是保存在本地的集群注册表，主要作用就是为 ohasd 守护进程提供集群的配置信息和初始化资源的定义信息。当集群启动 ohasd 时会从 /etc/oracle/olr.loc 文件中读取 OLR 的位置。OLR 默认为 $GRID_HOME/cdata/<node_name>.olr
关于 OLR 的内容可以通过 ocrdump -localfilename 导出到文件中查看
OHASD 从 11g R2 版本开始就是集群启动的唯一始点。负责管理集群所有的守护进程对应的资源。
在看守护进程日志前先简单介绍下 CRS 中进程的日志记录大致格式：
<时间>:[组件][<线程编号或者id>]<线程名称>:<消息内容>
那么我们来看一下这段时间内 OHAS 服务的日志，这个日志被放在<GRID_HOME>/log/<nodename>/ohasd 目录下，名为 ohasd.log。
通过 OHASD 的日志中红色的信息可以看到，第一步是初始化 OLR 文件，然后检查 OLR 中的信息。最后红色部分表示 RD(Resource Discovery 资源发现服务)已经启动了，代表 ohasd 正式启动了。
接着查看 ohasd 日志信息：
开始启动 cssdagent、orarootagent、oraagent、cssdmonitor 守护进程，以及初始化一些资源（crf、diskmon、ctss、cluster_interconnect.haip、crsd、mdns、gpnp、gipc、evm、asm、css、cssdmonitor
等）的信息。
以上信息为发送需要启动的资源给对应的进程，接下来查看对应的进程日志（日志位置参考最开始），查看这4(cssdagent、orarootagent、oraagent、cssdmonitor)个进程分别负责什么资源：
我们将日志启动的进程从日志中提取出来查看：
我们再次回顾一下最开始的那张《RAC 组件启动关系图》：
现在想想，整个启动过程通过日志内容是不是已经完全对应上了？
这里我们再简单介绍下这4个守护进程 (cssdagent、orarootagent、oraagent、cssdmonitor) 的作用：
-
Cssdagent: 负责启动以及监控 ocssd.bin 守护进程。
-
Orarootagent: 这个代理进程以 root 用户启动，负责管理用户为 root 的资源。
-
Oraagent: 这个进程会以 oracle 或者 grid 用户启动(日志文件名末尾会以_<username>.log 结尾)，负责管理用户为 oracle 或 grid 的资源。
-
Cssdmonitor: 只负责监控 ocssd.bin 守护进程。
接下来的流程中就是由 CRSD 来启动所有的应用程序（或者说是应用程序对应的资源）了。但是这里我们先不着急去看启动对应的资源的信息，我们重新去看一下这个时候的 CRS 告警日志信息所记录的内容：
从告警日志中可以看出来，GPNP 启动后才会有 CSSD 启动的信息。CSSD 的启动至少必须是在 GPNP 启动完成后才能启动的。这里我们观察一下 OCSSD 的日志：
从日志中可以看出集群版本为11.2.0.4，同时会检查 GIPC 的状态，目前检查结果为 down。
这里会回答大家的一个疑问，就是怎么去看这些进程与线程的功能。准确的说是怎么去猜。
目前我并没有找到一本官方的去说明 CRS 中各个线程、组件具体功能的书籍。至少我目前没有找到，如果谁有的话请发给我一份，谢谢。
这里我会将我猜的方法告诉大家。
一般情况下，组件名称为4位的，基本只看前两位英文或者四位英文去猜测。比如 [AGFW]这个组件，具体是什么含义呢？我们看前两位英文为 AG，那么 CRS 中有什么单词是 AG 开头的呢？就是 AGENT。那么我们在观察一下这个组件出现时的日志，都是与 AGENT 代理进程有关，至少也是与 AGENT 的功能职责有关。前面说过，AGENT 负责管理对应用户的资源，从之前的日志中可以看到基本上是在启动资源。我们没有办法明确的知晓 FW 的具体含义（我个人猜测为 FILE WORKSET，不一定对），但是我们至少知道这个组件与 AGENT 有关。
那么借助这个思想，我们来分析一下线程的具体含义，比如 clssscmain 线程。同样，前两位是 cl，可以假设为 cluster 的前两位英文，那么 CLSS 就等同于 CSS，那么 clssscmain 这个线程就被分解为了 css，scmain 两部分，而 main 是我们所认识的完整的单词，现在拿掉。就分解为 sc，main 两个部分。而 sc 出现在 cssd 的启动阶段，是不是可以理解为 start check，然后组合起来就是 css start check main，css 启动检查主线程。在去对比一下这个线程后面所跟着的内容，你会发现好像就是这么回事。
借助这样子的思想，我们再分析接下来日志中出现的线程的含义：
我们试着猜测下线程 clssnmReadDiscoveryProfile 与 clssnmvDDiscThread 的作用。
-
clssnmReadDiscoveryProfile：css node manager Read Discovery Profile
-
clssnmvDDiscThread：css node manager vote disk Discovery Thread
在根据后面的内容去确定一下，大概就是这么回事。
这个时候我们去解读一下刚才的日志内容。就是 CSSD 的节点管理功能通过读取 RD profile 找到 voting file 的 string 参数，然后 CSSD 的节点管理功能 vote disk 发现线程去查找 vote disk。
现在我们已经具备了初步阅读 CRS 日志的能力，不至于看见什么都很慌张了。之所以说是初步阅读，是因为这个方法并不是万能的，重要的还是平时的积累。当然还有一些其他的方式可以知道某些线程、模块的大概功能的，这里就留给大家去发现了。我们接着阅读 CSSD 的日志：
确认只有一节点状态为 ALIVE，无需重新配置，CSSD 配置完成，再次观察告警日志信息
在 CSSD 启动后 CTSS、OCR、EVMD、CRSD 相继被启动。
这里对 CTSS、EVMD 以及 CRSD 进程简单介绍下功能：
-
CTSS：负责同步集群节点时间的组件。有观察者与活动两种模式
-
OCR：集群中所有资源的信息
-
EVMD：负责产生并记录集群时间，并在节点间传递发生的事件
-
CRSD：管理集群中的应用程序（或者说是应用程序对应的资源），以便实现集群资源的高可用性。同时也管理 OCR
这里所说的资源大家可以通过命令 crs_stat 查看：
这些就是由 CRS 所管理的资源。
当 CRSD 守护进程运行起来之后，CRS（The Oracle Clusterware）启动完成。而之后就开始由 CRSD 负责启动各种资源，包括数据库实例（前提是 AUTO_START 参数正确）。
关于 CRS 启动的顺序，官方文档的说明：
Level 1: OHASD Spawns:
cssdagent - Agent responsible for spawning CSSD.
orarootagent - Agent responsible for managing all root owned ohasd resources.
oraagent - Agent responsible for managing all oracle owned ohasd resources.
cssdmonitor - Monitors CSSD and node health (along wth the cssdagent).
Level 2: OHASD rootagent spawns:
CRSD - Primary daemon responsible for managing cluster resources.
CTSSD - Cluster Time Synchronization Services Daemon
Diskmon
ACFS (ASM Cluster File System) Drivers
Level 2: OHASD oraagent spawns:
MDNSD - Used for DNS lookup
GIPCD - Used for inter-process and inter-node communication
GPNPD - Grid Plug & Play Profile Daemon
EVMD - Event Monitor Daemon
ASM - Resource for monitoring ASM instances
Level 3: CRSD spawns:
orarootagent - Agent responsible for managing all root owned crsd resources.
oraagent - Agent responsible for managing all oracle owned crsd resources.
Level 4: CRSD rootagent spawns:
Network resource - To monitor the public network
SCAN VIP(s) - Single Client Access Name Virtual IPs
Node VIPs - One per node
ACFS Registery - For mounting ASM Cluster File System
GNS VIP (optional) - VIP for GNS
Level 4: CRSD oraagent spawns:
ASM Resouce - ASM Instance(s) resource
Diskgroup - Used for managing/monitoring ASM diskgroups.
DB Resource - Used for monitoring and managing the DB and instances
SCAN Listener - Listener for single client access name, listening on SCAN VIP
Listener - Node listener listening on the Node VIP
Services - Used for monitoring and managing services
ONS - Oracle Notification Service
eONS - Enhanced Oracle Notification Service
GSD - For 9i backward compatibility
GNS (optional) - Grid Naming Service - Performs name resolution
关于 RAC 的 CRS 启动过程我们就讲到这里，当你了解了整个启动过程后，如果 RAC 在启动时出错导致无法启动，我们就可以根据启动过程中这些进程的报错信息，去分析诊断导致故障的原因，进而快速解决相关的故障。
比如：
-
OHASD 无法启动，我们可以需要去查看 OLR 文件是否存在。
-
CRSD 一直无法启动，是不是 CSSD 都不能成功启动造成。
-
CSSD 无法启动是否 vote disk 出现问题。
这些疑问我们都可以根据了解 CRS 的启动过程去思考，当然了这个启动过程是最简单的一种，其他节点都关闭的情况。所以学会去阅读 CRS 的日志也是很重要的，这里也将我自己的思考分享给了大家，希望对大家有帮助。
最后，我们再来思考一个问题：CRSD 与 ASM 谁先启动呢？
根据官方文档的说法是：
如果 OCR 保存在 ASM 中,那么 ora.asm 资源 (ASM 实例) 必须已经启动而且 OCR 所在的磁盘组必须已经被挂载,否则我们在 crsd.log 会看到以下的类似信息：
注意：在11.2 的版本中 ASM 会比 crsd.bin 先启动，并且会把含有 OCR 的磁盘组自动挂载。
在测试中，将 ASM 设置为不自动启动，然后重启服务器，ASM 依然自动启动，对应的 OCR 磁盘组已经挂载。
今天的分享到此结束，为大家带来这个主题，也是为了让大家更清楚地理解 RAC，做到知其然，更能知其所以然。