1

2

3

4

5

6

7

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

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

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

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

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

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

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

1

2

3

4

5

基本上我们可以把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脚本。

1

2

3

4

5

6

7

8

9

ohasd进程启动四个代理进程，分别是:

(1)orarootagent

负责管理所有root用户拥有的ohasd资源的代理进程。

(2)cssdagent

CSSD的代理进程(由它来生成CSSD进程)

(3)oraagent

负责管理所有oracle用户拥有的ohasd资源的代理进程。

(4)cssdmonitor

同cssdagent一起监控CSSD的节点健康状况。

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

(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进程监控进程。

1

2

3

CRSD启动如下2个进程：

oraagent  负责管理所有oracle用户的所有crsd资源的代理进程。

orarootagent 负责管理所有root用户的所有crsd资源的代理进程。

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

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解析)的资源。

1

2

3

4

5

6

7

8

9

10

(1) Network Resource

监控公共网络资源。

(2) SCAN VIP

SCAN VIP资源。

(3) NODE VIP

每个节点一个的VIP资源。

(4) ACFS Registry

加载ACFS资源。

(5) GNS VIP

GNS VIP资源。

1

2

3

4

5

6

7

8

9

10

11

12

$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 <==通过这个脚本获得更全面的诊断日志。

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

(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)  消息事件队列，Oracle 就是放进队列，广播出去

一个后台进程，发布由Clusterware创建的事件，是CRS和CSS通信的桥梁。

对应进程evmd.bin。----- 集群资源要切换， 节点不能通讯等等，不是直接联系，可能需要汇总判断吧

1

2

3

4

5

6

7

8

9

10

(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。

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

(1)LMON 全局队列服务监控器   以前是锁，后面用队列管理latch lock mutex

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； 所以才有2 way /3 way

当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日志文件，写入一些重要告警信息。

1

2

3

4

GRD（Global Resource Directory）

GCS全局缓存服务(Global Enqueue Service)   2-3 写反了吧

GES全局队列服务(Global Cache Service)

GRD、GCS、GES是Cache Fusion结构的核心。

1

2

3

4

5

6

7

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协调资源和管理的来源。

1

2

3

4

5

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负责实例间数据块的传递工作。

1

2

3

4

5

6

http://www.itpub.net/thread-1758255-1-1.html

GRD（Global Resource Service）

其实就是一张哈希表，也就是一个全局资源目录。用来记录各个RAC节点资源的使用情况。

每个实例掌握着某一组资源，所有实例加起来构成了GRD。

集群组中的资源根据其权重平等的分布在节点之间。

GRD由两个服务管理，这两个服务分布为:全局缓存服务(GES)和全局队列服务(GES)。

1

2

3

4

5

GCS（Global Cache Service）

对应的进程是LMSn ，负责数据块在实例间的传递。

GES（Global Enqueue Service）

对应的进程是LMD和LMON，负责在多个实例之间协调对数据块的访问顺序，也就是管理队列资源，保证数据的一致性访问。

LMD是实现队列资源的释放和分配的，LMON主要监控节点的健康。

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

其他：

GES全局队列服务(Global Enqueue Service)：

对应的进程是LMD和LMON，

主要负责维护字典缓存和库缓存内的一致性。

字典缓存是实例的内所存储的对数据字典信息的缓存，用于高速访问。

由于该字典信息存储在内存中，因而在某个节点上对字典进行的修改（如DDL)必须立即被传播至所有节点上的字典缓存。

GES负责处理上述情况，并消除实例间出现的差异。

出于同样的原因，为了分析影响这些对象的SQL语句，数据库内对象上的库缓存锁会被去掉。

这些锁必须在实例间进行维护，而全局队列服务必须确保请求访问相同对象的多个实例间不会出现死锁。

LMON、LCK和LMD 进程联合工作来实现全局队列服务的功能。

GES是除了数据块本身的维护和管理（由GCS完成）之外，在RAC环境中调节节点间其他资源的重要服务。

GCS全局缓存服务(Global Cache Service):

要和Cache Fusion结合在一起来理解，全局缓存要涉及到数据块。

全局缓存服务负责维护该全局缓冲存储区内的缓存一致性，确保一个实例在任何时刻想修改一个数据块时，都可获得一个全局锁资源，从而避免另一个实例同时修改该块的可能性。

