OracleRAC基本概念及入门

1、什么是cluster

一个cluster是由两个或是多个独立的、通过网络连接的servers组成的。几个硬件供应商多年以来提供了Cluster性能的各种需求。一些Clusters仅仅为了提供高可用性的，在当前活动的node发生故障时转移到次节点node。另一些是为了提供分布式的连接、工作的可扩展性。另一个Cluster的共同特点是，对于一个应用程序，它可以看做是一个单独的server。同样，管理几个servers应该尽可能像管理一个server一样简单。Cluster管理器软件提供了这种功能。

如果是single server的nodes，文件必须存储在其各自node能访问的位置。存在有几个不同拓扑结构来解决数据访问的问题，这主要依赖于Cluster设计的主要目标。

相互连接时一个物理的网络连接，作为每个Cluster节点直接的交互通信。

简而言之，一个Cluster就是一组独立的servers，它们共同协作，组成一个single system。

2、什么是Oracle real Application Cluster(RAC)

RAC是一个软件可以使你通过运行多个依赖相同Database的Instance，使用Cluster硬件。数据库files被存放在物理或是逻辑上连接每个节点的磁盘上。以便于每个活动的Instance都可以对files进行读写操作。

RAC软件管理着数据的访问。所以更改操作在Instances之间是被相互协调的，并且每个Instance看到的信息和数据镜像都是一致的。

通过RAC结构，可以获得冗余，从而使得即使在一个系统crash或是不可访问时，应用程序也可通过其他Instance访问Database。

3、为啥使用RAC

RAC可以高度利用标准的Cluster，降低模块servers成本。

RAC自动的提供了服务的工作量管理。应用程序的服务可以被分组或分类，组成商业组件完成应用工作任务。RAC中的服务可以是持续的、不间断的Database操作，并为多Instance上的多个服务提供支持。可以设计services到一个或多个Instance上运行，并且交替Instances可以用于备份Instances。如果主Instance失败，Oracle会将services从失败的Instance节点移动到活动的可替代的Instance上。Oracle也会自动的通过连接进行数据装载的平衡。

RAC利用多个廉价的computers共同提供Database的服务，就像一个大的computer一样，服务于只有大规模SMP才能提供的各种应用。

RAC是基于共享磁盘结构的，在需求上可以增加或缩减，而不需要人为的在Cluster中进行数据的分隔。并且RAC可以简单的增加、移出Cluster中的servers。

4、Clusters和可扩展性

如果使用对称多处理(symmetric multiprocessing SMP)机制能够对应用程序提供透明的服务，则应该使用RAC也可以得到同样的效果，而不需要进行应用程序代码的任何改动。

当一个节点发生失败，RAC可以排除该Database Instance和node本身，从而保证Database的完整。

下面是一些可扩展性的例子：

* 允许更多并发的批处理。

* 允许更大程度的并发执行。

* 在OLTP系统中可以是连接的用户大增。

1)可扩展性的层次：主要有四个层次

* hardware 的可扩展性：相互连接性是它的关键，这一般依赖于较高的带宽和较低的延迟。

* OS的可扩展性：在OS中，同步方法可以决定系统的可扩展性。在一些情况下，硬件的潜在可扩展性会因为OS无力并发维持请求的多个资源而被丢失。

* Database管理系统的可扩展性：在并发结构中的一个关键因素是并发是由内部影响的还是外部进程影响的。此问题的答案影响了同步的机制。

* 应用层次上的可扩展性：应用程序必须被明确的设计为可扩展的。当系统中如果多数情况下，每个session都在更新相同的data，则可能产生瓶颈。这不仅是指RAC，对于single-instance系统也是一样。

需要明确的是，如果任何一个层次没有达到可扩展性，不管其他层次可扩展性多强，并发的Cluster进程都可能失败。可扩展性不足的典型原因是共享资源的访问。这使得并发的操作在此瓶颈上序列化执行。这不仅仅是RAC中的局限，而是所有结构中的局限性。

2)scaleup和speedup

* scaleup是工作量和资源都成比例增加时能维持相同性能水平的能力(相应时间)

Scaleup=(volume parallel)/(volume original)–time for ipc

* speedup是指通过增加资源的数量完成固定的工作量，获得执行时间成比例的缩减的效果。

Speedup=(time original)/(time parallel)–time for ipc

其中，ipc是进程间通信的简写——interprocess communication

RAC Architecture and Concepts

1、RAC软件原理

在一个RAC Instance中，会见到一些普通Instance中不存在的后台进程，它们主要是用于维持Database在每个Instance中的一致性。管理全局资源，具体如下：

* LMON：全局队列服务监控进程——Global Enqueue Service Monitor

* LMD0：全局队列服务守护进程——Global Enqueue Service Daemon

* LMSx：全局缓冲服务进程，x可以从0到j——Global Cache Service Processes

* LCK0：锁进程——Lock process

* DIAG：诊断进程——Diagnosibility process

在Cluster层，可以找到Cluster Ready Services软件的主要进程，它们在所有平台上提供标准的Cluster接口，并实现高可用性的操作。在每个Cluster node上都可以看到如下的进程：

* CRSD和RACGIMON：用于高可用性操作的引擎。

* OCSSD：提供成员节点和服务组的访问

* EVMD：事件检测进程，由oracle用户运行管理

* OPROCD：Cluster的监控进程

此外还存在几个工具用于管理Cluster中全局层次上的各种资源。这些资源是ASM Instance、RAC Database、Services和CRS应用节点。本书中涉及的工具主要有Server Control(SRVCTL)、DBCA和Enterprise Manager。

2、RAC软件存储原理

Oracle10g的RAC安装分为两个阶段。第一阶段是安装CRS，其次是安装带有RAC组件的Database软件并创建Cluster数据库。CRS软件使用的Oracle home必须不同于RAC软件使用的home。尽管可以将Cluster中CRS和RAC软件通过使用Cluster文件系统共享存储，但是软件总是按一定规则安装在每个节点的本地文件系统中。这支持在线补丁的升级，并消除了单节点软件造成的失败。另外有两个必须存储在共享的存储设备中：

* voting file：其本质上是用于Cluster synchronization Services守护进程进行节点信息的监控。大小约为20MB。

* Oracle Cluster Registry(OCR)文件：也是CRS关键的组成部分。用于维护在Cluster中高可用性组件的信息。例如，Cluster节点列表，Cluster数据库Instance到节点的映射和CRS应用资源的列表(如Services、虚拟内部链接协议地址等)。此文件是通过SRVCTL类似的管理工具自动维护的。其大小约100MB。

voting file和OCR file是不能被存储在ASM中的，因为它们必须在任何Oracle Instance启动前就可以被访问。并且，两者必须是在冗余的、可靠的存储设备中存放，如RAID。推荐最好的做法是将这些文件放在裸磁盘上。

3、OCR的结构

Cluster的配置信息是在OCR中维护的。OCR依赖分布式的共享缓存结构用于优化关于Cluster知识库的查询。在Cluster中的每个节点都通过OCR进程访问OCR缓存在其内存中维护着一个副本。事实上在Cluster中，只有一个OCR进程对共享存储中的OCR进行读写操作。此进程负责刷新(refresh)其自己拥有的本地缓存以及Cluster中其他节点的OCR cache。对于涉及到Cluster知识库的访问，OCR客户端直接访问本地OCR进程。当客户端需要更新OCR时，它们将通过本地OCR进程与那个扮演读写OCR文件的进程进行交互。

OCR客户端应用有：Oracle通用安装器(OUI)、SRVCTL、企业管理器(EM)、DBCA、DBUA、NetCA和虚拟网络协议助理(VIPCA)。此外，OCR维护管理着CRS内部中定义的各种应用程序的资源的依赖和状态信息，特别是Database、Instance、Services和节点的应用程序。

配置文件的名字是ocr.loc，并且配置文件变量是ocrconfig_loc。Cluster 知识库的位置是不受限于裸设备的。可以将OCR放置在由Cluster file system管理的共享存储设备上。

note：OCR也可用于在ASM的单Instance中作为配置文件，每个节点有一个OCR。

4、RAC Database存储原理

与single-Instance Oracle的存储方式最主要的不同之处在于RAC存储必须将所有RAC中数据文件存放在共享设备中(裸设备或是Cluster文件系统)以便于访问相同Database的Instance能够共享。必须为每个Instance创建至少两个redo log组，并且所有的redo log组必须也存储在共享设备中，从而为了crash恢复的目的。每个Instance的在线redo log groups被称作一个Instance的在线redo 线程。

此外，必须为每个Instance创建一个共享的undo表空间用于Oracle推荐的undo自动管理特点。每个undo表空间必须是对所有Instance共享的，主要用于恢复的目的。

归档日志不能被存放在裸设备上，因为其命名是自动产生的，并且每个是不一致的。因此需要存储在一个文件系统中。如果使用Cluster file system(CFS)，则可以在任何时间在任何node上访问这些归档文件。如果没有使用CFS，就不得不使其他Cluster成员在恢复时那些归档日志是可用的，例如通过网络文件系统(NFS)来实现。如果使用推荐的flash recovery area特性，则其必须被存储在共享目录下，以便于所有的Instance能够访问。(共享目录可以是一个ASM磁盘组，或是一个CFS)。

5、RAC和共享存储技术

存储是网格技术中的关键组成部分。传统上，存储都直接依附在每个Server(directly attached to each inpidual Server DAS)上。在过去的几年来，更灵活的存储出现并得到应用，主要是通过存储空间网络或是正规的以太网来实现访问。这些新的存储方式使得多个Servers访问相同的磁盘集合成为可能，在分布式环境中，可以获得简单的存取。

storage area network(SAN)代表了数据存储技术在这一点的演进。传统上，C/S系统中，数据被存储在Server内部或是依附它的设备中。随后，进入了network attached storage(NAS)阶段，这使得存储设备与Server和直接连接它们的网络向分离。它在SAN遵循的原则进一步允许存储设备存在于各自的网络中，并直接通过高速的媒介进行交换。用户可以通过Server系统对存储设备的数据进行访问，Server 系统与本地网络(LAN)和SAN相互连接。

文件系统的选择是RAC的关键。传统的文件系统不支持多系统的并行挂载。因此，必须将文件存储在没有任何文件系统的裸卷标或是支持多系统并发访问的文件系统中。

因此，三个主要的方法用于RAC的共享存储有：

* 裸卷标：既是一些直接附加的裸设备，需要用于存储，并以block模式进程操作。

* Cluster file system：也需要以block模式进程存取。一个或多个Cluster file 系统可以被用于存储所有的RAC文件。

* 自动存储管理(ASM)：对于Oracle Database files，ASM是一个轻便的、专用的、最佳化的Cluster file system。

6、Oracle Cluster file system

Oracle Cluster file system(OCFS)是一个共享文件系统，专门为Oracle RAC设计。OCFS排除了Oracle Database files被连接到逻辑磁盘上的需要，并使得所有的节点共享一个ORACLE Home，而不需每个node在本地有一个副本。OCFS卷标可以横跨一个或多共享disks，用于冗余和性能的增强。

