一、Oracle RAC 几个常见的错误观点
　　由于最终用户习惯于获得瞬间响应时间，Oracle为其产品提供持续可用性方面受到了前所未有的挑战。那些在Redwood Shores(译者注：Oracle公司总部所在地)的家伙们提供了一个重要的工具这就是Oracle Real Application Clusters (RAC)。
　　什么是RAC?简单来说就是一套允许单个数据库被多份oracle程序同时访问的软件工具。如果一个服务器崩溃了，事务能够在最短的down机时间内被重定向到其他存活的服务器上。
　　Oracle的宣传称RAC是治愈多种疾病的良药，而IT厂家则会对这样的市场宣传产生误解，从而无法正确区别在高可用环境(HA)中使用RAC的成本和收益。
　　最常见的Oracle RAC错误观点在于误解了它的功能和限制。Oracle Real Application Clusters被作为综合能力规划战略的一部分，但是人们并不完全明了其技术上的强项和限制。下面列举一些关于这项技术的常见误解。
　　Oracle RAC是为了提供扩展性的
　　尽管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，或者采购更快的存储比如说固态硬盘。
　　Oracle RAC保证了快速响应时间
　　事务响应时间总是重要的，但是它对于RAC数据库来说尤为重要。这是因为在连接阶段为了探测是否一个RAC节点或者机器已经失效而消耗了等待时间，因此你必须保证新事务要小于1秒时间这样才能保证2秒的failover时间。
　　Oracle RAC不需要灾难恢复组件
　　除了在少数案例中使用了DWDM技术(也就是dark fiber)，你仍然需要创建一份灾难恢复解决方案。因为RAC节点通常只间隔数英里，像飓风这样的自然灾害还是能够引起全局中断。因此RAC最佳实践中还是要包含一份地理上的快速失效接管解决方案，比如Data Guard或者更好一些，多路流复制。
　　二、Oracle RAC最佳实践之实施篇　　

       RAC数据库通常都遵循着跟任何 Oracle数据库一样的最佳实践方案，只是其中有一些是Oracle RAC系统特有的。首先，很重要的一点是如何尽量缩小RAC节点间的物理距离而又能保证它们之间互相独立，这样才能避免所有节点同时失效的情况。
