[Oracle 11g r2(11.2.0.4.0)]集群守护进程CSS介绍

CSS介绍：

CSS ( Cluster Synchronization Service）这个组件负责构建集群， 并且维护集群的一致性。
会对css 的启动过程、NM ( Node Management）和GM ( Group Management） 介绍。

ocssd启动顺序：

1 . 10g

操作系统被启动， 并调用／etc/inittab文件中与CRS相关的脚本。

hl:35:respawn:/etc/init.d/init.evmd run >/dev/null 2 ＞& 1 </dev/null 
h2:35:respawn:/etc/init.d/init. cssd fatal >/dev/null 2 ＞& 1 </dev/null 
h3:35:respawn:/etc/init.d/init. crsd run >/dev/null 2>&1 </dev/null 

从这些脚本的名称不难看出cssd、crsd和evmd 实际上是同时启动的。但是，它们之间是存在依赖关系的，css 需要首先完成启动，构建集群，之后crsd启动，并将所有管理的资源上线（ Online） ，最后evmd启动。这也是为什么在crsd.log和evmd.log 中经常出现这两个进程。
在集群最初启动时总是会抱怨css 没有准备就绪（Ready）的原因。
2）守护进程ocssd.bin 被启动。守护进程ocssd.bin 的优先级为RT （实时）。
3 ) ocssd.bin 访问OCR ，获得构建集群的基本信息， 例如：集群名称、节点列表、访问远程节点的套接字（ TCP协议）、表决盘（ Voting File）位置、集群参数配置（ miscount ，集群私阿信息、diagwait 等）。
4) occsd.bin向远程节点发送连接信息、和远程节点通过私网建立连接、向表决盘中写入本地节点的信息。
5）该节点加入集群。

2 . 11g r2

1 . 对于 linux 6版本，不再是/etc/inittab启动了，而是/etc/init/oracle-ohas.conf 来启动。

[[email protected]$]more /etc/init/oracle-ohasd.conf 
# Copyright (c) 2001, 2011, Oracle and/or its affiliates. All rights reserved. 
#
# Oracle OHASD startup

start on runlevel [35]
stop  on runlevel [!35]
respawn
exec /etc/init.d/init.ohasd run >/dev/null 2>&1 null

注意：
从11gR2版本开始，init.ohasd成为了集群启动的源头，10g 版本中的3个脚本已经不存在了。
2 . ohasd.bin守护进程被启动。该进程负责启动所有的代理进程，包括oracssdagent_root代理进程。
3 . oracssdagent_root 代理进程启动ocssd.bin守护进程。
4 . ocssd.bin守护进程访问gpnpd.bin ， 以获得构建集群的基本信息，例如：集群名称、集群GID、集群私网信息、VF位置等。同时，从gipcd.bin 获得联系远程节点的连接信息。
5 . 在获得了步骤4）中提到的信息后，ocssd.bin和远程节点通信，并通过访问VF的租借块（Lease Block）获得本地节点的节点编号。
6 . 该节点加入集群。

cssd启动日志分析：

接下来， 通过ocssd. bin守护进程的日志来了解一下基本的过程。首先，说明一下ocssd.bin
的日志结构， 以方便读者更好地理解日志内容。
1 . 10g版本：［组件名］＜时间＞［＜线程编号或者id＞］＞＜消息类型〉：〈线程名称〉：〈
消息内容＞。
2 . 11g版本：＜时间＞： ［组件］［＜线程编号或者id＞］＜线程名称＞： ＜消息内容＞。
下面看一下ocssd.bin 是如何启动的。
1.10g 版本

能看到集群的版本为10.2.0.3

[CSSD]2014-08-18 09:43:46.907 >USER: Or acle Database 10g CSS Release
10.2.0.3.0 Production Copyright 1996, 2004 Oracle. All rights reserved.

这个套接字（Socket File ）主要是在其他进程和ocssd.bin通信时使用

[CSSD]2014-08-18 09:43:46.907 >USER: CSS daemon log for node <* * * *>, number
<* * * *>, in cluster 〈 *  * * *〉
[CSSD]2014-08-18 09:43:46 931 [1] >TRACE: clssscmain: local-only set to false
[clsdmt] Listening to (ADDRESS= (PROTOCOL=ipc) (KEY=* * * ** * CSSD))

集群中存在两个节点

[CSSD]2014-08-18 09:43:46.947 [1] >TRACE: clssnmReadNodeinfo: added node 1
(** * * * *) to cluster
[CSSD]2014-08-18 09:43:46.958 [1] >TRACE: clssnmReadNodeinfo: added node 2
(** *  * * *) to cluster

第三方集群管理软件（ HP ServiceGuard ）正在运行。

[CSSD]2014-08-18 09:43:46.972 [SJ >TRACE: clssnm_skgxninit: initialized skgxn
version (2/0/Hewlett-Packard SKGXN 2.0

开始读取VF上的信息。由于节点2刚刚被启动， 所以VF上节点2的状态仍然是旧的状态
（也就是关闭状态）。

[CSSD]2014-08-18 09:43:52.101 (1] >TRACE: clssnmNMinitial工ze: misscount set to
(600), impending reconfig threshold set to (596000)

miscount 值被设置为600 s。

[CSSD] 2014-08-18 09: 43: 52. 104 [ 1 J >TRACE: clssnmNMini tialize: diskShortTimeout
set to (597000)ms

short 1/0 超时被设置为597 s。

[CSSD]2014-08-18 09:43:52.106 [1] >TRACE: clssnmNMinitialize: diskLongTimeout
set to (597000)ms

long 1/0 超时被设置为597 s。

[CSSD]2014-08-18 09:43:52.116 [1] >TRACE: clssnmDiskStateChange: state from 1
to 2 disk (0 //dev/ **********)

VF被发现。

[CSSD]2014-08-18 09:43:52.116 [6] >TRACE: clssnmvDPT: spawned for disk O (/dev／＊＊＊＊＊＊＊ ）
[CSSD]2014-08-18 09:43:54.134 [6] >TRACE: clssnmDiskStateChange: state from 2
to 4 disk (0//dev ／＊＊＊＊＊＊＊＊＊）
[CSSD]2014-08-18 09:43:54.160 [7] >TRACE: clssnmvKillBlockThread: spawned for
disk O (/dev/**********) initial sleep interval (lOOO)ms
[CSSD]2014-08-18 09:43:54.161 [6] >TRACE: clssnmReadDskHeartbeat: node(2) is
down. rcfg (12) wrtcnt (11466281) LATS (145773296) Disk lastSeqNo (11466281)

尝试通过私网连接远程节点

[CSSD]2014-08-18 09:43:54.162 [l] >TRACE: clssnmFatalinit: fatal mode enabled
[CSSD]2014-08-18 09:43:54.180 [9] >TRACE: clssnmconnect: connecting to node 1,
flags OxOOOl, connector 1

ocssd 通过这个套接字地址（ endpoint ）和远程节点进行网络心跳。这些信息可以在OCR 中找到

[CSSD]2014-08-18 09:43:54.191 [9] >TRACE: clssnmClusterListener: Listening on
(ADDRESS= ( PROTOCOL=tcp) (HOST=<******>) ( PORT＝＊ * * ＊））

创建其他的endpoint

[CSSD]2014-08-18 09:43:54.192 [9] >TRACE: clssnmClusterListener: Probing node
2, con (60000000008cbe90)
[CSSD]2014-08-18 09:43:54.208 (10] >TRACE: clssgmclientlsnr: listening on
(ADDRESS=(PROTOCOL=ipc) (KEY=Oracle_CSS一LclLstnr一＊＊＊＊_l))
(CSSD]2014 08 18 09:43:54.209 (10] >TRACE: clssgmclientlsnr: listening on
(ADDRESS= (PROTOCOL=ipc) (KEY=OCSSD_LL_ ****** _crs))
[CSSD]2014-08-18 09:43:54.212 [13] >TRACE: clssgmPeerListener: Listening on
(ADDRESS= (PROTOCOL=tcp) (DEV=22) (HOST=<******>) (PORT=*****))

集群节点状态被更新

[CSSD]2014-08-18 09:43:54.319 [9] >TRACE: clssnmConnComplete: connected to
node 2 (con 60000000008cbe90), state 3 birth 0, unique 1396483476/1396483476
prevConuni(O)
[CSSD]2014-08-18 09:43:54.720 [15] >TRACE: clssnmSendingThread: Connection
complete
[CSSD]2014-08-18 09:43:54.720 [16] >TRACE: clssnmRcfgMgrThread: Connection
complete
[CSSD]2014-08-18 09:43:54.726 [14] >TRACE: clssnmPollingThread: Connection
complete
[CSSD]2014-08-18 09:43:55.405 [9] >TRACE: clssnmHandleSync: Acknowledging sync:
src[2] srcName[******] seq[13] sync[12]
[CSSD]2014-08-18 09:43:55.405 [9] >TRACE: clssnmHandleSync diskTimeout set to
(597000)ms
[CSSD]2014-08-18 09:43:55.407 [9] >T R A C E: c l s s n m S e ndV o t e i n f o: n o d e(2)
syncSeqNo (12)
[CSSD]2014-08-18 09:43:55.434 [9] >TRACE: clssnmUpdateNodeState: node 0, state
(0 ／〔）） unique (0/0) prevConuni (0) birth (0/0) (old/new)
[CSS0]2014-08-18 09:43:55.435 [9] >TRACE: clssnmDeactivateNode: node O () left
cluster
[CSSD] 2014-08-18 09: 43: 55. 435 [ 9] >TRACE: clssnmUpdateNodeState: node 1, state
(1/2) unique (1408326226/1408326226) prevConuni (0) birth (0/12) (old/new)
[CSS0]2014-08-18 09:43:55.435 [9] >TRACE: clssnmUpdateNodeState: node 2, state
(4/3) unique (1396483476/1396483476) prevConuni (0) birth (0/8) (old/new)
[CSS0]2014-08-18 09:43:55 435 [9] >USER: clssnmHandleUpdate: SYNC(l2) from
node(2) completed
[CSS0]2014-08-18 09:43:55.435 [9] >USER:
IS ACTIVE MEMBER OF CLUSTER
[CSSD]2014-08-18 09:43:55.435 [9] >USER:
IS ACTIVE MEMBER OF CLUSTER

集群重新配置（Reconfiguration）开始。

clssnmHandleUpdate: NODE 1 (*** * * *)
clssnmHandleUpdate: NODE 2 (*** * * *)
[CSSD] 2014-08-18 09: 43: 55. 435 [ 9] >TRACE: clssnmHandleUpdate: diskTimeout set
to (597000)ms
[CSSD]2014 08-18 09:43:55.535 [l] >USER: NMEVENT SUSPEND (00] [00] [00] [00]
[CSS0]2014-08-18 09:43:55.536 [17] >TRACE:
reconfig ( 12)

集群incarnation 为12 。

clssgmReconfigThread: started for
[CSSD]2014-08-18 09:43:55.536 [17] >USER: NMEVENT RECONFIG [00] [00] [00] [06]
[CSSD]2014-08-18 09:43:55.537 [17] >TRACE: clssgmEstablishConnections: 2 nodes
in cluster incarn 12

GM层面的主（MASTER）节点被设置为节点2。

[CSSD ] 2 0 1 4-08-18 09:43:55.54 7 [13] >T R A C E: c l s s g m l n i t i a l R e c v:
(60000000002llfc0) accepted a new connection from node 2 born at 8 active (2,
2), vers (10, 3, 1, 2)
[CSSD]2014-08-18 09:43:55.547 [13] >TRACE: clssgmlnitialRecv: conns done (2/2)
[CSSD]2014-08-18 09:43:55.547 [17] >TRACE: clssgmEstablishMasterNode: MASTER
for 12 is node(2) birth(8)

重新配置结束。

[CSSD]2014-08-18 09:43:55.547 [17] >TRACE: clssgmChangeMasterNode: requeued 0
RPCs
[CSSD]2014-08-18 09:43:55.643 [13] >TRACE: clssgmHandleDBDone (): src/dest
(2/65535) size (72) incarn 12
[CSSD]CLSS-3000: reconfiguration successful, incarnation 12 with 2 nodes
[CSSD]CLSS-3001: local node number 1, master node number 2
[CSSD]2014-08-18 09:43:55.648 [17] >TRACE: clssgmReconfigThread: completed for
reconfig(l2), with status(l)

从上面的日志， 能够看到ocssd 的启动顺序为：
I ) ocssd.bin 进程被启动。
2）通过读取OCR获得节点列表（如果集群中存在其他集群管理软件， 那么， 集群节点列表是从对应的集群管理软件中获得的）。
3）根据OCR中的信息访问表决盘， 并从表决盘中获得各个节点的状态信息。
4 ）通过集群私网连接集群中的其他节点， 并开始集群的重新配置（也就是加入集群）。
5） 集群重新配置成功， 节点加入集群。

11gR2版本

集群版本为l 1.2.0.4。

2014-01-10 16 53:56.959: [CSSD] [l]clssscmain: Starting CSS daemon, ve rsion
11.2.0.4.0, in (clustered) mode with uniqueness value 1389398036

IPMI没有配置。

2014-01-10 16:53:56.986: [CSSD] [l]clssscSetPrivEnv: Can ’ t access local IPM I
device--no device configured or driver missing/incompatible. I PMI support may
be available w工th static IP configuration.

ocssd.bin进程的操作系统进程号（ospid）。

[clsdmt] [3]L istening to (ADDRESS=( PROTOCOL=ipc)( KEY＝＊＊＊＊_CSSD))
2014-01-10 16:53:57.007: [ clsdmt] [3]PID for the Process [26811, connkey 4

ocssd使用的endpoint被创建， 并且开始访问即np profile， 以获得集群的基本信息。

2014-01-10 16:53:57. 011: [C S S D] [5]c l s s g m c l i e n t l s n r: li s t e n i n g o n
c l s c : / /( A D D R E S S =( P R OTO C O L = i p c ) (KE Y= O C S S D _ L L ＿＊＊＊＊＿） (GIPC ID=00000000-00000000-2681))
2014-01-10 16:53:57.011: [G P N P] (l]c l s g p n p_In i t: [a t c l s g p n pO.c:585］ ’ ／
grid/11. 2. 0/grid ’ in effect as GPnP home base.
2014-01-10 16:53:57.011: [G P N P][l]c l s g p n p_ In i t: [a t c l s g p n pO.c:619] G P n P
pid=2681, GPNP comp tracelevel=l, depcomp tracelevel=O, tlsrc:ORA D AEMON
LOGGING LEVELS, apitl:O, complog:1, tstenv:0, devenv:O, envopt:O, flags=3
2014-01-10 16: 53 :57. 024: [GPNP] [1] clsgpnpkwf_initwfloc: [at clsgpnpkwf .c: 399]
Using FS Wallet Location : /gr工d/11.2.0/grid/gpnp ／ ＊＊＊＊＊ ／ wallets/peer/

ocssd.bin访问gpnp profiles失败。由于gip cd、四np d和ocssd都是由ohasd的代理进程同时启
动的， 所以上面的错误可以忽略。

[CLWAL] [l]clsw Initialize: OLR in工tlevel [70000]
2014-01-10 16:53:57.069: [GPNP] [l]clsgpnp_profileCallUrlint: [at clsgpnp.c:2104]
get-profile call to url ”ipc://GPNPD一＊＊＊＊＊” disco”” ［f=O claimed- host:
cname: seq: auth:J
2014-01-10 16:53:57.077: [GPNP] [l]clsgpnpm newWiredMsg: [at clsgpnpm.c:742] Msgreply
has soap fault 10 (Operation returned Retry (error CLSGPNP_CALL_AGA IN))
[uri ” http://www.grid-pnp.org/2005/12/gpnp-errors＃ ” ］

在gpnpd.bin 正常工作后， ocssd.bin 访问gpnp profile 成功。

2014-01-10 16:53:59.094: [GPNP] [l]clsgpnp p r ofil eCallUrlint: [at clsgpnp.
c:2234] Result: (0) CLSGPNP OK. Successful get-profile CALL to remote ” ipc://
GPNPD ******" disco””

ocssd.bin 开始从gpnp profile ( discovery string ）中获取的VF 搜索路径上搜索VF。

2014-01-10 16:53:59.129: [CSSD] [6]clssnmvDDiscThread: using discovery string I
dev/****** for initial discovery

ocssd 成功地发现了3块VF 。

2014-01-10 16:53:59.240: [CSSD] [6]clssnmvDiskVerify: Successful discovery of 3 disks
2014-01-10 16:53:59.240: [CSSD] [6]clssnmCompletelnitVFDiscovery: Completing
initial voting file discovery
2014-01-10 16:53:59.240: [CSSD] [6]clssnmCompleteVFD工scovery: Complet工ng voting
file discovery
2014-01-10 16:53:59.240: [CSSD] [6]clssnmvDiskStateChange:
to pending disk /dev/******
2014-01-10 16:53:59.240: [CSSD] [6]clssnmvDiskStateChange:
to pending disk /dev/******
2014-01-10 16:53:59.240: [CSSD] [6]clssnmvDiskStateChange:
to pending disk /dev/******
2014-01-10 16:53:59.240: [CSSD] [6]clssnmvDiskStateChange:
configured disk /dev/******
2014-01-10 16:53:59.240: [CSSD] [6]clssnmvDiskStateChange:
configured disk /dev/****
2014-01-10 16:53:59.240: [CSSD] [6]clssnmvDiskStateChange:
configured disk /dev/****
state from discovered
state from discovered
state from discovered
state from pending to
state from pending to
state from pending to
2014-01-10 16:53:59.240: [C S S D] [6]c l s s n m C o m p l e t e VFD i s c o v e r y: C o m m i t t e d
configuration for CIN 0:1389306975:0

从VF 中读出了集群的相关配置参数。例如misscount、re boot time、long 1/0 timeout、short 1/0
timeout 。

2014-01-10 16:53:59.240: [CSSD] [6] misscount 30 reboot latency 3
2014-01-10 16:53:59.240: [CSSD] [6] long I/0 timeout 200 short I/0 timeout 27
2014-01-10 16:53:59.240: [CSSD] [6] diagnostic wait O active version
11.2.0.4.0
2014-01-10 16:53:59.240: [CSSD] [6] Listing unique IDs for 3 voting files:
2014-01-10 16:53:59.240: [CSSD] [6] voting file 1: 03135304-al664fl9-bf6a369aa8b23957
2014-01-10 16:53:59.240: [CSSD] [6]
7834f7fa
2014-01-10 16:53:59.240: [CSSD] [6]
b43027f7
voting file 2: 13f2a350-4bl44f05-bf77166bvoting
file 3: 822d8f 4d-0884 4 f8c-bfa4 9615-

开始访问gipc， 获得集群私网的状态

2014-01-10 16:53:59.241: [CSSD] [l]clssnmOpenGIPCEndp: open工ng cluster listener on
gipc ：／／＊＊＊＊＊： nm＿＊* * *

由于集群的私网信息同样在gp叩profile中记录， 所以还要和gpnp通信

2014-01-10 16: 53: 59. 241: [GIPCHGEN] [ 1 J gipchainternalRegister: I n工tializing HA
GIPC
2014-01-10 16:53:59.888: [GPNP] [BJ clsgpnp profileCallUrlint: [at clsgpnp.c:2104]
get-profile call to url ”ipc://GPNPD一****” disco ”” [ f=3 clai1ed- host:
cname: seq: auth:]
2014-01-10 16:53:59.898: [GPNP] [BJ clsgpnp_p rofileCallUrlint: [at clsgpnp.
c:2234] Result: (0) CLSGPNP一OK. Successful get-profile CALL to remote ”ipc://
GPNPD ****” disco””

获得集群私网信息

2014-01-10 16:53:59.898: [CLSINET] [8] Returning NETDATA: 1 interfaces
2014-01-10 16:53:59.898: [CLSINET] [8] # 0 Interface ’****’，ip＝’*
．*．*． *’ ，mac＝’****’，mask＝’****’ ，net＝’ *
．*．*．* ’，use ＝’cluster interconnect’

准备和远程节点通信:

2014-01-10 16:53:59.898: [GIPCHGEN] [8] gipchaNodeAddinterface: adding interface
information for inf 600000000161d3d0 { host ''， haName '*****', local
0000000000000000, ip ’****’， subnet ’****’， mask ’****”， mac’****’， if name ’****’， numRef 0, numFail 0, idxBoot 0, flags Ox1841 )
2014-01-10 16:53:59.898: [GIPCHTHR] [7] gipchaWorkerCreateinterface: created local
interface for node  ****’， ha Name ’****’， inf ’udp: //****：*’
2014-01-10 16:53:59.899: [GIPCHTHR] [7] gipchaWorkerCreateinterface: created
local bootstrap multicast interface for node ’****’， ha Name ’****’， inf
’mcast://****:*／****’
2014-01-10 16:53 59.899 [GIPCHTHR] [7] gipchaWorkerCreateinterface: created local
bootstrap multicast interface for node ＇****’， haName ’****’， inf ’mcast://230.0 1.0：*’
2014-01-10 16:53:59 899: [GIPCHTHR] [7] gipchaWorkerCreateinterface: c reated
local bootstrap broadcast interface for node ’****’， haName ’****’， inf ’udp://****:*’
2014-01-10 16:53:59.899: [CSSD] [1]clssnm Open GIPC Endp: listeningongipcha://****：nm2＿****

节点编号租借（ Lease ）完成:

2014-01-10 16:54:15.162: [CSSD] [l]clssnmlgetslot:lease ac quisition for node
****／slot 2 completed in 15158 msecs

从上面的日志里能够看到ocssd 的启动顺序如下：
1 ) ocssd.bin 守护进程被启动。
2 ) ocssd.bin和gpnpd 通信， 读取gpnp profile中VF 的discovery string， 并在对应的路径中扫描。
3）找到VF之后，ocssd.bin就能够获得集群的一些基本配置参数，例如： misscount、reboot t ime 、long VO timeout 、short VO timeout。
4 ) ocssd.bin继续和即npd通信，获得集群的私网信息，以便和集群中的其他节点通信。
5 ) ocssd.bin通过gipcd进程获得本地节点和远程节点的具体私网连接信息。
6） 节点间的私网连接被建立，集群重新配置开始。
7） 集群重新配置结束，集群成员列表被更新。

集群心跳机制

在理解了ocssd.bin的启动过程后，接下来看一下Oracle集群如何维护集群的一致性。所谓集群的一致性就是指集群中每个成员能够了解其他成员的状态，而且每个成员获得的集群中其他节点的状态和集群中节点成员列表信息（ Node Membership）是一致的，这也是集群最基本的要求。Oracle集群管理软件是通过以下一些机制来实现集群一致性的：
1 . 确定节点和节点间的连通性（心跳），以便节点之间能够了解彼此的状态。
2：用一（几）个共享的位置来保存节点之间的连通性信息，以便在集群需要进行重新配置（节点数量发生改变）时，能够做出正确的决定并记录集群最新的状态。
3：本地节点自我监控机制，以便当本地节点出现问题时能够主动离开集群，避免不一致的产生。
对于Oracle集群， 上面的三种机制主要是通过三种心跳来实现的，而这三种心跳的机制可以用下图概括。

网络心跳

首先是确定集群节点之间的连通性，以便节点之间能够了解彼此的状态，而对于Oracle集群，这是通过节点间的网络心跳（Network HeartBeat，简称NHB）来实现的。对于Oracle集群，ocssd.bin守护进程每秒钟会向集群的其他节点发送网络心跳（当然是通过集群的私网）。
例如：一个4节点的集群，集群的每一个节点每一秒钟都会向集群中的其他三个节点发送网络心跳信息，这也意味着每个节点每一秒钟也会收到集群中其他节点发送的网络心跳。既然节点间互相发送网络心跳，就需要有一种机制来确定节点之间的连通性，以及当网络心跳出现问题处理机制：
1 . 发送线程（ clssnmSendingThread）：该线程每秒钟向集群中所有的节点发送网络心跳信息。
2 . 分析线程（ clssnmPollingThread）：该线程会分析收到的网络心跳信息并进行处理，如果发现集群中的某一个（些）节点持续丢失网络心跳（超过misscount设置），就会通知集群进行重新配置。
3 . 集群重新配置线程（ clssnmRcfgMgrThread）：当clssnmPollingThread 发现集群需要进行重新配置时，该进程负责对集群进行重新配置。
4 . 派遣线程（ clssnmClusterListener）：该线程负责接收从远程节点传递过来的信息，之后，根据信息的种类发送给相关的线程进行处理。
注意：
可以使用pstack

磁盘心跳

第二种心跳称为磁盘心跳（Disk HeartBeat, DHB）。磁盘心跳的主要目的就是当集群发生脑裂时帮助制定脑裂的解决方案。Oracle集群的每一个节点每秒钟都会向集群的所有表决盘注册本地节点的磁盘心跳信息（也就是说，所有VF中的信息是相同的），同时也会将自己能够联系到的集群中其他节点的信息，或者说本地节点认为集群中的成员列表信息写入到表决盘中。
一旦发生脑裂，css 的重新配置线程就可以通过表决盘中的信息了解集群中节点之间的连通性，从而决定集群会分裂成几个子集群，以及每个子集群包含的节点情况和每个节点的状态。
磁盘心跳主要通过以下的ocssd.b in 线程实现：
1 . 磁盘心跳线程（clssnmvDiskP ingThread）： 该线程负责向集群的表决盘中发送磁盘心跳信息。同时，该线程也负责读取表决盘中的kill block信息，以确定本地节点是否需要重新启动。
2 . 磁盘心跳监控线程（clssnmvDiskPingMonitorThread）：该线程用于确定磁盘心跳线程是否能够正确地发送磁盘心跳，并且能够正确地读取killblock中的信息。
3 . killblock线程（clssnmvKillBlockThread）：该线程负责监控VF的killblock信息。
Oracle规定，如果某个节点在short 1/0 timeout时间内一直无法访问某一个VF的话，对应的VF会被离线掉，而当大多数的VF ( [VF数量／2]+1 ）被离线掉时，该节点会被重新启动。因此， 配置奇数个VF要更好一些， 这也是Oracle建议的配置方法。
Oracle制定这种规则的目的就是为了确保在出现需要通过VF中的信息决定节点去留的情况下， 至少有一个VF能被集群所有节点访问到。例如：一个两节点的集群（nod1, node2)配置了3块VF (VF1, VF2和VF3 ), node1无法访问VF1, node2无法发访问VF2，这意味着两个节点仍然同时能够访问VF3。而当集群中某一个节点无法访问大多数VF 时，就意味着当需要通过VF 中的信息决定节点去留的时候，可能会出现没有任何一个VF可被集群中的全部节点访问到的情况， 这也意味着无法决定哪些节点应该离开集群， 哪些节点应该被保留。
例如： 一个两节点的集群（node 1, node2 ）配置了3块VF (VF1, VF2和VF3 ), node1无法访问VF1和VF2, node2无法发访问VF3，这意味着当出现网络问题时，集群无法通过VF的信息获得一致的所有节点的状态， 也就无法完成集群重新配置。

本地心跳

集群中的第三种心跳称为本地心跳（ Local HeartBeat， 简称LHB），这种心跳机制是在11gR2版本中正式被引人的。这种心跳的作用是监控ocssd.bin进程以及本地节点的状态。在版本10g中，Oracle通过clsomon和oprocd来实现 。
守护进程 oclsomonb. in监控ocssd.bin进程的状态，oprocd.bin进程监控本地节点是否出现了性能问题例如：hang 住）。从11 . 2.0.1版本开始，新的集群资源cssdagent和cssdmonitor被引人，它们的功能就是监控本地节点的ocssd.bin进程状态和本地节点的状态（是否hang住）。
对于ocssd.bin进程的监控，GI是通过本地心跳来实现的，Oracle会在每一秒钟，在发送网络心跳的同时（ 同一个线程）向cssdagent和cssd monitor发送本地ocssd.bin进程的状态（也就是本地心跳）如果本地心跳没有问题，cssdagent就认为ocssd.bin进程正常。反之，如果ocssd.bin进程持续丢失本地心跳（到达miss count的时间）, ocssdagent就会认为本地节点的ocssd.bin进程出现了问题，并重启该节点。
oprocd进程同样也被整合到了cssdagent和cssdmonitor 中， 变成了其中的一个线程，而且监控节点是否hang住的方式也发生了改变，也就是说，对于版本11 .2.0.1及以上的集群，修改节点的时间基本上不会再导致节点直接重启了，但是， 作者仍然不建议在集群运行时大幅度（ 修改的幅度不要超过miss count） 地修改系统时间 。
对于10g版本， 实际上并没有明确本地心跳的概念，但是实际上著名的oprocd.bin进程从某种意义上来说承担了本地心跳的工作， 接下来就对oprocd进行简单介绍。
1 . 这个进程存在于10.2.0.4＋和11gR1版本中，而且没有安装在第三方集群管理软件的系统上。由于绝大部分的第三方集群管理软件都具有类似于oprocd的功能，Oracle也就没有必要再做重复的工作了。
2 . 这个进程的主要目的是监控本地节点是否出现了hang住的情况，所以它由root用户启动，而且优先级级别为实时。
3 . 该进程每秒钟都会被调用一次，而且设置了500 ms的margin time。换句话说，Oracle在默认情况下要求oprocd进程在1.5 s之内被返回。而oprocd进程所做的事情只是返回一下系统时间。如果一个由root 用户启动， 而且优先级为实时的进程在1.5s 钟之内无法返回系统时间的话， Oracle 就会认为本地节点有严重的问题， 并重启该节点。也正是因为oprocd 进程会返回系统时间并进行相应的验证， Oracle 一直推荐客户使用NTP 的slew 方式来微调系统时间， 另外， 在修改系统时间（理论上来讲大于0.5s ）之前， 需要首先停止该节点上的CRS 软件。
修改CRS 参数diagwait ( Oracle 只支持把这个参数改成13， 其他的值是不支持的）的作用时姜oprocd的margin time修改为10s。这个时间可以通过如下公式计算出来：
margin time=diagwait(13)-reboot time(3)=10s
修改diagwait 参数的另外一个作用就是在节点重启之前CRS 有更多的时间把相关的日志写到磁盘上。以下是修改diagwait 参数的步骤。
步骤1 ：使用root 用户停止集群中的所有节点。

tcrsctl stop crs
t/bin/oprocd stop

步骤2 ：验证CRS 是否被停止。

fps -ef legrep ”crsd.binlocssd.binlevmd.binloprocd”

上面的命令应该不返回任何进程， 而且要说明的是， 如果在不停止CRS 的情况下修改ait，很可能会导致OCR corrupt， 有太多这样的案例了。
步骤3：使用root 用户在集群的一个节点上修改diagwait 参数。

icrsctl set css diagwait 13 -force

步骤4：验证修改是否成功。

icrsctl get css diagwait

步骤5 ：使用root 用户重启所有节点的CRS。

tcrsctl start crs
tcrsctl check crs

注意：

如果因为特殊原因需要恢复diagwait 参数的话， 可以使用下面的命令。
#crsctl unset css diagwait -force
当然， 前提条件也是集群中所有节点的CRS 要被关闭。

另外，在10g版本中，还存在一个oclsomon.bin 进程，这个进程的作用是监控ocssd.bin 进程的健康性。