第二部分 平台
第4章 Grid 的五脏六腑
在这一章中，我们会把 Grid 放在放大镜下仔细地剖析，这一章的内容并不有趣，很枯燥乏味，对我来说也是这样，因此，请读者朋友做好准备。我建议读者朋友对文字内容做泛读，不要强迫自己去记住多少，把重点放在本章中的几幅图上，以后有需要时再回过头来详读相应的章节。
在这一章中，我们继续对比图4-1和图4-2的不同，以此来展开说明。
图4-1 Oracle Clusterware 10g的架构图
图4-2 Oracle Grid 11g R2的架构图
先说明一下，从Oracle Clusterware 到Oracle Grid，这其中的变化不是颠覆性的，而是改善性的。它俩比起来，Clusterware就是一个未经修饰的原生态，只有最核心的功能、朴素的外表，没有任何花哨的包装。而Grid就是个经过包装的、看起来更加精美的玩意。核心功能、算法还是原来那一套，只是被外面这层华丽的包装给掩盖住了，会让人误以为又是个全新的东西了。
所有Oracle Clusterware中的内容在Grid中仍然存在，Grid的基础仍然是原来Clusterware提供的三大服务，引入的变化包括：
层次化；
Agent的管理方式；
更丰富的资源；
启动顺序的变化。
下面我们分别介绍这些变化。
4.1 层次变化
Oracle Grid 11.2对原来的Clusterware重新架构，原来的CRS被拆成了两部分，分成了两个栈。在官方文档中，这两个栈分别叫做CRSD栈（Cluster Ready Service Daemon）和OHASD栈（Oracle High Availability Service Daemon），前者负责上层高级别的资源（Higher Level Resource），比如数据库实例，而后者负责下层低级别（Low Level）进程，因此也有Upper Stack和Lower Stack的叫法，我这里遵循的是Oracle文档的术语。
配合着CRS的拆分，CRS的配置信息OCR也被拆分成了两部分，分别是OLR和OCR。其中OHASD管理的是OLR，而CRSD管理的是OCR。
OHASD进程是整个Oracle进程堆栈的基础，它根据/etc/oracle/scls_scr/<hostname>目录下的控制文件的内容决定其他堆栈成员的状态，这些文件内容不可以手工修改。另外，ohasd 还会使用一个有名管道，位于/var/tmp/.oracle目录下，而其他进程使用的管道也是放在这个目录下。因此在集群运行过程中不可以清理这个目录。
OHASD管理的daemon可以和其他节点上的对应进程相互通信。只要OHASD启动，这个节点就可以加入到集群中，而且可以使用那些共享元素（比如 OCR）。OHASD 栈的启动顺序记录在GPnP profile中，也依赖于OLR中的信息。
CRSD现在更专注于上层（应用层）资源的维护。区分这两种级别的资源也很简单，通过关闭CRS的输出内容中就可以看出来，先于CRSD关闭的那些资源就是上层资源，而CRSD之后再关闭的资源就全部是OHASD的资源了。来看下面的输出内容：
[root@indexserver2 ～]# /u01/app/11.2.0.2/grid/bin/crsctl stop crs
CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on'indexserver2'
CRS-2673: Attempting to stop 'ora.crsd' on 'indexserver2'
CRS-2790: Starting shutdown of Cluster Ready Services-managed resources on 'indexserver2'
CRS-2673: Attempting to stop 'ora.DATA.dg' on 'indexserver2'
CRS-2673: Attempting to stop 'ora.registry.acfs' on 'indexserver2'
CRS-2673: Attempting to stop 'ora.oc4j' on 'indexserver2'
CRS-2673: Attempting to stop 'ora.cvu' on 'indexserver2'
CRS-2673: Attempting to stop 'ora.LISTENER.lsnr' on 'indexserver2'
CRS-2673: Attempting to stop 'ora.LISTENER_SCAN3.lsnr' on 'indexserver2'
CRS-2677: Stop of 'ora.cvu' on 'indexserver2' succeeded
CRS-2672: Attempting to start 'ora.cvu' on 'indexserver1'
CRS-2677: Stop of 'ora.LISTENER.lsnr' on 'indexserver2' succeeded
CRS-2673: Attempting to stop 'ora.indexserver2.vip' on 'indexserver2'
CRS-2677: Stop of 'ora.LISTENER_SCAN3.lsnr' on 'indexserver2' succeeded
CRS-2673: Attempting to stop 'ora.scan3.vip' on 'indexserver2'
CRS-2677: Stop of 'ora.scan3.vip' on 'indexserver2' succeeded
CRS-2672: Attempting to start 'ora.scan3.vip' on 'indexserver1'
CRS-2677: Stop of 'ora.indexserver2.vip' on 'indexserver2' succeeded
CRS-2672: Attempting to start 'ora.indexserver2.vip' on 'indexserver4'
CRS-2676: Start of 'ora.cvu' on 'indexserver1' succeeded
CRS-2677: Stop of 'ora.registry.acfs' on 'indexserver2' succeeded
CRS-2676: Start of 'ora.indexserver2.vip' on 'indexserver4' succeeded
CRS-2676: Start of 'ora.scan3.vip' on 'indexserver1' succeeded
CRS-2672: Attempting to start 'ora.LISTENER_SCAN3.lsnr' on 'indexserver1'
CRS-2676: Start of 'ora.LISTENER_SCAN3.lsnr' on 'indexserver1' succeeded
CRS-2677: Stop of 'ora.oc4j' on 'indexserver2' succeeded
CRS-2672: Attempting to start 'ora.oc4j' on 'indexserver3'
CRS-2676: Start of 'ora.oc4j' on 'indexserver3' succeeded
CRS-2677: Stop of 'ora.DATA.dg' on 'indexserver2' succeeded
CRS-2673: Attempting to stop 'ora.asm' on 'indexserver2'
CRS-2677: Stop of 'ora.asm' on 'indexserver2' succeeded
CRS-2673: Attempting to stop 'ora.ons' on 'indexserver2'
CRS-2677: Stop of 'ora.ons' on 'indexserver2' succeeded
CRS-2673: Attempting to stop 'ora.net1.network' on 'indexserver2'
CRS-2677: Stop of 'ora.net1.network' on 'indexserver2' succeeded
上面这些就是CRSD层维护的资源。
CRS-2792: Shutdown of Cluster Ready Services-managed resources on 'indexserver2' has completed
下面这些就是OHASD层维护的资源。
CRS-2677: Stop of 'ora.crsd' on 'indexserver2' succeeded
CRS-2673: Attempting to stop 'ora.ctssd' on 'indexserver2'
CRS-2673: Attempting to stop 'ora.evmd' on 'indexserver2'
CRS-2673: Attempting to stop 'ora.asm' on 'indexserver2'
CRS-2673: Attempting to stop 'ora.mdnsd' on 'indexserver2'
CRS-2673: Attempting to stop 'ora.drivers.acfs' on 'indexserver2'
CRS-2677: Stop of 'ora.asm' on 'indexserver2' succeeded
CRS-2673: Attempting to stop 'ora.cluster_interconnect.haip' on 'indexserver2'
CRS-2677: Stop of 'ora.evmd' on 'indexserver2' succeeded
CRS-2677: Stop of 'ora.drivers.acfs' on 'indexserver2' succeeded
CRS-2677: Stop of 'ora.cluster_interconnect.haip' on 'indexserver2' succeeded
CRS-2677: Stop of 'ora.mdnsd' on 'indexserver2' succeeded
CRS-2677: Stop of 'ora.ctssd' on 'indexserver2' succeeded
CRS-2673: Attempting to stop 'ora.cssd' on 'indexserver2'
CRS-2677: Stop of 'ora.cssd' on 'indexserver2' succeeded
CRS-2673: Attempting to stop 'ora.diskmon' on 'indexserver2'
CRS-2673: Attempting to stop 'ora.crf' on 'indexserver2'
CRS-2677: Stop of 'ora.crf' on 'indexserver2' succeeded
CRS-2673: Attempting to stop 'ora.gipcd' on 'indexserver2'
CRS-2677: Stop of 'ora.diskmon' on 'indexserver2' succeeded
CRS-2677: Stop of 'ora.gipcd' on 'indexserver2' succeeded
CRS-2673: Attempting to stop 'ora.gpnpd' on 'indexserver2'
CRS-2677: Stop of 'ora.gpnpd' on 'indexserver2' succeeded
CRS-2793: Shutdown of Oracle High Availability Services-managed resources on 'indexserver2' has completed
CRS-4133: Oracle High Availability Services has been stopped.
4.2 基于Agent的管理方式
在Oracle 11.2之前，Clusterware对于资源的管理、监控都是通过RACG脚本方式进行的，每当Clusterware要启动、关闭、检查一个资源时，就会调用这些脚本，传入相关的参数（start、stop、check）即可。
从Oracle 11.2开始出现了多用户的概念，Oracle开始使用一组多线程的daemon来同时支持多个用户使用、管理这些资源，这些daemon就叫做Agent。这些Agent都是一些常驻内存的进程，因为常驻在内存中，所以可以进行更加快速的故障检查以及更加快速的恢复。比如，对于Oracle监听器来说，平均的故障恢复时间从原来的5分钟缩短到了30秒，而检查的频率也由原来的10分钟一次增加到1分钟一次。这些Agent本身是由OHASD和CRSD以spawn方式启动的，可以管理更多的资源。
Agent 这种框架可以支持用 C、C++、脚本等多种语言的插件，因此可以按自己的喜好来开发、管理所有资源。这种管理方式也叫做Agent-Based管理系统。
1．Agent的分类
Oracle Grid 11.2的Agent有多个，其中有两个最重要，分别是Oracle Agent和Oracle Root Agent。这两种Agent的区别就在于维护资源所使用的身份不同。
Oracle Agent就是以Oracle用户身份运行（这个Oracle用户是一个泛指，根据场合的不同可能是Grid，也可能是Oracle），Oracle Root Agent是以root身份运行的。
这两个Agent对应的操作系统进程名字分别是orarootagent、oraagent。在Grid 11.2环境中，不管是Oracle Agent还是Oracle Root Agent都不止一个，而是多个，或者说多套。
OHAS栈会启动一套Oracle Agent和Oracle Root Agnet，由OHAS启动的Oracle Agent是用Grid的安装用户（通常是grid）身份运行的。
CRS栈也会启动一套Oracle Agent和Oracle Root Agent，这个Oracle Agent是以Oracle身份运行的，如果Grid不是用oracle用户安装的——大部分情况下都不是——CRS栈还会启动第3套Oracle Agent，这套Oracle Agent是以Grid身份运行的
这两类Agent对应的进程名字都是orarootagent、oraagent。它们有各自的日志文件，这些Agent的日志文件位于：
$GRID_HOME/log/<hostname>/agent/{ohast|crsd}/<agentname>_<owner>/<agentname>_<owner>.log
比如，ora.crsd是由OHASD管理的，属于root用户，因此Agent的名字是orarootagent，于是对应的日志就是：
$GRID_HOME/log/<hostname>/agent/ohasd/orarootagent_root/orarootagent_root.log。
同一个 Agent 日志文件中可以记录来自于多个源的日志，前提条件是这些源是由同一个Daemon、同一个Agent、同一个用户管理的。
这两个 Agent 是最主要的 Agent，此外还有专门负责管理和监视 CSSD 的 Agent，叫做cssdmonitor 和 cssdagent。这两个 Agent 也是由 OHAD 启动的。还有一种 Script Agent，这种Agent是供用户插入自定义资源使用的。比如我们后面会演示用Grid维护第三方资源，那里用到的就是Script Agent。
2．OHASD的Agent
由OHASD进程启动的Agent统称为OHAS Agent，它包括了4种：orarootagent、oraagent、cssdagent和cssdmonitor。这一组Agent的主要功能就是对Clusteware的进程进行监控。
由OHASD启动的Oracle Agent是以Grid用户（grid）的身份运行的，它是作为OHAS启动过程的一部分由OHASD直接启动的，这个Agent负责启动那些不需要root权限的资源和进程，这些进程和资源包括：
EVMD和EVMLOGGER；
Gipc daemon；
Gpnp daemon；
mDNS daemon；
ASM。
由OHAS启动的Oracle Root Agent负责启动那些需要root权限的资源和进程，包括：
CRS daemon；
CTSS daemon；
Disk monitor daemon；
ACFS驱动。
3．CRSD的Agent
由CRSD启动的Agent统称为CRS Agent，它包括oraagent和orarootagent。这一组Agent的功能是对CRS资源进行监控。
对ASM的监控是OHAS Agent的任务，而对数据库资源的监控则是CRS Agent的任务了。
一旦CRS被启动了，CRS就会创建另一个Oracle Agent和Oracle Root Agent，如果安装Grid的用户不是oracle而是grid，还会创建第二个Oracle Agent。这个grid的Oracle Agent负责：
启动并监视本地的ASM实例；
ONS和eONS daemon；
SCAN Listener；
Node Listener。
而oracle的Oracle Agent只负责启动数据库资源，包括数据库实例和服务。当然，如果Grid的安装用户也是oracle，这个Agent同样也会负责grid Oracle Agent的任务（前面已经列出的）。
Oracle Root Agent则负责创建GNS（如果配置了的话）、GNS VIP（如果启用了GNS的话）、ACFS Registry、Network、SCAN VIP和Node VIP这些资源。
以上这些复杂的关系可以总结为图4-3。图4-3就是Agent和资源之间的树状关系图。
图4-3 Agent关系示意图
在 Grid 11.2 中，Oracle Agent 提供的功能对应着 Clusterware 10.2 版本中的 racgmain 和racgimon两个后台进程的功能（这两个进程是RACG体系的一部分）。
4.3 更丰富的资源
Oracle Grid 11.2所维护的资源比Oracle Clusterware要丰富得多，而所谓资源其实就是一堆进程，我们把这些进程梳理一下。
4.3.1 ohasd
ohasd这个进程是由/etc/init.d/ohasd脚本启动的，这个脚本能接收start、stop两个参数。ohasd也是在rc过程中会调用的进程。
4.3.2 ohasd 的 oraagent
ohasd的oraagent是以Grid用户身份运行的，由它维护的资源有以下几项。
1．ora.asm
ASM必须要先于CRSD启动，这样CRSD才能访问ASM。因此ohasd负责启动、关闭、监视ASM实例。
2．ora.evmd
EVM负责订阅集群环境中事件的生成和发布。EVMD会产生一个叫evmlogger的子进程，再由这个进程产生更多的子进程。evmlogger进程会根据$GRID_HOME/evm/admin/evmlogger.conf配置文件产生日志，可以使用这个文件中的maxsize参数来控制日志文件的大小。
EVMD 的另一个功能就是调用用户的回调脚本，用户把这些脚本放在特定的 RACG 目录下，EVMD会扫描这个目录并负责调用这些脚本。
EVMD是以Grid身份运行的，会在失败时自动重启。它的日志文件位于$GRID_HOME/log/hostname/evmd/evmd.log。
3．ora.mdnsd
MDSN即Multicast DNS，它与GNSD合作来提供域名解析工作。
Oracle Grid 11.2引入了SCAN，简单地说，SCAN就是一种域名访问机制，就像我们只需要知道www.google.com这个域名就能访问谷歌一样，通过Grid的域名SCAN就能访问Grid的数据库。但这个域名也需要进行解析，转换成一个IP地址才行。
解析有两种方式，一种是通过通用的域名解析机制即 DNS，另一种是就是 Oracle 自己提供的GNS。
可以把GNS想象成Oracle专为Grid量身定做的域名解析机制，它不能对Grid之外的域名解析。它的日志文件为$GRID_HOME/log/hostname/mdnsd/mdnsd.log。
4．ora.gpnpd
GPNPD即Grid Plug and Play Daemon，这个进程负责集群节点间GPnP profile的同步。这个文件保存在每个节点的本地，位置是$GRID_HOME/gpnp/profile/peer/profile.xml。
这是一个XML文件，该文件中的内容是这个节点加入集群所需要的必需信息。它的日志文件位于$GRID_HOME/log/hostname/gpnpd/gpnpd.log。
5．ora.gipcd
在以前的版本中，集群使用TCP进行通信协议，和RDBMS的通信协议完全一样。
从Oracle Grid 11.2开始，Oracle使用一个全新的代码完成集群的通信协议，叫做Grid IPC以及 Grid Inter Process Communication Daemon（GIPCD）。Grid IPC 支持多种通信协议类型，包括 UDP、IPC、TCP 及 Grid IPC 本身。它的日志位于$GRID_HOME/log/hostname/gicpd/gicpd.log。
4.3.3 ohasd 的 orarootagent
这个进程是以root身份运行的，负责ora.crsd、ora.ctssd、ora.drivers.acfs和diskmon的启动、关闭和检查，这些进程也都是以root身份运行的。
1．ora.crsd
这个 daemon 负责启动管理应用资源的 Agent。Oracle 10.2 Clusterware 的 CRSD 是通过RACG框架来管理资源，而Oracle 11.2 Grid的CRSD是通过Agent来管理资源的。
2．ora.ctssd
这个 daemon负责处理时间同步。Oracle数据库用SCN来跟踪操作发生的先后顺序，数据的完整性也靠SCN来保证，SCN是根据时间戳实现的。因此集群里所有节点的时间必须同步。
Grid 11.2之前依靠的是操作系统自带的时间服务器NTP，不过NTP并没考虑RAC的要求，NTP调整时间的方式会引起节点的重启，因此需要对NTP做特别的设置，于是Oracle引入了自己的同步机制。
CTSS既可以取代NTP也可以和NTP合作使用。具体的细节可以参考2.3.3节。这个进程的日志文件为$GRID_HOME/log/hostname/ctssd/ctssd.log。
3．ora.diskmon
Diskmon daemon用以监控Exadata中的Cell Server，只有在Exadata环境中才有用。但是在Grid版本11.2.0.1和11.2.0.2中有个bug，即便是非Exadata环境也会默认启动该守护进程。到了版本11.2.0.3，改进了这一细节，非Exadata环境无法启动Diskmon了。
4．ora.drivers.acfs
这个进程负责保证ACFS驱动的加载，确保ACFS可用。这个进程的日志会写到系统日志及控制台中。
4.3.4 ohasd 的 cssdagent 和 cssdmonitor
之前说到Clusterware中有两个关键进程oprocd和oclsmon。在Grid 11.2中，这两个进程没有了，取而代之的是这两个 Agent，所以它们的作用和原来那两个进程是一样的。cssdagent负责cssd进程的启动、关闭和检查，而cssdmonitor监控cssdagent。
这两个进程和ocssd进程都运行在实时（real time）模式下，因为这可以保证有效的调度，任何一点调度上的延迟都可能会被看做是进程的挂起，会导致节点被隔离。
这几个进程的日志分别在：
$GRID_HOME/log/hostname/agent/ohasd/oracssdagent_root/agent/ohasd/oracssdagent.root.log、
$GRID_HOME/log/hostname/agent/ohasd/oracssdmonitor_root/oracssdmonitor_root.log
注意：从Clusterware 10.2.0.4开始，Linux RAC就不再需要配置的hangcheck-timer模块了。
4.3.5 CSSD
在Clusterware时期，CSS就是保证集群稳定的基石。
它主要管理节点成员信息并分发配置，所有成员节点上的CSSD进程间会产生网络心跳，CSSD 的网络心跳以及 Voting Disk 的磁盘心跳共同用来监视集群的健康状况和节点的成员身份，当有节点加入或者离开集群时，也是由 CSSD 进行投票并通知注册的进程组发起集群重构。
到了Grid，CSSD仍然是整个集群的基础，而且其工作机制和作用方式也没变，如果CSSD不能正常启动，这个节点还是不能加入到集群。
CSSD的日志文件为$GRID_HOME/log/hostname/cssd/ocssd.log。
4.3.6 CRSD
Clusterware中的CRSD是负责应用资源的可用性，比如数据库。负责启动、关闭、重新分配（Relocate）这些资源；还负责维护 OCR 中资源记录的完整性。另外，CRSD 还负责 OCR的备份。
这些功能在Grid中仍然保留，除此之外，CRSD还负责启动两个Agent，分别是ORAAGENT和ORAROOTAGENT。CRSD的日志文件为$GRID_HOME/log/hostname/crsd.log。
1．CRSD的oraagent
如果Grid和RDBMS是用两个用户安装的，基本都是一个grid、一个oracle。这样就会启动两个oraagent，一个以grid用户身份运行，另一个以oracle用户身份运行。其中grid的这个oraagent负责diskgroup、node listener、scan listener、ons、eons，而oracle这个oraagent负责数据库、实例和服务。
Grid用户的日志文件为$GRID_HOME/log/hostname/agent/crsd/oraagent_grid/oraagent_grid.log。
2．CRSD的orarootagent
CRSD启动的这个以root身份运行的Agent负责管理GNS、VIP、node vip、scan vip等网络资源。它的日志文件为$GRID_HOME/log/<hostname>/agent/crsd/orarootagent_root.log。
3．CRSD的scriptagent
如果使用Grid监管第三方应用程序，比如Tomcat，也必须通过Agent框架，这些资源就是通过这个 Agent 进行管理的。它的日志文件为$GRID_HOME/log/hostname/crsd/scriptagent_grid/scriptagent_grid.log。
这就是Grid框架中涉及的一些重要服务和进程，下面再来看整个Grid栈的启动顺序，并这些进程在其中的位置标出来。
4.4 Grid的进程和启动顺序
在用 Clusterware 时，Clusterware 是随着操作系统的启动而自动启动，具体说就是由操作系统的INIT启动了CRSD、CSSD、EVMD三个进程。
以后的运行过程中，如果EVMD、CRSD进程异常挂了，操作系统会自动重启这两个进程，如果CSSD挂了，整个操作系统会自动重启。
这些是通过/etc/inittab中的这3条内容体现的，这些内容也是在Clusterware部署过程中自动添加的：
h1:3:respawn:/etc/init.d/init.evmd run >/dev/null 2>&1 </dev/null
h2:3:respawn:/etc/init.d/init.cssd fatal >/dev/null 2>&1 </dev/null
h3:3:respawn:/etc/init.d/init.crsd run >/dev/null 2>&1 </dev/null
到了Grid后就变化了，Grid部署过程会自动在/etc/inittab文件中添加一条内容，具体如下：
h1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null
也就是说，Grid栈的启动仍然是由操作系统触发的。在操作系统的启动过程中INIT会启动init.ohasd脚本，后者会启动OHASD进程（Oracle High Availability Service Daemon），从这个时刻开始，整个Grid栈的启动正式拉开了序幕。
虽然Grid栈要比Clusterware复杂得多，但是Grid栈的层次结构很清晰，它的启动进程也是层次分明，可以分成4个级别或者4个阶段。下面我们依次解释。
1．级别1：OHASD的活动
这个阶段是 OHASD 的舞台，OHASD 要启动 4 个 Agent ，分别是 ORAAGENT、ORAROOTAGENT、CSSDAGENT和CSSDMONITOR。
CSSDAGENT：这个Agent以root身份运行，负责启动CSSD，对应的进程名字是cssdagent；
ORAROOTAGENT：这个Agent以root身份运行，负责管理所有属于root用户的OHAS资源，对应的进程名字是orarootagent.bin；
ORAAGENT：这个Agent以grid身份运行，负责管理所有属于grid用户的ohasd资源，对应的进程名字是oraagent.bin；
CSSDMONITOR：这个进程以root身份运行，和CSSDAGENT一起负责监控CSSD以及节点的健康状况，对应的进程名字是cssdmonitor。
注意：记住这些进程是由ohasd.bin启动的，而不是CRS或者CSS启动的，因为这个时候还没有这两项呢，这也是不同于Clusterware的。
阶段1结束时，舞台上多出了4个“小生”，于是舞台就交给他们并进入到了第二个阶段。在这个阶段，每个“小生”又都有自己的任务。
2．级别2：ROOTAGENT的活动
由OHASD启动的orarootagent要启动以下几个进程。
CRSD：这个进程是我们的老朋友了，它以root身份运行，对应的进程名字是crsd.bin。
CTSSD：Cluster Time Synchronization Services Daemon，只是Oracle Grid自己的时间同步服务，也是以root身份运行，对应的进程名字是octssd.bin。
Diskmon：在非Exadata机器上是无效进程，Grid 11.2.0.3 之后就不再有了，对应的进程名字是diskmon.bin。
ACFS：这是ASM集群文件系统的驱动，以root身份加载。
3．级别2：ORAAGENT的活动
由OHASD启动的ORAAGENT进程负责启动下面这些进程和服务，并且这些服务是以grid身份运行的。
ASM：ASM实例，用于挂载磁盘组。
EVMD：对应的进程名字是evmd.bin。
MDNSD：对应的进程名字是mdnsd.bin，取决于是否使用GNS服务。
GIPCD.bin：对应的进程名字是 gipcd.bin ，用于进程间（ inter-process ）和节点间（inter-node）通信协议。
GPnPD：对应的进程名字是gpnpd.bin。
4．级别2：CSSDAGENT的活动
CSSDAGENT启动ocssd.bin，这个进程以Grid用户身份运行。CSSDAGENT不再启动其他进程。
5．级别3：CRSD的活动
CRSD会启动两个或三个Agent，ORAROOTAGENT和ORAAGENT。如果Grid和Database的安装用户不是同一个，就会创建两个ORAAGENT。
再重申一遍，OHASD和CRSD都会创建自己的一组Agent，于是从操作系统上我们可以看到多个同名的agent进程，比如：
[oracle@indexserver1 ～]$ ps -ef|grep oraagent
Grid 6161 1 0 Jul18 ? 03:34:32 /u01/app/11.2.0.2/grid/bin/oraagent.bin
Grid 6782 1 0 Jul18 ? 01:00:15 /u01/app/11.2.0.2/grid/bin/oraagent.bin
Oracle 9421 1 0 Oct18 ? 00:12:07 /u01/app/11.2.0.2/grid/bin/oraagent.bin
[oracle@indexserver1 ～]$ ps -ef|grep orarootagent
root 6198 1 0 Jul18 ? 10:20:53 /u01/app/11.2.0.2/grid/bin/orarootagent.bin
root 6786 1 0 Jul18 ? 13:18:42 /u01/app/11.2.0.2/grid/bin/orarootagent.bin
oracle 18750 17134 0 10:11 pts/1 00:00:00 grep orarootagent
oraagent有三个，orarootagent有两个。不过这两组Agent的日志文件所在的位置也不一样，一组位于$LOG_HOME/agent/crsd，另一组位于$LOG_HOME/agent/ohasd。
ORAROOTAGENT：这个 Agent 负责启动以 root 身份运行的资源，这些资源也可以叫做CRSD资源。
ORAROOTAGENT：这个Agent会有两个，分别负责管理以grid、oracle身份运行的CRSD资源。
接下来舞台就交给这几个Agent，Grid的启动也进入第4个阶段。看看它们都要干些什么？
6．级别4：ORAROOTAGENT的活动
这个Agent负责启动下面这些资源。
Network Resource：这个资源是Grid 11.2新出现的，对应着Public Network。
SCAN VIP(s)：SCAN是Grid 11.2新出现的，由SCAN VIP和SCAN Listener配对组成。
Node VIPs：这个VIP和Clusterware中的VIP一样，是Public NIC上的VIP地址，因此每个节点都需要一个VIP。
SCAN VIP和Node VIP类似，都是浮动地址。不同的是，Node VIP在数量上等于节点的个数，每个节点一个。而SCAN VIP和节点数量没有关系，和集群规模没关系，固定就是3个（在实验环境中可以不用DNS，而是用/etc/hosts来解析SCAN域名，这时SCAN VIP可以只要一个，但仅限于实验环境，生产环境不可以这么做）。SCAN VIP是在DNS上定义的，它和节点之间初始时没有任何关系，而NODE VIP是通过/etc/hosts定义的，初始时都是和节点配对定义的，只是在运行过程中会出现浮动。
ACFS Registry：用户挂载ACFS文件系统，后面的章节中会详细介绍。
GNS VIP（可选）：GNS的VIP。如果不使用DNS而使用GNS来解析SCAN名字，那么就需要知道Grid中的这个GNS服务本身也是高可用的，也就是它是在集群内浮动的，因此，它对外的访问渠道IP是VIP，也是虚拟浮动的。
7．级别4：ORAAGENT的活动（Grid用户）
以Grid身份运行的ORAAGENT会启动以下这些资源。
ASM资源：ASM实例。
Diskgroup：管理和监视ASM磁盘组。
SCAN Listener：监听SCAN VIP的监听器。
Listener：监听节点VIP的节点监听器。
ONS：Oracle Notification Service（Oracle事件通知服务）。
eONS：增强版的ONS。
GSD：向后兼容Oracle 9i的服务，如果环境中没有Oracle 9i数据库，这个进程不会启动。
GNS（可选）：Grid Naming Service，代替DNS处理名字解析。
8．级别4：ORAAGENT的活动（Oracle用户）
这个Agent的任务貌似比较少，但是直接关系到用户的使用体验。
DB：管理和监视DB和实例；
Service：管理和监视Service。
上面这些进程除了 ONS 之外，其他的都位于$GRID_HOME/bin 目录下，而 ONS 位于$GRID_HOME/opmn/bin目录下，eONS是一个Java程序，因此也不是从$GRID_HOME/bin目录下启动，不过对应的JAR文件是在$GRID_HOME/bin目录下。
4.5 配置文件
在Oracle Clusterware和Oracle Grid 11.1中，集群的配置信息保存在OCR中，这个文件中同时记录着集群的信息以及由集群维护的资源信息。而Voting File记录的是节点成员身份信息。
到了Oracle Grid 11.2后，由于集群架构被拆分成了两层，OCR配置文件同样被做了相应的拆分，原来的一个OCR现在拆成了OLR和OCR，另外，还有一个GPnP也是属于配置文件。这样拆分的目的就是集群的归集群、资源归资源，归属清楚。用于集群的是GPnP和OLR（Oracle Local Registry），用于资源的是OCR。
于是，集群的构成信息现在就来自于3个文件：VotingFile、OLR和GPnP，这3部分共同构成了集群的信息。而OCR是给CRSD管理Cluster中的资源的。尽管OCR中也会记录一些本地资源的信息，但对于本地节点加入到集群这样的处理是不需要 OCR 的，因为这些信息是来自于OLR和GPnP的。比如，集群的互联信息是在GPnP中记录的。
先来看第一个配置文件GPnP。
4.5.1 GPnP（Grid Plug and Play）
GPnP Profile是一个XML文件，保存在每个节点的本地，这个文件所记录的信息是这个节点要加入到集群中所需要的最基础的信息。这个文件也需要节点间的同步，Grid中专门设计了GPnPD（Grid Plug and Play Daemon）来负责这个文件的同步工作。
下面是这个文件的内容，可以使用gpnptool得到这些内容：
<?xml version="1.0" encoding="UTF-8"?>
<gpnp:GPnP-Profile Version="1.0" xmlns="http://www.grid-pnp.org/2005/11/gpnp-profile" xmlns:gpnp="http://www.grid-pnp.org/2005/11/gpnp-profile" xmlns:orcl="http://www.oracle.com/gpnp/2005/11/gpnp-profile" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi: schemaLocation="http://www.grid-pnp.org/2005/11/gpnp-profile gpnp-profile.xsd" Profile- Sequence="4" ClusterUId="0829b9ed4ba4dff6ffb88b20d6be239f" ClusterName="indexgrid" PALoca-tion="">
<gpnp:Network-Profile>
<gpnp:HostNetwork id="gen" HostName="*">
<gpnp:Network id="net1" IP="192.168.1.0" Adapter="eth0" Use="public"/>
<gpnp:Network id="net2" IP="10.0.0.0" Adapter="eth1" Use="cluster_interconnect"/>
</gpnp:HostNetwork>
</gpnp:Network-Profile>
<orcl:CSS-Profile id="css" DiscoveryString="+asm" LeaseDuration="400"/>
<orcl:ASM-Profile id="asm" DiscoveryString="ORCL:*" SPFile="+DATA/indexgrid/asmparame-terfile/registry.253.787835657"/>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<InclusiveNamespaces xmlns="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="gpnp orcl xsi"/>
</ds:Transform></ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>F7XCODDT+nhYjFsT/lmO3ROPj8o=</ds:DigestValue>
</ds:Reference></ds:SignedInfo>
<ds:SignatureValue>gnPGH5rLhYwl1pdw4Fq2wrTwiZD3tM7JfUTr9QLeGCCXwgFLmThpgI+24C3I8p3sY0 rn6KMGEaFy92tNwKZlqQJSzSZuSRInjBhlPa4rqq49xqsjr1QIuwTLvpRltxr9JoxNu5Ny79uGyOjpcRFxNsLiCaWv ZEDsB8KwYp6W1S8=
</ds:SignatureValue>
</ds:Signature>
</gpnp:GPnP-Profile>
我们能从这个文件中看到集群的一些重要信息，比如集群的名字ClusterName，gpnp:Network记录着集群所使用的共有网络和私有网络。
ASM Discovery String也出现在这里。集群启动时CSS会按照这个信息扫描这些ASM磁盘或者磁盘头部的元信息。Clusterware时，集群和ASM是没有任何关系的，这个数据是被记录在ASM的参数文件中的。而Grid中Clusterware是依赖于ASM的，比如Clusterware的Voting File和OCR都保存在ASM磁盘上，二者的关系就像是先有蛋还是先有鸡那么纠结，于是集群就通过把ASM Diskcover string记录到这个文件中来打破这个怪圈。
ASM实例的SPFILE的位置也是记录在GPnP的，这又是个先有蛋还是先有鸡的问题，既然ASM SPFILE放在ASM磁盘中，按理说应该是ASM实例启动后才能访问ASM文件，但是ASM实例启动又必须要依赖SPFILE。解决办法就是，ASM磁盘头的元数据中有个标志说明了SPFILE 是否位于这个 ASM 磁盘中以及位于哪一个 AU，于是可以跳过 ASM 实例得到 ASM SPFILE。因此，既保证了ASM实例不再有本地SPFILE，同时也保证了ASM实例在启动时能够找到它的SPFILE。
1．关联命令
Grid 中提供了 gpnptool命令，供用户访问 GPnP，比如可以这样得到上面所展示的 GPnP内容：
[grid@indexserver3 ～]$ gpnptool get
2．关联文件
与GPnP 关联的文件有两个，一个是GPnP Profile，另一个是GPnPD 的trace 文件，这两个文件分别位于不同的位置。
GPnP Profile：$GRID_HOME/gpnp/profiles/peer/profile.xml。
GPnPD trace：$GRID_HOME/log/<hostname>/gpnpd/gpnpd.log。
4.5.2 OLR（Oracle Local Registry）
OLR文件中记录的是本地节点的元数据，可以把 OLR 看作是 OCR 的本地替身，这也是Grid引入的新特性。OLR中记录的是OHASD启动所必需的信息，如GPnP的wallet。它和GPnP文件一起提供了这个节点要加入到集群中所需要的信息，OCR中记录的是CRSD需要的信息。因此，OHASD栈的启动只需要OLR、GPnP profile就可以，并不需要OCR的内容。它的内容格式和OCR一样，也是key、value格式。如果把OLR和OCR内容进行对比，就会发现OLR中记录的key更少。OLR是由OHASD管理的。
OLR本身就是对OCR的提取，因此内容格式和OCR一样，只是内容更少，它也不需要在集群中共享。所有用于OCR的命令也可以用于OLR，只是需要给这些命令加上-local参数。比如：
ocrdump –local
每个节点只需要一个OLR文件，文件的位置如下。
1．关联文件
在Clusterware中，OCR放在什么位置是通过一个叫做ocr.loc的文件记录的，这个文件一般放在/etc/oracle/ocr.loc，文件的内容是这样：
ocrconfig_loc=/dev/rdsk/emcpower1a
ocrmirrorconfig_loc=/dev/rdsk/emcpower5a
local_only=FALSE
这里记录了OCR的位置以及OCR镜像的位置。OLR也是延续了这种使用方法，OLR使用/etc/oracle/olr.loc这个文件来记录OLR文件的位置的，例如：
[root]# cat /etc/oracle/olr.loc
olrconfig_loc=/u01/app/11.2.0/grid/cdata/racassur-ipfix01.olr
crs_home=/u01/app/11.2.0/grid
2．关联命令
因为OLR就是从OCR中提取出来的，所以二者的内容格式也完全一样。同时，二者使用的命令也是一套，原来用于OCR的ocr***系列命令同样也适用于OLR，只是需要加上一个额外的参数local就行。例如，想检查OLR内容，可以这样做，用root身份运行：
[root@indexserver1 ～]# /u01/app/11.2.0.2/grid/bin/ocrcheck -local
Status of Oracle Local Registry is as follows :
Version : 3
Total space (kbytes) : 262120
Used space (kbytes) : 2576
Available space (kbytes) : 259544
ID : 1739919467
Device/File Name : /u01/app/11.2.0.2/grid/cdata/indexserver1.olr
Device/File integrity check succeeded
Local registry integrity check succeeded
Logical corruption check succeeded
再比如，OLR本身是有自动备份机制的，初次安装、每次升级OLR会自动备份，我们也可以手工备份。这个命令是这样的：
[root]# / /grid/bin/ocrconfig -local –manualbackup
4.5.3 OCR（Oracle Cluster Registry）
Oracle 11.2把原来的CRS拆成了两部分，OHASD负责管理低级的进程，而CRSD管理高级的资源，CRS的配置信息也被拆分成了两部分，OHASD管理的是OLR，而CRSD管理的是OCR。原来CRS是通过RACG框架来管理资源的可用性的；Oracle Grid 11.2使用基于Agent的框架来管理可用性。
OCR中保存的是由集群管理的资源的元数据和Wallet
。所有CRSD以及Agent所管理的资源信息是在OCR中记录的，这一点和Clusterware是一样的。
说明：尽管 OCR 中也会记录一些本地资源的信息，但是对于节点加入到集群这样的过程并不需要OCR，因为这些信息来自于OLR和GPnP。
Oracle Clusterware的OCR要放在集群文件系统或者裸设备，不支持ASM。
Grid 11.2不再支持裸设备，OCR是作为普通的ASM文件保存在ASM中。但是CRSD不能直接读取ASM磁盘，必须要通过ASM实例才行，因此也就是说必须先把ASM实例启动，然后ASM实例挂载包含OCR的ASM磁盘组，然后CRSD才可能启动。
如果要想关闭 ASM 实例，必须先关闭连到 ASM 实例的客户端，因此也就是必须要先关闭CRSD，同样，就算是不关闭ASM实例而只是想卸载一个磁盘组，如果OCR是在这个磁盘组上的话，也必须先关闭CRSD。否则，就会遇到下面这个错误，这个错误也是我刚使用Grid时常遇到的，因为当时只安装了Grid，还没有安装数据库软件，更谈不上数据库了。所以一度对这个提示很郁闷，搞不清楚到底是谁连接了 ASM 实例。后来才明白，是因为这个原因在作祟。
ORA-15097: cannot SHUTDOWN ASM instance with connected client
1．关联文件
Grid中记录OCR所在位置的方式没变，仍然是通过/etc/oracle/ocr.loc文件来记录的，下面是一个实例：
[root@indexserver1 ～]# more /etc/oracle/ocr.loc
ocrconfig_loc=+DATA
local_only=FALSE
可见这个文件保存在ASM的DATA磁盘组上。
2．关联命令
和OLR共用同一组命令，不过不用-local参数。比如，检查OCR文件的内容：
[root@indexserver1 ～]# /u01/app/11.2.0.2/grid/bin/ocrcheck
Status of Oracle Cluster Registry is as follows :
Version : 3
Total space (kbytes) : 262120
Used space (kbytes) : 3684
Available space (kbytes) : 258436
ID : 1126146844
Device/File Name : +DATA
Device/File integrity check succeeded
Device/File not configured
Device/File not configured
Device/File not configured
Device/File not configured
Cluster registry integrity check succeeded
Logical corruption check succeeded
3．OCR的自动备份
Clusterware 会自动地备份 OCR 文件，每隔 4 个小时就会进行一次备份，备份文件放在$GRID_HOME/cdata/<cluster_name>目录下。Clusterware 会自动保留一份周备份、日备份以及最后3次的备份，我们可以这么检查这几份备份：
[root@indexserver1 ～]# /u01/app/11.2.0.2/grid/bin/ocrconfig -showbackup
indexserver4 2012/09/18 10:55:03 /u01/app/11.2.0.2/grid/cdata/indexgrid/backup00.ocr
indexserver4 2012/09/18 06:55:02 /u01/app/11.2.0.2/grid/cdata/indexgrid/backup01.ocr
indexserver4 2012/09/18 02:55:01 /u01/app/11.2.0.2/grid/cdata/indexgrid/backup02.ocr
indexserver4 2012/09/17 02:54:55 /u01/app/11.2.0.2/grid/cdata/indexgrid/day.ocr
indexserver4 2012/09/06 02:53:55 /u01/app/11.2.0.2/grid/cdata/indexgrid/week.ocr
需要注意的是，这个备份只在一个节点上进行，所以用这个命令来确认这些备份是在哪个节点上生成的。
4.5.4 Voting File
Voting File记录集群的节点以及每个节点的状态，提供集群节点成员身份管理和节点隔离（fencing）功能。
集群运行过程中，每个节点每秒都要给其他节点发送一个网络心跳、每秒都要往每个Voting File更新自己的状态，这些动作用来声明“我还活着”。同时也会读取其他节点的信息，知道其他节点的状况。通过节点的心跳就可以掌握集群的状态。如果某个节点没有在一定时间内（CSS有个参数Miscount定义的就是这个时间）发出自己的心跳（包括网络和磁盘），就认为节点的心跳信息丢失了，那么这个节点就出问题了，或者说这个节点已经失去控制了。这个节点不一定宕机了，有可能还在运行着，上面的数据库实例、LGWR、DBWR等还在不断地写数据。失去了控制就意味着数据破坏，因此集群需要把这个节点踢出集群，避免脑裂和数据破坏。
这时会由某个节点触发一次重构过程，所谓重构其实就是把节点踢出集群以及之后的扫尾工作，比如处理该实例未提交的事务。
这些节点会通过 Voting File 进行投票（其实就是说有哪些节点能与它通信），根据所有节点的投票，Clusterware就能判断出健康的集群成员集合，这个新的成员集合组成新的集群。
这只是集群层面的重构，上层的 RAC 数据库也会被触发一次数据库层面的重构。在数据库开始重构时，会有一段短暂的静默期，这期间要进行数据恢复，数据库会暂停对外服务，不接受新的连接请求。因此，RAC并不是完全的24×7。
我们现在所说的是一个非常概括、笼统的过程，其实会有很多进程参与到这个过程中。对于大型的集群来说，最后得到的集群是节点数量最多的集合。
在Grid 11.2中，Oracle允许把Voting File放在集群文件系统中或者裸设备上，不过从Oracle 11.2 开始不再支持裸设备，Voting File 只能放在 ASM 磁盘组或者集群文件系统中。如果是升级方式到Grid 11.2的，Voting File和OCR文件还是能放在裸设备或者块设备上。
不管是哪一种配置，都需要保持Voting File的数量是奇数个。如果一个集群只有两个节点，当内部互联失败时，可以确保总会有一个节点获得多数Voting File。如果集群节点数量超过两个，集群会使用一种更为复杂的算法确定到底哪个节点最终获得集群的控制权。
不同选型意味着冗余策略会有所差异。如果使用集群文件系统保存Voting File，我们可以配置5个拷贝。这些拷贝应该放在不同的单独磁盘上，以避免单点故障。如果使用ASM存放Voting File，我们是不能直接控制实际创建的文件数量，ASM会根据所配置的Failure Group的数量来进行镜像，具体规则如下。
External Redundancy：只会使用一个Voting File。
Normal Redundancy：会有3个拷贝，但要求磁盘组至少要配置3个Failure Group。
High Redundancy：会有5份拷贝，但要求磁盘组至少要配置5个Failure Group。
在配置Voting File时，一定要保证奇数数量，也就是让节点之间有交叉。这样，可以容忍节点临时失去对一个Voting File的访问。假设有两个Voting File，两个节点。节点A丢失了对于Voting 1的访问，这时，如果节点B丢失了对于Voting 2的访问，也就是节点A只能访问Voting 2，而节点B只能访问Voting 1，这时，两个节点就无法获得彼此的信息了，集群就不稳定了。使用3个文件后，就算每个节点都丢失了对一个Voting File的访问，但是只要还剩两个，总是会有一个交叉的，因此集群还是不用重构的，如果丢失了对两个Voting的访问，就会触发重构了。
尽管Voting File是保存在ASM磁盘组中，但实际上Voting File是保存在其中的一个磁盘之上的，而不是像普通的ASM文件那样可能跨越多个磁盘。CSSD是可以直接访问这个ASM磁盘的，这也是为什么CSS可以在ASM之前被启动了。
Voting File的命令在Grid中没有变化，和Clusterware是一样的，比如查看Voting File的位置：
[root@indexserver1 ～]# /u01/app/11.2.0.2/grid/bin/crsctl query css votedisk
## STATE File Universal Id File Name Disk group
-- ----- ----------------- --------- ---------
1.ONLINE 187c6c1cf3d14f57bfa4d5e56133e666 (ORCL:WXXRDATA1) [DATA]
Located 1 voting file(s).
这个输出显示，有一个Voting File在ASM磁盘组DATA的唯一一个磁盘上。
4.5.5 OCR、ASM SPfile、Voting file、CRS 和 ASM 的关系总结
最后这一节，我们再把这几个元素之间的关系梳理一下，我曾一度被这些关系搞糊涂。
回顾一下，OCR、Voting File、ASM SPFILE都在ASM磁盘组中。
（1）CSSD负责维护集群的节点成员身份，启动它需要有Voting File，Voting File是保存在ASM磁盘组的，因此CSSD需要依赖于ASM。
（2）CRSD负责维护集群的上层资源，它需要用到OCR，OCR也是保存在ASM磁盘组上的，因此CRSD需要依赖于ASM。
（3）ASM 本身就是一个没有数据文件的数据库而已，启动 ASM 实例需要它的参数文件SPFILE，以前 SPFILE 是保存在节点本地的$ORACLE_HOME 里的，Grid 11.2 中它是保存在ASM 磁盘组中的。既然它是个普通的 ASM 文件，一定要启动 ASM 实例，我们需要能访问SPFILE，因此要启动ASM实例，必须先有ASM实例，然后将ASM实例作为自己的一个客户端访问自己。
如果照这些问题的思路下来，Oracle Grid 11.2中ASM应该是一个最底层的支撑元素，它应该位于整个Grid软件栈最底下一层才对，但我们知道，ASM只是CRS所维护的一个资源而已。那这些纠结的问题又是如何解决的呢？这一节就把这些问题做统一的解答。
在Oracle Grid 11.2之前，这些元素之间的关系比较简单，Clusterware需要OCR和Voting File才能运行，OCR和Voting File又是放在裸设备上的，所以Clusterware完全不需要ASM。ASM实例的启动需要ASM SPFILE，ASM SPFILE保存在本地的$ORACLE_HOME中的，所以ASM实例的启动也和普通数据库实例一样。
到了Grid 11.2后，这种简单的关系被搅乱了，ASM和Clusterware被合成一体，于是二者之间相互依赖又相互作用。
Oracle Grid 11.2中，OCR是按照一个普通的ASM文件形式放在ASM磁盘组中的，这一点和ASM SPFILE一样，但是又与Voting Fisk不同。OCR和ASM SPFILE这两个文件都是普通的 ASM 文件。比如，使用 asmcmd 命令可以很容易地看到 ASM 磁盘组中的 OCR、ASM SPFILE，但看不到Voting File。
[grid@indexserver1 ～]$ export ORACLE_SID=+ASM4
[grid@indexserver1 ～]$ asmcmd
ASMCMD> ls
DATA/
ASMCMD> cd DATA
ASMCMD> ls
indexgrid/
ASMCMD> cd indexgrid
ASMCMD> ls
ASMPARAMETERFILE/
OCRFILE/
ASMCMD> cd OCRFILE
ASMCMD> ls
REGISTRY.255.787835657 -------------OCR文件
ASMCMD> cd ../ASMPARAMETERFILE
ASMCMD> ls
REGISTRY.253.787835657 -------------ASM SPfile
因为OCR是一个普通的ASM文件，因此CRS启动需要先启动ASM实例、挂载磁盘组，然后OCRSD才能以ASM客户端的身份连接到ASM实例，透过ASM实例访问OCR文件，然后CRS才得以启动。这就是CRS和ASM的依赖关系。因此，在Oracle Grid 11.2中，如果想关闭ASM实例，我们必须同时关闭CRS，正确的关闭方法就是crsctl stop crs。这一点已经多次讲过了。
好了，OCR是当作一个普通的ASM文件使用的，CRS和ASM的依赖关系也清楚了。
SPFILE和Voting File这两个问题的解决方法是一样的。
Grid 11.2的ASM磁盘盘头中添加了新的元数据，包括标记（marker）、Voting File在磁盘上的开始位置（staring Allocation Unit）（kfdhdb.vfstart）以及Voting File在磁盘上的结束位置（ending AU）（kfdhdb.vfend）。标记是表明这个磁盘上是否有Voting File，后两个位置数据告诉CSS 到哪里找 Voting File。这样一来只需要扫描这些元数据，即使不启动 ASM 实例，也是可以获得Voting File位置信息的，也就能够找到它，一旦找到了Voting File，CSS就可以加入到集群中。这些数据结构可以用kfed 工具来查看。对于ASM SPFILE 的处理也是同样。回顾一下Grid的GPnP参数文件，这个文件中记录了Voting File、ASM SPFILE的Diskcover String，综合这些信息，Grid就可以找到这两个文件了。
<orcl:CSS-Profile id="css" DiscoveryString="+asm" LeaseDuration="400"/>
<orcl:ASM-Profile id="asm" DiscoveryString="ORCL:*" SPFile="+DATA/indexgrid/asmparameterfile/registry.253.787835657"/>
也就是说，对这两个文件的访问并不是透过 ASM 实例完成的，而是借助 ASM 驱动直接从磁盘上读取的。
4.6 小结
在这一章中，我们对Oracle Grid做了深入的剖析，讨论了Grid的几大组件：文件、进程、启动顺序、相互关系。
这一部分的内容比较枯燥，我试图把它们讲解得生动有趣易于理解，因为搞清楚每一个细节，对技能的进步和提高是最有效的，而且这种“从小处着手”的学习方式也能培养我们“从大处着眼”的意识和态度。