Oracle RAC中最常见的错误观点是因为误解了Oracle RAC的功能与限制。以下的文章就是列举一些关于Oracle RAC中最常见的错误观点中经常出现的一些错误的观点，以下就是文章的相关内容的介绍。
Oracle RAC 几个常见的错误观点
由于最终用户习惯于获得瞬间响应时间，Oracle为其产品提供持续可用性方面受到了***的挑战。那些在Redwood Shores(译者注：Oracle公司总部所在地)的家伙们提供了一个重要的工具这就是什么是RAC?简单来说就是一套允许单个数据库被多份oracle程序同时访问的软件工具。
如果一个服务器崩溃了，事务能够在最短的down机时间内被重定向到其他存活的服务器上的宣传称RAC是治愈多种疾病的良药，而IT厂家则会对这样的市场宣传产生误解，从而无法正确区别在高可用环境(HA)中使用RAC的成本和收益。
最常见的Oracle RAC错误观点在于误解了它的功能和限制。Oracle Real Application Clusters被作为综合能力规划战略的一部分，但是人们并不完全明了其技术上的强项和限制。下面列举一些关于这项技术的常见误解。
是为了提供扩展性的尽管Oracle公司希望你买小型刀片服务器然后使用他们的网格计算方案来获得“水平扩展”，但是实际上这并不是多数用户使用RAC的方法。注意：RAC只是在超大型IT部门需要超过单个服务器提供极限的更多马力时的一种正统扩展方法。
作为Oracle***实践，要通过“垂直扩展”先进行单个服务器的扩容，先向上扩展再向外扩展。只有在你使单个服务器容量饱和之后再考虑“scale out”到多个服务器上。今天，单个服务器的内存和CPU马力比起前几年来说有了突飞猛进，因此比起往RAC环境中添加一个新服务器而言，增加单个机器的资源更加简单。
在真实环境中，单个服务器能够处理每秒上千次的事务。只有世界上***的那些Oracle数据库需要扩展到使用RAC。
Oracle RAC是独立的高可用解决方案
记住RAC只能保护你免于实例失效，这仅仅是众多可能引起非计划性中断的原因之一。为了真正的持续可用性，我们还必须部署多重镜像磁盘和冗余网络组件。
为了每个RAC节点的可用性，需要多个冗余的主机总线适配器，多个网卡以及多个电源。就算只是在数据库实例产生了failover，你也需要提供软件以允许多个主机总线适配器自动failover，并且提供单个组件失效通知。
就像我们已经提到的，RAC系统需要一个cluster interconnect来提供内存对内存(RAM-to-RAM)的数据块传输。Interconnect必须非常快速，必须有高带宽和低延迟。Interconnects包括
Cache fusion上的瓶颈也是为什么RAC扩展或者说水平扩展有问题的另外一个原因。如果你的cluster interconnect无法处理这样的流量，那么额外的服务器将会降低整个系统的性能而不是提升它。解决这个问题的唯一办法就是改造应用以适应RAC，或者采购更快的存储比如说固态硬盘。
保证了快速响应时间事务响应时间总是重要的，但是它对于RAC数据库来说尤为重要。这是因为在连接阶段为了探测是否一个RAC节点或者机器已经失效而消耗了等待时间，因此你必须保证新事务要小于1秒时间这样才能保证2秒的failover时间。
Oracle RAC不需要灾难恢复组件除了在少数案例中使用了DWDM技术(也就是dark fiber)，你仍然需要创建一份灾难恢复解决方案。因为RAC节点通常只间隔数英里，像飓风这样的自然灾害还是能够引起全局中断。因此RAC***实践中还是要包含一份地理上的快速失效接管解决方案，比如Data Guard或者更好一些，多路流复制。
【编辑推荐】
