如何理解Oracle CRS/GI的进程

47次阅读

共计 4838 个字符，预计需要花费 13 分钟才能阅读完成。

今天就跟大家聊聊有关如何理解 Oracle CRS/GI 的进程，可能很多人都不太了解，为了让大家更加了解，丸趣 TV 小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。

在
10g 和 11.1，Oracle 的集群称为 CRS(Oracle Cluster Ready Service)，
在 11.2，Oracle 的集群称为 GI(Grid Infrastructure)。
对于 CRS/GI，他们的一些核心进程的功能基本类似，但是在 11.2，新增了很多新的 Deamon 进程。

10.2 CRS：
$ ps -ef|grep crs/bin
root 4373 3605 0 Feb25 ? 00:02:49 /u01/app/crs/bin/crsd.bin reboot
oracle 4380 4379 0 Feb25 ? 00:00:03 /u01/app/crs/bin/evmd.bin
oracle 4925 4888 0 Feb25 ? 00:00:00 /u01/app/crs/bin/oclsomon.bin
root 4928 4483 0 Feb25 ? 00:00:00 /u01/app/crs/bin/oprocd.bin run -t 1000 -m 10000 –
hsi 5:10:50:75:90 -f
oracle 5065 4512 0 Feb25 ? 00:00:54 /u01/app/crs/bin/ocssd.bin
oracle 6825 4380 0 Feb25 ? 00:00:00 /u01/app/crs/bin/evmlogger.bin -o

11.2 GI：
$ ps -ef|grep grid/bin
root 6656 1 0 Feb25 ? 00:09:20 /u01/app/11.2.0/grid/bin/ohasd.bin reboot
grid 7960 1 0 Feb25 ? 00:16:54 /u01/app/11.2.0/grid/bin/oraagent.bin
grid 7972 1 0 Feb25 ? 00:00:05 /u01/app/11.2.0/grid/bin/mdnsd.bin
grid 7982 1 0 Feb25 ? 00:03:45 /u01/app/11.2.0/grid/bin/gpnpd.bin
grid 7993 1 0 Feb25 ? 00:14:19 /u01/app/11.2.0/grid/bin/gipcd.bin
root 7995 1 1 Feb25 ? 00:41:42 /u01/app/11.2.0/grid/bin/orarootagent.bin
root 8010 1 0 Feb25 ? 00:28:03 /u01/app/11.2.0/grid/bin/osysmond.bin
root 8026 1 0 Feb25 ? 00:01:31 /u01/app/11.2.0/grid/bin/cssdmonitor
root 8040 1 0 Feb25 ? 00:02:22 /u01/app/11.2.0/grid/bin/cssdagent
grid 8057 1 1 Feb25 ? 00:48:04 /u01/app/11.2.0/grid/bin/ocssd.bin
root 8136 1 0 Feb25 ? 00:02:49 /u01/app/11.2.0/grid/bin/octssd.bin reboot
grid 8158 1 0 Feb25 ? 00:02:24 /u01/app/11.2.0/grid/bin/evmd.bin
root 8278 1 0 Feb25 ? 00:04:18 /u01/app/11.2.0/grid/bin/crsd.bin reboot
grid 8357 8158 0 Feb25 ? 00:00:00 /u01/app/11.2.0/grid/bin/evmlogger.bin -o
/u01/app/11.2.0/grid/evm/log/evmlogger.info -l /u01/app/11.2.0/grid/evm/log/evmlogger.log
grid 8406 1 0 Feb25 ? 00:11:22 /u01/app/11.2.0/grid/bin/oraagent.bin
root 8414 1 1 Feb25 ? 00:36:22 /u01/app/11.2.0/grid/bin/orarootagent.bin

我们对这些常见的集群进程做一些解释：

各个版本共有的：
1.
ocssd.bin：这是一个很核心的进程，如果它异常终止会导致这个节点的集群或者主机重启。这个进程主要用于检查表决盘能否正常访问，节点私网间的通
信是否正常。数据库实例上的 LMON 进程也会注册到 CSSD 上，这样 CSSD 会通过 LMON 来了解数据库实例的健康情况。
如果节点发生了主机自动重启，需要查看 ocssd 的日志，位于：/log//cssd。

可以参考下面的文档来了解节点重启：
如何诊断节点重启问题
11gR2 如何诊断节点重启问题

2. crsd.bin：这个进程主要用于管理集群中的资源。用来启动、停止检查一些资源，比如数据库实例、ASM、监听、磁盘组、VIP 等。在 11.2，这些具体的操作由对应的 agent 执行。另外，OCR 的维护也是由 CRSD 完成的。
当发现某些资源异常终止后，首先需要查看 crsd 的日志：/log//crsd。

3. evmd.bin：事件监控 (event monitor) 进程，由它来发布集群事件，比如实例启动、停止等事件。

4. ons 进程：Oracle Notification Service
daemon，它用于接收 evmd 发来的集群事件，然后将这些事件发送给应用预订者或者本地的监听，这样就可以实现 FAN(Fast
Application Notification)，应用能够接收到这些事件并进行处理。