下面时可放入OCFS中的文件类表：

* Oracle software的安装文件：在10g中，此设置只在windows 2000中支持。说是后面的版本会提供在Linux中的支持，但我还没具体看。

* Oracle 文件(控制文件、数据文件、redo logs文件，bfiles等)

* 共享配置文件(spfile)

* 在Oracle运行期间，由Oracle创建的文件。

* voting和OCR文件

Oracle Cluster file system对开发人员和用户时免费的。可从官方网站下载。

7、自动存储管理(ASM)

是10g的新特性。它提供了一个纵向的统一管理的文件系统和卷标管理器，专门用于建立Oracle Database 文件。ASM可以提供单个SMP机器的管理或是贯穿多个Oracle RAC的Cluster节点。

ASM无需再手动调节I/O，会自动的分配 I/O 负载到所有的可用资源中，从而优化性能。通过允许增加Database大小而不需shutdown数据库来调节存储分配，来辅助DBA管理动态数据库环境。

ASM可以维护数据的冗余备份，从而提高故障的容错。它也可以被安装到可靠的存储机制中。

8、选择RAW或CFS

* CFS的优点：对于RAC的安装和管理非常简单;对RAC使用Oracle managed files(OMF);single Oracle软件安装;在Oracle data files上可以自动扩展;当物理节点失败时，对归档日志的统一访问。

* 裸设备的使用：一般会用于CFS不可用或是不被Oracle支持的情况下;它提供了最好的性能，不需要在Oracle和磁盘之间的中间层;如果空间被耗尽，裸设备上的自动扩展将失败;ASM、逻辑存储管理器或是逻辑卷标管理其可以简化裸设备的工作，它们也允许加载空间到在线的裸设备上，可为裸设备创建名字，从而便于管理。

9、RAC的典型Cluster栈

在Cluster中的每个节点都需要一个被支持的相互连接的软件协议来支持内部Instance的交互，同时需要TCP/IP支持CRS的轮询。所有的UNIX平台在千兆以太网上使用user datagram protocol(UDP)作为主要的协议并进行RAC内部Instance 的IPC交互。其他支持的特有协议包括用于SCI和Sunfire的连接交互的远程共享内存协议和超文本协议，用于超光纤交互。在任何情况下，交互必须能被平台的Oracle所辨识。

使用Oracle clusterware，可以降低安装并支持并发症。但如果用户使用非以太交互，或开发了依赖clusterware的应用程序在RAC上，可能需要vendor clusterware。

同交互连接一样，共享存储方案必须被当前平台的Oracle所辨识。如果在目标平台上，CFS可用，Database area和flash recovery area都可以被创建到CFS或ASM上。如果在目标平台上，CFS不可用，则Database area可以创建在ASM或是裸设备上(需要卷标管理器)并且flash recovery area必须被创建在ASM中。

10、RAC certification Matrix：它设计用于处理任何认证问题。可以使用matrix回答任何RAC相关的认证问题。具体使用步骤如下：

* 连接并登陆 https://metalink.oracle.com

* 点击菜单栏的“certify and availability”按钮

* 点击“view certifications by product”连接

* 选择RAC

* 选择正确的平台

11、必要的全局资源

一个single-Instance环境，锁坐标通向一个共享的资源就像表中的一行。lock避免了两个进程同事修改相同的资源。

在RAC环境中，内部节点的同步时关键，因为它维持着不同节点中各自进程的一致性，避免其在同时修改相同的资源数据。内部节点的同步确保每个Instance看到buffer cache中block的最近的版本。上图中显示了当不存在加锁的情况。

1)全局资源的协调

cluster操作要求在所有Instance中对控制共享资源的访问进行同步。RAC使用Global Resource Directory来记录cluster Database中资源的使用信息。Global Cache Service(GCS)和Global Enqueue Service(GES)管理GRD中的信息。

每个Instance在其本地的SGA中维护GRD的一部分。GCS和GES指定一个Instance管理特殊资源的所有信息，它被称为资源的master。每个Instance都知道resource的Instance masters。

维护RAC的活动中的cache的依附性(cache coherency)是非常重要的。所谓cache coherency是保持在不同Oracle Instances中的多个block版本的一致性的技术。GCS通过所谓的cache融合算法来实现cache coherency。

GES管理所有非cache 融合算法的内部Instance资源操作和Oracle入队机制的状态轨迹。GES主要的控制的资源是字典cache locks和library cache locks。同时，它还对所有死锁敏感的队列和资源起到死锁检测的作用。

2)Global cache coordination实例

假设某data block被第一个节点修改，成为脏数据。并且在clusterwide中，只有一个block copy版本，其内容用SCN号代替了。则具体的步骤如下：

① 第二个Instance视图修改该block，向GCS提出请求。

② GCS向block的holder(持有者)提交请求。在此，第一个Instance就是holder。

③ 第一个Instance接到消息，并将block发送给第二个Instance。第一个Instance保存脏buffer用于恢复的目的。block的脏镜像被称作block的past image。一个past image block将不能进一步被改变。

④收到block后，第二个Instance通知GCS，告知已经holds该block。

3)write to disk coordination：example

在cluster结构中的Instances中的caches中，可能存在同一个block的不同的修改版本。由GCS管理的写协议确保了只有最近一个版本被写入磁盘中。它同时需要确保其他之前的版本从其他cache中被清洗。一个写磁盘的请求可以从任意一个Instance上发起，无论它是保存了block的当前版本还是过去的版本。假设第一个Instance hold过去的block镜像，请求Oracle将buffer写入磁盘，如上图，过程如下：

①第一个Instance发送一个写请求给GCS

②GCS将请求转给第二个Instance，当前该block的holder

③第二个Instance接到写请求后将block写入磁盘

④第二个Instance通知GCS，告知其写操作完成

⑤当接到GCS接到通知后，GCS命令所有的过去的镜像的holders删除其过去的镜像。此镜像将不会在因恢复而需要。

12、RAC和Instance/crash recovery

1)当一个Instance失败，当该失败被其他Instance检测到，第二个Instance将会执行下面的恢复操作：

①在恢复的第一阶段，GES重新灌入队列

②GCS也重新灌入其资源。GCS进程只重新灌入那些失去其控制的资源。在这期间，所有的GCS资源请求和写请求都临时被挂起。然而，事务可以继续修改data blocks，只要这些事务已经获得了必要的资源。

③当队列被重新配置后，一个活动的Instance可以获得占有该Instance恢复队列。因此，当GCS资源被重新灌入的同时，SMON确定需要被恢复的blocks的集合。这个集合被称作恢复集。因为，使用cache 融合算法，一个Instance传送这些blocks的内容到请求的Instance，而不需要将这些blocks写入磁盘。这些blocks在磁盘上的版本可能不包含其他Instance进程的data的修改操作的blocks。这意味着SMON需要合并所有失败的Instance的redo logs来确定恢复集。这是因为一个失败的线程可能导致一个在redo 中的hole(洞)需要用指定的block填补。所以失败的Instance的redo 线程不能被连续的应用。同时，活动的Instances的redo 线程不需恢复，因为SMON可以使用过去和当前的通信缓冲的镜像。

④用于恢复的缓冲空间被分配，并且那些之前读取redo logs被辨识的资源被声明为恢复资源。这避免了其他Instance访问这些资源。

⑤所有在随后的恢复操作中需要的资源被获得，并且GRD当前是不冻结的。任何不需恢复的data block现在可以被访问。所以当前系统时部分可用的。此时，假设有过去或当前的blocks镜像需要被恢复，而其在cluster Database中的其他caches中，对于这些特殊的blocks，最近的镜像是开始恢复点。如果对于要恢复的block，过去镜像和当前镜像缓冲都不在活动的Instance的caches中，则SMON将写入一个log，表明合并失败。SMON会对第三步中辨识的每个block进行恢复和写入，在恢复之后会马上释放资源，从而使更多的资源在恢复时可以被使用。

当所有的block被恢复，占用的恢复资源被释放，则系统再次可用。

note：在恢复中，log合并的开支和失败的Instances的数目是成比例的，并且与每个Instance的redo logs的大小有关。

2)Instance recovery和Database availability

上图显示了在进行Instance恢复时，每一步执行时数据库的可用程度：

A. RAC运行在多节点上

B. 有节点失败被检测到

C. GRD的队列部分被重新设置;资源管理被重新分配到活动的nodes。此操作的执行比较快

D. GRD的缓冲部分被重新设置，SMON读取失败Instance的redo logs辨识那些需要恢复的blocks的集合

E. SMON向GRD发起请求，获得所有在需要恢复的blocks集合中的Database blocks。当请求结束，所有的其他的blocks都可被访问了

F. Oracle执行滚动的向前恢复。失败线程的redo logs被应用到Database，并且那些被完全恢复的blocks将马上可以被访问

G. Oracle执行滚回恢复。对于尚未提交的事务，undo blocks被应用到Database中

H. Instance的恢复完成，所有的data可以被访问

13、有效的内部节点行级锁

Oracle支持有效的行级锁。这些行级锁主要是在DML操作时被创建，例如UPDATE。这些锁被持有，直到事务被提交或回滚。任何请求同行的lock的进程都将被挂起。

cache融合算法的块传输独立于这些user可见的行级锁。GCS对blocks的传输是一个底层的操作，无需当代行级锁被释放就开始进行。blocks可能被从一个Instance传输到其他其他Instances，同时该blocks可能被加锁。

GCS提供对data blocks的访问，允许多个事务的并发进行。

14、RAC的额外的内存需求

RAC特有的内存多数是在SGA创建时从shared pool中分配的。因为blocks可能跨越Instances被缓冲，必须要求更大的缓冲区。因此，当将single Instance的Database迁移到RAC中时，保持每个Instance的请求工作量都能通single-instance时的情况，则需要对运行RAC的Instance增大10%的buffer cache和15%的shared pool。这些值只是基于RAC大小的经验，一个初始的尝试值。一般会大于此值。

如果正在使用推荐的自动内存管理特性，可以通过修改SGA_TARGET初始参数来设置。但考虑到同样数量的user访问被分散到多个nodes中，每个Instance的内存需求可以被降低。

实际资源的使用可以通过查询每个Instance中的GCS和GES实体中的视图V$RESOURCE_LIMIT视图CURRENT_UTILIZATION和MAX_UTILIZATION字段，具体语句为：

SELECT resource_name, current_utilization, max_utilization FROM v$resource_limit WHERE resource_name like ‘g%s_%’;

15、RAC与并发执行

Oracle的优化器是基于执行访问代价的，这就考虑了并发执行的代价，并将其作为获得理想的执行计划的一个部件。

在RAC环境中，优化器的并发选择是由内部节点和外部节点并发两类组成的。例如，一个特殊的查询请求需要六个查询进程完成，并且在本地节点有六个并发的从属执行进程都是idle的，则查询通过使用本地资源执行，从而获得结果。这阐述了有效地内部节点并发，也无需多节点并发的查询协调的开支。如果本地节点中只有两个并发执行从属进程可用，则这两个进程和其他节点的四个进程共同执行查询。在这种情况下，内部节点和外部节点并发都被使用到，从而加速查询。

