oracle_11g_R2_RAC原理解读

oracle 11g RAC 的一些基本概念（一）

总的来说，oracle 11g r2 RAC提供了以下功能：

1. 高可用：shared-everything 模式保证了单节点的故障不会停止服务，集群中的其他节点将快速接管

2. 可扩展性：多节点分担负载，可以提供远超单机数据库能提供的处理能力。且增删节点可以在线完成，不需要停机

3. 易用性：多个数据库可以加入到一个集群中

4. 低成本：RAC可以部署在标准硬件上，硬件上节省的成本抵消了购买license的成本

Oracle 11g r2 还提供了一个叫RAC One Node的新功能。Oracle发现一些RAC的部署纯粹只是为了高可用，而虚拟化越来越多的被用户所使用，并成为了一个新的趋势。Oracle One Node建立在以下基础之上：Oracle Clusterware、Oracle ASM、Oracle database。

我们再来看一眼RAC的结构图

相比较单机数据库，RAC需要一个共享存储；一个私有网络来进行集群内部通讯；一个公有网络来连接应用和客户端；配置虚拟IP来提高节点故障时的连接速度，当一个节点出现故障，它的虚拟ip立即指向其他节点的ip上(若不配置vip，当一个节点发生故障时，新的连接将会发生等待，直到与该节点ip的通讯出现time out)。

Failover的连接配置

有两种连接方式可以实现数据库连接的failover

1. TAF(Transparent Application Failover)

让我们看一下官方文档。TAF让Oracle Net将一个失效的连接从故障点转移到另一个监听上，用户能使用这个新的连接来继续未完成的工作，这是一个client端的功

能。

TAF可以配置为使用client端的(Transparent Network Substrate)TNS连接字符串来连接，或者使用server端的服务。如果两种方式同时使用，则使用server端的服务配置。

TAF可以工作在两种模式下：session failover和select failover。前者在failover时会重建失败的连接，后者则能够继续进程中未完成的查询(如果failover前一个session正在从一个游标中获取数据，则新的session将在相同的snapshot下重新运行select语句，并返回余下的行)。如果failover时，session执行了DML操作且未提交，则failover后，若不执行rollback回滚而执行新的操作，将会收到一条错误信息ORA-25402: transaction must roll back

TAF在dataguard中使用，可以自动进行failover

一个典型的使用了TAF的TNS连接串如下：

NEWSDB =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip)(PORT = 1521))

(ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip)(PORT = 1521))

(LOAD_BALANCE = yes)

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = dyora)

(FAILOVER_MODE =

(TYPE = SELECT)

(METHOD = BASIC)

(RETRIES = 180)

(DELAY = 5)

)

)

)

failover_mode参数介绍

failover_mode参数

BACKUP

说明

备用连接的网络服务名。若使用了preconnect的连接方法，则需要指定这个参数

连接重试的时间间隔(秒)。如果指定了RETRIES参数，若不指定该参数，默认为1秒。若注册了callback，该参数将被忽略

设置failover方法。basic: failover时才尝试连接备用实例的监听；preconnect:

每次连接数据库时，都会在备用实例上也产生一个连接，以实现更快的切换

failover后，尝试连接的次数。如果指定了DELAY参数，则RETRIES默认为5次。若注册了callback，则该参数将被忽略

OCI默认提供了3种类型：session: 若用户连接丢失，将在备用节点上重新创TYPE

建；select: 除了重建连接外，将继续从打开的游标中获取数据，如果采用这种方式，普通select操作也将在客户端产生开销；none: 默认值，也可显示指定来禁用failover功能

DELAY

METHOD

RETRIES

2. FCF(Fast Connect Failover)

oracle11g提供了FCF方式连接数据库，它支持JDBC Thin和JDBC OCI驱动；与连接缓存(implicit connection cache)协同工作提供更高的连接性能和高可用；可以在应用代码中设置，无需另外配置

需要的条件：启用了隐含连接缓存，FCF需要与JDBC的连接缓存机制共同工作，为应用管理连接以确保高可用；应用使用服务名而非服务标识符来连接数据库；JDBC运行的节点上配置并启用了Oracle Notification Service (ONS)；JDBC例程运行的java虚拟机必须包含home并指向ORACLE_HOME

例子：

配置ONS

Configuration("nodes=:4200,:4200");

启用FCF

// declare datasource

(

"jdbc:oracle:oci:@(DESCRIPTION=

(ADDRESS=(PROTOCOL=TCP)(HOST=cluster_alias)

(PORT=1521))

(CONNECT_DATA=(SERVICE_NAME=service_name)))");

r("scott");

nectionCachingEnabled(true);

tConnectionFailoverEnabled(true):

("myDS",ods);

ds=(OracleDataSource) ("MyDS");

