前面已经介绍了 RAC 的后台进程，为了更深入的了解这些后台进程的工作原理，先了解一下 RAC 中多节点对共享数据文件访问的管理是如何进行的。要了解 RAC 工作原理的中心，需要知道 Cache Fusion 这个重要的概念，要发挥 Cache Fusion 的作用，要有一个前提条件，那就是互联网络的速度要比访问磁盘的速度要快。否则，没有引入 Cache Fusion 的意义。而事实上，现在 100MB 的互联网都很常见。

Cache Fusion 就是通过互联网络（高速的 Private interconnect）在集群内各节点的 SGA 之间进行块传递，这是RAC最核心的工作机制，他把所有实例的SGA虚拟成一个大的SGA区，每当不同的实例请求相同的数据块时，这个数据块就通过 Private interconnect 在实例间进行传递。以避免首先将块推送到磁盘，然后再重新读入其他实例的缓存中这样一种低效的实现方式(OPS 的实现)。当一个块被读入 RAC 环境中某个实例的缓存时，该块会被赋予一个锁资源（与行级锁不同），以确保其他实例知道该块正在被使用。之后，如果另一个实例请求该块的一个副本，而该块已经处于前一个实例的缓存内，那么该块会通过互联网络直接被传递到另一个实例的 SGA。如果内存中的块已经被改变，但改变尚未提交，那么将会传递一个 CR 副本。这就意味着只要可能，数据块无需写回磁盘即可在各实例的缓存之间移动，从而避免了同步多实例的缓存所花费的额外 I/O。很明显，不同的实例缓存的数据可以是不同的，也就是在一个实例要访问特定块之前，而它又从未访问过这个块，那么它要么从其他实例 cache fusion 过来，或者从磁盘中读入。GCS（Global Cache Service，全局内存服务）和 GES（Global EnquenceService，全局队列服务）进程管理使用集群节点之间的数据块同步互联。

这里还是有一些问题需要思考的：

1. 在所有实例都未读取该块，而第一个实例读取时，是怎么加的锁，加的什么锁？如果此时有另一个实例也要读这个块，几乎是同时的，那么 Oracle 如何来仲裁，如何让其中一个读取，而另一个再从前者的缓存中通过 cache 来得到？
2. 如果一个块已经被其他实例读入，那么本实例如何判断它的存在？
3. 如果某个实例改变了这个数据块，是否会将改变传递到其他实例，或者说其他实例是否会知道并重新更新状态？
4. 如果一个实例要 swapout 某个块，而同时其他实例也有这个块的缓存，修改过的和未修改过的，本实例修改的和其他实例修改的，如何操作? truncate 一张表，drop 一张表... 和单实例有何不同？
5. 应该如何设计应用，以使 RAC 真正发挥作用，而不是引入竞争，导致系统被削弱？
6. RAC 下锁的实现。

锁是在各实例的 SGA 中保留的资源，通常被用于控制对数据库块的访问。每个实例通常会保留或控制一定数量与块范围相关的锁。当一个实例请求一个块时，该块必须获得一个锁，并且锁必须来自当前控制这些锁的实例。也就是锁被分布在不同的实例上。而要获得特定的锁要从不同的实例上去获得。但是从这个过程来看这些锁不是固定在某个实例上的，而是根据锁的请求频率会被调整到使用最频繁的实例上，从而提高效率。要实现这些资源的分配和重分配、控制，这是很耗用资源的。这也决定了 RAC 的应用设计要求比较高。假设某个实例崩溃或者某个实例加入，那么这里要有一个比较长的再分配资源和处理过程。在都正常运行的情况下会重新分配，以更加有效的使用资源；在实例推出或加入时也会重新分配。在 alert 文件中可以看到这些信息。而 Cache Fusion 及其他资源的分配控制，要求有一个快速的互联网络，所以要关注与互联网络上消息相关的度量，以测试互联网络的通信量和相应时间。对于前面的一些问题，可以结合另外的概念来学习，它们是全局缓存服务和全局队列服务。

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

猜想：Oracle 目前的 cache fusion 是在其他实例访问时会将块传输过去再构建一个块在那个实例的 SGA 中，这个主要的原因可能是 interconnect 之间的访问还是从本地内存中访问更快，从而让 Oracle 再次访问时可以从本地内存快速获取。但是这也有麻烦的地方，因为在多个节点中会有数据块的多个 copy，这样在管理上的消耗是很可观的，Oracle 是否会有更好的解决方案出现在后续版本中？如果 interconnect 速度允许的话...）

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