在真实环境的决策支持应用程序中，查询不能通过各种查询servers得到较好的划分。所以有些并发执行servers完成其任务后先于其他servers变为idle状态。Oracle并发执行技术动态监测idle的进程，并将超载进程的队列表中的任务分配任务给处于idle状态的进程。这样，Oracle有效的再分配了所有进程的查询工作量。RAC进一步扩展这个效率到整个cluster上。

16、全局动态性能视图

全局动态性能视图显示所有开启并访问RAC Database的Instances相关的信息。而标准动态性能视图只显示了本地Instance的相关信息。

对于所有V$类型的视图，都会对应一个GV$视图，除了几个别的特殊情况。除了V$视图中的columns，GV$视图中包含了一个名为INST_ID的额外的column，显示了RAC中的Instance number。可以在任何开启的Instance上访问GV$。

为了查询GV$视图，每个Instance上的初始PARALLEL_MAX_SERVERS初始化参数至少设置为1 。这是由于对GV$的查询使用了特殊的并发执行。并发执行的协调者运行在客户端连接的Instance上，并且每个Instance上分配一个slave用于查询其潜在的V$视图。如果有一个Instance上的PARALLEL_MAX_SERVERS被设置为0，则无法获得该node的信息，同理，如果所有的并发servers非常忙，则也无法获得结果。在以上两种情况下，不会获得提示或错误信息。

17、RAC和Service

18、虚拟IP地址和RAC

当一个node完全失败，虚拟IP地址(VIP)是关于所有有效应用的。当一个节点失败，其相关的VIP自动的分派到cluster中的其他node上。当这种情况出现时：

* crs在另外一个node的网卡的MAC地址上绑定这个ip,对用户来说是透明的。对于直接连接的客户端，会显示errors。

* 随后发往VIP的数据包都将转向新的节点，它将给客户端发送error RST返回包。从而使客户端快速的获得errors信息，进行对其他节点的连接重试。

如果不使用VIP，则一个node失败后，发往该节点的连接将等待10分钟的TCP过期时间。

转自：http://blog.csdn.net/mws1108/article/details/52856762

--- 另一篇文章参考

集群概念介绍

集群术语须知

服务硬件：指提供计算服务的硬件，比如 PC 机、PC 服务器。

服务实体：服务实体通常指服务软体和服务硬体。

节点（node）：运行 Heartbeat 进程的一个独立主机称为节点，节点是 HA 的核心组成部分，每个节点上运行着操作系统和Heartbeat 软件服务。

资源（resource）：资源是一个节点可以控制的实体，当节点发生故障时，这些资源能够被其他节点接管。如：磁盘分区、文件系统、IP 地址、应用程序服务、共享存储

事件（event）：事件也就是集群中可能发生的事情，例如节点系统故障、网络连通故障、网卡故障和应用程序故障等。这些事件都会导致节点的资源发生转移，HA 的测试也是基于这些事件进行的。

什么是集群

集群（cluster）就是一组计算机，它们作为一个整体向用户提供一组网络资源，这些单个的计算机系统就是集群的节点（node）。集群提供了以下关键的特性。

(一) 可扩展性。集群的性能不限于单一的服务实体，新的服务实体可以动态的加入到集群，从而增强集群的性能。

(二) 高可用性。集群通过服务实体冗余使客户端免于轻易遭遇到“out of service”警告。当一台节点服务器发生故障的时候，这台服务器上所运行的应用程序将在另一节点服务器上被自动接管。消除单点故障对于增强数据可用性、可达性和可靠性是非常重要的。

(三) 负载均衡。负载均衡能把任务比较均匀的分布到集群环境下的计算和网络资源，以便提高数据吞吐量。

(四) 错误恢复。如果集群中的某一台服务器由于故障或者维护需要而无法使用，资源和应用程序将转移到可用的集群节点上。这种由于某个节点中的资源不能工作，另一个可用节点中的资源能够透明的接管并继续完成任务的过程叫做错误恢复。

分布式与集群的联系与区别如下：

(一) 分布式是指将不同的业务分布在不同的地方。

(二) 而集群指的是将几台服务器集中在一起，实现同一业务。

(三) 分布式的每一个节点，都可以做集群，而集群并不一定就是分布式的。而分布式，从狭义上理解，也与集群差不多，但是它的组织比较松散，不像集群，有一定组织性，一台服务器宕了，其他的服务器可以顶上来。分布式的每一个节点，都完成不同的业务，一个节点宕了，这个业务就不可访问了。

集群主要分成三大类：

HA：高可用集群（High Availability Cluster）。

LBC：负载均衡集群/负载均衡系统（Load Balance Cluster）

HPC：科学计算集群（High Performance Computing Cluster）/高性能计算（High Performance Computing）集群。

为什么搭建数据库集群

随着经济的高速发展，企业规模的迅猛扩张，企业用户的数量、数据量的爆炸式增长，对数据库提出了严峻的考验。对于所有的数据库而言，除了记录正确的处理结果之外，还面临着以下几方面的挑战。

l 如何提高处理速度，实现数据库的均衡负载。
l 如何保证数据库的可用性、数据安全性、以及如何实现数据集群可扩性。
l 怎么综合解决这些问题成为众多企业关注的焦点。

在数据库上，组建集群也是同样的道理，主要有以下几个原因：

(一) 伴随着企业的成长，业务量提高，数据库的访问量和数据量快速增长，其处理能力和计算速度也相应增大，使得单一的设备根本无法承担。

(二) 在以上情况下，若扔掉现有设备，做大量的硬件升级，势必造成现有资源的浪费，而且下一次业务量提升时，又将面临再一次硬件升级的高额投入。于是，人们希望通过几个中小型服务器组建集群，实现数据库的负载均衡及持续扩展；在需要更高数据库处理速度时，只要简单的增加数据库服务器就可以得到扩展。

(三) 数据库作为信息系统的核心，起着非常重要的作用，单一设备根本无法保证系统的下持续运行，若发生系统故障，将严重影响系统的正常运行，甚至带来巨大的经济损失。于是，人们希望通过组建数据库集群，实现数据库的高可用，当某节点发生故障时，系统会自动检测并转移故障节点的应用，保证数据库的持续工作。

(四) 企业的数据库保存着企业的重要信息，一些核心数据甚至关系着企业的命脉，单一设备根本无法保证数据库的安全性，一旦发生丢失，很难再找回来。于是，人们希望通过组建数据库集群，实现数据集的冗余，通过备份数据来保证安全性。

数据库集群的分类

数据库集群技术是将多台服务器联合起来组成集群来实现综合性能优于单个大型服务器的技术，这种技术不但能满足应用的需要，而且大幅度的节约了投资成本。数据库集群技术分属两类体系：基于数据库引擎的集群技术和基于数据库网关（中间件）的集群技术。在数据库集群产品方面，其中主要包括基于数据库引擎的集群技术的 Oracle RAC、Microsoft MSCS、IBM DB2UDB、Sybase ASE，以及基于数据库网关（中间件）的集群技术的 ICX-UDS 等产品。

一般来讲，数据库集群软件侧重的方向和试图解决的问题划分为三大类：

l 负载均衡集群（Load Balance Cluster，LBC）侧重于数据库的横向扩展，提升数据库的性能。
l 高可用性集群（High Availability Cluster，HAC）侧重保证数据库应用持续不断。大部分的数据库集群侧重与此。
l 高安全性集群（High Security Cluster，HSC）侧重于容灾。

只有 Oracle RAC 能实现以上三方面

可扩展的分布式数据库架构

(一) Oracle RAC：

其架构的最大特点是共享存储架构（Shared-storage），整个 RAC 集群是建立在一个共享的存储设备之上的，节点之间采用高速网络互联。OracleRAC 提供了非常好的高可用特性，比如负载均衡和应用透明切块（TAF），其最大的优势在于对应用完全透明，应用无需修改便可切换到RAC 集群。但是RAC 的可扩展能力有限，首先因为整个集群都依赖于底层的共享存储，所以共享存储的 I/O 能力和可用性决定了整个集群的可以提供的能力，对于 I/O 密集型的应用，这样的机制决定后续扩容只能是 Scale up（向上扩展）类型，对于硬件成本、开发人员的要求、维护成本都相对比较高。Oracle显然也意识到了这个问题，在 Oracle 的 MAA（Maximum Availability Architecture）架构中，采用 ASM 来整合多个存储设备的能力，使得 RAC 底层的共享存储设备具备线性扩展的能力，整个集群不再依赖于大型存储的处理能力和可用性。

RAC 的另外一个问题是，随着节点数的不断增加，节点间通信的成本也会随之增加，当到某个限度时，增加节点可能不会再带来性能上的提高，甚至可能造成性能下降。这个问题的主要原因是 Oracle RAC 对应用透明，应用可以连接集群中的任意节点进行处理，当不同节点上的应用争用资源时，RAC 节点间的通信开销会严重影响集群的处理能力。所以对于使用 ORACLE RAC 有以下两个建议：

l 节点间通信使用高速互联网络；
l 尽可能将不同的应用分布在不同的节点上。

基于这个原因，Oracle RAC 通常在 DSS 环境（决策支持系统Decision Support System ，简称DSS)中可以做到很好的扩展性，因为 DSS 环境很容易将不同的任务分布在不同计算节点上，而对于 OLTP 应用（On-Line Transaction Processing联机事务处理系统），Oracle RAC 更多情况下用来提高可用性，而不是为了提高扩展性。

(二) MySQL Cluster

MySQL cluster 和 Oracle RAC 完全不同，它采用无共享架构Shared nothing（shared nothing architecture）。整个集群由管理节点(ndb_mgmd)，处理节点(mysqld)和存储节点(ndbd)组成，不存在一个共享的存储设备。MySQL cluster 主要利用了 NDB 存储引擎来实现，NDB 存储引擎是一个内存式存储引擎，要求数据必须全部加载到内存之中。数据被自动分布在集群中的不同存储节点上，每个存储节点只保存完整数据的一个分片(fragment)。同时，用户可以设置同一份数据保存在多个不同的存储节点上，以保证单点故障不会造成数据丢失。MySQL cluster 主要由 3 各部分组成：

l SQL 服务器节点
l NDB 数据存储节点
l 监控和管理节点

这样的分层也是与 MySQL 本身把 SQL 处理和存储分开的架构相关系的。MySQL cluster 的优点在于其是一个分布式的数据库集群，处理节点和存储节点都可以线性增加，整个集群没有单点故障，可用性和扩展性都可以做到很高，更适合 OLTP 应用。但是它的问题在于：

