为什么RAC比双机热备切换快得多？
- RAC与双机热备的区别？
在 Cluster ( 集群 ) 多机系统平台上，常用的高可用性技术有两种：双机热备份和 RAC 并行服务器。这两种方式采用的机制不同，实现的效果也不同。
- 1、双机热备份方式
这种方式的主要缺点在于：
由于需要重新启动数据库核心进程，无法保证数据库系统连续不间断地运行；
在系统切换的过程中，客户端与服务器之间的数据库连接会中断，需要重新进行数据库的连接和登录工作；
由于数据库系统只能在一台服务器上运行，另一台服务器无法分担系统的负载，实际上造成了客户投资的浪费。在有些系统中，为了解决双机负载分担的问题，将应用系统人为分割为两个数据库系统，分别在两台服务器上运行。这种方式在一定程度上解决了负载分担的问题，但给系统管理、统计分析等业务处理带来了很多额外的复杂性；
- 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 就能够提供完全的数据库访问和相对不间断的操作。
- 总结
2、软件呢，差别可不小。如果是双机热备，必须买操作系统级的双机管理软件；如果是RAC，目前还是建议购买双机管理软件（尽管10g的crs+asm可以摆脱双机软件了，但ASM目前实在太难伺候了），当然还得买RAC license。
3、日常维护。RAC要求的技术含量更高，也应该更勤快。最关键的是得买Oracle服务，否则遇到有些问题（bug），你就比单机还不高可用了。
4、优缺点。这个，看看RAC的官方论述吧。如果能用好，确实是很有好处的。目前我们的40多个客户的使用情况来看，RAC确实大大降低了他们的downtime，另一方面可以说就是提高了生产力。
- 为什么RAC比双机热备切换快很多？
1. B机接管数据库文件所在的磁盘, 花费时间为T1（算在B机接管数据库文件所在的磁盘这部分时间内了，因为总是需要从A umount，然后在B上mount的） ；
2. B机启动数据库实例，花费时间为T2 ；
3. B机的数据库实例mount数据库文件，花费时间为T3；
4. B机的数据库实例open数据库文件，完成数据库重启，花费时间为T4；
5. 应用重新连接上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的情况
3. 如果应用原来只跑在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相当于有多个火车头，即使一个不工作了，也不需要停下了。
本文地址：https://wenku.baidu.com/view/9a7a45df81c758f5f61f67e1.html