1.介绍
在部署以数据为中心的应用程序时面对的问题经常用Oacle实体应用程序集群RAC来进行解决，作为一种非常重要的方案，它经常要受到许多因素的影响，有些是技术上的，而有些则不是，但是所有这些相关因素都会带来对数据库技术的影响。本文将针对这些围绕Oacle实体应用程序集群RAC的观点展开分析，研究技术问题，以及对与数据库管理系统的发展趋势有关的相关问题进行探讨。
首先，让我们来了解一下作者的技术背景以及在接下来的讨论中所持有的观点。James Hamilton是Microsoft SQL Server研发组的软件架构师，在他的领导下，组员们共同对包括SQL语言编译器、最优化查询、查询执行引擎、数据定义语言DDL、元数据、目录管理组、安全、可扩展标记语言XML、客户网络协议组、全文本搜索开发组、公用语言运行时（CLR）等付出了努力。James在IBM工作了11年，那时他作为DB2 UDB的首席构架师，帮助发布了很多产品。帮助客户成功地配置了DB2并行版本（现在它已经是DB2企业版的重要组成部分），有些客户会明确指出他们倾向于使用基于磁盘的解决方案，而不是Oacle实体应用程序集群RAC所基于的核心技术——数据库并行。当然，其中的利害关系是很明显的，幸运的是，该观点涉及的内容是复杂的，这也不是仅仅通过对技术架构的偏见和爱好简单作出的决定。。所有潜在的并行集群技术都有它的优点和不足，并且每一个成功开展的例子都可以被引用，本文中将主要引用那些用RAC解决了的问题，通过选择Oracle和他的竞争者的不同解决方案来进行比较。
Oacle实体应用程序集群RAC解决方案，执行的状况，它的品牌名称，以及它的销售状况自从这项技术作为Oracle并行服务器的最初构想，在近十年来都有了很大地发展。[MORL02, YDNR02] Oracle 10g RAC 已经致力于解决面向以数据为中心的应用软件的两个最为核心的问题：1）应用程序的可用性，2）可负担起的性能，而这些要求对数据管理人员来说是非常重要的。因此，Oracle以及整个行业，要从整体上解决基于应用程序设计、需求分析和具体部署场景的所有需求。
2.应用程序的可用性
在寻找更多外来的可用技术之前，更应该先要回顾一下几个核心的技术原则。应用程序的可用性，尤其是当面对未知的障碍时，几个普遍原理将会适用于系统设计的整个过程：简单性、冗余性，以及独立性。
2.1 简单性
用来提高整个应用程序可用性的任何产品或功能都应该被设计的简单易用，在大多数情况下，操作和管理失误是导致应用程序中断的主要原因。例如，在最新发布的Oracle RAC白皮书中指出，在一个典型的服务器端系统中有36%的未知故障来源于管理失误[ORCL02]。David Patterson在他的论文“一种用来评价事故成本的简单方法”中也证实了这一点，同时他在文中还指出，在各种事故中，人为的失误占到53% [PATT01]。
系统的复杂性会导致管理失误，有时这些失误并不是最终结果，通常数据库管理员（DBA）被复杂的系统占据了大量的时间。这些日常冲突是经常存在的，这就使得管理组织不能将更多的时间用来设计长期方案和改善整个业务的基础构架。而且还需要指出的是，管理的复杂性，对于不同的数据库管理系统提供者来说可能会是完全不一样的，这是需要仔细研究的。然而，RAC忽视了不同竞争者之间存在的不一致性，并且只关注Oracle的产品，因为这要比它所提供的单点产品要复杂的多[FORE02]。长期以来Oracle的咨询报告指出，一个典型的、运行良好的、单点Oracle系统可以获得99.9%的可靠性，然而同样的应用工作负荷在两点的Oracle RAC上运行，投入同样水平的管理，则可以获得得适应性要明显的低，通常只能达到98%[YDNR02]。
关于这些报告的结果还有很多可以讨论的空间，因为它们是数据库管理员在管理不同的系统时所用到的工作负荷与质量的乘积。但是，关于复杂性问题可能带来的浪费数据库管理员大量的时间还是可能会产生适应性问题或者两者都有可能的问题，则很少有争议。
运营和管理的简单性是应用程序可用性的最强有力的驱动因素。
2.2 冗余性
组件可能会发生错误，因此在整个系统中就应该存在足够的冗余，从而使得在硬件、软件、以及管理过程中必然存在的组件错误能够得以幸免。许多高可靠性的系统一定会存在很多冗余的组件，因为在目前不可避免的错误中，要避免单点故障，这是一种有效的方法。硬件和软件组件可能会发生错误，如果在系统中没有足够的冗余，组件错误将会变为系统适应性的降低。
在过去的15年中，针对产生数据库数据冗余的最新技术已经形成了很多协议：在独立的数据节点之间进行日志传送。对它最早的公开描述是在1989年在加利福尼亚的Asilomar召开的高性能事务处理系统会议上由Burkes 和Treiber提出的[BURK89]。Oracle，DB2，以及 SQL Server都有共同点，Oracle提供的基于日志传送的解决方案具有数据保护功能[ORCL01]，IBM提供的DB2日志传送[DB203]，微软提供的SQL Server 2000日志传送[SQLS01]，以及SQL Server 2005数据库镜像功能[SQLS02]。数据库镜像可以在讨论这种类似于数据库有效性的各种优点时作为例子来使用。如图1所示，带有数据库镜像（日志传送），首节点与次要节点之间不共享任何资源，除了在两个系统之间以低层次的事务日志格式存在的唯一链接。值得提及的是，在关系型数据库系统中，日志和恢复、与事务日志相交互的组件，是最经得起测试的可靠代码路径。
在日志的传送配置中，两个系统的独立硬件、软件和数据拷贝将被100%的保留下来，同时，硬件或软件组件的错误则不会被传送。
如图2所示的Oracle RAC系统缺乏图1中所示的日志传送设计中的冗余度，并且集群中的所有节点共享存储子系统。对RAC来说，数据库计算的点是多余的并且是可替换的，这是非常好的现象。然而，只有一份数据库备份，也就是说，如果数据库的一部分遭到破坏，数据便不再有用，并且整个集群将会失效。
通过使用基于廉价冗余磁盘整列（RAID-based）的存储子系统，在任何RAC部署中数据冗余都是很容易实现的，但是这只能防止物理存储系统失败。如果存在失败，数据破坏或数据完整性的丢失在逻辑上是要比存储系统失败严重的多，存储区域网络（SAN）将会把这些受损的数据冗余存储在各数据文件中，不过这些数据在整个集群的各个点中将不再有用。然而，通过诸如数据保护或者数据库镜像等日志传送措施，数据将会受到保护，因为逻辑上存在的数据冗余将会位于存储子系统、主机总线适配器、驱动设备和操作系统之上。
需要记住的一个关键点是存储区域网络（SAN）可以存储多个数据冗余文件，这戏数据冗余的获得可以避免其他在数据库、操作系统和存储堆栈中产生的软件和硬件组件错误。
总之，Oracle RAC配置可以计算出多点冗余（运行数据库节点可以防止发生错误），特别的，在使用基于廉价冗余磁盘整列（RAID-based）的存储子系统时可以用来配置物理数据库冗余。然而，它仅仅是一个逻辑数据库文件备份，而且这是系统中非常重要的资源。在下一部分中，失败的方式将会导致在RAC中难以获得数据，因为这些点点失败将会存在于更多的细节中，而且这些点点错误在进行共享、并发的访问磁盘系统来获得高可用性的应用软件时会让我们很不舒服，这需要很高程度的可靠性。存储区域网络（SAN）系统提供了很优秀的管理性能和高质量的数据保护措施，但这却不是数据库可用性的全部解决方案。用户只是配置RAC而不增加数据保护或其他有用技术的解决方案，这将使得系统在日益增多的公共系统错误面前不能受到保护。
包括Oracle在内的所有数据库管理系统的主要供应商都可以提供完全的日志传送冗余，这是一种更好的可用性解决方案。
3.可负担的性能
对于以数据为中心的应用系统而言，性能和数据库的可测量性是最为重要的因素，数据库的可测量性还是应用系统开发商所要考虑的核心因素，因为要扩展同步的回归状态是非常困难的（很多应用程序提供全部的ACID属性（原子性、一致性、独立性、持久性）来使得它易于操作）。应用程序的扩展能力受到我们关于共享的应用程序规定的管理扩展能力的制约，如果应用程序是真正无状态的，或者应用程序的状态是完全非共享的，线性的应用程序扩展将很容易获得，要想扩展这样的一个应用程序，只需要增加它的实例。不幸的是，绝大多数有用的应用系统都具有相当多的状态，并且在不同的实例之间需要共享这些状态，这样可以支持更多的应用程序实例。这些共享的状态通常被存储在关系型数据库管理系统（RDBMS）中，因此，数据库管理系统的扩展会对应用程序设计者带来巨大的挑战。
应用程序设计者使用很多窍门和技术来降低数据库瓶颈，但是这些技巧是需要通过努力获得的，并且经常会限制应用程序的编写，这样就可能潜在的导致管理或操作成本的增加，因此，这就强烈的需要数据库管理系统基本设施提供者来解决这些问题，使得应用程序提供者更多地关注应用而不是关注集群的并行。
这些对性能扩展的探讨可能会被应用于工业领域，主要有以下两个方面：
1．硬件的发展和数据库扩展性能的提高。
2．中间层的缓存和扩展。
3.1硬件的发展和数据库扩展性能的提高
在过去的十年中，硬件得到了持续快速的发展，同时单点数据库性能也以摩尔定律的速度不断改进，在1994年，工业界中最好的单点TPC-C性能是1,470tpmC（IBM RS6000 PowerServer R24）
，然而，十年后的今天，三个主要数据库提供商可以生产出相当于当时1000倍的性能。同时，我们也可以看到性能改进了将近三个数量级，十年前的领先系统，IBM的产品，达到了$666.12/tpmC，而现在则通常是在$5/tpmC左右。
硬件以这样的速度不断发展，Intel认为在今后的十年中发展速度还会继续加快[INTL03]。
在前面的讨论中，之所以会产生TPC-C这样的结果仅仅是因为数据具有广泛的可用性，而且在两个大的数据库管理软件公司提供的产品中具有可比性，然而，作者所使用的大多数的客户端应用程序都明显的要比TPC-C复杂的多。虽然如此，在过去十年中硬件的发展以及由主要供应商所提供的数据库管理系统技术的改进都是非常巨大的，这一点毫无争议。例如，在90年代中期，作者帮助传送256个无共享数据库系统节点给客户，在最近的一次会议中，对于同一个客户，它与一个现代的单点系统进行了比较，在除了占地面积、重量和能量消耗之外的所有因素中，它与当时可用的单点系统相比要差很多。
由此可以得出结论，大多数的联机事务处理（OLTP）工作可以由高级别的单点系统顺利完成，但这并不意味着所有的工作负荷都可以通过这种方式来完成，其它因素也在起着作用，最应该关注的是它们都集中围绕更高级别的系统，这可能会导致发生与较低级别的系统不成比例的成本。也就是说，8个4 –ways要明显的比一个32-ways便宜得多，因此，尽管通常可以用单点系统来完成的工作负荷，也仍然存在有利于集群部署的好的意见。这些意见有：“一个单点系统可以在一个可接受的性能水平下完成整个工作负荷，如果使用基于集群的数据库管理系统体系，则所需要的硬件要比普通价格的硬件更昂贵。”高端的决策支持、实时的数据存储的工作负荷，以及应用程序的主体都可以用一个单点系统来完成，但是由于这些主机类型的系统相对比较昂贵，大多数的工业界人士倾向于“可负担的性能”，这从工程学的角度来说才是真正有意义的。实际上，整个解决方案使用的都是顾客的资源。
可以通过Oracle的RAC作为一个例子来说明讨论单一系统作为数据库管理系统集群映像的两个原因：1）在单点的数据库管理系统中工作负荷不能被完成；2）使用一个常用的多点系统更为便宜。不幸的是，就像对许多技术进行选择一样，这并没有明确的答案。
从图4中可以看出，管理和运行成本在硬件和软件成本中占有很大的比重，每年的硬件成本下降使得这一点变得更为明显，软件成本由不变逐渐下降，系统复杂性提高，同时人们的消费升高。
管理和运行成本仍占主导地位，在接下来的十年中，如果得不到改进这种状况将会继续。关于这些数据存在两种观点：1）复杂性是可以被避免的；2）在数据集中型应用系统中，硬件成本在不断降低，并且在整个成本构成中所占的比重将会变得很小。
尽管这个观点是在很多年前出现的，但目前它仍然是正确的：应用程序的工作负荷能够在单个系统上运行，而且也应该是这样的。虽然如此，有时数据库管理系统需要在多个系统中进行扩展，至少有两个基本的方法可以实现数据库管理系统工作负荷的扩展：1）依赖于单个系统映像，基于集群的数据库管理系统，例如Oracle的RAC；2）使用中间层的缓存或者数据分割。代表巨大进步的数据库管理系统供应商们明显对此有意见，因为这似乎很简单，但是实际上并非如此。本文重将更为详细的分析这些观点，讨论当选择一个基于集群的数据库管理系统时可能存在的潜在成本和所需要的替代技术，并且对比高速缓存和数据分割方法的各种优点和不足。
集群数据库管理系统所产生的费用：运行一个基于集群的数据库管理系统体系会产生很多相关的成本，以下作者将进行简单的总结；
按照目前的价格，Oracle（数据库）企业版每个CPU的消耗是40,000美元，或者每个用户许可证（NUP）的消耗是800美元，RAC的成本要在上述成本的基础上多出50%，也就是说，每个CPU的消耗是60,000美元或者每个NUP的消耗是1200美元[YDNR02]。
除了初始的采购价格之外，还需要年度维修费用，因此，尽管RAC可以使用常规的硬件，这也只能在软件授权价格方面有所提高，很讽刺的是，要对每个CPU花费60,000美元才能使用成本更低的、通用的硬件。
性能影响：Scale Abilities 的James Morle在他的论文Unbreakable [MORL02]中对一个RAC系统的运行进行了概括性的研究，在这篇论文中，他记录了在同一硬件环境下，使应用程序在Oracle的非RAC系统下运行，并且在单点RAC系统下执行同样的操作，通过比较发现，在完全相同的硬件条件下，同样的工作负荷在RAC系统中运行的消耗要增加18%，Oracle公司一位专家在一次幽默的但是公开的讨论中解释说，RAC系统就像一个放大器 [ASKTOM04]。他的意思是说，RAC系统产生了一个不好的应用，但是它同样也可以产生一个更好的应用。Tom继续发言道：
我曾经听开发者们说过“如果共享池出现问题是因为我们没有绑定，那么我们将选择使用RAC——这样我们将会拥有两个共享池，问题就解决了。” Bzzzt—你有两个保持一致的共享池，这需要依靠慎重的、复杂的分析——如果在一个单点出现了问题，那么就会导致一个多点的错误。
Morle 也作了类似的报告[MORL02]，在报告中指出“应当非常关注集群的配置、调优和运行。”
很多应用程序可以不经过任何修改就能在RAC上运行，但是大多数的则需要对应用程序进行投资和调优来实现合理的性能，这不是RAC的真正问题，而只不过是集群的普通现象：不管数据库管理系统是如何运作的，要使得应用程序在集群中运行良好，都非常需要进行应用程序的开发投资。众所周知，这是与目前市场上的很多产品相冲突的，但这却很显然是与通过进行多集群部署得到的结果相吻合的。
常规硬件：RAC依赖于共享磁盘的支持，使用共享多重存取启动的计算机系统接口（SCSI）来运行在技术上是可行的，但是通常所说的“基于Linux的Oracle RAC最佳实践” [ORCL03]，事实上是可以运行RAC的。
. . .与双向端口共享SCSI驱动器和10MB/S的以太网，理解运行RAC功能所需的最少的需求是非常有意义的，但是在实际运行中是不太有用的。
RAC需要特定的存储系统软件，而且这可能会带来额外的开支，如图4所示，所有的硬件成本在整个系统的总成本中约占12%的比重，仅仅看硬件成本，磁盘组件占有很大的比重，而且在硬件成本中磁盘组件正呈现出增长的趋势，国际数据公司IDC的报告中指出，大型数据库开发的硬件成本的75%是用于磁盘子系统的，在Terraserver 中Jim Gray的结论与此类似，Terraserver的基础硬件成本投入中78%是用于存储系统的[GRAY04]。
对这些结论进行总结可以得出，在大型系统部署中比重以磁盘形式存在的硬件开支大约占75%，而
系统硬件（非磁盘形式的硬件部分）存在的系统硬件的支出仅占25%，从图4中可以看出，硬件支出大约占整个系统成本的12%，因此，在整个系统成本中，以磁盘形式存在的硬件支出约占9%，而以非磁盘形式存在的硬件支出约占3%，这些数据并非是不可见的，但是在系统决策时他们并没有出现很多而成为首要驱动，在使用RAC时他们必须承担其它的成本和约束限制。
在考虑这些数据时，有两个因素是很明确的：1）RAC侧重于使用通用硬件，这仅仅是全部成本的3%；2）在前面章节中所讲到的由于使用RAC所带来的额外的软件成本以及额外的管理成本将在下面的章节中进行更深入的研究。
管理成本和复杂性：随着计算机系统解决方案的增加，运行和管理成本直线上升，这也就是为什么在需求允许的情况下，操作人员在较少的系统中花费的工作负荷在不断增加。只有很少的扩展系统价格便宜，然而，在提供解决方案时要承担更多系统的额外运作成本，这些附加的工作负荷使得通用系统的成本优势不再明显，这一观点也进一步说明了前面的结论：管理成本占据最大部分的系统成本（约为58%），系统成本（非磁盘硬件）占系统成本得很小部分（约为3%）。
如果可以使用通用硬件，那就应该使用它，然而，在一个特定应用程序部署中，所有的成本都应该被明确以保证他们是紧耦合、多节点配置是改善成本的重要因素。作者曾见过有些工作负荷可以在一个单点系统中可以运行得更好，也见过有些工作负荷在集群中运行是更好的选择，正确的选择是要根据特定的应用程序来确定，然而，也必须要考虑到管理复杂性的其他情况，首先，到目前为止最为重要的，70%的中断是由管理或运行错误所导致的，很明显，良好的管理是非常重要的因素，但珍重关键的因素仍然是系统的复杂性，系统复杂性和管理错误所带来的风险之间的关系是近似线性的，系统复杂性是中断的主要原因。
系统设计者，不管他们是数据库管理系统的工程开发者还是应用程序构架师，都应该对系统开发的高扩展性负责，随着他们经验的增多，也越来越担心系统的复杂性，复杂性使得系统容易瘫痪并且是难以理解的，难以配置和难以维护的，实际上，当与高级系统设计者交流时作者想要要找的关键技能是对于谦虚和担心的有机结合，作者最感兴趣的是与有足够能力设计和运行最为复杂的系统的工程师合作，然而只要有可能，他们都努力工作来避免问题的发生，复杂性，只要能被避免，就应该避免。
调试一个紧耦合的、多系统的数据库管理系统是非常困难的，当出现问题时，往往要一直追朔到系统开发者才能找到问题的解决方案，这往往需要好几个星期的时间，一个具有10年Oracle工作经验的员工通过一个详细的分析，很简单的说明了以上问题：
在我的一生中，我曾经历过很多的集群在不知原因的情况下发生停止，当这种现象发生时，有可能使得操作系统或者集群软件产生一个记录文件/日至文件。
这些问件（通常以GB为单位）被打包给供应商，在数月之后他们会返回报告，不能查明整个集群停止或瘫痪的真正原因，但是这种现象可能会很少见，也可能会很常见。
这是经常发生的事，我真的没有真正看见过任何一个供应商可以对一个停止运行的集群或者是一个瘫痪的集群给出准确地判断和解释。
对一个复杂系统进行判断是很困难的，也是很浪费时间的，Mr. Norgaard继续说：
一种有效的方法是：如果你使用一个独立的Unix box，那么在一年之内，它通常保持99.9%的有效性（有人认为是99.5%，有人认为是99.9%），他仍然正常的运行，使用Oracle的系统也是如此，如果使用的是一个双节点的Unix集群，运行一年之后的有效性将会降低至98%。
是的，的确很惊奇，两个主要的原因是，在集群和RAC中增加的复杂性（特殊的代码层，特殊的硬件等）将会导致许多额外的停止，这将会延长导入集群、启动RAC，以及运行一些其它的管理任务的时间，
基于集群的数据库管理系统是复杂的软件系统，因此，在安装、配置、升级和调试时要更加细心，Orbitz RAC配置的失败就是一个在有故障的前提下进行调试的例子[EWK04]，并且导致了非常严重的系统中断。尽管导致中断的真实原因还没有被完全明确（这通常也是导致集群错误的原因），而重新使用Oracle的单点系统则可以完全解决这个问题，同时会产生这样的疑问：应用程序是否需要将RAC作为首选方案。在这个例子中，在后续的报道中没有产生主要错误，有点讽刺意味的是，似乎单点系统要比多点系统更为有用，很明显，其实并非如此。然而，这样的现象却一再的重复出现，复杂的系统很难得到发展。
所有的主流数据库管理系统都是有缺陷的，并且都会偶尔出现问题，因此冗余是很重要的，必须解决单节点的错误，并且最为重要的是，要不断地消除系统中的复杂性，如果出现难以消除的故障，错误将会迅速增加并且难以控制，在联机数据处理的时代，要想将一周的错误进行恢复几乎是不可能的。
[
| 诚征版主 | 版主堂 | 意见建议 | 大史记 | 论坛地图