l NDB（“NDB” 是一种“内存中”的存储引擎，它具有可用性高和数据一致性好的特点。）存储引擎必须要求数据全部加载到内存之中，限制比较大，但是目前 NDB 新版本对此做了改进，允许只在内存中加载索引数据，数据可以保存在磁盘上。
l 目前的 MySQL cluster 的性能还不理想，因为数据是按照主键 hash 分布到不同的存储节点上，如果应用不是通过主键去获取数据的话，必须在所有的存储节点上扫描，返回结果到处理节点上去处理。而且，写操作需要同时写多份数据到不同的存储节点上，对节点间的网络要求很高。

虽然 MySQL cluster 目前性能还不理想，但是 share nothing 的架构一定是未来的趋势，Oracle 接手 MySQL之后，也在大力发展 MySQL cluster，我对 MySQL cluster 的前景抱有很大的期待。

(三) 分布式数据库架构

MySQL 5 之后才有了数据表分区功能（Sharding）， Sharding 不是一个某个特定数据库软件附属的功能，而是在具体技术细节之上的抽象处理，是水平扩展(Scale Out，亦或横向扩展、向外扩展)的解决方案，其主要目的是为突破单节点数据库服务器的 I/O 能力限制，解决数据库扩展性问题。比如 Oracle 的 RAC 是采用共享存储机制，对于 I/O 密集型的应用，瓶颈很容易落在存储上，这样的机制决定后续扩容只能是 Scale Up（向上扩展）类型，对于硬件成本、开发人员的要求、维护成本都相对比较高。Sharding 基本上是针对开源数据库的扩展性解决方案，很少有听说商业数据库进行 Sharding 的。目前业界的趋势基本上是拥抱 Scale Out，逐渐从 Scale Up 中解放出来。

Sharding 架构的优势在于，集群扩展能力很强，几乎可以做到线性扩展，而且整个集群的可用性也很高，部分节点故障，不会影响其他节点提供服务。Sharding 原理简单，容易实现，是一种非常好的解决数据库扩展性的方案。Sharding 并不是数据库扩展方案的银弹，也有其不适合的场景，比如处理事务型的应用它可能会造成应用架构复杂或者限制系统的功能，这也是它的缺陷所在。读写分离是架构分布式系统的一个重要思想。不少系统整体处理能力并不能同业务的增长保持同步，因此势必会带来瓶颈，单纯的升级硬件并不能一劳永逸。针对业务类型特点，需要从架构模式进行一系列的调整，比如业务模块的分割，数据库的拆分等等。集中式和分布式是两个对立的模式，不同行业的应用特点也决定了架构的思路。如互联网行业中一些门户站点，出于技术和成本等方面考虑，更多的采用开源的数据库产品(如 MYSQL)，由于大部分是典型的读多写少的请求，因此为 MYSQL 及其复制技术大行其道提供了条件。而相对一些传统密集交易型的行业，比如电信业、金融业等，考虑到单点处理能力和可靠性、稳定性等问题，可能更多的采用商用数据库，比如 DB2、Oracle 等。就数据库层面来讲，大部分传统行业核心库采用集中式的架构思路，采用高配的小型机做主机载体，因为数据库本身和主机强大的处理能力，数据库端一般能支撑业务的运转，因此，Oracle 读写分离式的架构相对MYSQL 来讲，相对会少。读写分离架构利用了数据库的复制技术，将读和写分布在不同的处理节点上，从而达到提高可用性和扩展性的目的。最通常的做法是利用 MySQL Replication 技术，Master DB 承担写操作，将数据变化复制到多台 Slave DB上，并承担读的操作。这种架构适合 read-intensive 类型的应用，通过增加 Slave DB 的数量，读的性能可以线性增长。为了避免 Master DB 的单点故障，集群一般都会采用两台 Master DB 做双机热备，所以整个集群的读和写的可用性都非常高。除了 MySQL，Oracle 从 11g 开始提供 Active Standby 的功能，也具备了实现读写分离架构的基础。读写分离架构的缺陷在于，不管是 Master 还是 Slave，每个节点都必须保存完整的数据，如果在数据量很大的情况下，集群的扩展能力还是受限于单个节点的存储能力，而且对于 Write-intensive 类型的应用，读写分离架构并不适合。

采用 Oracle 读写分离的思路，Writer DB 和 Reader DB 采用日志复制软件实现实时同步； Writer DB 负责交易相关的实时查询和事务处理，Reader DB 负责只读接入，处理一些非实时的交易明细,报表类的汇总查询等。同时，为了满足高可用性和扩展性等要求，对读写端适当做外延，比如 Writer DB 采用 HA 或者 RAC 的架构模式，目前，除了数据库厂商的集群产品以外，解决数据库扩展能力的方法主要有两个：数据分片和读写分离。数据分片(Sharding)的原理就是将数据做水平切分，类似于 hash 分区的原理，通过应用架构解决访问路由和Reader DB 可以采用多套，通过负载均衡或者业务分离的方式，有效分担读库的压力。

对于 Shared-nothing 的数据库架构模式，核心的一个问题就是读写库的实时同步；另外，虽然 Reader DB只负责业务查询，但并不代表数据库在功能上是只读的。只读是从应用角度出发，为了保证数据一致和冲突考虑，因为查询业务模块可能需要涉及一些中间处理，如果需要在数据库里面处理(取决与应用需求和设计)，所以Reader DB 在功能上仍然需要可写。下面谈一下数据同步的技术选型问题：

能实现数据实时同步的技术很多，基于 OS 层(例如 VERITAS VVR)，基于存储复制(中高端存储大多都支持)，基于应用分发或者基于数据库层的技术。因为数据同步可能并不是单一的 DB 整库同步，会涉及到业务数据选择以及多源整合等问题，因此 OS 复制和存储复制多数情况并不适合做读写分离的技术首选。基于日志的 Oracle 复制技术，Oracle 自身组件可以实现，同时也有成熟的商业软件。选商业的独立产品还是 Oracle 自身的组件功能，这取决于多方面的因素。比如团队的相应技术运维能力、项目投入成本、业务系统的负载程度等。

采用 Oracle 自身组件功能，无外乎 Logical Standby、Stream 以及 11g 的 Physical Standby(Active Data Guard)，对比来说，Stream 最灵活，但最不稳定，11g Physical Standby 支持恢复与只读并行，但由于并不是日志的逻辑应用机制，在读写分离的场景中最为局限。如果技术团队对相关技术掌握足够充分，而选型方案的处理能力又能支撑数据同步的要求，采用 Oracle 自身的组件完全可行。选择商业化的产品，更多出于稳定性、处理能力等考虑。市面上成熟的 Oracle 复制软件也无外乎几种，无论是老牌的 Shareplex，还是本土 DSG 公司的 RealSync 和九桥公司的 DDS，或是 Oracle 新贵 Goldengate，都是可供选择的目标。随着 GoldenGate 被 Oracle 收购和推广，个人认为 GoldenGate 在容灾、数据分发和同步方面将大行其道。当然，架构好一个可靠的分布式读写分离的系统，还需要应用上做大量设计，不在本文讨论范围内。

(四) CAP 和 BASE 理论

分布式领域 CAP 理论：

l Consistency(一致性), 数据一致更新，所有数据变动都是同步的
l Availability(可用性), 好的响应性能
l Partition tolerance(分区容错性) 可靠性

定理：任何分布式系统只可同时满足二点，没法三者兼顾。

忠告：架构师不要将精力浪费在如何设计能满足三者的完美分布式系统，而是应该进行取舍。

关系数据库的 ACID 模型拥有高一致性 + 可用性很难进行分区：

l Atomicity 原子性：一个事务中所有操作都必须全部完成，要么全部不完成。
l Consistency 一致性. 在事务开始或结束时，数据库应该在一致状态。
l Isolation 隔离层. 事务将假定只有它自己在操作数据库，彼此不知晓。
l Durability. 一旦事务完成，就不能返回。

(五) 跨数据库事务

2PC (two-phase commit)， 2PC is the anti-scalability pattern (Pat Helland) 是反可伸缩模式的，也就是说传统关系型数据库要想实现一个分布式数据库集群非常困难，关系型数据库的扩展能力十分有限。而近年来不断发展壮大的 NoSQL（非关系型的数据库）运动，就是通过牺牲强一致性，采用 BASE 模型，用最终一致性的思想来设计分布式系统，从而使得系统可以达到很高的可用性和扩展性。那么，有没有可能实现一套分布式数据库集群，既保证可用性和一致性，又可以提供很好的扩展能力呢？

BASE 思想的主要实现有按功能划分数据库 sharding 碎片BASE 思想主要强调基本的可用性，如果你需要 High 可用性，也就是纯粹的高性能，那么就要以一致性或容错性为牺牲，BASE 思想的方案在性能上还是有潜力可挖的。

l 共同点：都是关系数据库 SQL 以外的可选方案，逻辑随着数据分布，任何模型都可以自己持久化，将数据处理和数据存储分离，将读和写分离，存储可以是异步或同步，取决于对一致性的要求程度。
l 不同点：NOSQL 之类的 Key-Value 存储产品是和关系数据库头碰头的产品 BOX，可以适合非 Java 如 PHP RUBY等领域，是一种可以拿来就用的产品，而领域模型 + 分布式缓存 + 存储是一种复杂的架构解决方案，不是产品，但这种方式更灵活，更应该是架构师必须掌握的。

目前，已经有很多分布式数据库的产品，但是绝大部分是面向 DSS 类型的应用，因为相比较 OLTP 应用，DSS 应用更容易做到分布式扩展，比如基于 PostgreSQL 发展的 Greenplum，就很好的解决了可用性和扩展性的问题，并且提供了很强大的并行计算能力。对于 OLTP 应用，业务特点决定其要求：高可用性，一致性，响应时间短，支持事务和 join 等等。数据库和 NoSQL当越来越多的 NoSQL 产品涌现出来，它们具备很多关系型数据库所不具备的特性，在可用性和扩展性方面都可以做到很好。

第一，NoSQL 的应用场景非常局限，某个类型的 NoSQL 仅仅针对特定类型的应用场景而设计。而关系型数据库则要通用的多，使用 NoSQL 必须搞清楚自己的应用场景是否适合。

第二，利用关系型数据库配合应用架构，比如 Sharding 和读写分离技术，同样可以搭建出具备高可用和扩展性的分布式数据库集群。

第三，关系型数据库厂商依然很强大，全世界有大量的用户，需求必然会推动新的产品问世。

第四，硬件的发展日新月异，比如闪存的技术的不断成熟，未来闪存可以作为磁盘与内存之间的 cache，或者完全替代磁盘。而内存价格越来越低，容量越来越大，In-memory cache 或 database 的应用越来越广泛，可以给应用带来数量级的性能提升。数据库面临的 IO 问题将被极大改善。

Oracle集群概念和原理

Oracle的三种高可用集群方案

1 RAC（Real Application Clusters）

多个Oracle服务器组成一个共享的Cache，而这些Oracle服务器共享一个基于网络的存储。这个系统可以容忍单机/或是多机失败。不过系统内部的多个节点需要高速网络互连，基本上也就是要全部东西放在在一个机房内，或者说一个数据中心内。如果机房出故障，比如网络不通，那就坏了。所以仅仅用RAC还是满足不了一般互联网公司的重要业务的需要，重要业务需要多机房来容忍单个机房的事故。

