备注：本文摘抄于张晓明《大话Oracle RAC:集群 高可用性 备份与恢复》
因为集群环境需要多个计算机协同工作，要达到理想状态，必须要考虑在集群环境下面临的新挑战。
1.并发控制
在集群环境中，关键数据通常是并发存放的，比如放在共享磁盘上。而集群内各个成员的生身份是对等的，所有节点对数据有相同的访问权利。这时就必须有某种机制能够控制节点对数据的访问。
在Oracle rac中，是利用DLM (Distribute Look Management)机制来进行多个实例间的并发控制。
2.健忘症 (Amnesia)
这个问题发生在集群配置文件不是集中存放，而是每个节点都有一个本地副本。在集群正常运行时，用户可以在任何节点更改集群的配置，并且这种更改会自动同步到其他节点。
但考虑这样一种场景：两个节点的集群，节点1因为正常的维护需要被关闭，然后在节点2修改了某些配置，然后关闭节点２，启动节点１。因为之前在节点2做的配置修改没有同步到节点1，所以节点1启动后，它仍然是用旧的配置文件工作，这时就会造成配置丢失，也基于是所谓的"健忘症"。
解决"健忘症"最简单的办法是，整个集群使用一个集群配置文件，无论哪个节点修改了配置信息都是同一分，配置信息对每个节点都是一样的。
Oracle RAC使用OCR DISK 文件来解决这个问题。
3.脑裂 (Split Brain)
在集群里，节点间需要通过某种机制（心跳）了解彼此的健康状况，以确保各节点协调工作。假设只是"心跳"出现故障，但各个节点还在正常运行。这时，每个节点都认为其他节点宕机，自己是整个集群环境中的"唯一健在者"，自己应该获得集群的"控制权"。在集群环境中，存储设备都是共享的，（都来控制独享，势必会破坏数据的完整性和一致性）这就意味着数据灾难，这样一种状况就是"脑裂"。
解决这个问题的通常办法是使用投票算法（Quorum Algorithm），这个算法的原理如下：
集群中各个节点需要心跳机制来通报彼此的"健康状况"，假设每收到一个节点的"通报"代表一票。对于三个节点的集群，正常运行时，每个节点都会有3票（自己和另外两个节点的通报）。假设节点1的心跳出现故障，但是节点1还在运行：这时整个集群就会分裂为两个小的Partition。节点1自己是一个Partition，节点2和节点3是一个Partition。这时就必须剔出一个Partition，应该剔出哪个Partition呢?
这时节点2和节点3组成的Partition，每个节点有两票；节点1自己是一个partition，节点1只有一票。安装投票算法节点2和节点3组成的小集群获得了控制权，而节点1被踢出，由节点2和节点3组成的新的集群继续对外提供服务。
如果集群只有两个节点，则上面的算法就没有用了，因为每个节点只有一票，没有办法比较。这必须要引入第3个设备Quorum Device。
Quorum Device通常采用的是共享磁盘，这个磁盘也叫Quorum Disk，这个Quorum Disk也代表一票。当新跳出现故障时，两个节点同时去争取Quorum Disk这一票，最早到达的请求被最先满足，后到达的这个节点就无法获得这一票。这时，最先获得Quorum Disk的节点就获得两票，而另一个节点只有一票，就会被踢出集群。
在ORACLE RAC中Voting Disk用来记录节点间成员的状态，当出现脑裂时，仲裁哪个partition获得控制权，其他的partition被踢出。
4.IO隔离 (IO Fencing)
这个问题是脑裂问题的延伸，当集群出现"脑裂"时，必须要能够判断出哪个节点应该获得集群的控制权，哪些节点要被赶出集群，这就是"投票算法"要解决的问题，前一部分已经做了解释。
但仅仅这样做是不够的，还必须保证被赶出来的节点不能操作共享数据。因为这时该节点可能还在运行中，如果不加限制很有可能会修改共享数据。这是IO隔离(IO Fencing)要解决的问题。
IO Fencing实现有硬件和软件两种方式。对于支持SCSI Reserve/Release命令的存储设备，可以使用SG命令实现。正常节点使用SCSI Reserve命令"锁住"存储设备，故障节点发现存储设备被锁后，就知道自己被赶出集群了，也就是说知道自己出现了异常状况，就要自行重启，以恢复到正常工作状态，这个机制也叫做suicide (自杀)，Sun和Veritas使用的是这种机制。
STONITH (Shoot The Other Node In The Head)是另一种实现方式，这种方式直接操作电源开关。当一个节点发生故障时，另一个节点如果能够侦测到，就会通过串行口发出命令，控制故障节点的电源开关，通过暂时断电，而后又上当的方式使得故障节点被重启动。这种方式需要硬件支持。
Oracle Rac采用的是软件方式，直接重启故障节点。无论采用哪种方式，IO Fencing目的都是相同的，为了保障故障节点不能再继续访问共享数据。
------摘抄于张晓明《大话Oracle RAC:集群 高可用性 备份与恢复》
5.安装RAC对网络和时间的要求
RAC安装的时候对网络和时间同步的要求非常高。
在rac环境中，会要求各个节点之间的时间差不能超时。一般如果超过30秒，节点很可能会重启。 所以要同步各节点的时间。例如，我们需要配置一个ntp时钟服务器，来给rac的各个节点进行时 间同步。或者让节点之间进行时间同步，保证各节点的时间同步，但无法保证rac数据库的时间的准确性。
节点间的时间同步方法：
方法一：建立ntp时钟服务器，各节点与ntp server同步时间
方法二：利用定时任务，让节点间时间同步（用rdate或ntpdate）
在RAC环境中需要两种网络，一种是公共网络，另一种是私有网络。其中，公共网络用于提供客户端的访问，而私有网络用于节点间的通信，比如每个节点通过私有网络探测其他节点的状态，两个数据库实例通过私有网络对事务进行协调等。
对于公共网络的要求是：必须支持TCP 协议，而且必须使用每个节点上名称相同的网卡，比如在所有节点上都使用en0 ，而不能在一个节点上使用en0 ，在另外一个节点上使用en1 。这些网卡的IP 地址必须属于同一个子网。
对于私有网络的要求是：必须支持UDP协议，尽量使用每个节点上名称相同的网卡，节点之间需要通过网络交换机相连，不能使用TOKEN-RING网络，也不能使用直线连接两个节点，这些网卡的IP 地址应该属于同一个子网。RAC中的所有节点都需要通过私有网络连接在一起。私有网络应该只用于节点间的通信，而不应该有其他的用途。私有网络在物理上也应该与其他 网络分开。
6.10G RAC网段的配置注意（10.2.0.1.0）
在Oracle10G（10.2.0.1.0） RAC的安装中，Oracle默认认为10网段开头和192网段开头的都是私有网络，有时安装的时候我们的习惯会把192网段的配置成公共网络，这样有可能会报错。
在安装的时候要注意给网卡配置网关，不配置网关有可能vip启不来。
7.RAC的命令及启动关闭顺序
crsctl (使用root）主要是管理操作系统的一写进程
crs_*(root/oracle都可以)主要是管理在集群上的资源的
srvctl(oracle)主要是针对RAC上的DB，主要管理RAC上的DB
遵循以下步骤启动和停止单独的应用程序资源。
srvctl start nodeapps -n <node1 hostname>
srvctl start nodeapps -n <node2 hostname>
srvctl start asm -n <node1 hostname>
srvctl start asm -n <node2 hostname>
srvctl start database -d <database name>
srvctl start service -d <database name> -s <service name>
crs_stat -t
srvctl stop service -d <database name> -s <service name>
srvctl stop database -d <database name>
srvctl stop asm -n <node1 hostname>
srvctl stop asm -n <node2 hostname>
srvctl stop nodeapps -n <node1 hostname>
srvctl stop nodeapps -n <node2 hostname>
crs_stat -t
8.Votedisk的"多数可用算法"
在RAC中需要注意的是,Votedisk使用的是一中"多数可用算法"。如果有多个Votedisk,则必须一半以上 votedisk同时可用,Clusterware才能正常工作。比如配置了4个votedisk,如果有一个votedisk被破坏， 集群不受影响正常工作。如果有两个votedisk被破坏，剩下的两个votedisk在数量上不满足一半以上，集群 会立即宕掉，所有节点立即重启。所以如果添加votedisk,尽量不要只添加一个，而应该添加两个以上，这一点和ocr 不一样。
添加和删除votedisk的操作比较危险，必须在停止数据库、停止ASM、停止CRS Stack后操作,并且操作时必须使用-force参数。
注意：即使在CRS关闭后，也必须通过-force参数来添加删除votedisk。并且-force参数只有在crs关闭的场合下使用才安全。
因为votedisk的数量应该是奇数，所以添加删除操作都是成对进行的。
9.OCR磁盘
Oracle Clusterware把整个集群的配置信息放在共享存储上，这个存储就是OCR Disk。在整个集群中，只能有一个节点对 OCR Disk进行读写操作，这个节点叫作Master Node,所有节点都会在内存中保留一份OCR的拷贝，同时有一个OCR Process
从这个内存中读取内容。OCR内容发生改变时，由Master Node的OCR Process负责同步到其他节点的OCR Process。
因为OCR的内容如此重要，Oracle会每4个小时对其做一个备份，并且保留最后的3个备份，以及前一天、前一周的最后一
个备份。这个备份有Master Node的CRSD进程完成，备份的默认位置是$CRS_HOME/crs/cdata/<cluster_name>目录下。每次备份后，备份文件名字会自动更改，以反映备份时间顺序，最近一次的备份叫作backup00.ocr。这些备份文件除了保存在本地，DBA还应该在其他存储上保存一份，以防止意外的存储故障。
可以使用 ocrconfig -showbackup命令查看ocr自动的备份信息
10.RAC中当遇到一个节点重启，我们该如何入手分析原因
尽管可能会有各种原因造成节点重启，不过我们这里只关注有Oracle Clusterware所造成的节点重启。 对于Oracle Clusterware来说，可能导致节点重启的进程有三：ocssd进程、oprocd进程、oclsomon进程。
<1>oprocd:如果在UNIX平台上，并且没有使用厂商的clusterware,就会有这个进程出现。在LINUX平台上， 从10.2.0.4开始也是用这个daemon（守护进程、后台进程）,这个daemon进行一个无穷的循环，如果超过1.5秒没有激活，就会重启节点。
<2>cssd:这个daemon通过私有网络以及表决磁盘(Voting Disk）去ping集群中的其他节点。如果在规定时间内(Misscount和Disktimeout) 没有收到响应，就会重启节点。
<3>oclsmon:这个进程内是监控CSSD的进程，保证CSSD的健康，如果发现任何问题，这个进程都会重启节点。
不论是哪种原因造成的系统重启，其目的只有一个,就是提供IO Fencing的功能。因此，要想分析系统重启的原因，其实就是要找出到底 是哪个进程造成的系统重启，然后再分析具体原因，这种分析只能通过进程的日志来进行。
--参考P184