选择具有高可用性的数据库：SQL Server 与 Oracle 对比分析

Michael Otey 和 Denielle Otey

摘要

Microsoft® SQL Server™ 2005 已经证明能满足客户的高可用性要求，而且提供此功能的成本要比 Oracle 10g 低很多。SQL Server 2005 在 SQL Server 2005 Standard Edition 和 SQL Server 2005 Enterprise Edition 中均提供了所有主要的高可用性功能，如 Microsoft Clustering Services 支持、Database Mirroring、数据库快照、日志传送和复制等，无需额外的资金投入。

Oracle 的 Real Application Clusters (RAC) 可以在高可用性配置中实现。不过，RAC 仅在 Oracle 10g Standard Edition 中提供，而在 Oracle 10g Enterprise Edition 中并不提供此功能。RAC 可以实现自动故障转移，但并不能提供 SQL Server 2005 Database Mirroring 所提供的小于 5 秒的故障转移速度。同样，Oracle 10g 的 Flashback 和 Data Guard 功能在 Oracle 10g Standard Edition 中不可用；为了获得这些功能，客户必须购买价格更高的 Oracle 10g Enterprise Edition。

SQL Server 2005 Enterprise Edition 还通过对多个服务器间的数据进行分区提供了提高可用性的能力。在 Oracle 10g 中增加此功能需要购买 Oracle Partitioning 产品。高可用性并不需要同样的高成本，SQL Server 2005 以比 Oracle 10g 低很多的价格满足客户的高可用性要求。

简介

确保企业中的计算资源的持续可用性是当今各个数据库管理员 (DBA) 的主要目标之一。如果用户和客户不能访问其开展工作所依赖的资源，世界上的所有计算资源和安全/防护应用程序所起的作用就微乎其微了。如果支持应用程序的数据库和服务器不可用，不仅会给组织带来金钱方面的损失，也会有损其信誉和商誉。

根据组织的性质和应用程序的类型不同，服务停机带来的损失可能会非常大。Forrester Research 所做的一个研究表明，在线经纪公司 eTrade 的一次 1 个小时的停机事故造成了 800 万美元的损失。与此类似，DELL 公司一次 10 小时停机事故造成了 8,300 万美元的损失，而英特尔一次 33 小时的停机事故造成了 27,500 万美元的损失。这些数字仅代表了收入的损失，并不包括其他相对不太明显的损失，如客户满意度或公司信誉方面的影响。

对于任务关键型应用程序，支持这些应用程序的数据库和服务器需要在用户需要这些应用程序时保持可用状态。现在，在企业中达到必要的可用性水平不再只是由传统的备份和还原技术提供的简单数据保护。今天的企业需要比以往任何时候都要大的可用性窗口，很多组织需要每天 24 小时、每周 7 天、一年 365 天的可用性。创建高可用性环境以实现业务持续性是一项复杂的工作，因为这会涉及到企业的很多方面。它还受到很多因素的影响，包括技术挑战和功能以及人为因素和组织因素的影响，远远超出了纯技术的范围，而延伸到了运营当中。在此白皮书中，我们将就 SQL Server 2005 和 Oracle 10g 提供的高可用性技术进行比较。客户可以使用此信息帮助评估这两个系统间的功能差异，从而选择最适合其需求的数据库。

高可用性的定义与5个9

可用性可以定义为系统或资源可以使用的时间。高可用性的定义则通常根据其绝对可用性的百分比进行测定，100% 表示资源随时可用，没有停机时间。不过，要实现 100% 可用性非常困难。非常高的可用性的最接近测定为 5 个 9，即 99.999%。可用性可以用数学表达式定义为：

可用性百分比 = ((总时间 – 停机时间的总和)/总时间)