SQL> select * from gv$sysstat where name like 'gcs %'

这里可以看到 gcs 和 ges 消息的发送个数。（如果没有使用 DBCA 来创建数据库，那么要 SYSDBA 权限来运行CATCLUST.SQL 脚本来创建 RAC 相关的视图和表）

Oracle failsafe、Data Guard 和 RAC 均为 ORACLE 公司提供的高可靠性（HA）解决方案。然而之三者之间却存在着很大区别。HA 是 High Availability 的首字母组合，翻译过来，可以叫做高可用，或高可用性，高可用（环境）。我觉得应该说 HA 是一个观念而不是一项或一系列具体技术，就象网格一样。作过系统方案就知道了，评价系统的性能当中就有一项高可用。也就是 OS 一级的双机热备。RAC 是 real application cluster 的简称，它是在多个主机上运行一个数据库的技术，即是一个 db 多个 instance。它的好处是 可以由多个性能较差的机器构建出一个整体性能很好的集群，并且实现了负载均衡，那么当一个节点出现故障时，其上的服务会自动转到另外的节点去执行，用户甚 至感觉不到什么。

1、    操作系统：

failsafe 系统局限于 WINDOWS 平台，必须配合 MSCS（microsoft cluster server），而 RAC 最早是在 UNIX 平台推出的，目前已扩展至 LINUX 和 WINDOWS 平台，通过 OSD（operating system dependent）与系统交互。对于高端的 RAC 应用，UNIX 依然是首选的平台。

2、    系统结构：

FAILSAFE 采用的是 SHARE NOTHING 结构，即采用若干台服务器组成集群，共同连接到一个共享磁盘系统，在同一时刻，只有一台服务器能够访问共享磁盘，能够对外提供服务。只要当此服务器失效时，才有另一台接管共享磁盘。RAC 则是采用 SHARE EVERYTHING，组成集群的每一台服务器都可以访问共享磁盘，都能对外提供服务。也就是说 FAILSAFE 只能利用一台服务器资源，RAC 可以并行利用多台服务器资源。

3、    运行机理：

组成 FAILSAFE 集群的每台 SERVER 有独立的 IP，整个集群又有一个 IP，另外还为 FAILSAFE GROUP 分配一个单独的 IP（后两个 IP 为虚拟 IP，对于客户来说，只需知道集群 IP，就可以透明访问数据库）。工作期间，只有一台服务器（preferred or owner or manager）对外提供服务，其余服务器(operator)成待命状，当前者失效时，另一服务器就会接管前者，包括FAILSAFE GROUP IP与CLUSTER IP，同时FAILSAFE会启动上面的DATABASE SERVICE，LISTENER 和其他服务。客户只要重新连接即可，不需要做任何改动。对于 RAC 组成的集群，每台服务器都分别有自已的 IP，INSTANCE 等，可以单独对外提供服务，只不过它们都是操作位于共享磁盘上的同一个数据库。当某台服务器失效后，用户只要修改网络配置，如（TNSNAMES。ORA），即可重新连接到仍在正常运行的服务器上。但和 TAF 结合使用时，甚至网络也可配置成透明的。

4、    集群容量：

前者通常为两台，后者在一些平台上能扩展至 8 台。

5、    分区：

FAILSAFE 数据库所在的磁盘必须是 NTFS 格式的，RAC 则相对灵活，通常要求是 RAW，然而若干 OS 已操作出了 CLUSTER 文件系统可以供 RAC 直接使用。综上所述，FAILSAFE 比较适合一个可靠性要求很高，应用相对较小，对高性能要求相对不高的系统，而 RAC则更适合可靠性、扩展性、性能要求都相对较高的较大型的应用。

RAC 是 OPS 的后继版本，继承了 OPS 的概念，但是 RAC 是全新的，CACHE 机制和 OPS 完全不同。RAC 解决了 OPS 中 2 个节点同时写同一个 BLOCK 引起的冲突问题。 从产品上来说 RAC 和 OPS 是完全不同的产品，但是我们可以认为是相同产品的不同版本

Data Guard 是 Oracle 的远程复制技术，它有物理和逻辑之分，但是总的来说，它需要在异地有一套独立的系统，这是两套硬件配置可以不同的系统，但是这两套系统的软件结构保持一致，包括软件的版本，目录存储结构，以及数据的同步（其实也不是实时同步的），这两套系统之间只要网络是通的就可以了，是一种异地容灾的解决方案。而对于 RAC，则是本地的高可用集群，每个节点用来分担不用或相同的应用，以解决运算效率低下，单节点故障这样的问题，它是几台硬件相同或不相同的服务器，加一个 SAN（共享的存储区域）来构成的。Oracle 高可用性产品比较见下表：

