健忘、脑裂和clusterware进程的描述

1、ocr

首先，先来看下ocr的官方说明：

the OCR is a file that manages cluster and Oracle Real Application Clusters (Oracle RAC) database configuration information.

The OCR contains information about the cluster node list, instance-to-node mapping information, and information

OCR的备份：

Oracle每4个小时对其做一次备份，并且保留最后的3个备份。

可以通过ocrconfig –showbackup来查看备份所在的文件和目录。

“健忘“问题是由于每个节点都有配置信息的拷贝，修改节点的配置信息不同步引起的。要想解决“健忘”问题，最简单的办法就是整个集群只有一份配置，各节点共用这份配置，无论在哪个节点修改配置，都是修改相同的配置文件，这样就保证修改不会丢失。Oracle采用的方法就是把这个配置文件放在共享存储上，这个文件就是OCR Disk。

Ocr维护方面的文档：

Metalink：ID 428681.1

OCR、Vote disk Maintenance Operations(ADD、REMOVE、REPLACE、MOVE), including moving from RAW Devices to Block Devices

Metalink：ID 399482.1

How to Recreate OCR、Voting Disk Accidentally Deleted

2、Voting Disk

Voting Disk这个文件主要用于记录节点中成员状态，在出现“脑裂”时，仲裁哪个Partition获得集群的控制权，而其他Partition必须从集群中剔除。

在Clusterware安装以后，就可以通过下面命令来查看Voting Disk的位置。

[oracle@rac1 ~]$ crsctl query css votedisk

 0.    0   /dev/raw/raw2

 1.    0   /dev/raw/raw8

3、Clusterware后台进程

Clusterware由若干个进程组成，其中最重要的3个是CRSD. CSSD和EVMD。在安装Clusterware的最后阶段，会要求在每个节点执行root.sh脚本，这个脚本会在//etc/inittab文件的最后添加如下3行。这样以后每次系统启动时，Clusterwaxe也会自动启动，其中EVMD和CRSD两个进程如果出现异常，则系统会自动重启这两个进程，但是如果CSSD进程异常，系统会立即重启。

h1:35:respawn:/etc/init.d/init.evmd run >/dev/null 2>&1

h2:35:respawn:/etc/init.d/init.cssd fatal >/dev/null 2>&1

h3:35:respawn:/etc/init.d/init.crsd run >/dev/null 2>&1

3.1、OCSSD

OCSSD这个进程是Clusterware最关键的进程，如果这个进程出现异常，会导致系统重启。这个进程提供CSS (Cluster Synchronization Serviee)服务。CSS服务通过多种心跳机制，实时监控集群健康状态，提供脑裂保护等基础集群服务功能。

css服务有两种心跳机制：一种是通过私有网络的Network Heartbeat，另一种是通过Voting Disk的Disk Heartbeat。

这两个心跳都有最大时延，对于Disk Heartbeat，这个时延叫作IOT (I/O Timeout)；对于Network Heartbeat，这个时延叫作MC (Miscount)。两个参数都是以秒为单位，缺省时IOT大于MC。在缺省情况下，这两个参数是Oracle自动判定的，并且不建议调整。

可以通过下面命令查看这两个参数设置：

[oracle@rac1 ~]$ crsctl get css disktimeout

200

[oracle@rac1 ~]$ crsctl get css misscount

60

3.2、CRSD

CRSD是实现“高可用性(HA)”的主要进程，它所提供的服务叫作CRS (Cluster Ready Service)服务。

上文己经提到，Oracle Clusterware是位于集群层的组件，它要为应用层资源(CRS Resource)提供“高可用性服务”。因此，Oracle Clusterwaxe必须要监控这些资源，并在这些资源运行异常时进行干预，包括关闭、重启进程或者转移服务。而CRSD进程提供的就是这些服务。