　　在一个繁忙的RAC数据库中，server interconnect(服务器内联)的速度对于系统响应速度有决定性作用。最佳实践推荐我们使用尽可能快的interconnect，通常是比如 dark fiber这样的光纤解决方案。
　　有些客户将RAC节点分布在相邻的独立建筑中，得益于超快的dark fiber interconnect技术，可以使用“Extended RAC”架构来使RAC节点的距离大到100英里。这使您同时拥有了高可用性和灾难恢复能力。
　　不过Dark fiber非常昂贵，为了降低成本，大多数客户采取了将RAC和灾难恢复方案比如多路流复制结合在一起的最佳实践。
　　RAC的要点是保证最终用户在一个服务器失效后自动重新连接到还存活的其它服务器上。这是通过应用服务器层面或者是Oracle Transparent Application Failover (TAF)功能实现的。但是不论选择哪种方式，你都必须等待大概3秒，之后才会认为此服务器已失效而重新尝试连接到另外的服务器。
　　接下来，让我们更进一步探讨一下特定RAC技术的最佳实践。
　　三、Oracle RAC interconnect最佳实践
　　RAC是多实例共享同一数据库的方法，共享数据块通过高速interconnect在节点之间传输，这称为cache fusion。为了保证性能，关键之处在于密切关注interconnect层面并且记住以下几点：
　　RAC喜欢较小的block size，interconnect必须拥有足够快速的网络硬件，RAC负载均衡对性能至关重要。
　　Oracle RAC节点负载均衡最佳实践
　　我不太同意Oracle提出的负载均衡基于最小负载的实现方法，因为这增加了额外的cache fusion。在实际环境中，相似业务的最终用户都将请求发送到同一RAC节点上。如果我们的RAC系统有不同类型的最终用户，我们会希望将负载均衡到不同的数据区域去。举例来说，客户处理可能在节点1上，订单处理在节点2上，而产品处理则在节点3上。将RAC最终用户通过数据需求来分组可以保证 cache fusion负载降到最小。
　　Oracle RAC磁盘存储管理最佳实践
　　为了实施RAC系统，你应该使用共享存储设备因为很多服务器都必须同时存取磁盘。一个单实例数据库可以使用Direct Attached Storage (DAS)这是一种连接到单一服务器上的一组廉价磁盘，而RAC则必须使用Storage Area Network (SAN)，这是更昂贵更复杂的通常使用光纤通道连接到多个服务器的磁盘阵列。这需要一组独立的硬件，从主机总线适配器连接到SAN上。因此DBA具有数据存储层面的完整知识就显得很重要。
　　Oracle RAC块大小最佳实践
　　最佳实践是在RAC环境中使用小的2K block size以在cache fusion时最小化“baggage”传输。因为block size是工作的单位，block size越小，就能够通过更小的负载传输越高粒度的数据。如果你有较长的数据行(大于2K)，则需要转而使用4K的block size。
　　实施RAC集群仅仅是开始，持续监控RAC集群的健康状况在造成最终用户困扰之前就及时定位解决问题也是至关重要的。
　　Oracle RAC监控最佳实践
　　为了保证 RAC节点永远不会碰到全局问题(译者注：所有节点都失效)，正确的监控架构都必须的。RAC数据库很少在没有任何报警的情况下就失效。如果DBA懂得监控正确的指标，他就能够创建一套预警系统，能够及时发现问题并通知他，让他在实例崩溃之前就修复问题。
　　DBA必须监控集群，共享磁盘，ASM(或者OCFS)，数据库实例，监听，和更多的深层次指标，比如缓存一致性，interconnect延迟，磁盘时间等等一系列事情。
　　虽然高成本的性能监控工具比如Oracle Grid Cntrol能够帮助初学者进行初步的RAC监控，但是一个RAC DBA还是应该具有编程技巧，使用查询数据字典，dbms--scheduler以及邮件告警机制来创建属于自己的RAC监控架构。
　　四、如何准确定义RAC数据库的职业角色
　　数据库最佳实践是雇佣经验丰富的 RAC DBA来管理集群，避免招聘那些仅仅有培训经历而无实际工作经验的人。
　　认识到人力资源成本是Oracle管理中的最昂贵部分是很重要的，这数十年来，硬件开销已经极大下降但是人力成本还是与以往一样。
　　要注意到拥有RAC技术的Oracle专家比普通的DBA更值钱。最近的 Oracle从业人员工资调查指出，DBA平均年薪是97000美元，RAC专家通常可以拿到每年140000美元。而那些管理着价值上百万美元的RAC 数据库的专家则通常年薪高达250000美元。
　　可惜，培养自己的RAC DBA并不是简单的事儿，培训教程非常昂贵，并且又没有能够代替真实环境经验的课程。培训自己的DBA RAC技术会使他更有市场竞争力，花费了数万美元来培训自己的DBA然后他跳槽去了更好的地方这样的情况并不鲜见。
　　Oracle RAC工作角色
　　系统管理员(SA，负责管理数据库和磁盘)和RAC DBA(负责管理RAC数据库)之间永远都有冲突。同时也有网络管理员这个职位的明确定义，这是专门管理RAC数据库环境的集群心跳内联和节点间数据传输的职位。
　　如果DBA负责保障RAC数据库性能，那么他应该被被给予服务器和磁盘存储子系统的root权限，但是，并不是所有DBA都拥有管理复杂服务器和SAN环境的计算机知识，因此看个案而定是否给予此权限。
　　Oracle RAC培训
　　不能正确地培训SA，DBA和网络管理员就会导致系统的非计划停机，SAN环境，比如EMC，Tagmastore和 NetApp都有复杂的架构，这需要定期的培训课程。
　　磁盘配置也同样具有挑战性，RAC只有在使用了特定的磁盘配置(比如 ASM，OCFS，RAW或者第三方集群文件系统)时才能正常运转。这些工具也同样需要培训。
　　网络管理员也必须接受培训，来知道如何设置cluster interconnect，也包括在诸如Infiniband 和DWDM上配置interconnects。
　　这些RAC相关职位中，DBA有最大的学习曲线。他们必须要明白如何配置和管理所有复杂的RAC组件，包括clusterware和文件系统存储。
　　结论
　　总体来说，虽然RAC提供了持续的可用性，它也不是什么神话。有很多工作需要做才可以保证RAC数据库使用可用。每一个RAC数据库都有其特性，但是也有一些大家都知道的风险和陷阱。使用 Oracle RAC最佳实践是保证成功的必修课。

（责编：韩雨彤）

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。