通常在 RAC 环境下，在公用网络的基础上，需要配置两条专用的网络用于节点间的互联，在 HACMP/ES 资源的定义中，这两条专用的网络应该被定义为"private" 。在实例启动的过程中，RAC 会自动识别和使用这两条专用的网络，并且如果存在公用"public" 的网络，RAC 会再识别一条公用网络。当 RAC 识别到多条网络时，RAC会使用 TNFF (Transparent Network Failvoer Failback) 功能，在 TNFF 下所有的节点间通信都通过第一条专用的网络进行，第二条( 或第三条等) 作为在第一条专用的网络失效后的备份。RAC 节点间通信如下图所示。

CLUSTER_INTERCONNECTS 是在 Oracle RAC 中的一个可选的初始化(init.ora) 参数。此参数可以指定使用哪一条网络用于节点间互联通信，如果指定多条网络，RAC 会在这些网络上自动进行负载均衡。然而，当CLUSTER_INTERCONNECTS 设置时，TNFF 不起作用，这将降低 RAC 的可用性，任何一条节点间互联网络的失效，都会造成 RAC 一个或多个节点的失效。ORACLE RAC 用于 INTERCONNECT 的内网卡的物理连接方式的选择：采用交换机连接或是网线直连。直连的弊端是，一旦一个节点机的内网卡出现故障，oracle 从 OS 得到两个节点的网卡状态都是不正常的，因而会导致两个实例都宕掉。在 INTERCONNECT 线路出现问题的时候，oracle 一般情况下会启动一个竞争机制来决定哪个实例宕掉，如果宕掉的实例正好是好的实例的话， 这样就会导致两个实例都宕掉。在 9i 中，oracle 在启动竞争机制之前，会先等待一段时间，等待 OS 将网络的状态发给 oracle，如果在超时之前，oracle 获得哪个实例的网卡是 down 的话，则将该实例宕掉，这样的话，则可以保留正常的那个实例继续服务，否则还是进入竞争机制。

综上所述节点间通信分为两种情况：

 是接在交换机上面，此时一般情况下，是会保证正常的实例继续服务的，但有的时候如果 os 来不及将网卡状态送到 oracle 时，也是有可能会导致两个节点都宕掉的。

 如果是直连的话，则会导致两个实例都宕掉。

CSS 心跳

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

CSS 服务有 2 种心跳机制： 一种是通过私有网络的 Network Heartbeat，另一种是通过 Voting Disk 的 DiskHeartbeat。这 2 种心跳都有最大延时，对于 Disk Heartbeat，这个延时叫作 IOT (I/O Timeout);对于 Network Heartbeat, 这个延时叫 MC(Misscount)。这 2 个参数都以秒为单位，缺省时 IOT 大于 MC，在默认情况下，这 2 个参数是 Oracle自动判定的，并且不建议调整。可以通过如下命令来查看参数值：

$crsctl get css disktimeout

$crsctl get css misscount

Oracle RAC 节点间使用的通信协议见下表。

LOCK（锁）是用来控制并发的数据结构，如果有两个进程同时修改同一个数据， 为了防止出现混乱和意外，用锁来控制访问数据的次序。有锁的可以先访问，另外一个进程要等到第一个释放了锁，才能拥有锁，继续访问。总体来说,RAC 里面的锁分两种， 一种是本地主机的进程之间的锁，另外一种是不同主机的进程之间的锁。本地锁的机制有两类，一类叫做 lock（锁），另外一类叫做 latch 闩。

全局锁就是指 RAC lock，就是不同主机之间的锁，Oracle 采用了 DLM（Distributed Lock Management，分布式锁管理）机制。在 Oracle RAC 里面，数据是全局共享的，就是说每个进程看到的数据块都是一样的，在不同机器间，数据块可以传递。给出了 GRD目录结构。

可以看出 Mode、Role、n 构成了 RAC lock 的基本结构

1. Mode 有 N、S、X3 种方式
2. Role 有 Local 和 Global 两种
3. N 有 PI 和 XI 两种，一般 0 表示 XI，1 表示 PI
4. 全局内存管理
5. RAC 中的数据库文件
6. RAC 中读的一致性
7. 群集就绪服务（CRS）
8. 全局资源目录