所有需要“高可用性”的组件，都会在安装配置的时候，以CRS Resource的形式登记到OCR中，而CRSD进程就根据OCR中的内容，决定监控那些进程、如何监控、出现问题时如何解决。也就是说CRSD进程负责监控CRS Resource的运行状态，并要启动、停止、监控、Failover这些资源。默认情况下，CRS会自动尝试重启资源5次，如果还是失败，则放弃尝试。

CRS Resource包括GSD (Global Service Daemon ), ONS (Oracle Nofitication Service Daemon )、VIP、Database. Instance和Service。这些资源被分成两类：GSD, ONS, VIP和Listener属于Noteapps类；而Database, Instance和Service属于Database-Related Resource类。这种分类方式也很好理解，Nodeapps就是说每个节点只需要一个就够了，比如每个节点只有一个Listener而Database-Related是说这些资源是和数据库相关的，不受节点的限制，比如一个节点可以有多个实例、每个实例可以有多个Service。

GSD, ONS. VIP这3种服务是在安装Oracle Clusterware的最后，执行VIPCA时创建并登记到OCR中的(参见第1章的图1-56到图1-61)；而Database、Listener、Instance和Service是在各自的配置过程中自动或手动登记到OCR中的。

3.2.1、GSD

Oracle 9i的官方文档上是这么介绍这个服务的：（10g的官方文档上没有这个的描述，真恶心）

Global Services Daemon (GSD)

The Global Services Daemon (GSD) records information such as connection requests from SRVCTL and stores these records the gsdaemon_node_name.log file in the $ORACLE_HOME/srvm/log directory. Clients of the GSD, such as SRVCTL, the DBCA, and Oracle Enterprise Manager, interact with the GSD to perform. various manageability operations on the nodes in your cluster.

Clients of the Global Services Daemon (GSD), such as SRVCTL, the DBCA, and Oracle Enterprise Manager, interact with the GSD to perform. various manageability operations on the nodes in your cluster database. You must start the GSD on all the nodes in your Real Applications Clusters database so that the manageability features and tools operate properly.

For example, if you start an instance using Oracle Enterprise Manager, then the Intelligent Agent launches a script. that contains SRVCTL commands. The GSD executes these commands which correspond to the requested operation.

GSD与rac的管理工具dbca srvctl oem进行交互，用来完成实例的启动关闭等管理任务。为了保证这些管理工具运行正常必须在所有的节点上先start gsd,并且一个GSD进程支持在一个节点的多个rac.gsd进程位于$ORACLE_HOME/bin目录下，其log文件为$ORACLE_HOME/srvm/log/gsdaemon.log

例如：假设使用oem工具来启动一个实例，oem把该任务传递给相应的智能引擎，该智能引擎生成一个包含SRVCTL命令的脚本文件，GSD进程读取该脚本文件并且执行该脚本，最后GSD把执行结果返回给智能引擎,近而智能引擎返回给OEM.

又例如，假设使用srvctl工具关闭所有的实例，GSD进程接受来自SRVCTL工具发出的请求，并在本地节点上执行该请求，然后把执行结果返回给SRVCTL会话。

You can use gsdctl commands to start, stop, and obtain the status of the GSD service on any platform. The options for gsdctl are:

   * gsdctl start -- To start the GSD service

   * gsdctl stop -- To stop the GSD service

   * gsdctl stat -- To obtain the status of the GSD service

Gsd是从oracle 9i延续过来的，从我目前的测试来看，gsd关掉对srvctl没有影响，但对OEM的影响未知，而且，就算开着也不见得有写日志到$ORACLE_HOME/srvm/log/gsdaemon.log中，还有，gsdctl的命令似乎过时了，不管用。

Metalink：ID156561.1

What is the Global Services Daemon (GSD) for Oracle9i Real Application Clusters?

3.2.2、ONS

官方文档上是这样描述的：

A publish and subscribe service for communicating information about all FAN events.

对于 负责 所有的fan events之间的通信。

这是我从metalink上摘抄下来的：

