RAC 与双机热备的区别在 Cluster （ 集群 ） 多机系统平台上，常用的高可用性技术有两种：双机热备份和 RAC 并行服务 器这两种方式采用的机制不同，实现的效果也不同1、双机热备份方式在双机热备份方式下，数据库系统平时只能在一台服务器（例如服务器A）上运行，另一台服务 器无法直接访问数据库，自然也无法进行负载分担当服务器A由于故障失效时，由相应的操作 系统软件控制，将服务器A管理的存储设备（如硬盘）转交给服务器B控制，同时在服务器B上 启动另一个数据库进程，管理数据库这种切换并启动新的数据库核心的过程一般需要几十秒到 几分钟这种方式的主要缺点在于：• 由于需要重新启动数据库核心进程，无法保证数据库系统连续不间断地运行；• 在系统切换的过程中，客户端与服务器之间的数据库连接会中断，需要重新进行数据库的 连接和登录工作；• 由于数据库系统只能在一台服务器上运行，另一台服务器无法分担系统的负载，实际上造 成了客户投资的浪费在有些系统中，为了解决双机负载分担的问题，将应用系统人为分 割为两个数据库系统，分别在两台服务器上运行这种方式在一定程度上解决了负载分担 的问题，但给系统管理、统计分析等业务处理带来了很多额外的复杂性2、 RAC 方式在并行服务器方式下，两台 （或多台 ）服务器上各自运行一个数据库核心进程，但共同管理、 操作一个数据库。
客户端无论连接到哪个服务器都可以在数据库中进行操作当服务器A由于故 障失效时，数据库系统本身并未停止工作，连接在服务器 B 上的客户端还可以继续进行正常工作 同时，服务器B上也不需要再启动新的数据库服务器进程，因此也没有“切换时间”对于一些 特殊应用中严格要求前端应用不能中断的情况，Oracle并行服务器还提供了一种“预连接（pre- connect） ”方式，以这种方式连接的客户端当服务器端发生故障时，客户端与数据库服务器的连 接不会中断，会被Oracle并行服务器软件自动转接到还在正常工作的其它服务器上，不需要重新 输入用户名及口令同样有许多操作系统平台支持并行服务器方式的高可用性方案，例如 HP MC Service Guard OPS Edition 等与双机热备份方式相比，Oracle Real Application Cluster并行服务器方式有以下优点：• 各服务器共享一个数据库，在正常运行时可以进行负载分担，无需考虑应用数据的人为分 割• 并行服务器方式对应用完全透明，在应用程序设计和开发的过程中也不需要进行特殊编程， 简化了开发的复杂程度，同时今后系统扩展也无需修改应用程序• 不需要重新启动数据库核心进程，缩短了故障造成的停机时间3、 RAC的好处具有 Cache Fusion 体系结构的 Oracle Real Application Clusters 为企业应用开发提供了以下好处• 应用系统灵活和毫不费力的伸缩性；应用用户可以登录到单独的虚拟高性能集群服务器。
向数据库添加节点非常容易，并且当需要添加处理器节点或者业务需求变化时，不用手工 对数据进行分区对于所有的应用即时提供集群的可伸缩性－－不用修改应用程序• 较之传统集群数据库体系结构的高可用性解决方案；该体系结构为客户提供了几乎连续的 数据访问，使硬件和软件故障导致的业务中断最小化系统具备对多个节点失败的容错能 力，使部件失败屏蔽开最终用户• 单独的管理实体；为了进行所有管理操作，在集群中保持一个单独的系统映像 DBA 一次 性地进行安装、配置、备份、升级以及监控等功能，然后 Oracle 将管理功能自动分配到适 宜的节点这意味着 DBA 只管理着一个虚拟服务器• Cache Fusion 保存了所有 Oracle 客户在他们应用中学习和开发 Oracle 的投资所有单节点 数据库功能都保留下来，并且应用程序使用相同标准的 Oracle 接口连接到数据库上可伸缩性基于 RAC 应用的用户或者中间层应用服务器客户，可以通过虚拟数据库服务名连接到数据库 上Oracle在集群中多个节点之间自动平衡用户负载不同节点上的Real Application Clusters数 据库实例预订所有数据库服务或者部分子集数据库服务。
这使得DBA高度灵活地选定，连接到特 定数据库服务的特定应用程序客户是否可以连接到某些或者全部的数据库节点虽然每一个节点 有一个不同的物理 IP 地址时，应用客户仍可以在一个逻辑数据库服务名的水平上进行连接因此 客户端对于不相关的事情如多服务器的多个地址可以毫不关心随着业务的增长，应用系统可以 从容地增加处理能力Cache Fusion体系结构直接地利用新节点的CPU和内存资源DBA无需用 手工对数据重新分区这个优点是这种体系结构的副产品，因为有透明度的数据存取是 Cache Fusion 的一项基本功能 Cache Fusion 体系机构自动适应快速变化的应用需求及随之而来的工作 负荷的改变DBA也不必因为工作负荷变化而对数据进行手工的重新分区Real Application Clusters通过动态地重新分配数据库资源，从而在节点之间用最小化的磁盘I/O和低的延迟通信来 优化利用集群系统资源这使得Real Application Clusters可以从容实现增加的应用吞吐量和优化的 响应时间高可用性Real Application Clusters 提供了真正的高可用性解决方案，关键的突破是在大多数数据库恢复 期间能提供完整的数据库访问。
这使得Real Application Clusters成为应用所要求的24x7可用性的 最佳平台Real Application Clusters 在高可用性上在三个关键领域胜出：• 提供了数据库恢复期间的数据块访问• 透明的失效转移对最终用户屏蔽了系统失效• N-1 节点失效的容错能力只要有一个数据库节点幸存，Real Application Clusters就能够提供完全的数据库访问和相对不 间断的操作可管理性Real Application Clusters实现了真正意义上的一个单系统访问数据库，它提供了从任何节点到 所有磁盘设备和远程高速缓存进行无缝数据访问的能力此单系统映像延伸到所有数据库管理操 作安装、配置、备份、升级以及监控等操作只需进行一次，然后会自动发布到集群中所有节点 上去各种 Oracle 工具(如 Oracle Universal Installer、Database Configuration Assistant 以及 Recovery Manager )将发现集群数据块中所有不同的节点并以它们为目标分配给想得到的任务 通过为特定的管理操作选择多个目标节点，管理任务在数据库集群中多个节点上执行。
这为应用 系统管理其环境带来了极大的可伸缩性上的经济实惠例如，向数据库集群添加一个节点只会增 加最小的管理任务这样，Real Application Clusters支持商务应用和决策支持之类的应用，并 且为数据访问和管理提供了单一的虚拟高性能服务器总结1、 对于硬件来说基本上一样，共享存储、光纤线（也有还用SCSI线的）、多台小型机（可以做 多节点的相互热备，也可以做多节点的RAC）、光纤交换机（如果是用光纤卡的话）；但做RAC, 在主机之间，最好使用高带宽网络交换机（虽然不用也可以做成），硬件成本相差不大2、 软件呢，差别可不小如果是双机热备，必须买操作系统级的双机管理软件；如果是RAC，目 前还是建议购买双机管理软件（尽管10g的crs+asm可以摆脱双机软件了，但ASM目前实在太难 伺候了），当然还得买 RAC license3、 日常维护RAC要求的技术含量更高，也应该更勤快最关键的是得买Oracle服务，否则遇 到有些问题（bug），你就比单机还不高可用了4、 优缺点这个，看看RAC的官方论述吧如果能用好，确实是很有好处的目前我们的40多 个客户的使用情况来看，RAC确实大大降低了他们的downtime，另一方面可以说就是提高了生产 力。
另，为什么 RAC 比双机热备切换快很多？我们先分析双机热备切换的步骤：假设A机是主机，B机是备机当A机发生故障时，集群软件 通知B机接管数据库接管过程如下：1. B机接管数据库文件所在的磁盘，花费时间为T1 （算在B机接管数据库文件所在的磁盘这部分 时间内了，因为总是需要从A umount，然后在B上mount的2. B机启动数据库实例，花费时间为T23. B机的数据库实例mount数据库文件，花费时间为T34. B机的数据库实例open数据库文件，完成数据库重启，花费时间为T45. 应用重新连接上B机的数据库实例，花费时间为T5所以切换时间 T=T1+T2+T3+T4+T5 （可能还有其它一些可以忽略不计的时间）以上切换时间的计算 是从集群软件断定A机已经停机开始计算，之前的时间不计1. 如果数据库文件所在的磁盘已经是共享文件系统，而且事先B机已经mount该文件系统，那么 T1=0,否则T1可能需要十几秒到2分钟2. T2 一般比较快，如果Oracle SGA区比较大，时间会稍长一点，一般1~2分钟3. T3视数据文件的数量而定，如果数据文件比较多，那么这个时间也会比较长，一般2~5分钟。
这个时间和磁盘的速度也有关系4. 如果切换是属于计划停机切换，那么数据库一般是正常shutdown的，重新open时不需要做恢 复工作，这个时间可能会很快，例如1分钟之内；但是如果是由于故障停机切换，那么数据库重 新open的时候需要做大量的恢复（instance recovery）工作，所以T4有可能从1分钟到10分钟，甚 至更长这个时间和磁盘的速度也有关系5. 如果应用原来也跑在A机上，那么切换以后，还要重启应用，这个时间就比较长如果应用部 署在独立的应用服务器，例如C机上，那么一般需要等数据库服务器IP地址浮动到B机，Oracle 监听器重启以后，应用才能重新连接到数据库服务器这个时间可能需要1分钟到5分钟，重启 应用的时间也可能更长所以双机热备下切换时间最少T=0+1+2+1+1=5分钟，这是非常理想的情况下；按照经验，至少需 要10分钟也可能是T=2+2+5+10+5=24分钟，甚至更长，视数据库需要恢复的时间再看RAC的情况1. 一定是共享磁盘，不需要再mount磁盘T1=02. B机的实例平时已经Open，所以T2=0, T3=0, T4=03. 如果应用原来只跑在A机上，那么为缩短停机时间，可以事先可以在B机上把应用启动；A机 故障以后只要使用B机的应用即可。
没有停顿如果应用部署在独立的应用服务器上，例如C机, 甚至还有D机时，原来连接B机的应用正常工作，没有停顿时间；原来连接在A机上的应用重新 连接数据库，这个部分应用可能的中断时间很短，一般在几秒钟到1 分钟之内所以RAC环境下切换时间最少T=0+0+0+0+0.1=0.1分钟也可能T=0+0+0+0+1=1分钟，但不会长 很多如果有人不能理解这过于技术的描述，那么记住以下的比喻：双机热备相当于火车头坏了，停下来换一个火车头；而RAC相当于有多个火车头，即使一个不工 作了，也不需要停下了。