本文选自课程《Oracle DBA 武林秘籍》

介绍:

一：请介绍Oracle RAC启动过程？
二：请介绍Oracle RAC常见日志有哪些？
三：请介绍Oracle RAC Clusterware重要的服务和后台进程？
四：请介绍Oracle RAC数据库后台进程？
五：请介绍Oracle RAC中的GCS、GES、GRD之间的关系?
六：请介绍Oracle RAC的隔离机制？
七：请介绍Oracle RAC相关的等待事件？
八：请介绍在RAC中，实例1请求修改一个在实例2内存中块数据的过程？

一：请介绍Oracle RAC启动过程？

GI的启动过程可以分成3个阶段，ohasd阶段，构建集群阶段，启动资源阶段。
11gR2的RAC出现了很多以agent结尾的代理进程，用来协助主进程完成集群的管理工作。
这些进程都运行在spawns模式下，一旦运行失败就会知道重启，以维护RAC的高可用性。
首先由Linux的INIT进程执行init.ohasd脚本启动ohasd进程(Oracle高可用性 服务进程)，这个进程将启动4个代理进程。
其中：在11gR1中，/etc/init.d下有三个脚本，分别是init.evmd,init.cssd,init.crsd，到11gR2只有一个ohasd脚本。

ohasd阶段

1．/etc/initta
b文件中的脚本
h1:35:respawn:/etc/init.d/init.ohasd run

/dev/null 2>&1 </dev/null

被调用，产生下面的进程
root 4865 1 0 Dec02 ? 00:01:01 /bin/sh /etc/init.d/init.ohasd run

所以如果没有发现这个进程，那么说明:
(1)init.ohasd 脚本可能没有被调用
(3)os运行在不正确的级别
(3)一些S* ohasd脚本挂起， 例如S96ohasd
(4)GI没有配置自动启动（crsctl enable crs）

之后，ohasd.bin 进程会被启动，这个时候OLR会被访问,
所以，如果ohasd.bin不能正常工作，就需要查看OLR是否存在而且能够被正常访问。
OLR存放在$GRID_HOME/cdata/${HOSTNAME}.olr

2. ohasd.bin进程会启动对应的
   agents(orarootagent,oraagent, cssdagnet 和 cssdmonitor) 来启动集群的初始化资源。
   如果说，发现这些agent进程不能启动，很多时候都是由于路径$GRID_HOME/bin下的可执行文件存在问题，例如，文件权限设置有问题，文件corruption.

构建集群阶段:

1．Mdnsd 进程透过多播（Multicast）发现集群中的节点和所有的网卡信息。
所以，一定要确定集群中的网卡支持多播。而且节点间的通信正常。

2．Gpnpd 进程启动，发布构建集群所需要的
bootstrap 信息，并且在集群的所有节点之间同步gpnp profile。

当然，同步是透过mdnsd实现的。所以，如果是这个进程存在问题，您需要确认节点间的通信正常，而且gpnp profile（<gi_home>/gpnp/profiles/peer/profile.xml）存在而且可以被访问。

GPNPD(Grid Plug and Play 网格即插即用)
对应进程gpnpd.bin
在Clusterware中，CSS、GPnp等服务的启动都需要依赖于GPnP profile文件。
GPnP profile是一个XML文件，引导节点加入集群，GPnP profile提供新节点的配置信息，指定了整个集群的特性。
在Clusterware启动期间，CSS守护进程使用GPnP profile发现表决文件。
GPnP profile文件保存的是集群的配置信息。默认的保存位置是:
GRIDH​OME/gpnp/HOSTNAME/profile/peer/profile.xml GRID_HOME/gpnp/profile/peer/profile.xml(全局备份)
GPnP profile保存的是RAC的配置信息，包括集群名称、网络类型信息(public/private)、ASM和CSS的存储信息，以及ASM实例的SPFILE文件位置。
当集群配置发生变化时，所有节点的该文件会自动更新。

3．Gipcd 进程启动。
这个进程负责管理集群中所有的私网（cluster interconnect）网卡。
当然，私网信息是通过gpnpd获得的，所以，如果这个进程存在问题，需要确认gpnpd 进程正常运行。