The purpose of the ons daemon

The Oracle Notification Service daemon is an daemon started by the Oracle Clusterware as part of the nodeapps. There is one ons daemon started per clustered node.

The Oracle Notification Service daemon is receiving a subset of published clusterware events via the local evmd and racgimon clusterware daemons and forward those events to application subscribers and to the local listeners, this in order to facilitate:

a. the FAN or Fast Application Notification feature or allowing applications to respond to database state changes. Fast Connection Failover (FCF) is the client mechanism which uses the FAN feature to achieve it. FCF clients/subscribers are JDBC, OCI, and ODP.NET in 10gR2.

b. the 10gR2 Load Balancing Advisory (the RLB feature) or the feature that permit load balancing accross different rac nodes dependent of the load on the different nodes.The rdbms MMON is creating an advisory for distribution of work every 30 seconds and forward it via racgimon and ONS to listeners and applications.

通过上面的黑体字，似乎ons另外一个重要的作用是application failover。

ons相关的应用切换 是要 应用开发时考虑到用ons的包才有用的，国内的话99.9999%没有用

metalink：ID 759895.1

The ONS Daemon Explained In Oracle RAC / Oracle Clusterware Environment

从这篇文章中，还是能学习到一些知识的：

下面的命令能看到ons（包括gsd和vip）的执行脚本

crs_stat -p ora..ons | grep ACTION_SCRIPT

ACTION_SCRIPT=/u01/app/oracle/product/crs/bin/racgwrap

下面的命令能看到ons的执行权限

crs_getperm ora.hostname.ons

Name: ora.hostname.ons

owner:oracle:rwx,pgrp:dba:r-x,other::r--,

ons的 配置文件位于

$ORA_CRS_HOME/opmn/conf/ons.config

3.3、EVMD

EVMD这个进程负责发布CRS产生的各种事件(Event )。这些Event可以通过两种方式发布给客户—ONS和Callout Script。用户可以自定义回调脚本，放在特定的目录下，这样当有某些事件发生时，EVMD会自动扫描该目录，并调用用户的脚本，这种调用是通过racgevt进程来完成的。

3.4、RACGIMON

RACGIMON这个进程负责检查数据库健康状态，负责Service的启动、停止、故障转移(Failover)。这个进程会建立到数据库的持久连接，定期检查SGA中的特定信息，该信息由PMON进程定时更新。

3.5、OPROCD

OPROCD这个进程也叫作Process Monitor Daemon。如果在非Lines平台上，并且没有使用第三方的集群软件时，会看到这个进程，这个进程用来检测节点的Processor Hang (CPU挂起)，如果调度时间超过1.5秒，就会认为CPU工作异常，会重启节点，也就是说这个进程提供的是“I/O隔离”功能，从其在Windows平台上的服务名“OraFenceService”也能体会到它的功能。而在Linux平台上，是利用的hangcheck-timer模块来实现“IO隔离”功能的。

CRS一些官方的文档：

Metalink：ID259301.1

CRS and 10g/11.1 Real Application Clusters --也介绍了crs底下的各个进程

Metalink：ID259301.1

Troubleshooting 10g and 11.1 Clusterware Reboots

3.6、和单实例相比，后台进程的变化

3.6.1、LMSn

这个进程是Cache Fusion的主要进程，负责数据块在实例间的传递，对应的服务叫作GCS (Global Cache Service)，这个进程的名称来源于Lock Manager Service。从Oracle 9开始，Oracle对这个服务重新命名成Global Cache Service服务(GCS )，但是进程名字却没有调整。

这种进程的数量通过参数GCS_SERVER_PROCESSES来控制，缺省值是2个，取值范围为0-9。

the number of lms process to start depends on CPU, the default value is Max(CPU_COUNT/4,2),there is hidden parameter to change it . _lm _lms . This is FYI only , :-) , since I don't know how successful it would be if you test with these parameters change.

