RAC的实现都是基于硬件的配合，使用软件产品来实现的，根据前面讨论到的逻辑层次结构，构成RAC的软件主要包括存储层、集群层和数据库层，分别由存储管理软件、集群管理软件和数据库管理软件来实现。

在10g版本之前的Oracle RAC中，要搭建一个Oracle集群环境需要用到第三方的集群管理软件和存储管理软件。Oracle从10g开始，推出了自己的集群管理软件和存储管理软件。Oracle 11g R2将这两部分软件进行打包，作为一个基础的架构软件推出，同时支持第三方产品的使用。下面对这三部分软件进行详细的讨论。

存储管理软件

Oracle 11g之前，Oracle数据库支持直接使用裸设备，虽然它有高性能等特点，但也存在不便于管理等问题。从11gR2开始，Oracle图形化界面不再支持直接使用裸设备，取而代之的是使用Oracle ASM(Automated Storage Management，自动存储管理)作为Oracle默认的存储管理方式。

ASM结构没有文件系统那么复杂，丰富的特性使它同样具有出色的性能，非常适合Oracle数据库的使用。从11gR2版本开始，包括Clusterware磁盘文件OCR和Votedisk在内的所有Oracle文件，都支持直接存放到ASM当中，并且在ASM的基础上还推出了ACFS(ASM Clusterware File System，ASM集群文件系统)。由此Oracle有了自己的集群文件系统，ASM开始成为一种完整的存储解决方案。

ASM也是建立在裸设备基础上，没有任何文件系统对它进行格式化。ASM能够实现镜像和条带化，支持动态地添加、删除磁盘，并且能自动实现重新平衡(可以简单地理解为碎片整理功能)。ASM管理工具SRVCTL、ASMCMD在10g的基础上进行了扩展和增强。11gR2版本新推出的ASM图形化管理工具ASMCA，为ASM的使用提供了强有力的支撑。

除了ASM外，Oracle继续支持使用集群文件系统作为存储方式。10g版本中出现的OCFS(Oracle Cluster File System，Oracle集群文件系统)依然能够继续使用，从10g版本的使用情况来看OCFS是很稳定的，但它的稳定性依赖于节点网络(使用OCFS需要配置网络心跳)和存储连接的稳定性。Oracle也支持使用NFS的方式实现共享存储，同时继续支持第三方的集群文件系统，如Red Hat 的GFS、IBM AIX的GPFS等。

集群管理软件

部署RAC不仅硬件上有一定的要求，软件也不像单实例数据库只需要一个数据库软件。除了数据库软件外，集群还需要集群管理软件协调节点服务器之间的工作，以管理集群的各种资源，配合数据库实现集群的高可用性。Oracle有自己的集群管理软件Clusterware，Clusterware与Database高度地集成，它们的组合成为部署RAC的首选。同时，Oracle也支持第三方的集群软件来实现RAC，但这并不意味着不需要Clusterware，即使使用第三方集群管理软件也只能代替Clusterware的部分功能，从某种角度讲，使用第三方集群管理软件来实现RAC只会增加管理难度和维护成本。

Clusterware为所有平台的Oracle数据库提供一个完整的集群解决方案，并为RAC运行提供必要的基础架构。Clusterware通过对VIP地址、数据库、监听器、服务等CRS资源的管理提供RAC的高可用性。

使用Clusterware不仅可以使Database具有高可用性，通过简单的配置也可以使应用服务器具有高可用性。所以，Clusterware更像是一个独立的产品，它不只限于配合Database的使用，还可以和其他应用产品集成来实现各种产品的高可用性。从Oracle 11g开始，Clusterware作为Grid Infrastructure的一部分被安装和使用。安装和运行Clusterware的服务器可以具备不同机型、不同配置，但同一个集群必须安装相同的操作系统。

RAC的部署不依赖于第三方集群管理软件，提供了只使用Oracle产品就能完成集群搭建的整体解决方案。对于客户来说，这样既降低了维护成本，减少了厂家之间责任的推脱，也使问题得到了更快的解决。

数据库管理软件

狭义上讲，RAC特指RAC Database，是广义RAC体系中的数据库层，是RAC体系中最核心的部分，由分布在不同节点服务器的数据库实例和共享存储上的数据库组成。一个RAC Database只有一个数据库，但是有多个实例分布在不同的服务器上。RAC Database也是个集群，比单实例数据库有更多的后台进程来保证节点间实例访问的一致性，同时，它又与集群管理软件的后台进程配合，共同实现RAC高可用性。

在单实例数据库中，实例和数据库是一对一的关系;在RAC数据库中，实例和数据库是多对一的关系。RAC Database不同于Oracle单实例数据库，每个RAC实例有如下特点：

·有独立的Redo进程和文件，必须放在共享存储上。

·有独立的UNDO表空间，必须放在共享存储上。

RAC Database通常包含两个或更多的数据库实例，每个实例包含自己的内存结构和后台进程。RAC Database和单实例数据库有相同的内存结构和后台进程，另外还附加了一些RAC所特有的进程和内存结构。RAC数据库使用Cache Fusion技术，将所有实例的SGA融合到一起，使之形成逻辑上单一的缓冲区，每个节点实例缓冲区都是集群缓冲区的组成部分。由于Cache Fusion的原因，RAC数据库占用的SGA空间要比单实例占用SGA的空间更大。

RAC并不能解决运行中可能出现的所有故障。存储失败(如阵列磁盘损坏)对RAC来说是致命的，一旦存储失败就可能导致所有运行节点都会出现问题。Oracle针对这种情况提出了MAA(Maximum Availability Architecture，最高可用性构架)，即RAC Active Data Guard，它可以有效地避免存储失败导致的数据丢失和长时间停机。Active Data Guard中的Active指的是从11gR2开始，物理Standby以只读方式打开的情况下，依然可以应用传送过来的日志。本书第11章将详细讨论Data Guard技术。

需要说明的是，MAA构架是最高可用性，但不是完全可用性。Data Guard的主备切换可能需要几分钟或更长的时间。所以即使使用了MAA构架，当RAC所有节点出现了故障，在一定时间内也会影响系统的正常使用。

小结

RAC具有非常多的特点，首先RAC是并行运行的架构，所有的节点都同时工作，具备非常高的可用性，能够在出现单点故障的时候依然提供服务。由于11gR2版本中网格即插即用的出现，集群添加、删除节点变得非常方便，RAC的吞吐量随着节点数目的增加也不断得到增大。

RAC是高可用性的解决方案，但是由于它的运行需要众多不同类型硬件产品的支持和协同工作，所以可能存在一些不稳定的情况;同时，由于RAC的体系结构导致私有网络成为RAC的一个性能瓶颈，后面将对这两个问题进行详细的讨论。最后讨论了组成RAC的软件，分别由存储管理软件、集群管理软件和数据库管理软件构成。

Oracle RAC运行ocrconfig replace ocrmirror出现PROT-22错误

在oracle rac环境中，运行命令出现错误PROT-22: Storage too small，，导致问题产生的原因是空间不足。将ocrmirror对应的目标裸设备大小增加128M后，再次运行ocrconfig �Creplace ocrmirror，命令成功执行。

oracle rac,ocrconfig