系统可用性的百分比等于总时间减去系统不可用的总时间，然后除以总时间。每年的可用正常工作时间为 8,760 个小时（每天 24 个小时乘以每年 365 天）。总共的正常工作时间为 8,760 个小时，则表示当年的可用正常工作时间为 100%。不过，由于需要定期进行系统维护，而且也可能出现其他计划外的事件，通常不可能提供 8,760 个小时的正常工作时间。例如，系统经常每个月会有一天（8 小时）的计划停机时间，以进行每月的维护工作，以便 IT 人员进行硬件升级、应用系统修补程序或进行其他例行维护活动。在这种情况下，系统的可用性百分比如以下表达式中所示：

         98.9 = ((8760 – (8 x 12)/8760)

也就是说，每月停机一天的话，总可用性就为 98.9%。下面将说明如何计算系统可用性中的 9 的数量。9 的数量按照以下方式计算：99.9% 为三个 9，99.99% 为四个 9，依此类推。

正如所您所看到的，每个月停机一天，总体可用性为 98.9%，仅实现了 5 个 9 中的一个 9。每个月停机一天并不多，对于很多组织，这样的可用性就足以满足其需求了。不过，在很多情况下，这个百分比仍然不够。下表中所示为与每个持续增加的可用性水平相关的停机时间量。

9 的个数	可用性百分比	每年的停机时间
1	98.9%	3 天 18 小时 20 分钟
2	99.0%	3 天 15 小时 36 分钟
3	99.9%	8 小时 46 分钟
4	99.99%	53分钟
5	99.999%	5分钟

每年停机时间为每天 15 分钟或一年 92 小时（3 天 18 小时 20 分钟）就可以实现具有一个 9 的可用性。不过，随着 9 的个数的增加，要求也就越严格。最高的可用性（可用性为 5 个 9）中每年的停机时间必须小于每年 0.09 小时（约 5 分钟）。使用目前的数据库平台可以实现更高水平的停机时间，但不能仅靠使用技术而实现。这些高水平可用性仅能通过利用人员、流程和技术因素的组合才能实现。

务必注意，必须从对用户而言的系统可用性角度出发进行停机时间跟踪。某些供应商根据服务器可用性声称其可用性如何如何，但从服务器级别跟踪可用性并不一定考虑了对用户的真正可用性。如果服务器在正常工作，而其他因素导致最终用户无法访问系统，那么也应该将系统视为不可用。

影响可用性的因素

对于全天候可用性的要求受到很多因素的影响。可能会成为创建高可用性操作环境的障碍的主要因素包括：

            人员

            流程

            技术

信息的持续可用性不仅仅涉及到技术方面，还与公司员工（内部人员和位于远程位置的人员）有关。雇佣最好的人员以平稳地运行业务操作，这对于组织保持最大正常运行时间十分关键。将这一点与实现高效操作过程的流程和良好的策略相结合，可以确保您的人员最好地发挥其专业技能。

技术在创建高可用性环境过程中扮演的角色具有多重性。从系统角度而言，技术解决方案将处理例行维护和出现的各种类型的故障（如站点故障、服务器故障和数据库破坏）。从业务的角度而言，技术还会影响业务环境中的人员、策略和流程。例如，公司选择的硬件和软件解决方案将会同时影响人员所需的技能技巧和公司需要建立以管理该技术的流程。这些技能技巧的保持是非常重要的因素，可以影响系统可用性。持续的培训至关重要，这样可以使操作人员保持先进的技能水平，从而确保其能正确高效地执行例行操作和紧急任务。

计划停机时间

在执行例行系统维护的同时提供数据库可用性，以及恢复由于应用程序故障或其他事件而丢失的数据，在这两方面 SQL Server 2005 和 Oracle 10g 均提供了一组独特的可用性功能。下面一节将讨论不同数据库功能，这些功能设计用于促进操作持续性和提供数据保护，以防止受到目前的企业数据库平台中的数据损坏的影响。

 

针对服务器维护的数据库高可用性解决方案

目前的服务器硬件非常可靠，所有主要硬件供应商均为主要系统组件提供了很多冗余功能，不过，硬件和操作系统维护与升级始终是不可避免的。

硬件升级与维护

Microsoft Windows Server™ 2003 支持热切换 RAM 和 RAID 驱动器，可满足最常见的硬件升级场景：为系统增加内存和磁盘容量的需要。使用支持这些功能的硬件，可以在系统运行时动态地添加 RAM 和 RAID 驱动器，而不会对可用性造成影响。即使这样，仍然会需要进行例行硬件维护。例如，系统日志中某个时间指示某个系统组件出现了问题，或者需要应用要求重新启动系统的操作系统和应用程序级的服务包（service pack）。在单服务器环境中，此类事件会带来计划系统停机时间。计划停机对操作的持续性影响比非计划停机要小，因为可以计划在影响最小的时候进行。

不过，即使是计划的停机时间，对那些要求最大可用性水平的组织也代价巨大。为了满足例行维护和所需的停机时间的需要，目前所有可用的企业数据库平台都支持多服务器集群和其他可用性功能，以使 IT 人员能够进行轮换升级。Microsoft Windows Clustering Services 和 Oracle 的 RAC 都支持进行轮换升级，允许您手动将集群中的一台或一个系统组从网络中断开，以执行例行的维护工作。例如，如果有个要求具有全天候可用性的应用程序，则可以使用某个多服务器集群技术或其他可用技术在数据库平台上实现该技术。然后，当需要执行维护工作时，启动一个手动故障转移，以将需要维护的节点的工作负载关闭。然后就可以在该节点脱机时对其进行维修、升级或修补。其余的集群节点或后备服务器将在所维护的节点不可用时承担其工作负载。因此，不会有应用程序可用性损失。该过程结束后，可以将此节点还原到集群中，恢复正常操作。如果需要，可以对其他集群节点重复此过程。执行轮换升级，就消除了与例行维护关联的计划停机时间。

数据库维护

数据库维护是高效且高可用的数据不可或缺的部分。需要对索引进行维护、需要执行优化、需要执行备份，如此等等。良好的操作计划会将一定的数据库维护时间考虑到其中。不过，数据库维护时间并不一定与数据库停机时间相等。可以使用若干工具帮助 DBA 消除性能和停机时间的负面影响，并提高例行数据库维护任务期间的正常运行时间。

为了便于联机服务器和数据库维护，SQL Server 2005 允许对大部分