RAC进程与SCN(原创)

LMON:GLOBAL ENQUEUE SERVICE MONITOR 
LMON 主要监测群集内的全局队列和全局资源，管理实例和处理异常并对相应的群集队列(enqueues是用来进行串行化行更新的共享的内存结构)进行恢复操作。 监控全局锁定（global enqueues）及其资源，并提供global enqueues资源的恢复操作。
各个实例的LMON进程会定期通信，以检查集群中各个节点的健康状况，当某个节点出现故障时，负责集群重构、GRD恢复等操作，它提供的服务叫做Cluster Group Services（CGS）
集 群中，健康检测是非常重要的，如果健康检测出现问题，那么可能出现”脑裂问题“。但是在关键应用中只靠集群软件的健康软件的健康监测是不够的。比如某个节 点Instance异常挂起，导致其不能对我提供服务。如果单从Network、OS、ClusterWare几个层面看，可能检测不到这种异常。因此， 脱离了应用程序的集群检测是没有意义的，数据库必须有自我监测的机制，而LMON被赋予了自检功能，这个功能是LMON提供的CGS服务，总的来说，这个 服务有以下几个要点。
1、LMON提供了节点监控（Node Monitor）功能，这个功能是用来记录应用层各个节点的健康状况，节点的健康状况是通过一个保存在GRD中的位图（Bitmap）来记录的，每个节点 一位，0代表着关闭，1代表着正常运行。各个节点间的LMON会相互通信，确认这个位图的一致性。
2、节点上的LMON进程会定期进行通信，这个通信可以通过CM层完成，也可以不通过CM层，直接通过网络层。
3、 LMON可以和下层的Clusterware合作也可以单独工作，当LMON检测到实例级别的脑裂时（实例认为对方已经down掉，自己还健 在），LMON会先通知下层的Clusterware，期待借助Clusterware解决脑裂问题。但是RAC并不假设Clusterware肯定能够 解决问题，因此LMON进程不会无尽等待Clusterware层的处理结果。如果发生等待超时，LMON进程会自动触发IMR（Instance Membership Recovery）也叫做Instance Membership Reconfiguration。LMON提供的IMR看作是Oracle在数据库层提供的”脑裂“、”IO隔离“机制。
4、LMON主要也是借助两种心跳机制来完成健康检测。
节点间的网络心跳(Network Heartbeat)：可以想象成节点间定时发送Ping包检测节点状态。如果能够在规定的时间内收到响应，就认为对方健在。
通 过控制文件的磁盘心跳(Controlfile Heartbeat)：每个节点的CKPT进程每隔三秒更新一次控制文件的一个数据块，这个数据块叫做Checkpoint Progress Record，控制文件是共享的，因此实例间可以相互检查对方是否及时更新以判断状态。

可以通过视图查看这个操作:

SQL> select inst_id,cphbt from x$kcccp;
   INST_ID      CPHBT
---------- ----------
         1  801362227
         1  801340474

SQL> /
   INST_ID      CPHBT
---------- ----------
         1  801362229
         1  801340476

LMD:GLOBAL ENQUEUE SERVICE DAEMON 
LMD 进程主要管理对全局队列和资源的访问，并更新相应队列的状态，处理来自于其他实例的资源请求。每一个全局队列的当前状态存储在相应的实例共享内存中，该状 态表明该实例具有相应的权利使用该资源。一个实例（master)的共享内存中存在一个特殊的队列，该队列纪录来自其他远程实例的资源请求，当远程实例的 LMD进程发出一个资源请求时，该请求指向master实例的LMD,当master实例的LMD进程受到该请求后，在共享内存中的特殊队列中监测该资源 是否无效，如果有效则LMD进程更新该资源对列的状态，并通知请求资源的LMD进程该资源队列可以使用了，如果资源队列正在被其他实例使用或者当前无效， 则LMD进程通知正在使用中的实例的LMD进程应该释放该资源，等资源释放变得有效时，MASTER实例的LMD进程更新该资源队列的状态并通知请求资源 实例的LMD进程该资源队列可以使用了。另外LMD进程也负责队列的死锁问题。。。
这个进程负责提供的是GES( Global Enqueue Service)， 具体来说，这个进程负责在多个实例之间协调对数据块的访问顺序，保证数据的一致性。 
LMSn:GLOBAL CACHE SERVICE PROCESS(n 0~9) 
LMS 进程主要用来管理集群内数据块的访问，并在不同实例的BUFFER CACHE中传输块镜像。LMS进程跨集群管理数据库的请求，并保证在所有实例的BUFFER CACHE中一个数据块的镜像只能出现一次。LMS进程靠着在实例中传递消息来协调数据块的访问，当一个实例请求数据块时，该实例的LMD进程发出一个数 据块资源的请求，该请求只向MASTER数据块的实例的LMD进程，MASTER实例的LMD进程同时正在使用的实例的LMD进程释放该资源，这时拥有该 资源的实例的LMS进程会创建一个数据块镜像的一致性读，然后把该数据块传递到请求该资源的实例的BUFFER CACHE中。LMS进程保证了在每一时刻只能允许一个实例去更新数据块，并负责保持该数据块的镜像纪录（包含更新数据块的状态FLAG),RAC提供了 10个LMS进程，该进程数量随着节点间的消息传递的数据的增加而增加。

这个进程是Cache Fusion的主要进程，负责数据块在实例间的传递，对应的服务叫做GCS（Global Cache Service）。这种进程的数量是通过参数GCS_SERVER_PROCESSES来控制，缺省是2个，取值范围是0-9.

LCK:lock process 
负责Non-Cache Fusion资源的同步访问，每个实例有一个LCK进程。 
DIAG:DIAGNOSABILITY DAEMON 
DIAG进程主要用来捕获实例中失败进程的诊断信息，实例出现运行时错误时收集诊断数据包记录到Alter日志中或 生成相应的TRACE文件（该trace文件保存在backupground_dump_dest/cdmp_timestamp目录下），该进程不需要进行配置更不应该被停止。该进程自动启动不需要进行调整，如果该进程失效则自动重新启动。
OSD:Operating System-Dependent 
是指依赖操作系统的一些参数、软件等。RAC通过操作系统相关的软件来访问操作系统和一些于CLUSTER相关的服务进程。OSD软件可能由Oracle提供（windows平台）或由硬件厂商提供（unix平台）。
OSD包括三个自部分：
The Cluster Manager(CM)：集群监视器监视节点间通信，并通过interconnect来协调节点操作。同时还提供CLUSTER中所有节点和实例的统一视图。CM还控制CLUSTER的成员资格。
The Node Monitor（节点监视器）：节点监视器提供节点内各种资源的状态，包括节点、interconnect硬件和软件和共享磁盘等。
The Interconnect。

SCN

在RAC环境中，每个节点都有自己的SCN发生器，每个节点都会修改数据库。必须有某种机制 保证这些SCN在时间排序上的精确。如果紧靠计算机的系统时钟肯定是不够的。在RAC环境中， 由GCS负责全局维护SCN的产生，一共通过两个算法产生SCN:

Lamport算法:在所有节点间的通信内容中都携带SCN， 每个节点把接收到的SCN和本机的SCN对比，如果本机的SCN 小，则调整本机的SCN和接收的一致， 如果节点间通信不多，还会主动地定期相互通报。 故即使节点处于Idle 状态，还是会有一些Redo log 产生。Oracle9i及10.1 RAC默认采用这种方式。