分类： Oracle
2012-01-30 10:21:22
RAC模式，两个实例操作同一个数据库。常用的方式是客户端连接的时候分别使用ip1加实例名和ip2加实例名的方式连接两个实例。当一台主机故障之后，ip会切换到另一台主机上，但实例名变化了，仍然无法连接。所以有了服务名的概念。客户端使用ip加服务名方式连接数据库可以解决问题，切换比操作系统双机快。
但是对于tuxedo长连接的方式，没有重连接机制，仍然需要应用干预。
一 集群环境下的一些特殊问题
1.1 并发控制
在 集群环境中， 关键数据通常是共享存放的，比如放在共享磁盘上。 而各个节点的对数据有相同的访问权限， 这时就必须有某种机制能够控制节点对数据的访 问。 Oracle RAC 是利用DLM(Distribute Lock Management) 机制来进行多个实例间的并发控制。
1.2 健忘症(Amnesia)
集群环境配置文件不是集中存放的，而是每个节点都有一个本地副本，在集群正常运行时，用户可以在任何节点更改集群的配置，并且这种更改会自动同步到其他节点。
有一种特殊情况： 节点A 正常关闭， 在节点B上修改配置， 关闭结点A，启动结点B。 这种情况下，修改的配置文件是丢失的， 就是所谓的健忘症。
1.3 脑裂(Split Brain)
在 集群中，节点间通过某种机制(心跳)了解彼此的健康状态，以确保各节点协调工作。 假设只有"心跳"出现问题， 各个节点还在正常运行， 这时，每个节点 都认为其他的节点宕机了， 自己是整个集群环境中的"唯一建在者"，自己应该获得整个集群的"控制权"。 在集群环境中，存储设备都是共享的， 这就意味 着数据灾难， 这种情况就是"脑裂"
解决这个问题的通常办法是使用投票算法(Quorum Algorithm). 它的算法机理如下：
集 群中各个节点需要心跳机制来通报彼此的"健康状态"，假设每收到一个节点的"通报"代表一票。对于三个节点的集群，正常运行时，每个节点都会有3票。 当 结点A心跳出现故障但节点A还在运行，这时整个集群就会分裂成2个小的partition。 节点A是一个，剩下的2个是一个。 这是必须剔除一个 partition才能保障集群的健康运行。
对于有3个节点的集群， A 心跳出现问题后， B 和 C 是一个partion，有2票， A只有1票。 按照投票算法， B 和C 组成的集群获得控制权， A 被剔除。
如 果只有2个节点，投票算法就失效了。 因为每个节点上都只有1票。 这时就需要引入第三个设 备：Quorum Device. Quorum Device 通常采用饿是共享磁盘，这个磁盘也叫作Quorum disk。 这个 Quorum Disk 也代表一票。 当2个结点的心跳出现问题时， 2个节点同时去争取Quorum Disk 这一票， 最早到达的请求被最先满 足。 故最先获得Quorum Disk的节点就获得2票。另一个节点就会被剔除。
1.4 IO 隔离(Fencing)
当集群系统出现"脑裂"问题的时候，我们可以通过"投票算法"来解决谁获得集群控制权的问题。 但是这样是不够的，我们还必须保证被赶出去的结点不能操作共享数据。 这就是IO Fencing 要解决的问题。
IO Fencing实现有硬件和软件2种方式：
软 件方式：对于支持SCSI Reserve/Release 命令的存储设备， 可以用SG命令来实现。 正常的节点使用SCSI Reserve命令" 锁住"存储设备， 故障节点发现存储设备被锁住后，就知道自己被赶出了集群，也就是说自己出现了异常情况， 就要自己进行重启，以恢复到正常状态。 这个 机制也叫作 Sicide(自杀). Sun 和Veritas 使用的就是这种机制。
硬 件方式：STONITH(Shoot The Other Node in the Head)， 这种方式直接操作电源开关，当一个节点发生故障时，另 一个节点如果能侦测到，就会通过串口发出命令，控制故障节点的电源开关，通过暂时断电，而又上电的方式使故障节点被重启动， 这种方式需要硬件支持。
二 RAC 集群
2.1 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 组成的集群。
2.2 Clusterware 组成
Oracle Cluster 是一个单独的安装包，安装后，在每个结点上的Oracle Clusterware 会自动启动。 Oracle Clusterware的运行环境由2个磁盘文件(OCR,Voting Disk)，若干进程和网络元素组成。
2.2.1 磁盘文件:
Clusterware 在 运行期间需要两个文件：OCR和Voting Disk. 这2个文件必须存放在共享存储上。 OCR 用于解决健忘问题，Voting Disk 用于 解决健忘问题。 Oracle 建议使用裸设备来存放这2个文件，每个文件创建一个裸设备，每个裸设备分配100M左右的空间就够了。
2.2.1.1 OCR
健忘问题是由于每个节点都有配置信息的拷贝，修改节点的配置信息不同步引起的。 Oracle 采用的解决方法就是把这个配置文件放在共享的存储上， 这个文件就是OCR Disk。
OCR 中 保存整个集群的配置信息，配置信息以"Key-Value" 的形式保存其中。 在Oracle 10g以前， 这个文件叫作 Server Manageability Repository(SRVM). 在Oracle 10g， 这部分内容被重新设计，并重名为OCR.在 Oracle Clusterware 安装的过程中， 安装程序会提示用户指定OCR位置。并且用户指定的这个位置会被记录在/etc/oracle /ocr.Loc(Linux System) 或者/var/opt/oracle/ocr.Loc(Solaris System)文件中。 而在 Oracle 9i RAC中，对等的是srvConfig.Loc文件。 Oracle Clusterware在启动时会根据这里面的内容从指定位置 读入OCR 内容。
1). OCR key
整个OCR 的信息是树形结构，有3个大分支。分别是SYSTEM,DATABASE 和CRS。每个分支下面又有许多小分支。这些记录的信息只能由root用户修改。
2) 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 中的内容。
2.2.1.2 Voting Disk
Voting Disk 这 个文件主要用于记录节点成员状态，在出现脑裂时，决定那个Partion获得控制权，其他的Partion必须从集群中剔除。在安装 Clusterware时也会提示指定这个位置。 安装完成后可以通过如下命令来查看Voting Disk位置。
$Crsctl query css votedisk
2.2.2 Clusterware 后台进程
Clusterware 由 若干进程组成，其中最重要的3个是：CRSD,CSSD,EVMD. 在安装clusterware的最后阶段，会要求在每个节点执行root.sh 脚 本， 这个脚本会在/etc/inittab 文件的最后把这3个进程加入启动项，这样以后每次系统启动时，Clusterware 也会自动启动，其中 EVMD和CRSD 两个进程如果出现异常，则系统会自动重启这两个进程，如果是CSSD 进程异常，系统会立即重启。
1). OCSSD
OCSSD 这 个进程是Clusterware最关键的进程，如果这个进程出现异常，会导致系统重启，这个进程提供 CSS(Cluster Synchronization Service)服务。 CSS 服务通过多种心跳机制实时监控集群状态，提供脑裂保护等基础 集群服务功能。
CSS 服务有2种心跳机制： 一种是通过私有网络的Network Heartbeat，另一种是通过Voting Disk的Disk Heartbeat.
这 2种心跳都有最大延时，对于Disk Heartbeat， 这个延时叫作IOT (I/O Timeout);对于 Network Heartbeat, 这个延时叫MC(Misscount)。 这2个参数都以秒为单位，缺省时IOT大于MC，在默认情况下，这2个 参数是Oracle 自动判定的，并且不建议调整。可以通过如下命令来查看参数值：
$crsctl get css disktimeout
$crsctl get css misscount
注： 除了Clusterware 需要这个进程，在单节点环境中如果使用了ASM，也需要这个进程；这个进程用于支持ASM Instance 和 RDBMS Instance之间的通信。 如果在使用了ASM的节点上安装RAC，会遇到一个问题：RAC节点要求只有一个OCSSD进程，并且应该是 运行$CRS_HOME目录下的，这时就需要先停止ASM，并通过$ORACLE_HOME/bin/localcfig.Sh delete 删除之前 的inittab 条目。 之前安装ASM时，也使用这个脚本来启动OCSSD： $ORACLE_HOME/bin /localconfig.Sh add.
2). CRSD
CRSD是实现"高可用性(HA)"的主要进程，它提供的服务叫作CRS(Cluster Ready Service) 服务。
Oracle Clusterware是位于集群层的组件，它要为应用层资源(CRS Resource) 提供"高可用**"，所以， Oracle Clusterware 必须监控这些资源，并在这些资源运行异常时进行干预，包括关闭，重启进程或者转移服务。CRSD进程提供的就是这些服务。
所有需要 高可用性 的组件，都会在安装配置的时候，以CRS Resource的形式登记到OCR中，而CRSD 进程就是根据OCR中的内容，决定监控哪些进程，如何监控，出现问题时又如何解决。也就是说，CRSD 进程负责监控CRS Resource 的运行状态，并要启动，停止，监控，Failover这些资源。 默认情况下，CRS 会自动尝试重启资源5次，如果还是失败，则放弃尝试。
CRS Resource 包括GSD(Global Serveice Daemon),ONS(Oracle Notification Service),VIP, Database, Instance 和 Service. 这些资源被分成2类：
GSD，ONS,VIP 和 Listener 属于Noteapps类
Database，Instance 和Service 属于 Database-Related Resource 类。
我 们可以这样理解： Nodeapps 就是说每个节点只需要一个就够了，比如每个节点只有一个Listener，而Database- Related Resource 就是说这些资源和数据库有关，不受节点的限制，比如一个节点可以有多个实例，每个实例可以有多个Service。
GSD，ONS,VIP 这3个服务是在安装Clusterware的最后，执行VIPCA 时创建并登记到OCR中的。 而Database， Listener， Instance 和Service 是在各自的配置过程中自动或者手动登记到OCR中的。
3). EVMD
EVMD 这 个进程负责发布CRS 产生的各种事件(Event). 这些Event可以通过2种方式发布给客户：ONS 和 Callout Script. 用户 可以自定义回调脚本，放在特定的目录下，这样当有某些事件发生时，EVMD会自动扫描该目录，并调用用户的脚本，这种调用是通过racgevt进程来完成 的。
EVMD 进程除了复杂发布事件之外，它还是CRSD 和CSSD 两个进程之间的桥梁。 CRS 和CSS 两个服务之前的通信就是通过EVMD 进程完成的。
4). RACGIMON
RACGIMON 这个进程负责检查数据库健康状态，负责Service的启动，停止，故障转移(Failover)。 这个进程会建立到数据库的持久连接，定期检查SGA中的特定信息，该信息由PMON 进程定时更新。
5). OPROCD
OPROCD 这 个进程也叫作 Process Monitor Daemon. 如果在非Linux 平台上，并且没有使用第三方的集群软件时，就会看到这个进程。 这 个进程用来检查节点的Processor Hang(CPU 挂起), 如果调度时间超过1.5秒， 就会认为CPU 工作异常，会重启节点。 也就是说 这个进程提供 "IO 隔离" 的功能。 从其在Windows 平台上的服务名： OraFnceService 也可以看出它的功能。 而在 Linux 平台上， 是利用Hangcheck-timer 模块来实现"IO 隔离"的。
2.3 VIP 原理和特点
Oracle 的TAF 就是建立在VIP 技术之上的。 IP 和VIP 区别在与： IP 是利用TCP层超时， VIP 利用的是应用层的立即响应。VIP 它是浮动的IP. 当一个节点出现问题时会自动的转到另一个节点上。
假设有一个2个节点的RAC，正常运行时每个节点上都有一个VIP。 VIP1 和VIP2. 当节点2发生故障，比如异常关系。 RAC 会做如下操作：
1). CRS 在检测到rac2节点异常后，会触发Clusterware 重构，最后把rac2节点剔除集群，由节点1组成新的集群。
2). RAC的Failover 机制会把节点2的VIP转移到节点1上，这时节点1的PUBLIC 网卡上就有3个IP 地址： VIP1,VIP2, PUBLIC IP1.
3). 用户对VIP2的连接请求会被IP层路由转到节点1
4). 因为在节点1上有VIP2的地址，所有数据包会顺利通过路由层，网络层，传输层。
5). 但是，节点1上只监听VIP1和public IP1的两个IP地址。并没有监听VIP2，故应用层没有对应的程序接收这个数据包，这个错误立即被捕获。
6). 客户段能够立即接收到这个错误，然后客户段会重新发起向VIP1的连接请求。
VIP 特点：
1). VIP 是通过VIPCA脚本创建的
2). VIP 作为Nodeapps类型的CRS Resource 注册到OCR中，并由CRS 维护状态。
3). VIP 会绑定到节点的public 网卡上，故public 网卡有2个地址。
4). 当某个节点发生故障时，CRS 会把故障节点的VIP 转移到其他节点上。
5). 每个节点的Listener 会同时监听public 网卡上的 public ip 和VIP
6). 客户端的tnsnames.Ora 一般会配置指向节点的VIP.
2.4 Clusterware 的日志体系
Oracle Clusterware的辅助诊断，只能从log 和trace 进行。 而且它的日志体系比较复杂。
alert.log:
$ORA_CRS_HOME\log\hostname\alert.Log, 这是首选的查看文件。
Clusterware后台进程日志：
crsd.Log: $ORA_CRS_HOME\log\hostname\crsd\crsd.Log
ocssd.Log: $ORA_CRS_HOME\log\hostname\cssd\ocsd.Log
evmd.Log: $ORA_CRS_HOME\log\hostname\evmd\evmd.Log
Nodeapp日志位置：
$ORA_CRS_HOME\log\hostname\racg\
这里面放的是nodeapp的日志，包括ONS和VIP，比如：ora.Rac1.ons.Log
工具执行日志：
$ORA_CRS_HOME\log\hostname\client\
Clusterware 提供了许多命令行工具：
比如ocrcheck, ocrconfig,ocrdump,oifcfg和clscfg, 这些工具产生的日志就放在这个目录下
还有$ORACLE_HOME\log\hostname\client\ 和
$ORACLE_HOME\log\hostname\racg 也有相关的日志。
如果使用对称多处理（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 individual 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相关的认证问题。具体使用步骤如下：
* 连接并登陆
* 点击菜单栏的“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