4．Ocssd.bin 进程启动。
这个进程首先通过gpnp profile中的信息发现表决盘(Voting Disk)，之后通过gpnpd-进程获得集群私网信息，和其他的节点建立连接。
所以，如果ocssd.bin不能正常运行，您需要确认一下的信息:
(1)gpnp profile 存在而且可以被访问。
(2)gpnpd 进程正常运行。
(3)表决盘所在的asm disk 或设备能够正常被访问。
(4)节点私网间的通信正常。

5．启动其他的初始化进程：ora.ctssd, ora.asm, ora.cluster_interconnect.haip, ora.crf, ora.crsd等。
注意：
以上的过程是同时进行的。
也就是说ocssd.bin, gpnpd.bin 和 gipcd.bin 同时启动，直到gpnpd.bin正常运行，ocssd.bin 和 gipcd.bin 才能获得相应的信息，在gpnpd.bin没有正常运行之前,ocssd.bin 和 gipcd.bin 中出现的无法访问gpnp profile错误是可以忽略掉的。

资源启动阶段:

在这个阶段，主要是通过crsd进程启动各个资源。
1．Crsd进程启动。
这个进程需要访问OCR，如果OCR是存放在ASM上，需要确保ASM实例正常运行，并且OCR所在的ASM磁盘组已经装载。
如果OCR存放在裸设备上，那么需要确保对应的设备正常运行。

2．Crsd 启动对应的
agents(orarootagent,oraagent_<rdbms_owner>, oraagent_<gi_owner> )。
如果agent不能启动，很多时候都是由于路径$GRID_HOME/bin下的可执行文件存在问题，例如，文件权限设置有问题，文件corruption.

3．所有的资源启动。
(1)ora.net1.network : 网络资源，这个资源负责管理集群的公网，scanvip, vip,
listener资源都依赖于这个资源。
所以，如果这个资源存在问题，vip, scanvip 和listener 都会offline，您需要检查公网是否存在问题。
(2)ora.<scan_name>.vip：scan对应的vip资源，最多可以有3个。
(3)ora.<node_name>.vip : 节点对应的vip 资源
(4)ora.<listener_name>.lsnr: 监听程序资源。
在这里我们要注意，从11gR2开始，listener.ora文件会自动生成，不再需要手动修改。
(5)ora.LISTENER_SCAN.lsnr: scan 监听程序。
ora.<磁盘组名>.dg: ASM 磁盘组资源。
这个资源会在磁盘组被mount时创建，dismount时删除。
(6)ora.<数据库名>.db: 数据库资源。
在11gR2中实例资源已经不再存在了，新的数据库资源会管理rac 数据库的所有实例，而数据库包含哪些实例，是通过资源参数“USR_ORA_INST_NAME@SERVERNAME( )”来决定的。
另外，如果您的数据库存储在ASM磁盘上，那么数据库资源会依赖于对应的磁盘组资源，这个dependency是自动添加的。
但是，如果数据库被转移到了其他的磁盘组之后，原有的dependancy不会被自动删除，需要手动删除(crsctl modify res ……)。
(6)ora.<服务名>.svc：数据库服务资源。
从11gR2 开始，这个资源只有一个了，不会像10gR2一样，每个数据库服务资源包含，srv 和cs 两个资源。
(7)ora.cvu ：这个资源从11.2.0.2被引入，定期对集群执行cluvfy操作，验证集群是否存在一些配置上的问题
(8)ora.ons : ONS资源，和之前版本的功能，基本相同。

最后，集群的套接字文件(/var/tmp/.Oracle
或 /tmp/.oracle)，由于集群中很多进程之间的通信都是通过ipc实现的，所以，这些套接字文件一定要存在而且权限正确。

也可以将集群启动分为以下四层：

第一层：

ohasd进程启动四个代理进程，分别是:
(1)orarootagent
负责管理所有root用户拥有的ohasd资源的代理进程。
(2)cssdagent
CSSD的代理进程(由它来生成CSSD进程)
(3)oraagent
负责管理所有oracle用户拥有的ohasd资源的代理进程。
(4)cssdmonitor
同cssdagent一起监控CSSD的节点健康状况。

第二层：