sys> select ksppinm, ksppdesc from x$ksppi where ksppinm like '%lms%';

KSPPINM                       KSPPDESC

------------------------------ ------------------------------------------------------------

_lm_lms                       number of background global cache server processes to start

_lm_dynamic_lms               dynamic lms invocation

_lm_max_lms                   max. number of background global cache server processes

_lm_min_lms                   min. number of background global cache server processes

_lm_activate_lms_threshold    threshold value to activate an additional lms

_lm_lms_waittime              default wait time for lms

Metalink：ID181489.1

Tuning Inter-Instance Performance in RAC and OPS --it so good!

3.6.2、LMD

这个进程提供负责的是Global Enqueue Service (GES )。具体来说，这个进程负责在多个实例之间协调对数据块的访问顺序，保证数据的一致性访问。它和前面的LMSn进程的GCS服务还有GRD共同构成RAC最核心的功能Cache Fusion。

3.6.3、LCK

这个进程负责Non-Cache Fusion资源的同步访问，每个实例有一个LCK进程。

3.6.4、LMON

各个实例的LMON进程进行会定期通信，以检查集群中各节点的健康状态，当某个节点出现故障时，负责集群重构、GRD恢复等操作，它提供的服务叫作Cluster Group Services(CGS)，这个进程的更多细节参见4.5.2小节。

前面的章节已经介绍了集群环境中“脑裂”的危害和解决办法。但是，在关键应用中只靠集群软件的健康监测是不够的。比如某个节点的Instance异常挂起，导致其不能对外提供服务。如果单从Network, OS, ClusterWare几个层面看，可能检测不到这种异常的。因此，脱离了应用程序的集群状态检测是没有意义的，数据库必须有自我监控的机制。

Oracle RAC的LMON进程，被赋予了自检功能，这个功能就是LMON提供的CGS服务，总的来说，这个服务以下几个要点。

(1) LMON提供了节点监控(Node Montor)功能:这个功能是用来记录应用层各个节点的健康状态，节点的健康状态是通过一个保存在GRD中的位图< Bitmap)来记录的，每个节点一位，0代表着节点关闭，1代表节点正常运行。各个节点间的LMON会相互通信，确认这个位图的一致性。

(2)节点上的LMON进程间会定期进行通信，这个通信可以通过CM层完成，也可以不通过CM层，直接通过网络层完成。

(3) LMON可以和下层的ClusterWare合作也可以单独工作。当LMON检测到实例级别的“.脑裂”时，LMON会先通知下层的Clusterware，期待借助于Clusterware解决“脑裂”问题。但是RAC并不假设Clusterware肯定能够解决问题，因此，LMON进程不会无尽等待Clusxerware层的处理结果。如果发生等待超时，LMON进程会自动触发IMR (Instance Membership Recovery也叫Instance Membership Reconfiguration )。LMQN进程提供的IMR功能可以看作是Oracle在数据库层提供的“脑裂”、”I0隔离”机制。

(4) LMON主要也是借助两种心跳机制来完成健康监测。

节点间的网络心跳(Network Heartbeat)：可以想象成节点间定时发送Ping包检测节点的状态;如果能够在规定时间内收到相应，就认为对方状态正常。

通过控制文件的磁盘心跳(Controlfile Heartbeat )：每个节点的CKPT进程每个3秒钟更新一次控制文件一个数据块，这个数据块叫作Checkpoint Progress Record；控制文件是共享的，因此实例间可以相互检查对方是否及时更新以判断状态。

从视图中可以看到这个动作：

SELECT inst_id,cphbt FROM x$kcccp;

3.6.5、DIAG

DIAG进程监控实例的健康状态，并在实例出现运行错误时收集诊断数据记录到Alert.log日志中。

3.6.6、GSD

这个进程负责从客户端工具，比如srvctl接收用户命令，为用户提供管理接口。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/24531354/viewspace-732719/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/24531354/viewspace-732719/