5. gsd：只有当 CRS 或者 GI 上需要管理 9i 的数据库时才需要。在 11.2, gsd 默认就是 offline 的。
可以参考 My Oracle Support 文档：GSD Is Used Only if 9i RAC Database is Present (Doc ID 429966.1)

10g 和 11.1 特有的：
1. oprocd.bin：Oracle Clusterware Process Monitor Daemon，用来监控主机 hang，如果发现主机 hang 后会发起主机重启。只有未使用第三方的集群软件时才运行，Linux 上从 10.2.0.4 开始使用。
oprocd 的日志会在：/etc/oracle/oprocd/*.log.* 或者 /var/opt/oracle/oprocd/*.log.*。

2. oclsomon.bin：用来监控 ocssd 进程是否 hang，如果发现 hang，会发起 reboot.

11.2 特有的：
1. cssdagent(11.2)：这个进程由 ohasd 启动，然后由它来启动、停止、检查 ocssd 进程，以 root 身份运行。
它的日志位于：/log//agent/ohasd/oracssdagent_root

2. cssdmonitor(11.2)：监控 cssdagent，并且检查节点 hang（类似于 oprocd），监控 ocssd 进程是否 hang（类似于 oclsomon）, 监控 vendor clusterware（类似于 vmon），以 root 身份运行。
它的日志位于：/log//agent/ohasd/oracssdmonitor_root

3. ohasd.bin: 在 GI 启动时，最先启动的就是 ohasd, 然后由它启动 agent(orarootagent,oraagent, cssdagnet 和 cssdmonitor)，各个 agent 再启动对应的进程。
如果 GI 启动过程有问题，可以查看一下 ohasd 的日志：/log//agent/ohasd

4. mdnsd.bin：这个进程通过多播（Multicast）发现集群中的节点和所有的网卡信息。一定要确定集群中的网卡支持多播，而且节点间的通信正常。
它的日志位于：/log//mdnsd

5. gpnpd.bin：发布构建集群所需要的 bootstrap 信息，并且在集群的所有节点之间同步 gpnp profile。
它的日志位于：/log//gpnpd

6. gipcd.bin：这个进程负责管理集群中所有的私网（cluster interconnect）网卡。私网信息是通过 gpnpd 获得的。
它的日志位于：/log//gipcd

7. gnsd(可选): Grid Naming Service. 相当于子 DNS，功能和 DNS 类似，会取代使用 /etc/hosts 进行主机的解析。
它的日志位于：/log//gnsd

8. octssd.bin: The Cluster Time Sync Service(CTSS)
用于各个节点间的时钟同步，集群中的一个节点的时钟会作为参照节点，其它节点和这个节点进行时钟同步。注意：当第三方时间同步软件（例如：NTP）
存在时，CTSS 会以‘观察者’的方式运行，并不修改节点时间，但是，如果 CTSS 没有发现第三方时间同步软件，它会开始修改节点时间以便和参考节点同
步。
它的日志位于：/log//ctssd.

9. osysmond.bin：这是 Oracle Cluster Health
Monitor(CHM)的主要进程，这个进程在所有节点都会运行，sysmond 会将每个节点的资源使用情况发送给 cluster logger
service，后者将会把所有节点的信息都接收并保存到 CHM 的资料库。
它的日志位于：/log//crfmond/crfmond.log

10. ologgerd：这是 Oracle Cluster Health
Monitor(CHM)的另一个主要进程，在一个集群中的，ologgerd
会有一个主机点(master)，还有一个备节点(standby)。当 ologgerd 在当前的节点遇到问题无法启动后，它会在备用节点启用。
它的日志位于：/log//crflogd/crflogd.log

关于 CHM，请参考：
11gR2 新特性：Oracle Cluster Health Monitor(CHM)简介

11. agent.bin：在 11.2，各个资源的启动、停止和检查都是由 agent 来执行的。ohasd 会把这些 agent 启动。

Agent 包括两种，一种是 ohasd 的：
oraagent_grid：启动 / 停止 / 检查 / 清除 ora.asm, ora.evmd, ora.gipcd, ora.gpnpd, ora.mdnsd 等资源。
orarootagent_root：启动 / 停止 / 检查 / 清除 ora.crsd, ora.ctssd, ora.diskmon, ora.drivers.acfs, ora.crf (11.2.0.2)等资源。
oracssdagent_root: 启动 / 停止 / 检查 ocssd 进程。
oracssdmonitor_root：监控 cssdagent 进程。

它们的日志位于：/log//agent/ohasd

另一种是 crsd 的：
oraagent_grid: 启动 / 停止 / 检查 / 清除 asm, ora.eons, ora.LISTENER.lsnr, SCAN listeners, ora.ons, diskgroup 等资源
oraagent_oracle: 启动 / 停止 / 检查 / 清除 service, database 等资源
orarootagent_root : 启动 / 停止 / 检查 / 清除 GNS, VIP, SCAN VIP and network 等资源.
scriptagent_grid: 应用服务定制的服务。

它们的日志位于：/log//agent/crsd

看完上述内容，你们对如何理解 Oracle CRS/GI 的进程有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注丸趣 TV 行业资讯频道，感谢大家的支持。

正文完