(1)orarootagent启动如下4个进程：
CRSD 负责管理集群资源的主要进程。
CTSSD 集群时间同步服务进程。
Diskmon 磁盘监控进程。
ACFS Drivers ASM集群文件系统驱动程序。
(2)cssdagent启动1个进程:
CSSD 集群同步服务进程。
(3)oraagent启动如下5个进程：
MDNSD DNS lookup时使用的资源。
EVMD 事件监控进程。
ASM 监控ASM实例的资源。
GIPCD 内联集成和内连节点通信时使用的资源。
GPNPD 即插即用主进程。
(4) cssdmonitor启动1个进程:
cssdmontior CSSD进程监控进程。

第三层:

CRSD启动如下2个进程：
oraagent 负责管理所有oracle用户的所有crsd资源的代理进程。
orarootagent 负责管理所有root用户的所有crsd资源的代理进程。

第四层：

oraagent启动如下10个进程：
(1) ASM Resource
ASM实例资源。
(2) Diskgroup
管理，监控ASM磁盘组使用的资源。
(3) DB Resource
监控，管理数据库和实例使用的资源。
(4) SCAN Listener
SCAN监听器资源。
(5) Listener
节点监听器资源。
(6) Services
监控，管理Services使用的资源。
(7) ONS
Oracle通知服务。
(8) eONS
增强的Oracle通知服务。
(9) GSD
向后兼容9i的资源。
(10)GNS
网格命令服务(执行SCAN解析)的资源。

orarootagent启动如下5个进程：
(1) Network Resource
监控公共网络资源。
(2) SCAN VIP
SCAN VIP资源。
(3) NODE VIP
每个节点一个的VIP资源。
(4) ACFS Registry
加载ACFS资源。
(5) GNS VIP
GNS VIP资源。

二：请介绍Oracle RAC常见日志有哪些？

$GRID_HOME/log/<node_name>/alert<nodename>.log <==集群日志
$GRID_HOME/log/<node_name>/ocssd <==ocssd.bin日志
$GRID_HOME/log/<node_name>/gpnpd <==gpnpd.bin日志
$GRID_HOME/log/<node_name>/gipcd <==gipcd.bin日志
$GRID_HOME/log/<node_name>/agent/crsd <==crsd.bin日志
$GRID_HOME/log/<node_name>/agent/ohasd <==ohasd.bin日志
$GRID_HOME/log/<node_name>/mdnsd <==mdnsd.bin日志
$GRID_HOME/log/<node_name>/client <==用户使用GI 工具(ocrdump, crsctl, ocrcheck, gpnptool等等)对集群进行操作的日志。
$GRID_HOME/log/<node_name>/ctssd <==ctssd.bin日志
$GRID_HOME/log/<node_name>/crsd <==crsd.bin 日志
$GRID_HOME/log/<node_name>/cvu <==cluvfy 日志输出。
$GRID_HOME/bin/diagcollection.sh <==通过这个脚本获得更全面的诊断日志。

三：请介绍Oracle RAC Clusterware重要的服务和后台进程？

Clusterware由集群就绪服务层和高可用性 服务层两个单独的层组成。
集群就绪服务层：通过集群就绪服务(Cluster Ready Services,CRS)控制。
高可用性 服务层：通过Oracle高可用性 服务(High Availability Services)控制。

组成高可用性 服务层的主要进程：
(1) GPNPD(Grid Plug and Play)
网格即插即用，帮助快速地添加集群节点到集群中。
对应进程gpnpd.bin.
(2) GIPC(Grid Interprocess Communication)
支持守护进程使用多余网卡作为内部链接。
对应进程gipcd.bin。
(3)mDNS(Muliticast Domain Name Service)
用于GPnP在集群中查找profile,也用于使GNS去执行名称解析，该进程在Linux和UNIX中是一个后台进程，在Windows上是一个服务。
对应进程mdnsd.bin。
(4)GNS(Oracle Grid Naming Service)
网格命名服务，用于给集群自动分配SCAN VIP和节点VIP，解析SCAN名称等工作。
对应进程gnsd。
(5)CTSS(Cluster Time Synchronization Service)
集群节点之间的时间点应该是同步的，在11gR2中,Clusterware提供了CTSS服务，它能确保集群中所有节点是同步的。
如果在集群配置期间没有发现NTP服务，CTSS将在安装的被默认配置。
对应进程octssd.bin。
(6)CRS(Cluster Ready Services)
CRS守护进程crsd管理存储在OCR中的每个集群资源，包括启动、停止、监控和失败切换操作。
当资源的状态发生改变，crsd进程生成一个事件；
当有一个RAC节点被加载进来，crsd进程开始监控节点对应的实例、监听器等资源；
当这些组件出现失败情况，CRS会自动重启它们。
对应进程crsd.bin。
(7)CSS(Cluster Synchronization Services)
CSS控制集群包括的节点成员，并以发出通知的方式管理集群配置，如果使用第三方集群软件，CSS进程层面使用第三方的集群软件管理集群节点配置。
对应进程ocssd.bin