2 Data Guard.（最主要的功能是冗灾）

Data Guard这个方案就适合多机房的。某机房一个production的数据库，另外其他机房部署standby的数据库。Standby数据库分物理的和逻辑的。物理的standby数据库主要用于production失败后做切换。而逻辑的standby数据库则在平时可以分担production数据库的读负载。

3 MAA

MAA(Maximum Availability Architecture)其实不是独立的第三种，而是前面两种的结合，来提供最高的可用性。每个机房内部署RAC集群，多个机房间用Data Guard同步。

RAC概述

共享存储文件系统（NFS），或甚至集群文件系统（如：OCFS2）主要被用于存储区域网络（所有节点直接访问共享文件系统上存储器），这就使得节点失效而不影响来自其他节点对文件系统的访问，通常，共享磁盘文件系统用于高可用集群。

Oracle RAC的核心是共享磁盘子系统，集群中所有节点必须能够访问所有数据、重做日志文件、控制文件和参数文件，数据磁盘必须是全局可用的，允许所有节点访问数据库，每个节点有它自己的重做日志和控制文件，但是其他节点必须能够访问它们以便在那个节点出现系统故障时能够恢复。

Oracle RAC 运行于集群之上，为 Oracle 数据库提供了最高级别的可用性、可伸缩性和低成本计算能力。如果集群内的一个节点发生故障，Oracle 将可以继续在其余的节点上运行。Oracle 的主要创新是一项称为高速缓存合并的技术。高速缓存合并使得集群中的节点可以通过高速集群互联高效地同步其内存高速缓存，从而最大限度地低降低磁盘 I/O。高速缓存最重要的优势在于它能够使集群中所有节点的磁盘共享对所有数据的访问。数据无需在节点间进行分区。Oracle 是唯一提供具备这一能力的开放系统数据库的厂商。其它声称可以运行在集群上的数据库软件需要对数据库数据进行分区，显得不切实际。企业网格是未来的数据中心，构建于由标准化商用组件构成的大型配置之上，其中包括：处理器、网络和存储器。Oracle RAC 的高速缓存合并技术提供了最高等级的可用性和可伸缩性。Oracle 数据库 10g 和 OracleRAC 10g 显著降低了运营成本，增强了灵活性，从而赋予了系统更卓越的适应性、前瞻性和灵活性。动态提供节点、存储器、CPU 和内存可以在实现所需服务级别的同时，通过提高的利用率不断降低成本。

RAC 集成集群件管理

Oracle RAC 10g 在 Oracle 数据库 10g 运行的所有平台上提供了一个完整集成的集群件管理解决方案。这一集群件功能包括集群连接、消息处理服务和锁定、集群控制和恢复，以及一个工作负载管理框架（将在下文探讨）。Oracle RAC 10g 的集成集群件管理具有以下优势：

(一) 成本低。Oracle 免费提供这一功能。

(二) 单一厂商支持。消除了相互推诿的问题。

(三) 安装、配置和持续维护更简单。Oracle RAC 10g 集群件使用标准 Oracle 数据库管理工具进行安装、配置和维护。这一过程无须其它的集成步骤。

(四) 所有平台，质量始终如一。与第三方产品相比，Oracle 对新软件版本进行了更严格的测试。

(五) 所有平台，功能始终如一。例如，一些第三方集群件产品限制了集群内可以支持的节点的数量。借助Oracle RAC 10g，所有平台可以支持多达 64 个节点。用户还可以在所有平台上获得一致的响应体验，从而有效解决了高可用性挑战，包括服务器节点故障、互连故障以及 I/O 隔离现象等。

(六) 支持高级功能。这包括集成监视和通知功能，从而在发生故障时，在数据库和应用层之间实现快速协调的恢复。

RAC 的体系结构

RAC 是 Oracle 数据库的一个群集解决方案，是有着两个或者两个以上的数据库节点协调运作能力的。如下图所示的 RAC 结构图：

集群管理器（Cluster Manager）在集群系统中对其他各个模块进行整合，通过高速的内连接来提供群集节点之间的通信。各节点之间内连接使用心跳线互联，心跳线上的信息功能确定群集逻辑上的节点成员信息和节点更新情况，以及节点在某个时间点的运行状态，保证群集系统正常运行。通信层管理节点之间的通信。它的职责是配置，互联群集中节点信息，在群集管理器中使用由心跳机制产生的信息，由通信层负责传输，确保信息的正确到达。还有一些群集监视进程不断验证系统的不同领域运行状况。例如，心跳监测不断验证的心跳机制的运作是否良好。在一个应用环境当中，所有的服务器使用和管理同一个数据库，目的是分散每一台服务器的工作量。硬件上至少需要两台以上的服务器，而且还需要一个共享存储设备；同时还需要两类软件，一类是集群软件，另外一类就是 Oracle 数据库中的 RAC 组件。同时所有服务器上的 OS 都应该是同一类 OS，根据负载均衡的配置策略，当一个客户端发送请求到某一台服务的 listener 后，这台服务器根据负载均衡策略，会把请求发送给本机的 RAC组件处理，也可能会发送给另外一台服务器的 RAC 组件处理，处理完请求后，RAC 会通过群集软件来访问共享存储设备。逻辑结构上看，每一个参加群集的节点有一个独立的实例，这些实例访问同一个数据库。节点之间通过集群软件的通信层（Communication Layer）来进行通信。同时为了减少 I/O 的消耗，存在一个全局缓存服务，因此每一个数据库的实例，都保留了一份相同的数据库 cache。RAC 中的特点如下：

l  每一个节点的实例都有自己的 SGA；
l  每一个节点的实例都有自己的后台进程
l  每一个节点的实力都有自己的 redo logs
l  每一个节点的实例都有自己的 undo 表空间
l  所有节点都共享一份 datafiles 和 controlfiles

RAC 的结构组成和机制

在 Oracle9i 之前，RAC 称为 OPS（Oracle Parallel Server）。RAC 与 OPS 之间的一个较大区别是，RAC 采用了Cache Fusion（高缓存合并）技术，节点已经取出的数据块更新后没有写入磁盘前，可以被另外一个节点更新，然后以最后的版本写入磁盘。在 OPS 中，节点间的数据请求需要先将数据写入磁盘，然后发出请求的节点才可以读取该数据。使用 Cache Fusion 时，RAC 的各个节点间数据缓冲区通过高速、低延迟的内部网络进行数据块的传输。下图是一个典型的 RAC 对外服务的示意图，一个 Oracle RAC Cluster 包含了如下的部分

集群的节点（Cluster node）——2 个到 N 个节点或者主机运行 Oracle Database Server。
私有网络（Network Interconnect）——RAC 之间需要一个高速互联的私有网络来处理通信和 Cache Fusion。
共享存储（shared Storage）——RAC 需要共享存储设备让所有的节点都可以访问数据文件。
对外服务的网络（Production Network）——RAC 对外服务的网络。客户端和应用都通过这个网络来访问。

RAC 后台进程

Oracle RAC 有一些自己独特的后台进程，在单一实例中不发挥配置作用。如下图所示，定义了一些 RAC 运行的后台进程。这些后台进程的功能描述如下。

（1）LMS（Global cache service processes 全局缓存服务进程）进程主要用来管理集群内数据块的访问，并在不同实例的 Buffer Cache 中传输数据块镜像。直接从控制的实例的缓存复制数据块，然后发送一个副本到请求的实例上。并保证在所有实例的 Buffer Cache 中一个数据块的镜像只能出现一次。LMS 进程靠着在实例中传递消息来协调数据块的访问，当一个实例请求数据块时，该实例的 LMD 进程发出一个数据块资源的请求，该请求指向主数据块的实例的 LMD 进程，主实例的 LMD 进程和正在使用的实例的 LMD 进程释放该资源，这时拥有该资源的实例的 LMS 进程会创建一个数据块镜像的一致性读然后把该数据块传递到请求该资源的实例的BUFFER CACHE 中。LMS 进程保证了在每一时刻只能允许一个实例去更新数据块，并负责保持该数据块的镜像记录（包含更新数据块的状态 FLAG)。RAC 提供了 10 个 LMS 进程（0~9），该进程数量随着节点间的消息传递的数据的增加而增加。（2）LMON（Lock Monitor Process，锁监控进程）是全局队列服务监控器，各个实例的 LMON 进程会定期通信，以检查集群中各个节点的健康状况，当某个节点出现故障时，负责集群重构、GRD 恢复等操作，它提供的服务叫做 Cluster Group Service（CGS）。

LMON 主要借助两种心跳机制来完成健康检查。

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

(二) 通过控制文件的磁盘心跳（controlfile heartbeat）：每个节点的 CKPT 进程每隔 3 秒钟更新一次控制文件的数据块，这个数据块叫做 Checkpoint Progress Record，控制文件是共享的，所以实例间可以互相检查对方是否及时更新来判断。

(三) LMD（the global enqueue service daemon，锁管理守护进程）是一个后台进程，也被称为全局的队列服务守护进程，因为负责对资源的管理要求来控制访问块和全局队列。在每一个实例的内部，LMD 进程管理输入的远程资源请求（即来自集群中其他实例的锁请求）。此外，它还负责死锁检查和监控转换超时。

(四) LCK（the lock process，锁进程）管理非缓存融合，锁请求是本地的资源请求。LCK 进程管理共享资源的实例的资源请求和跨实例调用操作。在恢复过程中它建立一个无效锁元素的列表，并验证锁的元素。由于处理过程中的 LMS 锁管理的首要职能，只有一个单一的 LCK 进程存在每个实例中。

(五) DIAG（the diagnosability daemon，诊断守护进程）负责捕获 RAC 环境中进程失败的相关信息。并将跟踪信息写出用于失败分析，DIAG 产生的信息在与 Oracle Support 技术合作来寻找导致失败的原因方面是非常有用的。每个实例仅需要一个 DIAG 进程。

(六) GSD（the global service daemon，全局服务进程）与 RAC 的管理工具 dbca、srvctl、oem 进行交互，用来完成实例的启动关闭等管理事务。为了保证这些管理工具运行正常必须在所有的节点上先start gsd，并且一个 GSD 进程支持在一个节点的多个 rac.gsd 进程位ORACLEHOME/bin目录下，其log文件为

ORACLE_HOME/srvm/log/gsdaemon.log。GCS 和 GES 两个进程负责通过全局资源目录（Global Resource Directory GRD）维护每个数据的文件和缓存块的状态信息。当某个实例访问数据并缓存了数据之后，集群中的其他实例也会获得一个对应的块镜像，这样其他实例在访问这些数据是就不需要再去读盘了，而是直接读取 SGA 中的缓存。GRD 存在于每个活动的 instance 的内存结构中，这个特点造成 RAC 环境的 SGA 相对于单实例数据库系统的 SGA 要大。其他的进程和内存结构都跟单实例数据库差别不大。