进行修改的实例将拥有块的当前版本（包括已提交的和未提交的事物）以及块的前象(post image)。 post是后吧，sga是不是也一样，如果同时拥有，那前镜像什么时候可以flush，有了这个前镜像，一致性读的时候就不需要再Undo，这样效率更高，就是要占两份资源。

如果另一个实例也请求该块，那么全局缓存服务要负责跟踪拥有该块的实例、拥有块的版本是什么，以及块处于何种模式。LMS 进程是全局缓存服务的关键组成部分。

1

2

3

4

5

6

7

在所有的高可用环境中几乎都有心跳的存在。

心跳的主要目的是为了检测集群中节点的状态，如果检测失败，管理软件会认为某个节点存在故障，并根据一定的算法来做出适当的处理。

避免对环境的破坏，即高可用性软件的自动修复能力。

在RAC中，不同层次结构有不同的机制来检测RAC的健康情况。

在集群层，Clusterware软件由网络心跳和磁盘心跳来检测集群节点的健康状况。

如果Clusterware认为节点存在故障，那么它会根据一定算法来隔离故障节点，以避免对数据造成破坏。

通过故障的处理手段在一定程度上也能够恢复故障节点到正常状态。

1

2

3

4

5

6

7

8

9

通过私有网络来检测节点的状态。

如果由于私有网络硬件或软件的故障，导致集群节点间的私有网络在一定时间内无法进行正常通信，这种现象被称为脑裂。

出现脑裂时，Clusterware需要采取措施将不正确的集群节点隔离出去，避免对存储中的数据造成损坏。

私有网络出现不能正常通信有一个超时时间，这个时间称为misscount。通过crsctl工具可以查询。

crsctl get css misscount

10.2.0.4以后网络心跳超时misscount为60s,11.2以后网络心跳超时misscount为30s。

如果超过30秒，Oracle认为节点间发生了脑裂，并会在Clusterware的日志中会有相应心跳丢失的记录。

注意：

在实施两节点的集群的时候，一定不能采用节点间直连的方式来组建心跳网络，这样会导致心跳大量丢失，不利于Clusterware的稳定运行。  网口可以多路径，可以和交换机通信知道我这边好的

1

2

3

4

5

6

7

8

9

当出现脑裂的时候，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隔离的目的。

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

通过共享磁盘来检测节点的状态。

在Clusterware磁盘组文件中，表决磁盘就是用于检测Clusterware磁盘心跳的共享磁盘文件。

每个节点需要周期性的写磁盘心跳，通常每秒一次。

每个节点周期性的读取心跳数据，通常每秒读一次。

当数据的读取出现问题时，通常引起脑裂。

和磁盘心跳有关的参数：

(1)disktimeout参数

crsctl get css disktimout

默认200秒，如果ocssd进程对表决磁盘检测时间超过disktimeout设定值，Oracle就会认为该表决磁盘文件脱机，并在Clusterware告警日志中生成表决磁盘脱机记录。

如果节点表决磁盘脱机的个数小于在线表决磁盘的个数，这个节点能够幸存；

当脱机表决磁盘的个数大于等于在线表决磁盘的个数时，Clusterware会认为节点的磁盘心跳出现问题，节点会将该节点逐出集群，执行修复过程。

(2)reboottime参数

该参数表示节点被提出后，节点开始重启允许的最大时间。

crsctl get css reboottime

默认3秒。

1

2

3

4

5

6

7

8

9

这种心跳机制是在11gR2版本中被引入的。

作用是监控ocssd.bin进程以及本地节点的状态。  不是cssd监控本地啊 本地监控cssd， cssd监控另两

在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进程的状态（本地心跳）。  oracle 发出的，不是ocssd发出的，ocssd这些只是接收，看看有没有异常

如果本地心跳没有问题，cssdagent就认为ocssd.bin进程正常。

如果ocssd.bin进程持续丢失本地心跳（到达misscount的时间）ocssdagent就会认为本地节点的ocssd.bin进程出现了问题，并重启该节点。

1

2

3

4

5

6

7

8

9

10

注意：

网络心跳和磁盘心跳是由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后再实施。

1

2

3

4

5

(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

1

2

3

4

5

(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

1

2

3

4

(3) 面向争用的等待

1 gc current block busy

2 gc cr block busy

3 gc buffer busy acquire/release

1

2

3

4

5

(4) 面向负载的等待

1 gc current block congested

2 gc cr block congested

3 gc current grant congested

4 gc cr grant congested