数据一致性和并发性描述了 Oracle 如何维护多用户数据库环境中的数据一致性问题。在单用户数据库中，用户修改数据库中的数据，不用担心其他用户同时修改相同的数据。但是，在多用户数据库中，同时执行的多个事务中的语句可以修改同一数据。同时执行的事务需要产生有意义的和一致性的结果。因而，在多用户数据库中，数据并发性和数据一致性的控制非常重要：数据并发性：每个用户可以看到数据的一致性结果。ANSI/IOS SQL 标准（SQL 92）定义了 4 个事务隔离级别，对事务处理性能的影响也个不相同。这些隔离级别是考虑了事务并发执行必须避免的 3 个现象提出的。3 个应该避免的现象为：  

1. 脏读：一个事务可以读取其他事务写入但还没有提交的数据。  
2. 不可重复读（模糊读）：一个事务重复读到以前读到的和查询到的数据，这些数据是其他的已提交事务已经修改或者删除的数据。
3. 幻影读：一个事务重复运行查询返回的一些列行，这些行包括其他已经提交的事务已经插入的额外的行。

SQL92 根据这些对象定义了 4 个隔离级别，事务运行在特定的隔离级别允许特别的一些表现。如下表表示隔离级别阻止的读现象。

(一) OCR KEY 是树形结构。

(二) OCR PROCESS 每个节点都有 OCR CACHE 的复制，由 ORC MASTER 节点负责更新到 OCR DISK

自动启动的脚本/etc/inittab 里定义：

OCSSD（Clustery Synchronization Service）提供心跳机制监控集群状态

DISK HEARTBEAT

NETWORK HEARBEAT

CRSD（Clustery Ready Service）提供高可用、干预、关闭、重启、转移服务。

资源包括 nodeapps、database-related：前者每个节点只需要一个即可正常工作，后一个与数据库相关，不受节点限制，可以为多个。

EVMD： 这个进程负责发布 CRS 产生的各种事件，还是 CRS 和 CSS 两个服务之间通信的桥梁

RACGIMON： 这个进程负责检查数据库健康状态，包括数据库服务的启动、停止和故障转移。属于持久连接，定期检查 SGA。

OPROCD（Process Monitor Daemon）检测 CPU hang（非 Linux 平台使用）

DLM 分布式锁管理。

1. Non-Cache Fusion 资源：包括数据文件、控制文件、数据字典视图 、Library Cache、Row Cache
2. Cache Fusion 资源：包括普通数据块、索引数据块、段头、UNDO 数据块。
3. GRD（Global Resource Directory）：记录每个数据块在集群间的分布图，在SGA中分master node与shadownode
4. PCM lock：mode role Past Image
5. LMS0（LOCK MANAGER SERVICE）：对应服务为 GCS（Global Cache Service），主要负责数据块在实例间传递Cache fusion 参数 GCS_SERVER_PROCESSES
6. LMD：对应服务为 GES（Global ENQUEUE Service），主要负责传递过程中锁的管理。
7. LCK：负责 NON-CACHE FUSION 资源同步访问，每个实例有一个进程。
8. LMON：这个进程定期通信每个实例，对应服务为 CGS（Cluster Group Service）。提供节点监控 node monitor，通过 GRD 中用位图 0,1 来标志。0：节点关闭 1：节点正常运行通过 CM 层定期通信。
9. 两种心跳机制：网络心跳和控制文件磁盘心跳 3S 一次。
10. DIAG：监控状态，写日志 alert.log
11. GSD：为用户提供管理接口。

(一) NM（NODE MANAGEMENT）group

(二) 重构集群触发：有 node 加入或者离开集群，由 NM 触发 Network Heartbeat 异常：因为 LMON 或者 GCS、GES 通信异常 ，由 IMR（Instance Membership Reconfiguration）controlfile heartbeat 触发。

(一) 多节点负载均衡

(二) 提供高可用性，故障容错及无缝切换功能，将硬件和软件的异常造成的影响最小化。

(三) 通过并行执行技术提供事务响应的时间 - 通常用于数据分析系统。

(四) 通过横向扩展提高每秒交易数和连接数 - 通常用于 OLTP。

(五) 节约硬件成本，可以使用多个廉价的 PC 服务器代替小型机大型机，节约相应的维护成本。

(六) 可扩展性好，可以方便添加删除节点，扩展硬件资源。

(一) 管理更复杂，要求更高

(二) 系统规划设计较差时性能可能会不如单节点

(三) 可能会增加软件成本(按照 CPU 收费)