try {

nection(); // transparently creates and accesses cache

catch (SQLException SE {

}

}

看糊涂了？上面的java代码包含一个异常处理。工作过程如下：

1. 一个实例宕掉了，在缓存中留下一些过期连接

2. RAC产生一个事件，并将其发送给包含JDBC的java虚拟机

3. JVM中的后台线程找出所有受到该RAC事件影响的所有连接，通过sql异常(ORA-17008)通知它们关闭连接，并回滚事务

4. 连接接收到sql异常并重新执行失败的操作

FCF与TAF相比有如下不同：

1. FCF支持应用级别的连接重试，由应用来决定failover时如何处理，是重新执行，还是抛出异常；TAF只能在OCI/NET的层面进行重新连接

2. FCF与连接缓存很好地结合起来，让连接缓存管理器来管理缓存，失败的连接在缓存中会自动失效。而TAF在网络层面做预连接，当一个连接失效，连接缓存不能检测到

3. FCF基于Oracle RAC事件，可以快速为活跃/闲置的连接检测到故障

4. FCF通过实例的UP事件实现负载均衡，分配到在线的RAC实例中

oracle建议不要在一个应用中同时使用TAF和FCF

oracle 11g RAC 的一些基本概念（二）

集群的相关概念

配置Active/active集群

在这种模式下，所有的节点都能提供服务(不会有用户请求在standby上被闲置的情况)。大部分案例中，集群成员的硬件配置都是相同的，避免可能的性能问题，也更容易实现负载均衡。Active/active集群需要更复杂的管理软件来管理所有资源，比如磁盘和内存需要在所有节点间进行同步。更常见的，一个私有网络被用做心跳连接。集群管理软件必须能够检测到节点问题，比如节点故障或者集群通讯问题

脑裂(split-brain)是集群中的一个糟糕的情况：集群中的所有集群正在工作的时候，内部通讯被断开。这种情况下，集群被分成了几个部分，每个部分的集群软件都会尝试去接管其他节点的资源，因为在它看来，别的节点发生了故障。可能会出现以下问题：如果应用能够正常连接集群的这些部分，因为此时这些集群部分不同步，可能会有不同的数据会被写入到磁盘中。脑裂对集群的危害显而易见，集群软件的供应商必须提供方案来解决这个问题

oracle的集群软件(11g中的Grid Infrastructure)，使用一个仲裁设备(quorum

device)，称作voting disk，来决定集群中的成员。集群中的所有节点共享一个voting

disk，当一个节点不能向内部网络和voting disk发送心跳时，它就会被逐出集群。若一个节点不能和其他节点通讯，但依然能连接到voting disk，集群在这种情况下将进行投票，并发出指令将该节点剔除。这个投票使用的是STONITH方式，软件将发出一个请求，使被踢出的节点自动重启。当需要重启的节点hung住的时候，重启指令变得不可用，这种情况比较棘手。幸运的是，若硬件允许，Grid Infrastructure可以支持IPMI(智能平台管理接口)，可以向一个节点发出结束指令。当一个节点故障或被踢出集群，剩余的节点能够接管用户服务请求。

配置Active/passive集群

一个active/passive集群工作方式与active/active不同。一个active/passive集群中的成员硬件配置依然应该一致或基本一致，但同一时间两个节点中只有一个节点能处理用户请求。集群管理软件会不断地监控集群中资源的健康状况，当一个资源失败，集群管理软件会尝试将该资源重启数次，若还是无效，备用节点将进行接管。

根据安装时的选项，集群的资源可以分配在共享存储或文件系统上，后者在资源failover的时候也会进行一次failover。使用共享文件系统比使用非共享的文件系统更有优势，后者在重新挂载到standby节点上以前可能需要进行fsck(8)检测。Veritas集群套件、Sun(Oracle)集群和IBM的HACMP就可用作安装active/passive集群的集群管理工具。

鲜为人知的是，使用Oracle Grid Infrastructure来安装一个active/passive集群非常简单，利用Grid Infrastructure的应用程序接口和作为集群逻辑卷管理器的Oracle ASM，可以轻松地不间断监控一个单实例oracle数据库。当一个节点发生故障，数据库会自动迁移到备用节点。根据初始化参数fast_start_mttr_target和恢复集的大小，这个故障切换可能非常迅速。不过，作为failover过程的一部分，用户的数据库连接将被断开。

Active/passive模式可以通过将active_instance_count参数设置为1来打开，但仅当节点数为2时才有效。

配置Shared-All架构

一个所有节点同时访问共享存储和数据的集群被称为shared-all或者shared-everything结构。Oracle RAC就是基于shared-everything架构：一个数据库位于共享存储中，通过集群各个节点上运行的实例来访问。在Oracle术语中，一个实例由内存结构和一些进程组成。对应的，数据库存储在磁盘中的数据文件里。在RAC中，实例的故障并不意味着该实例管理的数据的丢失。在一个节点发生故障后，集群中的另一个实例将会进行实例恢复，所有剩余节点都将继续服务。使用高可用技术，例如FCF或TAF，可以将实例失效对用户造成的影响降到最低。故障节点最后将重新加入集群并分担工作量。

配置Shared-Nothing架构

在一个shared-nothing数据库集群中，每个节点有它私有的独立存储，其他节点不能访问。数据库被集群中的节点分割成几个部分，返回的查询结构集是各个节点结果集的结合。丢失一个节点会导致对应的数据无法访问。因此，一个shared-noting集群经常被实施成一些单独的active/passive或者active/active集群来增强可用性。MySQL的集群就是基于shared-nothing架构。

RAC的主要概念

集群节点

集群由单独的节点组成，在Oracle RAC中，允许的节点数和集群版本有关，公开文档中说明Oracle 10.2集群软件支持100个节点，而10.1支持63个实例。即使当个节点发生故障后，基于RAC上的应用能继续运行，还是应该花点精力来确认数据库服务器中的单个组件不会出现单点故障(SPOF)。

采购新的硬件时应该采用可热插拔的组件，比如内置磁盘和风扇，另外，服务器的电力供给、主机总线适配器、网卡和硬盘都应该做了冗余。可能的话，最好做一个逻辑绑定，比如硬盘硬件RAID或软件RAID、网卡绑定、存储网络的多路径。在数据中心也应该注意：要使用不间断的电源供应、足够的散热措施、服务器的专业上架。最好还能有个远程的lights-out管理控制台，当一个节点不知道由什么原因挂起，可能迫切需要进行故障排除或者重启。

内部互联

集群内部互联是Oracle RAC的特征之一。它不仅使得集群在不同实例间传递数据块时突破block pinging算法的限制，它还可用作心跳和常规通讯。连接失败将导致集群的重组来避免脑裂发生，Grid Infrastructure将使一个或多个节点重启。可以为RAC和Grid Infrastructure配置一个单独的连接，这种情况下你需要配置RAC来使用正确的连接。这个连接始终应该是私有的，不应该受到其他网络的干扰。RAC用户可以使用两种技术来实现内部互联：以太网和Infiniband。

使用基于以太网的内部互联

使用10G以太网作为集群内部互联可能是目前使用最多的，集群的后台进程使用TCP/IP进行通信。Cache Fusion（用来保持缓存的一致性）使用另一种通信方式：UDP(UserData该ramProtocol)。UPD和TCP同属于传输层，后者面向连接，使用显式的通讯握手来保证网络数据包按顺序到达，并转发失败的数据包。UDP则不包含状态，它是一个发完就忘(fire-and-forget)协议。UDP只是简单发送一个数据包到目的地。UDP比起TCP而言主要的好处是它比较轻便。

注意：两节点集群间应该避免使用交叉线来直连，集群的内部通讯必须经过交换，交叉电缆的使用应该被明确禁止！

使用jumbo frames可以使集群内部通信的效率和性能得到提升。Ethernet

Frames可以使用不同的大小，一般被限制在1500byte字节(MTU值)。框架大小决定了单个以太网框架能够传送多少数据，一个框架承受越大的数据负荷，服务器和交换机需要做的工作就越少，提供了更高的通讯效率。许多交换机允许在一个框架中容纳比标准MTU值更大的字节数（1500-9000），也叫jumbo frame。注意jumbo

frames是不能路由的，因此它不能被使用在公共网络上。当决定使用jumbo frames时，一定要确定集群中的所有节点使用同样的MTU。

刚才说过数据库服务器的相关组件应该有一个容易，网卡也是其中之一。多个网络端口可以在linux中使用bonding技术绑成一个逻辑单位，和很多其他操作系统不同，linux中网卡的绑定不需要购买其他软件就能实现。

使用基于Infiniband的内部互联

Infiniband常被用来实现远程内存直接访问(RDMA remote direct memory

access architecture)。这是一个高速互联，常与高性能计算(HPC)环境联系在一起。RDMA可以在集群的节点间使用并行、直接、内存到内存的传输，它需要专门的RDMA适配器、交换机和软件。它还能避免基于以太网的实现中的CPU处理和环境转换的开支。在linux中有两种途径来实现Infiniband互联。第一种叫做IP over

Infiniband(IPoIB)，它采用IB架构作为链路控制层，使用封装的方法实现IP和IB报文的转换，从而使在以太网运行的程序可以直接运行在Infiniband上。另一个方法就是使用基于Infiniband的 Reliable Datagram Sockets，oracle 1.2.0.3开始支持这个方法。RDS可以通过Open Fabric Enterprise Distribution(OFED)在linux和

windows上实现。RDS的重要特征是低延迟、低开销和高带宽。Oracle数据库服务器和Exadata存储服务器使用了Infiniband，为集群内的通讯提供高达40Gb/s的带宽，这是以太网所不可能做到的。Infiniband为高性能展现了巨大的优势，但它的成本同样非常高昂。

Clusterware/Grid Infrastructure

Grid Infrastructure与操作系统紧密结合，并提供以下服务：节点间连接；维护集群成员；消息传送；集群逻辑卷管理；隔离(fencing)

************************************************************************************************************************************************************************************************

I/O隔离：

当集群系统出现"脑裂"问题的时候，我们可以通过"投票算法"来解决谁获得集群控制权的问题。

但是这样是不够的，我们还必须保证被赶出去的结点不能操作共享数据。

这就是IO Fencing

要解决的问题。

IO Fencing实现有硬件和软件2种方式：

软件方式：对于支持SCSI Reserve/Release

命令的存储设备，

可以用SG命令来实现。

正常的节点使用SCSI Reserve命令"锁住"存储设备，

故障节点发现存储设备被锁住后，就知道自己被赶出了集群，也就是说自己出现了异常情况，

就要自己进行重启，以恢复到正常状态。

这个机制也叫作 Sicide(自杀). Sun

和Veritas

使用的就是这种机制。

硬件方式：STONITH(Shoot The Other Node in the Head)，

这种方式直接操作电源开关，当一个节点发生故障时，另一个节点如果能侦测到，就会通过串口发出命令，控制故障节点的电源开关，通过暂时断电，而又上电的方式使故障节点被重启动，

这种方式需要硬件支持。

************************************************************************************************************************************************************************************************

各个版本的Oracle集群软件的命名如下：

进程结构

安装结束后，会产生一些后台进程来确保集群正常工作并能够与外部通讯。其中的一些有序linux平台的要求需要以root用户权限来启动。比如，网络配置的改动就需要更高的权限。其他后台进程将以grid软件所在系统用户的权限来运行。下面的表格介绍主要的一些后台进程

后台进程 说明

Oracle高可用OHAS是服务器启动后打开的第一个Grid Infrastructure组件。服务 (OHAS) 它被配置为以init(1)打开，并负责生成agent进程。

Grid Infrastructure使用两个oracle代理进程。第一个，概括起来说，负责打开一些需要访问OCR和VOTING文件的资源。它Oracle Agent

由OHAS创建。

第二个代理进程由CRSD创建，负责打开所有不需要root权限来访问的资源。这个进程以Grid Infrastructure所属用户的权限运行，并且负责在RAC11.1中racg所做的工作。

和 Oracle 代理进程类似，有两个Root 代理进程被创建。 最初Oracle Root

Agent

的代理进程由OHAS引发，它为linux系统中需要更高权限的资源提供初始化。创建的主要后台进程是CSSD和CRSD。反过来，CRSD将触发另一个root代理。这个代理将打开需要root权限、主要和网络相关的资源

集群就绪服务进程

(CRSD)

集群同步服务进程

(CSSD)

oprocd在11.1版本中负责 I/O 隔离。它是在10.2.0.4补丁集Oracle进程监中为linux系统引入的。在这个补丁集以前，内核控

(OPROCD)

hangcheck-timer 模块来做类似的任务。有趣的是，oprocd以前常被用在非linux平台中。Grid Infrastructure用cssdagent进程来替换了oprocd进程。

事件管理器(EVM)

EVM负责发布Grid Infrastructure创建的事件

CTSS服务是一个可选项，通过网络时间协定服务器为集群提供时集群时间同步间同步，这个时间同步对RAC很重要。它可以运行在两种模式下：服务(CTSS) 观望或者活动。当NTP被激活的时候，它运行在观察模式，若没有启动NTP，它将根据主节点同步所有节点的时间。

Oracle警告服负责通过快速应用框架发布事件的主要后台进程。

管理集群的配置和节点成员

集群软件的后台主要进程，使用oracle集群注册信息来管理集群中的资源

务(ONS)

在RAC11.2中，Grid Infrastructure的启动顺序有了明显变化。代替直接通过inittab(5)打开CRS、CSS、EVM，OHAS进程现在主要负责创建agent进程，监控其他节点的健康状况，和打开集群资源。在非Oracle管理进程中，NTP是一个特殊的角色，在每个集群中，它需要提供时钟同步，Grid Infrastructure也不例外。

以下是11.2中Grid Infrastructure的一些主要后台进程：

配置网络组件

Grid Infrastructure需要一些IP地址来正常工作：每个主机配备一个公共网络地址；每个主机有一个私有网络地址；每个主机一个虚拟IP地址(未被指派)；1-3个未指派的IP地址用于Single Client Access Name特性；若使用了Grid即插即用，还需要一个未使用的虚拟IP分配给Grid命名服务。

节点虚拟IP是Oracle集群的最有用的功能之一。它们需要和公共IP配置在一个网段内，并作为Grid Infrastructure中的集群资源来维护。在9i中的时候，当一

个节点发生故障，该公共IP无法响应连接请求。当一个客户端会话尝试连接到这个故障节点时，它必须等待到连接超时，这可能是一个漫长的过程。有了虚拟IP，那就快多了：当一个节点故障，Grid Infrastructure将该节点的虚拟IP地址failover到集群中的另一个节点上。当一个客户端会话连接到故障节点的虚拟IP，Grid

Infrastructure知道这个节点不能正常工作，会让它连接到集群中的下一个节点。另一个需求是1-3个IP地址，不管集群有多大，这个要求是Grid Infrastructure中新增的，这种地址类型称为SCAN(single client access name)。SCAN在Grid

Infrastructure升级或安装时创建并配置，在执行安装以前，你需要将这些SCAN IP地址添加到DNS中来循环解析。如果你使用Grid命名服务(GNS)，你需要在公共网络上为它分配一个虚拟IP地址。

oracle 11g RAC 的一些基本概念（三）

Grid Infrastructure共享组件

Grid Infrastructure使用两种类型的共享设备来管理集群资源和节点：OCR(Oracle Cluster Registry)和表决磁盘。Oracle 11.2引入一个新的文件，称作Oracle Local Registry(OLR)，它只允许存放在本地。

OCR和OLR

OCR为所有节点所共享，包含了集群资源的所有信息和 Grid Infrastructure需要的操作许可。为了实现共享，OCR需要存放在裸设备、共享块设备、类似OCFS2的集群文件系统或者ASM上。在Grid Infrastructure中，只有通过升级而来的系统才支持非ASM管理的OCR，如果是新的安装，你必须使用集群文件系统或者ASM。在RAC10和11.1中，OCR可以有1个镜像，而到了11.2，则增加到了5个拷贝。

Grid Infrastructure每4个小时自动备份一次OCR，并保留一些备份用以恢复。RAC11.1中引入一个选项来手动备份Cluster Registy，以root用户运行诊断程序时将执行附加的完整性检查。Clusterware11.1通过Oracle Universal Installer简化了

Cluster Registry在共享的块设备上的部署，在此之前，需要手动进行一个移动OCR到块设备上的过程。当你在Red Hat 4或SLES10上，在RAC11.1中使用裸设备，需要通过udev来手动对裸设备进行配置。Oracle Support中对这个配置过程提供了说明，单路径和多路径连接共享存储的方法有所不同。

在一些罕见的情况中，OCR可能会被毁坏，此时就需要从备份中来还原。根据毁坏的严重性，可能从一个镜像中来还原就足够了，也可能需要从备份中来还原。只能通过Oracle提供的工具来管理和维护OCR，如果直接对OCR中的内容进行转储和修改，造成的配置问题Oracle将不予支持。

Oracle 11.2中引入另一个集群配置文件，叫OLR。这个文件在每个节点的Grid

Infrastructure安装目录中都有自己单独的拷贝。OLR存储了集群启动初期OHAS使用的重要的安全环境。定位voting盘时需要用到OLR和网格即插即用配置文件，如果它们存储在ASM中，GPnP的profile中的discovery相关字符串将被集群同步进程用来寻找它们。在集群软件启动的后期，cssd进程将启动ASM实例来连接OCR文件。然而，它们的路径存储在/etc/文件中，和RAC11.1中一样。当然，如果voting文件和OCR如果存储在一个共享的集群文件系统上，ASM实例不需要也不会启动，除非其他资源需要使用到ASM。

配置Voting Disks

若一个节点在指定时间内(countdown-threshold)无法响应其他节点的心跳请求，这个节点将被踢出集群。

与OCR类似，voting disk和它的镜像都必须存放在共享存储上(11.1中支持3个voting disks，11.2中增加到15个)。和OCR一样，Grid Infrastructure只在升级的系统上支持裸设备，新安装的只支持集群文件系统或ASM。块设备和裸设备在Oracle12中将不再支持。

Oracle强烈建议在不同的位置上使用至少3个voting disks。当使用ASM管理voting disks时，你需要注意磁盘组和故障组的冗余级别。注意，voting disk的所有拷贝都在一个磁盘组里面，你不能将voting disks分布在多个磁盘组中。当使用外部冗余的磁盘组，你只能有1个voting disk。使用normal redundancy冗余级别需要至少3个故障组来存储3个voting disks，high redundancy冗余级别更加灵活，它支持多达5个voting disks。

使用ASM

ASM是oracle10.1中开始引入的，它是Oracle的物理数据库结构上的一个支持集群的逻辑卷管理器。可以存储在ASM中的文件包括控制文件、数据库文件和在线重做日志(还有spfile和归档日志)。直到11g r2，都不能存储任何类型的操作系统文件。

ASM支持的文件类型每个版本都不太一样。下面贴出10.2和11.2的列表以供参考比较：

10.2

11.2：

ASM建立在ASM disk、Failure groups、ASM disk groups概念的基础上的。

几个ASM disk构成一个ASM disk group。与LVM类似，一个ASM disk就相当于LVM里的一个physical volume。与LVM不同的是，共享一个共同的故障点(例如磁盘控制器)的几个ASM disk可以组成一个failure group。一个ASM disk group可以用来存储物理数据库结构：数据文件、控制文件、redo日志和其他一些文件类型。与linux里的逻辑卷管理器(LVM)相比较，disk group上面没有再创建逻辑卷，取而代之的是，数据库中的所有文件进行了逻辑分组放在disk group上的一个目录里。ASM中不需要文件系统，这也是为何ASM相对传统的LVM更具性能优势。

Grid Infrastructure引入了ASM集群文件系统(ACFS)，消除了存储通用用途文件的限制。ASM使用stripe-and-mirror-everything方式来提供最佳性能。

ASM和ACFS的使用不受集群的限制；单实例oracle同样可以通过它得到很多好处。技术上，Oracle ASM被应用为一种特殊的Oracle实例，它有自己的SGA，但没有持续的字典。在RAC中，每个集群节点有且只有一个单独的ASM实例。当启动的时候，每个实例会通过集群软件中的初始化参数在Grid Infrastructure检测到ASM磁盘组资源。每个实例将挂载这些磁盘组。通过赋予正确的权限(ASM11.2中引入了访问控制列表(ACLs))数据库可以访问它们自己的数据文件。使用ASM需要应用OMF，这意味着不同的数据库文件管理方式。RDBMS实例中的初始化参数，例如db_create_file_dest和db_create_online_dest_n，还有db_recovery_file_dest，指定了相关的文件存储在哪个磁盘组中。当需要创建一个新的文件时，OMF将以以

下格式来创建：+diskGroupName/dbUniqueName/file_type/file_type_ation 给个例子：+DATA/oradb/datafile/users.293.699134381

ASM允许你执行许多在线操作，在ASM11.1及更高版本中，可以以滚动方式(rolling fashion)进行升级，最小化对数据库的影响。

ASM在裸分区级别上进行操作；为了降低产品系统的开销，应该避免使用LVM2逻辑卷。在NFS上ASM同样是被支持的。但是，代替直接挂载文件管理器给出的目录，需要用dd工具创建的零填补文件作为ASM卷。使用NFS的时候，你需要和供货商协商，让他们提供最佳实践的文档。

有特殊需求的环境，比如大于10TB数据量的海量数据库，可以在磁盘组级别从可定制的盘区(extent)大小上得到好处。一个通用的存储优化技术包括只使用磁盘边缘位置，比使用其他位置能提供更高的性能。ASM的智能数据分布允许管理员来定义具备更高速度和带宽的热点区域。经常访问的文件可以放置到这些位置来提高性能。硬盘制造商即将推出扇区大小为4k的硬盘，存储密度增加，且更快，容量更大。ASM为此做好了准备，它提供了磁盘组的一个属性，叫sector size，可以设置为512字节或4k。

大部分安装中，一个典型的工作流程：存储管理员提供集群的所有节点上用来做ASM disk的存储；系统管理员为这些新的块设备创建分区，做多路径配置，使用ASMlib或udev将这些分区后的块设备标记为候选磁盘；移交到数据库小组后，Oracle管理员可以配置ASM disk和ASM磁盘组。这些操作都可以在线完成，不需要重启服务器。

ASM disk

.

ASM disk是ASM的基本组成单位。当一块ASM候补磁盘被添加到磁盘组中时，元数据信息被写入到它的头部，使得ASM实例能认出这块磁盘并挂载到磁盘组中。在存储阵列中，磁盘故障经常发生。个别磁盘被高强度使用，它们发生故障是很正常的。大多数情况下，磁盘阵列能根据使用的保护级别，通过镜像磁盘或奇偶校验信息来恢复发生故障的磁盘数据。

ASM中的磁盘故障不经常发生，因为大多数情况下都是使用经过磁盘阵列保护的LUN。但是，如果当一个ASM保护的磁盘组中的磁盘发生了故障，需要紧急替换故障的磁盘以免它被丢弃。在ASM 11.1中引入一个新的参数叫做磁盘修复时间(disk repair time)，使管理员可以修复短暂的磁盘故障，而不需要进行一个全局的调

整操作。当一个磁盘被从一个磁盘组中添加或删除时，会发生重新调整操作，对磁盘组中的成员重新进行条带。根据ASM磁盘组的大小，这个调整可能会很耗时。若管理员能幸运地在重新调整操作发生之前使故障的ASM磁盘回到磁盘组中，磁盘组将能很快恢复到正常状态，因为只需要应用有数据改变的区域(dirty region)的日志即可，不需要对整体全新进行调整。

根据存储后台的使用，LUN可以通过阵列的RAID级别得到保护，也可以是一个没有经过保护的存储的集合(JBOD)。

************************************************************************************************************************************************************************************************

ASMLib和udev

ASMLib和udev都解决了设备名固定的问题。在linux中，设备的检测和枚举的顺序并不是固定的。这和在Solaris中不一样，举个例子，除非一个磁盘在阵列中从物理上移动了，否则设备名(例如c0t0d1p1)不会改变。没做多路径的存储阵列的重新配置在linux中会有很大的问题：一个设备原先在操作系统中显示为/dev/sda可能会在重启后被重新映射为/dev/sdg，仅仅是因为操作系统检测到它比上一次启动时晚了一点。基于设备名的裸设备映射注定是要失败的。

首先看看udev的解决方法。一个SCSI设备的world-wide-ID(WWID)不会发生改变，在udev中利用了这一点制定一个规则，这个规则创建一个映射，它定义设备/dev/raw/raw1总是指向SCSI ID是xxxx的LUN中。udev的主要问题是，它的配置不够直观和易用。由于udev不能复制配置，在集群中的每个节点上管理员都需要去维护udev配置。(我们可以使用udevinfo -q path -n /dev/sda1 来查看/dev/sda1对应的udev设备名，该路径在/sys下)

配置了多路径的存储则不会有这个问题，因为另一个软件层(比如，devicemapper-multipath包)或供货商指定的软件会创建一个逻辑设备。

ASMLib提供了另一种方式。ASMLib工具可以在中免费下载，它使ASM磁盘的管理变得非常简单。ASMLib由3个RPM包组成：一个内核模块、实际ASMLib和支持工具。在使用一个LUN作为ASM disk前，你可以使用ASMLib工具通过将元数据信息添加到磁盘头部来标记它，然后ASMLib就可以识别出这个新的LUN，将其作为添加到ASM disk group的一个可能的候选。重启的时候，ASMLib将扫描磁盘头部的信息来识别ASM disk，不管物理设备名在启动过程中变成了什么。它保证了设备名的稳定性，而且成本非常低。ASMLib是一个内核模块，在内部分配自己的内存结构，它可以在单路径和多路径下配置。

************************************************************************************************************************************************************************************************

ASM Disk Group

ASM磁盘组有三个冗余级别：外部冗余；一般冗余；高度冗余

当创建一个外部冗余的磁盘组时，ASM让存储阵列来承担数据保护的责任，不会做任何的镜像。它会在磁盘组中的ASM disk间做默认盘区大小为1M的条带。写入错误会迫使ASM磁盘被卸载。这将产生严重的后果，因为该磁盘上的盘区没有任何可用的拷贝，整个磁盘组都会变得不可用。

在普通冗余级别下，ASM将条带和镜像每个盘区，在一个盘区写入到磁盘中时，会有另一个盘区写入另一个故障组来提供冗余。在ASM11.2中，单个的文件可以用来做条带和镜像；默认做一个双向的的镜像。普通冗余可以容忍磁盘组中的一个ASM磁盘发生故障。

高度冗余提供了更高级别的保护，它默认提供条带和镜像，创建主盘区的两个额外的拷贝，可以容忍磁盘组中两个ASM磁盘的故障。

Failure Group

Failure group是一个逻辑的磁盘组，当其中一个组件发生故障，整个磁盘组都将不可用。打个比方，属于一个SCSI控制器的磁盘组成一个failure group，如果这个控制器发生故障，所有的磁盘都不可用。在normal和high冗余中，ASM使用failure

group来存储数据的镜像拷贝。如果没有明确配置，每个ASM disk组成自己的failure

group。Normal redundancy磁盘组需要由至少2个failure group来组成，high

redundancy磁盘组需要至少3个。然后，建议使用比这个最小值更多的fail group来提供额外的数据保护。

ASM默认从一个ASM disk group中的primary extent中读取，在一个extended distance集群中，如果primary extent在远程的存储阵列上，可能会导致性能问题。ASM 11.1引入了一个首选的镜像读取来解决这个问题：每个ASM实例都可以被指定从本地extent的拷贝中读取，不管它是primary extent还是copied extent。

ASM安装与管理选项

在Oracle 11.1以前，最佳实践是以单独地安装ASM，这提供了可以单独升级集群软件和ASM的好处。比如，集群软件和ASM可以升级到11.1.0.7，而数据库还保留在原来的版本。这个最佳实践中，有三个标准的Oracle安装目录：集群软件、ASM、数据库

如果需要的话，ASM 11.1可以安装在与安装RDBMS不同的操作系统用户下，Oracle对此解释说，数据库与存储管理间的角色独立是很多站点的通用实践。

可以通过SQL*Plus、企业管理器(dbconsole)或者DBCA来管理ASM。

在Oracle 11g Release 2中，ASM现在已经是Grid Infrastructure的一部分，不管在单实例还是RAC环境中。一个新的配置助手asmca接受并扩展了11.1的DBCA中提供的功能。ASM也不再可以从RDBMS Oracle home以外的地方启动。asmca增加了对另一个叫做ASM Cluster File System的ASM新特性的支持。

一个叫SYSASM的新的超级用户角色的引入使角色分离成为可能，就像Oracle 9i以后的SYSDBA一样。你可以将SYSASM权限绑定在不同于SYSOPER和SYSDBA用户的角色中。

oracle 11g RAC 的一些基本概念（四）

RAC

在Grid Infrastructure安装完以后，我们把注意力转移到集群上的Oracle软件的安装上来。我们看到，Grid Infrasctructure提供了运行RAC的框架，包括集群通讯链接、节点分离、节点成员关系等服务。ASM是Oracle存储数据库的首选方式。RAC利用这些概念并扩展了需要的基本服务。

安装选项

成功安装了Grid Infrastructure/Clusterware以后，Oracle Universal Installer检测到集群环境的建立，然后提供安装整个集群上或是用户指定其中几个节点的RAC选项。使用集群检验工具cluvfy来为RDBMS的安装检测是否满足先决条件是良好的做法。和安装集群一样，Oracle Universal Installer将首先在第一个节点上对软件

进行拷贝和链接，然后将Oracle主目录push到指定的其他节点中。和Grid

Infrastructure不同的是，Oracle RDBMS可以被安装在共享文件系统上(例如OCFS2或ACFS上)，在集群中增加新节点被简化，因为不需要在新的节点上重新安装软件，打补丁同样被简化了--只有一个Oracle主目录需要打补丁。但是补丁不能以rolling方式安装，因此停机时间不可避免。

在安装过程中，Oracle Universal Installer将提醒管理员安装或升级数据库，或只安装软件。如果安装的时候有新的版本发布，那么仅仅安装软件，打补丁升级后再创建数据库是比较好的做法。

单实例和RAC数据库

RAC和单实例数据库在很多重要方面都有所不同。

在RAC中，一个数据库在共享存储中为多个服务器上的实例所访问。数据库文件、在线redo文件、控制文件和服务器参数文件(spfile)都必须共享。此外，闪回日志、已归档的redo日志、数据泵转储文件、和dataguard broker配置文件也可以共享，根据你的配置来决定(这是可选的，但还是强烈建议这么做)。在使用ASM的时候，你同样可以在每个RAC的节点中找到一个本地的pfile文件，这个文件指向对应磁盘组中的spfile。另一个存储在本地的文件是Oracle密码文件。集群文件系统中的用户常常把这些文件放在一个共享的位置，通过符号链接指向$ORACLE_HOME/dbs

数据库文件

数据库文件包含数据库中的所有数据，包括表、索引、数据字典和经过编译的PL/SQL代码，不胜枚举。在RAC中，每个数据文件都只有一个拷贝，位于共享存储中，并为所有实例所访问。Oracle默认不为数据文件提供镜像，大部分用户选择在存储层面来做冗余，避免介质故障导致的数据丢失。在存储阵列没有这个功能时，可以使用Oracle ASM来提供冗余。

控制文件

控制文件储存数据库的物理结构的相关信息，包括它们的状态。如果你使用RMAN且没有专门的RMAN catalog数据库，控制文件中也可以储存RMAN备份的信息。在单实例数据库和RAC中，控制文件应该做镜像以防止损坏或存储故障。当同时使用ASM和闪回恢复区时，会自动做多路复用。默认情况下，Oracle在db_create_file_dest和db_recovery_file_dest指定的磁盘组中对控制文件做多路复用。这种情况下，若你使用spfile，control_files参数将自动更新。要知道控制文件会成为RAC中的一个争用点，因为它们会被频繁更新。因此不要对控制文件做过多的镜像拷贝，而且应该把它们放置在高速存储上。

REDO和归档

在RAC中，每个实例有它自己的联机日志文件，称为线程(thread)。线程的信息可以在V$LOG和相关的视图中查看。

每个线程中你需要两组redo日志，而且若没有使用ASM和闪回恢复区，你应该考虑手动对组中的成员做多路复用。由spfile负责实例和线程间的映射(通过初始化参数thread)。当添加一个新的实例到集群中时，就需要一个相应的redo线程，这可以使用两种方式来做到：第一种，执行SQL语句alter database add logfile group

x thread y; 第二种，在使用策略管理的数据库(policy-managed)中，会自动创建。然后由Oracle来启用。

lgwr后台进程将redo buffer刷新到redo log中。online redo log需要放在高速存储中，否则它可能会成为一个争用的点，特别是在一个高频率提交的系统中。通常对设计不合理的应用的优化是减少commit的频率，并至少将redo log和控制文件移到高速存储中，以减少一些性能瓶颈。在日志切换频繁的系统中，增加每个线程的重做日志组数会有所帮助，它能给归档进程更多的时间来归档redo日志。这种方法在归档进程需要将归档的redo传送到standby数据库中时也能获益，但是，现在的大部分系统采用Log Network Service(LNSn)进程来异步传送redo给standby数据库的Remote File Server(RFS)进程。在Oracle 10.2和11.1中，每个destination有一个LNS进程，到了11.2，LNSn进程被NSSn何NSAn后台进程所代替。NSSn进程被用来同步传送redo，NSAn用来异步传送redo。redo log大小设置的原则是，日志切换不会太频繁(AWR和statspack能够帮助定义一个合适的大小)。Oracle

11.2还允许管理员来选择redo log的块大小，现代存储单元使用4kb扇区大小代替了原先的512b。

当RAC中的一个实例发生故障，所有线程被合并来帮助建立恢复集，由服务器监控进程来执行前滚或回滚操作。

在lgwr进程将一个redo log写满以后，其中一个归档进程会将该文件拷贝到指定的目录中。

闪回恢复区在Oracle 10.1中引入，看是来是归档日志的最佳存放位置。如果你没有使用闪回恢复区，建议将归档日志放在一个共享文件系统中，以便每个节点都可以访问到。与单实例数据库不同，RAC需要所有线程的归档日志。当一个实例执行介质恢复时，你可以从它的alter日志上看到，Oracle使用了每个线程的所有日志文件。

Undo表空间

和redo线程类似，每个集群数据库的实例由它自己的undo表空间。spfile中配置了实例和undo表空间之间的一对一映射关系。但这个映射并不代表该undo表空间就长期绑定在该实例上，所有的其他实例同样可以访问该undo表空间来创建块的读一致前镜像。

当添加一个实例到集群中时，需要添加新的undo表空间并映射到该实例，和redo

log一样。在policy-managed数据库中，Oracle可以自己来做这件事。

虽然还是可以使用手动的undo管理，但是强烈建议使用自动undo管理(AUM)。

RAC数据库的存储选项

管理员可以在如下的选项中选择：







ASM 这是Oracle的首选存储选项，而且是RAC标准版中支持的唯一配置

OCFS2

裸设备 不推荐使用，不仅是因为被新版的linux内核弃用，在Oracle 11.2中同样不支持

网络文件系统(NFS)

Red Hat Global File System 只在红帽和Oracle Enterprise Linux中支持，可以用在闪回恢复区和数据库文件上





RAC实例

一个RAC数据库包含2个或更多的实例，一般每个实例都在不同的节点上，由一些共享内存结构和后台进程组成。

每个实例都有自己的SGA，在实例启动的时候分配。Oracle在10g中引入了自动共享内存管理(ASMM)，在11g中引入了自动内存管理(AMM)。但是AMM与linux的大页面不兼容，这对大内存的系统来说是个问题。

Oracle需要同步访问本地共享内存和整个集群。所有实例都能访问其他实例的SGA。

在RAC中Oracle内核对共享内存的保护措施和单实例中是一样的，同样使用了闩和锁。闩是一个低级别、轻量级的串行装置。请求闩的进程不会排队，如果进程不能获得闩，它就会进入spin状态。spin的意思是，这个进程会进入一个紧密循环来预防被操作系统的调度程序从CPU中取下。如果一个进程长时间得不到闩，它会进入睡眠，在一个时间间隔后再次尝试申请。闩是实例级别的，没有集群范围的闩。

另一方面，锁在更长的时间请求一次，比闩更为复杂。锁可以是共享或独占的，请求锁的进程以先进先出(FIFO)的机制来等待，由队列来控制锁的访问，这个队列是集群范围内的。

缓存一致性的需求意味着锁和闩在RAC中比单实例要更加复杂。和单实例中一样，对buffer cache中数据库的访问和队列必须在本地实例中管理，但是，远程实例的访问也需要管理。因为这个原因，Oracle使用全局资源目录(GRD)和一些额外的后台进程。

(Oracle将V$视图加上实例标识组合起来形成GV$视图，一个GV$视图包含了集群中所有实例的动态性能视图)

全局资源目录 (GRD)

RAC中使用了一些附加的后台进程来做缓存间的同步——记住RAC使用cache

fusion结构来模拟一个横跨集群内所有节点的全局SGA。访问buffer cache中的块需要在读一致和写的访问间进行协调，共享资源的队列现在也是在集群全局上的。全局缓存服务(Global Cache Service GCS)用来对公共buffer cache的访问，全局队列服务(Global Enqueue Service GES)用来管理集群中的队列。

GCS和GES对应用而言都是透明的。内部使用的原结构就是先前提到的GRD，由GCS和GES进程来维护。GRD分布在集群的所有节点上，是SGA的一部分，

这就是为什么一个RAC数据库的SGA比同等情况下的单实例数据库要来得大。资源管理由GCS和GES来协商。特定的资源完全由一个实例来管理，这个实例就是resource master。但它并是不固定的，Oracle 9.2以后的版本实现了动态的资源管理(DRM)，在9.2以前，资源的remastering只发生在实例故障、GRD重建的时候。新的版本中，如果Oracle检测到一个resource master以外的实例在一个给定的时间间隔中对一个特定的资源的访问过于频繁，就会发生resource mastering。在这种情况下，该资源就会被remaster到其他节点上，也就是说，频繁访问该资源的另一个节点将成为resource master。很多用户反馈了动态remastering的一些问题，当它过于频繁发生的时候会造成一些不必要的开支。这种情况下，可以禁用DRM。

（GRD还记录了哪些资源由哪些实例来管理，当一个实例发生故障时，恢复起来将非常方便）

下图说明GCS如何与GES协同工作来维护GRD

全局缓存服务(GCS)

LMSn后台进程使用GCS在全局buffer cache中维护缓存的一致性，SGA中可以存在同一个数据块的多份拷贝(当前版本只有一个)，GCS对数据块的状态和位置进行跟踪，并通过内部连接将块传输到其他节点的实例中。

全局队列服务(GES)

和GCS类似，GES工作在块级别，管理集群中的全局队列。根据经验，如果一个操作没有涉及在全局buffer cache中控制/移动数据块，那么很可能是经过了GES的处理。全局队列服务负责所有的实例中的资源操作，比如对数据字典和库缓存的访问或事务的全局管理。它同样可以检测集群中的死锁。它跟踪多个实例同时访问资源时Oracle队列机制的状态。全局队列服务监控(LMON)和全局队列服务后台进程(LMD)组成全局队列服务的一部分。锁进程LCK0负责无缓存方式的访问，比如library和row cache请求。

缓存融合(Cache Fusion)

缓存融合是实例间数据传送的最新演变。Oracle 8i中曾使用block ping的机制，作为替代，Oracle使用高速的内部连接来为所有节点间的读写转移数据块。

实例间使用block ping方法来转移数据块代价是很昂贵的，它建议你将工作量与实例联系在一起来使实例间的数据块转移达到最少。在Oracle并行服务器(Oracle

Parallel Server)中，当一个实例请求一个数据块来进行修改，而这个数据块当前正由别的实例所持有，它将发出一个信号给持有该块的实例，使其将块写入到磁盘，再发回该块已经可读的信号。这种方法的通讯和对磁盘的读写操作的量很不尽如人意。

缓存融合的块转移依赖于全局资源目录，不需要超过3次跳跃(hop)，这与安装及节点的个数有关。很明显，如果一个集群只有两个节点，那么有一个双向的缓存转移。如果多于2个节点，将跳跃数限制在3次是必要的。Oracle使用专用的等待事件来衡量涉及缓存的通讯，根据实际情况来决定做一个双向或是三向的缓存转移。

当一个实例通过缓存融合来请求一个数据块时，它首先与资源的master联系来确定这个资源的当前状态，如果这个资源没有正在被使用，那么它可以通过从本地磁盘读取以获得这个块。如果这个资源正在被使用，那么该资源master将把这个资源传递到发出请求的实例中。如果这个资源紧接着收到1个或多个实例的修改请求，

将会把该资源添加进GRD，资源的master、请求者和持有者都可以不同，这种情况下最多需要三次跳跃来获得这个块。

上面提到的双向和三向的块转移与资源的管理方式有关。当资源的master持有被请求的资源，那么对数据块的请求就能马上得到满足并开始块的传输，这就是双向的通讯。在三向的情况中，请求者、master和持有者都不相同，那么该资源master需要转发这个请求，引发了新的跳跃。

从刚才的讨论中，你可以知道在全局buffer cache中对块和它们影像间协调是不能低估的。在RAC数据库中，缓存融合常常代表了最大的利益和最高的成本。好处是缓存融合理论上运行按比例增大，并可能取得近乎线性的扩展性。然而，缓存融合强加的额外工作量可能会在10%-20%的范围内。

读一致性

Oracle数据库的主要特征之一就是能同时提供不同视野下的数据，这个特征叫做多版本读一致。查询是读一致的，写不会阻塞读，反之亦然。当然，多版本读一致对RAC一样有效，但涉及到一点其他的工作。

System Change Number(SCN)是一个Oracle的内部时间戳，对读一致非常重要。如果本地实例请求一个块的读一致版本，它需要联系这个块的resource master来确定这个块是否有相同SCN的版本，或者更新的版本存在于某个远程实例的buffer

cache中。如果这个块存在，那么resource master会发送请求给相应的远程实例来转发这个块的读一致版本给本地实例。如果远程实例持有这个块的请求时间SCN的版本，那么它会马上发送这个块。如果远程实例持有的是这个块更新的版本，它将创建这个块的拷贝（称为前镜像），并对这个拷贝应用回滚使其回到对应的SCN的状态，然后将其通过内部连接发送。

System Change Number(SCN)

SCN是Oracle数据库产生和使用的内部时间戳，数据库中发生的所有事件都以SCN标记，事务也一样。Oracle的读一致严重依赖于SCN和undo表空间中的信息。SCN需要在集群中同步，RAC中用来使SCN在所有节点间通用的方案有两个：broadcast-on-commit和Lamport。

broadcast-on-commit是10.2以后的默认方案，它解决了Lamport方案的一个问题：在以前，这个默认方案是Lamport，它承诺了更好的扩展性，让SCN像集群其他通讯一样来传播，但并不是在一个节点中commit后马上发生。这在大部分情况下都能满足要求，但是，Lamport方案有一个问题：一个节点的SCN相对另一个节点的SCN有延时是可能的，特别是在在消息传送不活跃的时候。这种SCN的延时意味着在一个节点上提交的事务从另一个延时的实例上“看起来”会有点太新了。

另一方面，broadcast-on-commit方案更加资源集中一点。LGWR进程在每次commit之后更新全局的SCN并将其广播到所有的其他实例中。在RAC11.1中，初始化参数max_commit_propagation_delay允许数据库管理员来修改默认的设定，这个参数在11.2中被移除。