(8)ASM
提供Clusterware磁盘文件的存储，ASM实例需要在cssd进程启动之前启动，且MOUNT相应磁盘组成功。
(9)EVM(Event Management)
一个后台进程，发布由Clusterware创建的事件，是CRS和CSS通信的桥梁。
对应进程evmd.bin。

集群就绪服务层
(1) ASM
提供用于数据文件等存储的ASM磁盘组管理。
(2) ONS(Oracle Notification Service)
为传输FAN(Fast Application Notionfation)事件发布和注册服务。
(3) oraagent(Oracle Agent)
扩大集群支持的Oracle特殊要求和复杂资源。
对应进程oraagent.bin。
(4) orarootagent(Oracle Root Agent)
专门的oraagent进程，帮助crsd管理root用户拥有的资源，如网络，网络虚拟IP地址资源。
对应进程orarootagent。

四：请介绍Oracle RAC数据库后台进程？

(1)LMON 全局队列服务监控器

LOCK Monitor Processes 也被称为Global Enqueue Service Monitor
监控整个集群状况；
维护GCS的内存结构；
监控非正常终止的进程和实例；
当实例离开和加入集群，锁和资源的重新配置；
管理和监控全局的锁和资源；
处理死锁和阻塞。

(2)LCK 实例队列进程

Instance Enqueue Process
LCK进程主要用来管理实例间资源请求和跨实例调用操作；
调用操作包括数据字典等对像访问，并处理非CACEH FUSION的CHACE资源请求(例如dictionary cache或row cache的请求)
由于LMS进程负责主要的锁管理功能，所以每个实例只有一个LCK进程。

(3)LMD 全局队列服务守护进程

Lock Monitor Deamon Process
Global Enqueue Service Daemon
LMD进程主要管理对全局队列和资源的访问，并更新相应队列状态；
处理来自于其它实例的资源请；
每一个全局队列的当前状态存储在相应的实例共享内存中，该状态表明该实例具有相应的权利使用该资源；
一个实例master的共享内存中存在一个特殊的队列，该队列记录来自其它远程实例的资源请求；
当远程实例的LMD进程发出一个资源请求，该请求指向master实例的LMD；
当master实例的LMD进程受到该请求后，在共享内存中的特殊队列中监测该资源是否有无效；
如果有效LMD进程更新该资源对列的状态，并通知请求资源的LMD进程该资源队列可以使用了；
如果资源队列正被其它实例使用或当前无效，则LMD进程通知正在使用中的实例的LMD进程应用释放该资源；
等资源释放变得有效，master实例的LMD进程更新该资源队列的状态，并通知请求资源实例的LMD进程，该资源队列可以使用了。

(4)LMSn 全局缓存服务进程

Lock Monitor Services也称作GCS(Global Cache Service Process)
LMS进程主要用来管理集群内数据库的访问，并在不同实例的buffer cache中传输块镜像，
当在某个数据块上发生一致性读，LMS负责回滚该数据块，并将它copy到请求的实例上。
每个RAC节点至少有2个LMS进程。

(5)DIAG 诊断守护进程

Diagnostic Deamon
oracle10g新的后台进程，例行对实例的健康情况进行监控，也监控实例是否挂起或者出现死锁。
收集实例和进程出错的关键诊断信息，这个进程会更新alert日志文件，写入一些重要告警信息。

五：请介绍Oracle RAC中的GCS、GES、GRD之间的关系?

GRD（Global Resource Directory）
GCS全局缓存服务(Global Enqueue Service)
GES全局队列服务(Global Cache Service)
GRD、GCS、GES是Cache Fusion结构的核心。
RAC使用GRD记录集群数据库中资源的使用信息。GCS和GES共同维护GRD中的信息。每个实例在SGA的一部分作为GRD的组成部分。