RAC 共享存储

RAC 需要有共享存储，独立于实例之外的信息，如上面提到的ocr 和 votedisk 以及数据文件都存放在这个共享存储里的。有OCFS、OCFS2、RAW、NFS、ASM 等这样的一些存储方式。OCFS（Oracle Cluster File System）和 OCFS2 就是一个文件系统而已，和 NFS 一样，提供一种集群环境中的共享存储的文件系统。RAW 裸设备也是一种存储方式，是 oracle11g 之前的版本中 RAC 支持的存储方式，在 Oralce9i 之前，OPS/RAC的支持只能使用这样的方式，也就是把共享存储映射到 RAW Device，然后把 Oracle 需要的数据选择 RAW device存储，但是 RAW 相对于文件系统来说不直观，不便于管理，而且 RAW Device 有数量的限制，RAW 显然需要有新的方案来代替，这样就有了 OCFS 这样的文件系统。当然，这只是 Oracle 自己的实现的集文件系统而已，还有其他厂商提供的文件系统可以作为存储的选择方案。ASM 只是数据库存储的方案而已，并不是 cluster 的方案，所以这里 ASM 应该是区别于 RAW 和 OCFS/OCFS2同一级别的概念，RAW 和 OCFS/OCFS2 不仅可以作为数据库存储的方案，同时也可以作为 Clusterware 里的存储方案，是 CRS 里需要的 storage，而 ASM 仅作为数据库的存储而已，严格来说仅是 RAC 中的一个节点应用（nodeapps）。ASM 对于 clusterware 安装时需要的 ocr 和 votedisk 这两项还不支持，毕竟 ASM 本身就需要一个实例，而 CRS 是完全在架构之外的，这也就是为什么使用了 ASM 的方案，却总还要加上 OCFS/OCFS2 和 RAW 其中的一个原因。各种 RAC 共享存储方式的对比如下：

集群文件系统——支持 windows 和 Linux 的 OCFS/OCFS2
AIX 下的 GPFS 等方式——优点是管理方便，表示也很直观，但缺点是基于文件系统管理软件，又要经过 OS 的 cache 处理，性能上和稳定性上都有欠缺，所以不适合在生产环境下使用。可以支持 CRS 集群软件文件和数据库文件。
RAW 裸设备方式——通过硬件支持的共享存储系统，直接用 RAW 设备存储，可以支持集群软件文件和数据库文件。
网络文件系统（NFS）——通过 NFS 实现共享存储，不过需要经过 Oracle 认证的 NFS 才行，可以支持CRS 集群软件文件和数据库文件。
ASM——集合 RAW 方式 I/O 高性能和集群文件系统易管理等优点，Oracle10g 下推出的共享存储方式，但是本身 ASM 就是需要 Oracle 的实例支持，所以 ASM 仅支持数据库文件，而不支持 CRS 文件。

RAC 数据库和单实例数据库的区别

为了让 RAC 中的所有实例能够访问数据库，所有的 datafiles、control files、PFILE/Spfile 和 redo log files 必须保存在共享磁盘上，并且要都能被所有节点同时访问，就涉及到裸设备和集群文件系统等。RAC database 在结构上与单实例的不同之处：至少为每个实例多配置一个 redo 线程，比如：两个实例组成的集群至少要 4 个 redo log group。每个实例两个 redo group。另外要为每一个实例准备一个 UNDO 表空间。

1、redo 和 undo，每个实例在做数据库的修改时谁用谁的 redo 和 undo 段，各自锁定自己修改的数据，把不同实例的操作相对的独立开就避免了数据不一致。后面就要考虑备份或者恢复时 redo log 和归档日志在这种情况下的特殊考虑了。

2、内存和进程各个节点的实例都有自己的内存结构和进程结构.各节点之间结构是基本相同的.通过 Cache Fusion（缓存融合）技术，RAC 在各个节点之间同步 SGA 中的缓存信息达到提高访问速度的效果也保证了一致性

RAC 工作原理和相关组件

OracleRAC 是多个单实例在配置意义上的扩展，实现由两个或者多个节点（实例）使用一个共同的共享数据库（例如，一个数据库同时安装多个实例并打开）。在这种情况下，每一个单独的实例有它自己的 cpu 和物理内存，也有自己的 SGA 和后台进程。和传统的 oracle 实例相比，在系统全局区（SYSTEM CLOBAL AREA,SGA）与后台进程有着显著的不同。最大的不同之处在于多了一个GRD,GRD内存块主要是记录此rac有多少个集群数据库与系统资源，同时也会记录数据块的相关信息，因为在 rac 架构中，每个数据块在每一个 SGA 中都有一份副本，而 rac 必须知道这些数据块的位置，版本，分布以及目前的状态，这些信息就存放在 GRD 中，但 GRD 只负责存放不负责管理，管理的责任则交给后台进程 GCS 和 GES 来进行。Oracle 的多个实例访问一个共同的共享数据库。每个实例都有自己的 SGA、PGA 和后台进程，这些后台进程应该是熟悉的，因为在 RAC 配置中，每个实例将需要这些后台进程运行支撑的。可以从以下几个方面了解 RAC工作原理和运行机制。

(一) SCN

SCN 是 Oracle 用来跟踪数据库内部变化发生先后顺序的机制，可以把它想象成一个高精度的时钟，每个 Redo日志条目，Undo Data Block，Data Block 都会有 SCN 号。 Oracle 的Consistent-Read， Current-Read，Multiversion-Block 都是依赖 SCN 实现。在 RAC 中，有 GCS 负责全局维护 SCN 的产生，缺省用的是 Lamport SCN 生成算法，该算法大致原理是：在所有节点间的通信内容中都携带 SCN，每个节点把接收到的 SCN 和本机的 SCN 对比，如果本机的 SCN 小，则调整本机的 SCN 和接收的一致，如果节点间通信不多，还会主动地定期相互通报。故即使节点处于 Idle 状态，还是会有一些 Redo log 产生。还有一个广播算法（Broadcast），这个算法是在每个 Commit 操作之后，节点要想其他节点广播 SCN，虽然这种方式会对系统造成一定的负载，但是确保每个节点在 Commit 之后都能立即查看到 SCN.这两种算法各有优缺点，Lamport 虽然负载小，但是节点间会有延迟，广播虽然有负载，但是没有延迟。Oracle 10g RAC 缺省选用的是 BroadCast 算法，可以从 alert.log 日志中看到相关信息：Picked broadcast on commit scheme to generate SCNS

(二) RAC 的 GES/GCS 原理

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

全局内存服务（GCS)，控制对数据块的访问。GES 是分布式锁管理器(DLM)的扩展，它是这样一个机制，可以用来管理 oracle 并行服务器的锁和数据块。在一个群集环境中，你需要限制对数据库资源的访问，这些资源在单 instance 数据库中被 latches 或者 locks 来保护。比如说，在数据库字典内存中的对象都被隐性锁所保护，而在库高速缓存中的对象在被引用的时候，必须被 pin 所保护。在 RAC 群集中，这些对象代表了被全局锁所保护的资源。GES 是一个完整的 RAC 组件，它负责和群集中的实例全局锁进行沟通，每个资源有一个主节点实例，这个实例记录了它当前的状态。而且，资源的当前的状态也记录在所有对这个资源有兴趣的实例上。GCS,是另一个 RAC 组件，负责协调不同实例间对数据块的访问。对这些数据块的访问以及跟新都记录在全局目录中（GRD）,这个全局目录是一个虚拟的内存结构，在所有的实例中使用扩张。每个块都有一个master实例，这个实例负责对GSD的访问进行管理，GSD里记录了这个块的当前状态信息。GCS 是 oracle 用来实施 Cache fusion 的机制。被 GCS 和 GES 管理的块和锁叫做资源。对这些资源的访问必须在群集的多个实例中进行协调。这个协调在实例层面和数据库层面都有发生。实例层次的资源协调叫做本地资源协调；数据库层次的协调叫做全局资源协调。

本地资源协调的机制和单实例 oracle 的资源协调机制类似，包含有块级别的访问，空间管理，dictionary cache、library cache 管理，行级锁，SCN 发生。全局资源协调是针对 RAC 的，使用了 SGA 中额外的内存组件、算法和后台进程。GCS 和 GES 从设计上就是在对应用透明的情况下设计的。换一句话来说，你不需要因为数据库是在 RAC上运行而修改应用,在单实例的数据库上的并行机制在 RAC 上也是可靠地。

支持 GCS 和 GES 的后台进程使用私网心跳来做实例之间的通讯。这个网络也被 Oracle 的群集组件使用，也有可能被群集文件系统（比如 OCFS)所使用。GCS 和 GES 独立于 Oracle 群集组件而运行。但是，GCS 和GES 依靠这些群集组件获得群集中每个实例的状态。如果这些信息不能从某个实例获得，这个实例将被关闭。这个关闭操作的目的是保护数据库的完整性，因为每个实例需要知道其他实例的情况，这样可以更好的确定对数据库的协调访问。GES 控制数据库中所有的 library cache 锁和 dictionary cache 锁。这些资源在单实例数据库中是本地性的，但是到了 RAC 群集中变成了全局资源。全局锁也被用来保护数据的结构，进行事务的管理。一般说来，事务和表锁在 RAC 环境或是单实例环境中是一致的。

Oracle 的各个层次使用相同的 GES 功能来获得，转化以及释放资源。在数据库启动的时候，全局队列的个数将被自动计算。GES 使用后台进程 LMD0 和 LCK0 来执行它的绝大多数活动。一般来说，各种进程和本地的 LMD0 后台进程沟通来管理全局资源。本地的 LMD0 后台进程与别的实例上的 LMD0 进程进行沟通。