GRD中包括如下共享资源信息：
(1)数据块的标识符，例如数据库地址(Data Block Address,DBA)。
(2)如果数据块在集群中多个节点的Buffer Cache中存在，GRD中保存该数据块最新版本的位置。
(3)实例持有的数据块的模式:Null(N)、Shared(S)、Exclusive(X)。
(4)每个实例持有的数据块角色：Local或者Global。

GRD中的信息是Cache Fusion的元数据信息，是Cache Fusion协调资源和管理的来源。
GRD是Cache Fusion的内部数据库，保存着所有实例资源的分布情况。
GCS是具体执行Cache Fusion工作的服务，对应的进程是LMSn(n可以是0-9)；
GES一方面协调各个实例之间的GCS完成数据传递的工作。另一方面还要完成Non-Cache Fusion资源的管理工作。对应的进程是LMD。
管理所有Non-Cache Fusion资源的同步，GES主要控制Dictionary Cache锁和Library Cache锁，还对所有死锁和资源死锁起到检测的作用。
其中GES协调全局锁的分配，之后GCS负责实例间数据块的传递工作。

GRD（Global Resource Service）
其实就是一张哈希表，也就是一个全局资源目录。用来记录各个RAC节点资源的使用情况。
每个实例掌握着某一组资源，所有实例加起来构成了GRD。
集群组中的资源根据其权重平等的分布在节点之间。
GRD由两个服务管理，这两个服务分布为:全局缓存服务(GES)和全局队列服务(GES)。

GCS（Global Cache Service）
对应的进程是LMSn ，负责数据块在实例间的传递。

GES（Global Enqueue Service）
对应的进程是LMD和LMON，负责在多个实例之间协调对数据块的访问顺序，也就是管理队列资源，保证数据的一致性访问。
LMD是实现队列资源的释放和分配的，LMON主要监控节点的健康。
其他：
GES全局队列服务(Global Enqueue Service)：
对应的进程是LMD和LMON，
主要负责维护字典缓存和库缓存内的一致性。
字典缓存是实例的内所存储的对数据字典信息的缓存，用于高速访问。
由于该字典信息存储在内存中，因而在某个节点上对字典进行的修改（如DDL)必须立即被传播至所有节点上的字典缓存。
GES负责处理上述情况，并消除实例间出现的差异。
出于同样的原因，为了分析影响这些对象的SQL语句，数据库内对象上的库缓存锁会被去掉。
这些锁必须在实例间进行维护，而全局队列服务必须确保请求访问相同对象的多个实例间不会出现死锁。
LMON、LCK和LMD 进程联合工作来实现全局队列服务的功能。
GES是除了数据块本身的维护和管理（由GCS完成）之外，在RAC环境中调节节点间其他资源的重要服务。

GCS全局缓存服务(Global Cache Service):
要和Cache Fusion结合在一起来理解，全局缓存要涉及到数据块。
全局缓存服务负责维护该全局缓冲存储区内的缓存一致性，确保一个实例在任何时刻想修改一个数据块，都可获得一个全局锁资源，从而避免另一个实例修改该块的可能性。
进行修改的实例将拥有块的当前版本（包括已提交的和未提交的事物）以及块的前象(post image)。
如果另一个实例也请求该块，那么全局缓存服务要负责跟踪拥有该块的实例、拥有块的版本是什么，以及块处于何种模式。LMS 进程是全局缓存服务的关键组成部分。

六：请介绍下Oracle RAC的隔离机制？

在所有的高可用环境中几乎都有心跳的存在。
心跳的主要目的是为了检测集群中节点的状态，如果检测失败，管理软件会认为某个节点存在故障，并根据一定的算法来做出适当的处理。
避免对环境的破坏，即高可用性软件的自动修复能力。
在RAC中，不同层次结构有不同的机制来检测RAC的健康情况。
在集群层，Clusterware软件由网络心跳和磁盘心跳来检测集群节点的健康状况。
如果Clusterware认为节点存在故障，那么它会根据一定算法来隔离故障节点，以避免对数据造成破坏。
通过故障的处理手段在一定程度上也能够恢复故障节点到正常状态。

1.网络心跳

通过私有网络来检测节点的状态。
如果由于私有网络硬件或软件的故障，导致集群节点间的私有网络在一定周期内无法进行正常通信，这种现象被称为脑裂。
出现脑裂，Clusterware需要采取措施将不正确的集群节点隔离出去，避免对存储中的数据造成损坏。
私有网络出现不能正常通信有一个超时，这个称为misscount。通过crsctl工具可以查询。
crsctl get css misscount
10.2.0.4以后网络心跳超时misscount为60s,11.2以后网络心跳超时misscount为30s。
如果超过30秒，Oracle认为节点间发生了脑裂，并会在Clusterware的日志中会有相应心跳丢失的记录。
注意：
在实施两节点的集群的时候，一定不能采用节点间直连的方式来组建心跳网络，这样会导致心跳大量丢失，不利于Clusterware的稳定运行。

2.投票算法

当出现脑裂的时候，Clusterware需要根据投票算法将不正确的节点踢出集群。
如果是3节点的集群，分别是A,B,C。当节点A因故私有网络不能和其他两个节点正常通信，那么整个集群被分为两部分。
A节点组成第一部分，投票拥有1票。
没有出现故障的B和C能够正常通信，组成另外一部分，拥有2票。
Oracle的规定，控制权会交给票数较多的部分，也就是说，这种情况下拥有一票的A节点组成的部分会被踢出集群，由B和C节点组成新集群。
如果是2节点的集群，两部分各持一票，最先获得表决磁盘一票的部分票数最多，将获得集群的控制权。
当出现脑裂时，Clusterware最重要的任务就是要保证错误节点与正确节点之间的I/O是隔离的，这样才能避免对数据造成不一致的损坏。
而处理这个问题的方法就是踢出错误节点执行修复过程。
从Oracle 11gR2开始，还可以在安装的时候或通过CRSCTL工具配置IPMI来实现I/O隔离的目的。

3.磁盘心跳

通过共享磁盘来检测节点的状态。
在Clusterware磁盘组文件中，表决磁盘就是用于检测Clusterware磁盘心跳的共享磁盘文件。
每个节点需要周期性的写磁盘心跳，通常每秒一次。
每个节点周期性的读取心跳数据，通常每秒读一次。
当数据的读取出现问题时，通常引起脑裂。

和磁盘心跳有关的参数：
(1)disktimeout参数
crsctl get css disktimout
默认200秒，如果ocssd进程对表决磁盘检测时间超过disktimeout设定值，Oracle就会认为该表决磁盘文件脱机，并在Clusterware告警日志中生成表决磁盘脱机记录。
如果节点表决磁盘脱机的个数小于在线表决磁盘的个数，这个节点能够幸存；
当脱机表决磁盘的个数大于等于在线表决磁盘的个数时，Clusterware会认为节点的磁盘心跳出现问题，节点会将该节点逐出集群，执行修复过程。
(2)reboottime参数
该参数表示节点被提出后，节点开始重启允许的最大时间。
crsctl get css reboottime
默认3秒。

4.本地心跳(Local HeartBeat,LHB)

这种心跳机制是在11gR2版本中被引入的。
作用是监控ocssd.bin进程以及本地节点的状态。
在10g版本中，Oracle通过oclsomon和oprocd来实现。
守护进程oclsomon.bin监控ocssd.bin进程的状态，oprocd.bin进程监控本节点是否出现了性能问题（例如，hang住）。
从11.2.0.1版本开始，新的集群cssdagent和cssdmonitor被引入，它们的功能就是监控本地节点的ocssd.bin进程状态和本地节点的状态（是否hang住）。
cssdagent和cssdmonitor的功能就是监控本地节点的ocssd.bin进程状态和本地节点的状态，对于ocssd.bin进程的监控是通过本地心跳来实现的。
Oracle会在每一秒钟，在发送网络心跳的同时向cssdagent和cssdmonitor发送本地ocssd.bin进程的状态（本地心跳）。
如果本地心跳没有问题，cssdagent就认为ocssd.bin进程正常。
如果ocssd.bin进程持续丢失本地心跳（到达misscount的时间）ocssdagent就会认为本地节点的ocssd.bin进程出现了问题，并重启该节点。
注意：
网络心跳和磁盘心跳是由OCSSD进程来检测的，网络和存储的稳定是一方面，OCSSD进程的稳定对RAC的稳定也至关重要。
不管是磁盘心跳还是网络心跳都依赖于cssd.bin进程来实施这些操作，在真实世界中任何造成cssd.bin这个普通用户进程无法正常工作的原因均可能造成上述2种心跳超时。
原因包括但不局限于CPU无法分配足够的时间片、内存不足、SWAP、网络问题、Votedisk IO问题、本次磁盘IO问题等等。
此外在使用ASM的情况下，DB作为ASM实例的Client客户；
ASM实例会对DB实例的ASMB等进程进行监控， 以保证DB与ASM之间通信正常。
若DB的ASMB进程长期无响应(大约为200s)则ASM实例将考虑KILL DB的ASMB进程，由于ASMB是关键后台进程所以将导致DB实例重启。
也存在其他可能的情况，例如由于ASMB 被某些latch block, 会阻塞其他进程，导致PMON进行强制清理。
综上所述不管是Clusterware的cssd.bin进程还是ASMB进程，他们都是OS上的普通用户进程，OS本身出现的问题、超时、延迟均可能造成它们无法正常工作导致。
建议在确认对造成OS长时间的网络、IO延时的维护操作，考虑先停止节点上的Clusterware后再实施。