LCK0 后台进程用来获得整个实例需要的锁。比如，LCK0 进程负责维护 dictionary cache 锁。影子进程(服务进程）与这些后台进程通过 AST(异步陷阱）消息来通信。异步消息被用来避免后台进程的阻塞，这些后台进程在等待远端实例的的回复的时候将阻塞。后台进程也能发送 BAST(异步锁陷阱）来锁定进程，这样可以要求这些进程把当前的持有锁置为较低级限制的模式。资源是内存结构，这些结构代表了数据库中的组件，对这些组件的访问必须为限制模式或者串行化模式。换一句话说，这个资源只能被一个进程或者一直实例并行访问。如果这个资源当前是处于使用状态，其他想访问这个资源的进程必须在队列中等待，直到资源变得可用。队列是内存结构，它负责并行化对特殊资源的访问。如果这些资源只被本地实例需求，那么这个队列可以本地来获得，而且不需要协同。但是如果这个资源被远程实例所请求，那么本地队列必须变成全球化。

ClusterWare 架构

在单机环境下，Oracle 是运行在 OS Kernel 之上的。 OS Kernel 负责管理硬件设备，并提供硬件访问接口。Oracle 不会直接操作硬件，而是有 OS Kernel 代替它来完成对硬件的调用请求。在集群环境下，存储设备是共享的。OS Kernel 的设计都是针对单机的，只能控制单机上多个进程间的访问。如果还依赖 OS Kernel 的服务，就无法保证多个主机间的协调工作。这时就需要引入额外的控制机制，在RAC 中，这个机制就是位于 Oracle 和 OS Kernel 之间的 Clusterware，它会在 OS Kernel 之前截获请求，然后和其他结点上的 Clusterware 协商，最终完成上层的请求。在 Oracle 10G 之前，RAC 所需要的集群件依赖与硬件厂商，比如 SUN,HP,Veritas. 从 Oracle 10.1版本中，Oracle推出了自己的集群产品. Cluster Ready Service(CRS),从此 RAC 不在依赖与任何厂商的集群软件。在 Oracle 10.2版本中，这个产品改名为：Oracle Clusterware。所以我们可以看出，在整个 RAC 集群中，实际上有 2 个集群环境的存在，一个是由 Clusterware 软件组成的集群，另一个是由 Database 组成的集群。

(一) Clusterware 的主要进程

a) CRSD——负责集群的高可用操作，管理的 crs 资源包括数据库、实例、监听、虚拟 IP，ons，gds 或者其他，操作包括启动、关闭、监控及故障切换。改进程由 root 用户管理和启动。crsd 如果有故障会导致系统重启。

b) cssd，管理各节点的关系，用于节点间通信，节点在加入或离开集群时通知集群。该进程由 oracle 用户运行管理。发生故障时 cssd 也会自动重启系统。

c) oprocd – 集群进程管理 —Process monitor for the cluster. 用于保护共享数据 IO fencing。

d) 仅在没有使用 vendor 的集群软件状态下运行

e) evmd ：事件检测进程，由 oracle 用户运行管理

Cluster Ready Service（CRS，集群准备服务）是管理集群内高可用操作的基本程序。Crs 管理的任何事物被称之为资源，它们可以是一个数据库、一个实例、一个监听、一个虚拟 IP（VIP）地址、一个应用进程等等。CRS是根据存储于 OCR 中的资源配置信息来管理这些资源的。这包括启动、关闭、监控及故障切换（start、stop、monitor 及 failover）操作。当一资源的状态改变时，CRS 进程生成一个事件。当你安装 RAC 时，CRS 进程监控Oracle 的实例、监听等等，并在故障发生时自动启动这些组件。默认情况下，CRS 进程会进行 5 次重启操作，如果资源仍然无法启动则不再尝试。Event Management（EVM）：发布 CRS 创建事件的后台进程。Oracle Notification Service（ONS）：通信的快速应用通知（FAN：Fast Application Notification）事件的发布及订阅服务。RACG：为 clusterware 进行功能扩展以支持 Oracle 的特定需求及复杂资源。它在 FAN 事件发生时执行服务器端的调用脚本（server callout script）Process Monitor Daemon（OPROCD）：此进程被锁定在内存中，用于监控集群（cluster）及提供 I/O 防护（I/Ofencing）。OPROCD 执行它的检查，停止运行，且如果唤醒超过它所希望的间隔时，OPROCD 重置处理器及重启节点。一个 OPROCD 故障将导致 Clusterware 重启节点。

Cluster Synchronization Service（CSS）：CSS 集群同步服务，管理集群配置，谁是成员、谁来、谁走，通知成员，是集群环境中进程间通信的基础。同样，CSS 也可以用于在单实例环境中处理 ASM 实例与常规 RDBMS 实例之间的交互作用。在集群环境中，CSS 还提供了组服务，即关于在任意给定时间内哪些节点和实例构成集群的动态信息，以及诸如节点的名称和节点静态信息（这些信息在节点被加入或者移除时被修改）。CSS 维护集群内的基本锁功能（尽管大多数锁有 RDBMS 内部的集成分布式锁管理来维护）。除了执行其他作业外，CSS 还负责在集群内节点间维持一个心跳的程序，并监控投票磁盘的 split-brain 故障。在安装 clusterware 的最后阶段，会要求在每个节点执行 root.sh 脚本，这个脚本会在/etc/inittab 文件的最后把这 3 个进程加入启动项，这样以后每次系统启动时，clusterware 也会自动启动，其中 EVMD 和 CRSD 两个进程如果出现异常，则系统会自动重启这两个进程，如果是 CSSD 进程异常，系统会立即重启。

注意：

1、Voting Disk 和 OCR 必须保存在存储设备上供各个节点访问。

2、Voting Disk、OCR 和网络是安装的过程中或者安装前必须要指定或者配置的。安装完成后可以通过一些工具进行配置和修改。

RAC 软件结构

RAC 软件结构可以分为四部分。

操作系统相关的软件
RAC 共享磁盘部分
RAC 中特别的后台进程和实例进程
全局缓冲区服务和全局队列服务

(一) Operation System-Dependent（OSD）

RAC 通过操作系统的相关软件来访问操作系统和一些与 Cluster 相关的服务进程。OSD 软件可能由 Oracle 提供（windows 平台）或由硬件厂商提供（unix 平台）。OSD 包括三个自部分：

l The Cluster Manager(CM)：集群监视器监视节点间通信，并通过 interconnect 来协调节点操作。同时还提供 CLUSTER 中所有节点和实例的统一视图。CM 还控制 CLUSTER 的成员资格。
l The Node Monitor（节点监视器）：节点监视器提供节点内各种资源的状态，包括节点、interconnect 硬件和软件和共享磁盘等。
l The Interconnect 节点间心跳（两种心跳机制，一种是通过私有网络的 network heartbeat；另一种是通过 voting disk 的 disk heartbeat）

(二) Real Application Cluster Shard Disk Component

RAC 中这部分组件和单实例 Oracle 数据库中的组件没有什么区别。包括一个或者多个控制文件、一些列联机重做日志文件、可选的归档日志文件、数据文件等。在 RAC 中使用服务器参数文件会简化参数文件的管理，可以将全局参数和实例特定的参数存储在同一个文件中。

(三) Real Application Cluster-Specific Daemon and Instance Processes包括以下部分：

The Global Service Daemon（GSD）：在每个节点上都运行一个全局服务后台进程，用于接收客户端如DBCA、EM 等发出的管理消息，并完成相应的管理任务，比如实例的启动和关闭。
RAC 中特别的实例进程： Global Cache Service Processes(LMSn)：控制到远端实例的消息的流量，管理全局数据块的访问。还用于在不同实例的缓冲区之间传递 BLOCK 的映射。
Global Enqueue Service Monitor(LMON)：监视全局队列和集群间的资源交互，执行全局队列的恢复操作。
Global Enqueue Service Daemon(LMD)：管理全局队列和全局资源访问。对于每个实例，LMD 管理来自远端的资源请求。
Lock Processes(LCK)：管理除 Cache Fusion 以外的非数据块资源请求，比如数据文件，控制文件，数据字典试图，library 和 row cache 的请求。
Diagnosability Daemon(DIAG)：在实例中捕获进程失败的诊断数据。

(四) The Global Cache and Global Enqueue Service

全局缓存服务（GCS）和全局队列服务（GES）是 RAC 的集成组件，用于协调对共享数据库和数据库内的共享资源的同时访问。

GCS 和 GES 包括以下特性：

应用透明性。
分布式结构
分布式结构的全局资源目录：只要还存在一个节点，即使出现一个或多个节点失败，GCS 和 GES 仍然可以保证全局资源目录的完整性。
资源控制：GCS 和 GES 会选择一个实例来管理所有的资源信息，这个实例叫做 resource master。GCS和 GES 会根据数据访问方式阶段性的评估和修改 resource master。这种方式会减少网络流量和资源获取时间。
GCS 和 GES 与 CM 之间的交互：GCS 和 GES 独立于 CM。但同时 GCS 和 GES 依赖于 CM 提供的各个节点上实例的状态信息。一旦无法取得某个实例的信息，则 Oracle 会马上关闭没有响应的实例，来保证整个 RAC 的完整性。

集群注册（OCR）

健忘问题是由于每个节点都有配置信息的拷贝，修改节点的配置信息不同步引起的。Oracle 采用的解决方法就是把这个配置文件放在共享的存储上，这个文件就是 OCR Disk。OCR 中保存整个集群的配置信息，配置信息以”Key-Value” 的形式保存其中。在 Oracle 10g 以前，这个文件叫作 Server Manageability Repository(SRVM). 在 Oracle 10g，这部分内容被重新设计，并重名为 OCR.在 Oracle Clusterware 安装的过程中，安装程序会提示用户指定 OCR 位置。并且用户指定的这个位置会被记录在/etc/oracle/ocr.Loc(LinuxSystem) 或者/var/opt/oracle/ocr.Loc(SolarisSystem)文件中。而在 Oracle 9i RAC 中，对等的是 srvConfig.Loc 文件。Oracle Clusterware 在启动时会根据这里面的内容从指定位置读入 OCR 内容。

(一) OCR key

整个 OCR 的信息是树形结构，有 3 个大分支。分别是 SYSTEM,DATABASE 和 CRS。每个分支下面又有许多小分支。这些记录的信息只能由 root 用户修改。

(二) OCR process

Oracle Clusterware 在 OCR 中存放集群配置信息，故 OCR 的内容非常的重要，所有对 OCR 的操作必须确保OCR 内容完整性，所以在 ORACLE Clusterware 运行过程中，并不是所有结点都能操作 OCR Disk.在每个节点的内存中都有一份 OCR 内容的拷贝，这份拷贝叫作 OCR Cache。每个结点都有一个 OCR Process来读写 OCR Cache，但只有一个节点的 OCR process 能读写 OCR Disk 中的内容，这个节点叫作 OCR Master 结点。这个节点的 OCR process 负责更新本地和其他结点的 OCR Cache 内容。所有需要OCR 内容的其他进程，比如OCSSD,EVM等都叫作Client Process，这些进程不会直接访问OCR Cache，而是像 OCR Process发送请求，借助 OCR Process获得内容，如果想要修改 OCR 内容，也要由该节点的 OCR Process像 Master node 的 OCR process 提交申请，由 Master OCR Process 完成物理读写，并同步所有节点 OCR Cache 中的内容。

Oracle 仲裁盘（Voting Disk）

Voting Disk 这个文件主要用于记录节点成员状态，在出现脑裂时，决定那个 Partion 获得控制权，其他的Partion 必须从集群中剔除。在安装 Clusterware 时也会提示指定这个位置。安装完成后可以通过如下命令来查看Voting Disk 位置。$Crsctl query css votedisk

集群的网络连接

一、专用网络

每个集群节点通过专用高速网络连接到所有其他节点，这种专用高速网络也称为集群互联或高速互联 (HSI)。Oracle 的 Cache Fusion 技术使用这种网络将每个主机的物理内存 (RAM) 有效地组合成一个高速缓存。 OracleCache Fusion 通过在专用网络上传输某个 Oracle 实例高速缓存中存储的数据允许其他任何实例访问这些数据。它还通过在集群节点中传输锁定和其他同步信息保持数据完整性和高速缓存一致性。专用网络通常是用千兆以太网构建的，但是对于高容量的环境，很多厂商提供了专门为 Oracle RAC 设计的低延迟、高带宽的专有解决方案。 Linux 还提供一种将多个物理 NIC 绑定为一个虚拟 NIC 的方法（此处不涉及）来增加带宽和提高可用性。

二、公共网络

为维持高可用性，为每个集群节点分配了一个虚拟 IP 地址 (VIP)。如果主机发生故障，则可以将故障节点的 IP 地址重新分配给一个可用节点，从而允许应用程序通过相同的 IP 地址继续访问数据库。

三、Virtual lP（VIP）

即虚拟 IP，Oracle 推荐客户端连接时通过指定的虚拟 IP 连接，这也是 Oracle10g 新推出的一个特性。其本质目的是为了实现应用的无停顿(虽然目前还是有点小问题，但离目标已经非常接近)。用户连接虚 IP，这个 IP并非绑定于网卡，而是由 oracle 进程管理，一旦某个用户连接的虚 IP 所在实例宕机，oracle 会自动将该 IP 映射到状态正常的实例，这样就不会影响到用户对数据库的访问，也无须用户修改应用。Oracle 的 TAF 建立在 VIP 技术之上。IP 和 VIP 区别在与： IP 是利用 TCP 层超时， VIP 利用的是应用层的立即响应。VIP 它是浮动的 IP. 当一个节点出现问题时会自动的转到另一个节点上。

透明应用切换（TAF）

透明应用故障转移（Transport Application Failover，TAF）是 oracle 数据提供的一项，普遍应用于 RAC 环境中，当然也可以用于 Data Guard 和传统的 HA 实现的主从热备的环境中。TAF 中的 Transparent 和 Failover，点出了这个高可用特性的两大特点：

TAF 是用于故障转移的，也就是切换。当 Oracle 连接的会话由于数据库发生故障不可用时，会话能够自动切换到 RAC 中的其他可用的节点上，或者切换到 Standby 上面，或者切换到 HA 方式中的另一个可用的节点上面。
TAF 的故障转移，对应用来说是透明的，应用系统不需要进行特别的处理就能够自动进行故障转移。

但是，TAF 是完美的吗？是不是使用了 TAF，应用就能真的无缝地进行切换呢？对应用和数据库有没有其他什么要求？要回答这些问题，我们需要全面地了解、掌握 TAF。我始终认为，要用好一个东西，首先得掌握这个东西背后的工作原理与机制。首先来看看 Failover。Failover 有两种，一种是连接时 Failover，另一种则是运行时 Failover。前者的作用在于，应用（客户端）在连接数据库时，如果由于网络、实例故障等原因，连接不上时，能够连接数据库中的其他实例。后者的作用在于，对于一个已经在工作的会话（也就是连接已经建立），如果这个会话的实例异常中止等，应用（客户端）能够连接到数据库的其他实例（或备用库）。

连接负载均衡

负载均衡（Load-Banlance）是指连接的负载均衡。RAC 的负载均衡主要指的是新会话连接到 RAC 数据库时，根据服务器节点的 CPU 负载判定这个新的连接要连接到哪个节点进行工作。Oracle RAC 可以提供动态的数据服务，负载均衡分为两种，一种是基于客户端连接的，一种是基于服务器端的。

VIP 的原理和特点

Oracle 的 TAF 建立在 VIP 的技术之上。IP 和 VIP 区别在于：IP 是利用 TCP 层超时，VIP 利用的是应用层的立即响应。VIP 是是浮动的 IP，当一个节点出现问题的时候，会自动的转到另一个节点上。假设有一个两节点的 RAC，正常运行时每个节点上都有一个 VIP，即 VIP1 和 VIP2。当节点 2 发生故障，比如异常关系。RAC 会做如下操作：

(一) CRS 在检测到 rac2 节点异常后，会触发 Clusterware 重构，最后把 rac2 节点剔除集群，由节点 1 组成新的集群。

(二) RAC 的 Failover 机制会把节点 2 的 VIP 转移到节点 1 上，这时节点 1 的 PUBLIC 网卡上就有 3 个 IP 地址：VIP1,VIP2, PUBLIC IP1.

(三) 用户对 VIP2 的连接请求会被 IP 层路由转到节点 1

(四) 因为在节点 1 上有 VIP2 的地址，所有数据包会顺利通过路由层，网络层，传输层。

(五) 但是，节点 1 上只监听 VIP1 和 public IP1 的两个 IP 地址。并没有监听 VIP2，故应用层没有对应的程序接收这个数据包，这个错误立即被捕获。

(六) 客户端能够立即接收到这个错误，然后客户端会重新发起向 VIP1 的连接请求。VIP 特点：

l  VIP 是通过 VIPCA 脚本创建的。
l  VIP 作为 Nodeapps 类型的 CRS Resource 注册到 OCR 中，并由 CRS 维护状态。
l  VIP 会绑定到节点的 public 网卡上，故 public 网卡有 2 个地址。
l  当某个节点发生故障时，CRS 会把故障节点的 VIP 转移到其他节点上。
l  每个节点的 Listener 会同时监听 public 网卡上的 public ip 和 VIP.
l  客户端的 tnsnames.Ora 一般会配置指向节点的 VIP.

日志体系

Redo Thread

RAC 环境下有多个实例，每个实例都需要有自己的一套 Redo Log 文件来记录日志。这套 Redo Log 就叫做 RedoThread，其实单实例下也是 Redo Thread，只是这个词很少被提及，每个实例一套 Redo Thread 的设计就是为了避免资源竞争造成的性能瓶颈。Redo Thread 有两种，一种是 Private，创建语法 alter database add logfile ......thread n；另一种是 public，创建语法：alter database add logfile......；RAC 中每个实例都要设置 thread 参数，该参数默认值为 0。如果设置了这个参数，则使用缺省值 0，启动实例后选择使用 Public Redo Thread，并且实例会用独占的方式使用该 Redo Thread。RAC 中每个实例都需要一个 Redo Thread，每个 Redo Log Thread 至少需要两个 Redo Log Group，每个 Log Group成员大小应该相等，没组最好有 2 个以上成员，这些成员应放在不同的磁盘上，防止单点故障。

注意：在 RAC 环境下，Redo Log Group 是在整个数据库级别进行编号，如果实例 1 有 1,2 两个日志组，那么实例 2 的日志组编号就应该从 3 开始，不能使用 1,2 编号了。在 RAC 环境上，所有实例的联机日志必须放在共享存储上，因为如果某个节点异常关闭，剩下的节点要进行 crash recovery，执行 crash recovery 的这个节点必须能够访问到故障节点的连接日志，只有把联机日志放在共享存储上才能满足这个要求。

Archive log

RAC 中的每个实例都会产生自己的归档日志，归档日志只有在执行 Media Recovery 时才会用到，所以归档日志不必放在共享存储上，每个实例可以在本地存放归档日志。但是如果在单个实例上进行备份归档日志或者进行 Media Recovery 操作，又要求在这个节点必须能够访问到所有实例的归档日志，在 RAC 幻境下，配置归档日志可以有多种选择。

使用 NFS

使用 NFS 的方式将日志直接归档到存储，例如两个节点，每个节点都有 2 个目录，Arch1，Arch2 分别对应实例 1 和实例 2 产生的归档日志。每个实例都配置一个归档位置，归档到本地，然后通过 NFS 把对方的目录挂到本地。

实例间归档（Cross Instance Archive CIA）

实例间归档（Cross Instance Archive）是上一种方式的变种，也是比较常见的一种配置方法。两个节点都创建 2 个目录 Arch1 和 Arch2 分别对应实例 1 和实例 2 产生的归档日志。每个实例都配置两个归档位置。位置 1对应本地归档目录，位置 2 对应另一个实例

使用 ASM

使用 ASM 将日志归档到共享存储，只是通过 Oracle 提供的 ASM，把上面的复杂性隐藏了，但是原理都一样。

Trace 日志

Oracle Clusterware 的辅助诊断，只能从 log 和 trace 进行。而且它的日志体系比较复杂。 alert.log：$ORA_CRS_HOME/log/hostname/alert.Log, 这是首选的查看文件。

Clusterware 后台进程日志

l crsd.Log: $ORA_CRS_HOME/log/hostname/crsd/crsd.Log
l ocssd.Log: $ORA_CRS_HOME/log/hostname/cssd/ocsd.Log
l evmd.Log: $ORA_CRS_HOME/log/hostname/evmd/evmd.Log

Nodeapp 日志位置

ORACRSHOME/log/hostname/racg/这里面放的是nodeapp的日志，包括ONS和VIP，比如：ora.Rac1.ons.Log工具执行日志：

ORA_CRS_HOME/log/hostname/client/

Clusterware 提供了许多命令行工具比如 ocrcheck, ocrconfig,ocrdump,oifcfg 和 clscfg, 这些工具产生的日志就放在这个目录下，还有ORACLEHOME/log/hostname/client/和

ORACLE_HOME/log/hostname/racg 也有相关的日志

Cache Fusion 原理

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

什么是 Cache Fusion？

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，全局队列服务）进程管理使用集群节点之间的数据块同步互联。

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

在所有实例都未读取该块，而第一个实例读取时，是怎么加的锁，加的什么锁？如果此时有另一个实例也要读这个块，几乎是同时的，那么 Oracle 如何来仲裁，如何让其中一个读取，而另一个再从前者的缓存中通过 cache 来得到？
如果一个块已经被其他实例读入，那么本实例如何判断它的存在？
如果某个实例改变了这个数据块，是否会将改变传递到其他实例，或者说其他实例是否会知道并重新更新状态？
如果一个实例要 swapout 某个块，而同时其他实例也有这个块的缓存，修改过的和未修改过的，本实例修改的和其他实例修改的，如何操作? truncate 一张表，drop 一张表... 和单实例有何不同？
应该如何设计应用，以使 RAC 真正发挥作用，而不是引入竞争，导致系统被削弱？
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。它的好处是可以由多个性能较差的机器构建出一个整体性能很好的集群，并且实现了负载均衡，那么当一个节点出现故障时，其上的服务会自动转到另外的节点去执行，用户甚至感觉不到什么。

FAILSAFE 和 RAC 的区别

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 区别

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

双机热备、RAC 和 Data Guard的区别

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

节点间的通信（Interconnect）

通常在 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 的基本结构

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

一致性管理

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

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

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

OCR 结构

(一) OCR KEY 是树形结构。

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

Oracle Clusterware 后台进程

自动启动的脚本/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 平台使用）

RAC 的并发控制

DLM 分布式锁管理。

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

RAC 的主要后台进程

RAC 重构触发条件

(一) NM（NODE MANAGEMENT）group

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

RAC 优缺点

RAC 优点

(一) 多节点负载均衡

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

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

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

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

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

RAC 缺点

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

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

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

出处：http://www.cnblogs.com/baiboy/