七：请介绍Oracle RAC相关的等待事件？

集群等待事件属于以下类别之一：

(1) 面向块的等待

1 gc current block 2-way
2 gc current block 3-way
3 gc cr block 2-way
4 gc cr block 3-way

(2) 面向消息的等待

1 gc current grant 2-way
2 gc current grant 3-way
3 gc cr grant 2-way
4 gc cr grant 3-way

(3) 面向争用的等待

1 gc current block busy
2 gc cr block busy
3 gc buffer busy acquire/release

(4) 面向负载的等待

1 gc current block congested
2 gc cr block congested
3 gc current grant congested
4 gc cr grant congested

八：请介绍在RAC中，实例1请求修改一个在实例2内存中块数据的过程？

请求块

(1)实例1试图修改块，它向GCS提交一个请求。
The instance attempting to modify the block, instance 1, submits a request to the GCS.

(2)GCS将请求发送给块的持有者，实例2。
The GCS transmits the request to the holder, instance 2.

(3)实例2接收消息，LMS进程将块发送给实例1。
Instance 2 receives the message and the LMS process sends the block to instance 1.

(4)在发送块之前，实例2中的资源从独占模式降级为空模式(N)，实例2保留脏缓冲区作为PI。
Before sending the block, the resource is downgraded in instance 2 from exclusive to null mode (N) and instance 2 retains the dirty buffer as a PI.

(5)由于块在多个实例中可能变成脏的，所以角色更改为global (G)。
The role changes to global (G) because the block may become dirty in more than one instance.

(6)与块一起，实例2与请求实例通信，实例2在null (N)模式下保留PI。
Along with the block, instance 2 communicates to the requesting instance that instance 2 retained a PI in null (N) mode.

(7)在同一消息中，实例2还指定请求者必须以排他性(X)模式和全局(G)角色保留块。
In the same message, instance 2 also specifies that the requestor must retain the block in exclusive (X) mode and with a global (G) role.

(8)在接收到块时，实例1通知GCS它以独占模式和全局角色持有块。
On receipt of the block, instance 1 informs the GCS that it holds the block in exclusive mode and with a global role.

注意，在将资源授予实例1之前，数据块不会写入磁盘。
Note that the data block is not written to disk before the resource is granted to instance 1.

写入块

(1)实例2向GCS发送一个写请求。
Instance 2 sends a write request to the GCS.

(2)GCS将请求转发给实例1，即当前的块持有者。
The GCS forwards the request to instance 1, the current block holder.

(3)实例1接收写请求并将块写入磁盘。
Instance 1 receives the write request and writes the block to disk.

(4)实例1记录GCS写操作的完成，并通知GCS资源角色可以变成本地角色，因为实例1执行了当前块的写操作。
Instance 1 records the completion of the write operation with the GCS and informs the GCS that the resource role can become local because instance 1 performed the write of the current block.

(5)收到通知后，GCS命令所有PI持有人丢弃或冲洗其PI，PI不再需要恢复。
After receipt of the notification, the GCS orders all PI holders to discard, or flush, their PIs; the PIs are no longer needed for recovery.

缓冲区是空闲的，以前以空模式持有的资源被关闭。
The buffer is free and the resource previously held in null mode is closed.

欢迎关注我的公众号《IT小Chen》