摘要 

    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 提供的高可用性技术进行比较。客户可以使用此信息帮助评估这两个系统间的功能差异，从而选择最适合其需求的数据库。

高可用性的定义与五个“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。每个月停机一天并不多，对于很多组织，这样的可用性就足以满足其需求了。不过，在很多情况下，这个百分比仍然不够。下表中所示为与每个持续增加的可用性水平相关的停机时间量。

    每年停机时间为每天 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 允许对大部分 SQL Server 系统属性进行动态配置。下表列出了可以联机更改的服务器属性。 

    为了便于联机服务器和数据库维护，SQL Server 2005 允许对大部分 SQL Server 系统属性进行动态配置。下表列出了可以联机更改的服务器属性。

    SQL Server 2005 独有索引碎片整理语句，允许对表和视图上的聚集索引和非聚集索引进行联机碎片整理。DBCC INDEXDEFRAG 语句并不会长时间占用锁定，因此不会阻塞任何正在运行的查询和更新。SQL Server 2005 和 Oracle 10g 都包含联机索引操作，可提高数据可用性、响应时间、磁盘空间利用率和数据库性能。可以对索引进行碎片整理、添加或重新生成，而同时能够继续对基础表数据进行查询或更新。 

    在每种数据库解决方案中均具有综合数据库优化工具，能提高性能（即使用户负载和查询会随时间而发生变化）。这些工具给 DBA 提出建议，以通过各种方式最佳地利用配置设置，例如监视和分析查询语句的操作，以及监视磁盘 I/O 子系统的性能。

计划外停机时间
        

    每个不同的企业级数据库平台都使用其自己的方法和技术的不同组合，提供了类似级别的高可用性。正如您可以预料的，不同的高可用性解决方案提供不同程度的服务器故障和数据破坏保护，而不同的方法会带来不同的成本开销，其中既有购买解决方案所需的技术开销，也包括解决方案实现和操作所必需的人员方面支出的成本。

针对数据库恢复的数据库高可用性解决方案 

    创建高可用性环境的能力可能会受到纠正应用程序错误和数据破坏的需求的影响。保持数据对用户和员工可用的一个重要方面就是确保“正确”的数据可用。如果数据库中的数据被破坏（例如，用户错误，如使用不正确的信息更新数据库或无意删除了信息），则必须有相应的过程能够快速识别并将数据还原到其原始状态。 

•     SQL Server 2005——备份与事务时间点恢复 
          

    高可用性的关键组成部分之一就是良好的备份与恢复计划。SQL Server 2005 不同的恢复模型在记录开销和数据的完全恢复能力这两方面实现了平衡。SQL Server 2005 提供三种恢复模型：简单、完全、批量记录。 

    简单恢复模型。此模型具有最低的记录开销，但不能恢复任何最后一次备份前的数据。使用简单恢复模型，将丢失从上次备份以来的所有数据修改。 

    完全恢复模型。该模型与简单恢复模型正好相反，将记录所有的数据更改。使用完全恢复模型，所有数据都可以恢复到发生故障时的状态。默认情况下，SQL Server 使用完全恢复模型。
批量记录恢复模型。此模型位于两个极端之间，将记录处理批量操作（如批量复制和 SELECT INTO）之外的全部事务。在进行恢复时，这些操作会丢失。而批量记录模型可以恢复到最后的数据库或记录备份时的状态。 

    选择了恢复模型后，组织需要确定采用何种备份计划。可以备份到磁盘、磁带或其他媒体。执行磁盘备份是用于备份和还原数据最快的机制。为了防止受驱动器故障的影响，应始终将备份放置到独立的驱动器上，最好是与数据库数据独立的控制器上。SQL Server 支持三种基本数据库备份类型：完全备份、差异备份和日志备份。 

    完全数据库备份。此类备份是数据库的完全副本。这将提供一个已知点，从此处开始还原过程。
差异备份。此备份仅复制最后一次完全数据库备份之后修改过的数据库页。频繁进行差异备份，可以尽可能减少将数据库恢复到最近事务状态时所需的事务日志数量。 

    日志备份。此备份仅复制事务日志。事务日志备份可以在还原了最后的差异备份之后应用。 

    事务时间点恢复允许将整个数据库恢复到任何给定的时间点时的状态。SQL Server 2005 事务日志是一系列记录，包含自最后一次备份事务日志以来在数据库中所做的全部更改。使用事务日志备份，可以将 SQL Server 数据库恢复到任何特定的时间点。例如，如果 04:00 时出现了应用程序错误，导致一个数据库中数据被破坏，则可以使用 SQL Server 2005 事务日志备份将数据库恢复到 03:59（发生数据破坏前）的状态。 

    当还原了 SQL Server 事务日志时，该日志中包含的所有事务都会被前滚。除了用于更新数据库的数据外，每个事务日志记录都包含一个时间戳，用以指明事务发生的时间。达到事务日志尾部或在还原期间遇到了指定的时间时，数据库将处于最后事务时的精确状态，使您能够迅速从数据破坏错误恢复。 

    除了这些标准的备份选项之外，SQL Server 2005 还提供非常准确的页级别还原功能，可以还原一个页或一组页。

  高可用性的关键组成部分之一就是良好的备份与恢复计划。SQL Server 2005 不同的恢复模型在记录开销和数据的完全恢复能力这两方面实现了平衡。SQL Server 2005 提供三种恢复模型：简单、完全、批量记录。   简单恢复模型。此模型具有最低的记录开销，但不能恢复任何最后一次备份前的数据。使用简单恢复模型，将丢失从上次备份以来的所有数据修改。   完全恢复模型。该模型与简单恢复模型正好相反，将记录所有的数据更改。使用完全恢复模型，所有数据都可以恢复到发生故障时的状态。默认情况下，SQL Server 使用完全恢复模型。 批量记录恢复模型。此模型位于两个极端之间，将记录处理批量操作（如批量复制和 SELECT INTO）之外的全部事务。在进行恢复时，这些操作会丢失。而批量记录模型可以恢复到最后的数据库或记录备份时的状态。   选择了恢复模型后，组织需要确定采用何种备份计划。可以备份到磁盘、磁带或其他媒体。执行磁盘备份是用于备份和还原数据最快的机制。为了防止受驱动器故障的影响，应始终将备份放置到独立的驱动器上，最好是与数据库数据独立的控制器上。SQL Server 支持三种基本数据库备份类型：完全备份、差异备份和日志备份。   完全数据库备份。此类备份是数据库的完全副本。这将提供一个已知点，从此处开始还原过程。 差异备份。此备份仅复制最后一次完全数据库备份之后修改过的数据库页。频繁进行差异备份，可以尽可能减少将数据库恢复到最近事务状态时所需的事务日志数量。   日志备份。此备份仅复制事务日志。事务日志备份可以在还原了最后的差异备份之后应用。   事务时间点恢复允许将整个数据库恢复到任何给定的时间点时的状态。SQL Server 2005 事务日志是一系列记录，包含自最后一次备份事务日志以来在数据库中所做的全部更改。使用事务日志备份，可以将 SQL Server 数据库恢复到任何特定的时间点。例如，如果 04:00 时出现了应用程序错误，导致一个数据库中数据被破坏，则可以使用 SQL Server 2005 事务日志备份将数据库恢复到 03:59（发生数据破坏前）的状态。   当还原了 SQL Server 事务日志时，该日志中包含的所有事务都会被前滚。除了用于更新数据库的数据外，每个事务日志记录都包含一个时间戳，用以指明事务发生的时间。达到事务日志尾部或在还原期间遇到了指定的时间时，数据库将处于最后事务时的精确状态，使您能够迅速从数据破坏错误恢复。   除了这些标准的备份选项之外，SQL Server 2005 还提供非常准确的页级别还原功能，可以还原一个页或一组页。

• SQL Server 2005——有延迟的日志传送

    可以将日志传送配置为允许“时间窗”，以方便地从出现数据破坏的情况恢复。日志传送是一种数据库可用性技术，该技术将日志从数据库服务器发送到一个或多个备份服务器上。如果主服务器或数据库出现故障，就可以随后将这些事务应用到备份服务器上。主服务器的事务日志备份在发送到从服务器之前可能会有指定量的延迟。例如，不采用立即将事务日志发送到从服务器的方式，而可以将日志传送配置为每五分钟向从服务器写入一次。如果在这五分钟期间出现数据错误，可以使用从服务器上的事务日志将数据恢复到五分钟前的状态。

• SQL Server 2005——文件组还原

    时间点恢复和日志传送恢复功能均在 SQL Server 2005 中可用。事务日志备份可以应用于将数据恢复到特定的时间点。 

    SQL Server 2005 的新功能允许方便地还原被破坏的对象。SQL Server 2005 中的细粒度还原功能允许对数据库中选择的文件组进行还原。在 SQL Server 2000 中，可用性单位是数据库。在数据库可用之前，不能接触到数据库的任何组件。在 SQL Server 2005 中，可用性单位则为文件组。这样就提高了可用性，因为只有当前正在还原的数据不可用；仍然可以访问包含在其他文件组中的其他数据库数据。SQL Server 2005 允许一次还原一个文件组，或在主文件组就绪时，甚至可以还原一个页或一组页。

• SQL Server 2005——快速恢复
          

    与 Oracle 的 FastStart Fault Recovery 一样，SQL Server 2005 的快速恢复功能允许用户在事务日志前滚后立即重新连接到正在恢复的数据库，从而提供了数据库可用性。SQL Server 的早期版本要求用户必须等到回滚了未完成的事务之后，即使用户不需要访问所涉及的数据库区域也是如此。

• SQL Server 2005——数据库快照

    SQL Server 2005 包含数据库快照，允许快速方便地还原损坏的数据。数据库快照提供了生成数据库只读视图的工具，而不会有创建整个数据库及其相关存储区的副本的系统开销。图 1 所示为数据库快照的概览。

图 1：数据库快照

    数据库快照与数据库副本不同。数据库快照仅占用包含数据库信息更改所需的空间。随着对数据库进行更改，快照将从数据库接收自己的原始页副本。要从不恰当的数据库更改恢复，可以将快照中的原始页重新应用到数据库。

•  Oracle 10g—Recovery Manager (RMAN)

    Oracle 10g 包括了一款称为 Recovery Manager (RMAN) 的工具，用于管理创建备份和进行还原的流程。RMAN 工具由 RMAN 可执行函数、要备份的目标数据库和可选恢复目录组成。如果未指定恢复目录，备份详细信息将存储在目标数据中的一个“控制文件”中。Recovery Manager 可以用于恢复被破坏的数据或不能接受的数据更改。控制文件中包含关于数据文件和从数据文件创建到恢复时的存档日志文件的信息。 

    标准 RMAN 备份包含组成特定数据文件的数据块的备份单元。数据块以特殊的压缩格式存储。需要还原数据文件时，需要从备份单元中的块重新创建整个数据文件。现在使用 Oracle 10g，可以在数据库级、表空间级或数据文件级创建映像副本。数据文件的映像副本的还原速度较快，因为数据文件的实际结构已经存在了。一项称为 Incrementally Updated Backups 的 RMAN 功能允许将增量数据库更改应用到数据文件映像副本备份，以将其前滚到特定的时间点。通过不时地使用增量备份来更新数据文件映像副本，可以将数据文件映像副本前移到更为接近其最近状态的位置。这就减少了数据恢复时间。 

    Change Tracking 是 Oracle 10g 中的一个可选功能，可以提高增量备份的性能。在 Oracle 以前的版本中，需要对数据文件中的所有块进行扫描，以发现从最后一次增量备份以来的更改。启用了 Change Tracking 后，只需对第一个增量备份进行全面扫描，因为所有更改过的块的 ID 都被写入了 Change Tracking 文件。后续的增量备份将扫描 Change Tracking 文件，以确定是否需要备份任何更改过的块。

•  Oracle 10g—Flashback

    Oracle 10g 的 Flashback 提供了与 SQL Server 2005 数据库快照非常相似的功能。Flashback 数据库允许使用 Flash Recovery Area 代替标准备份媒体，将数据库恢复到特定的时间点。Flashback 功能最好用于恢复被破坏的简单表和行数据，与最适合用于恢复较大的数据块的 RMAN 功能相对。要使用此功能，DBA 必须配置一个 Flash Recovery Area，使其包括 Flashback 数据库日志、Redo 存档日志和 RMAN 备份。块更改的副本写入到 Flashback 日志中，可以在出现用户或应用程序错误事件时还原到数据。Flashback 包含特定的 SQL 语句，用于对 Flash Recovery Area 进行查询和从中恢复数据，因此，为了访问对象，需要给用户授予适当的特权。 

    注意：Flashback 技术的一个重要局限在于其并不具有对引用完整性的内置支持。如果使用 Flashback 还原具有依赖项的表，而这些依赖对象已经发生更改，则可能会在数据库中造成不一致现象。 

    Flashback Table、Database 和 Transaction Query 功能仅在 Oracle Enterprise Edition 中提供。

附录A — 数据库高可用性的障碍

    •人员障碍 

    任何环境下引起停机的最大原因之一是人为错误。快速从人为错误中恢复的能力在数据库可用性要求中处于首位。David Patterson 的研究论文 A Simple Way to Estimate Downtime 表明，53% 的停机时间是人为错误的结果。其他研究（如《Disaster Recovery Journal》中发表的数据）也表明，组织中发生数据丢失的人为错误占到了 36% 之多。显然，克服人员障碍是达到更高可用性的最重要步骤之一。操作员错误可在数分钟内破坏数据库，而恢复或还原数据则需要数个小时或数天。这些恢复时间的代价巨大，不过却是可以避免的。 

    人会犯错误，但还是可以主动采取措施来尽可能减少停机时间，以从这些错误中恢复。人为错误主要由两个途径引入：用户错误和操作员错误。如果给予了相关权限，用户可能会因为疏忽而删除重要数据或使用不正确信息错误更新数据库，最终对公司信息造成破坏。培训、创建足够的应用程序文档和建立相关的规程等等是防止用户错误的最佳预防措施。减小由于用户错误引起的可能停机时间的最重要步骤之一是严格限制每个用户对数据和服务的访问权限，仅提供其所需的权限。 

    操作员或应用程序开发人员的错误也会对数据库和应用程序可用性产生巨大的影响。例如，错误地从数据库删除一个表，或者编写引起数据库写入不正确数据的代码都会影响应用程序的可用性。防止这些类型错误的一个好方法是加强职员对持续信息可用性相关的复杂性和职责的意识，特别是上层管理职员。这些将增加培训预算，并且需要花费时间和投入资源来开发操作指南，还要开发并实施灾难恢复计划。 

    维护数据库的完整性对数据库管理员来说是一个日益困难的任务。在很多情况下，都需要 DBA 参与整个开发过程的所有阶段。这可能包括结构和数据库设计、应用程序开发、数据库管理，以及灾难和恢复方案的实施。DBA 需要经过良好培训，能够对问题进行故障诊断，并且具有必需的工具来有效地实行数据恢复计划。 


    •流程障碍 

    另一个深刻影响创建高可用环境能力的因素是内部流程。制定合适的流程有助于消除不必要的停机时间，在服务中断时可以快速恢复。 

    高可用性最重要的障碍之一是缺少文档操作程序。组织应制定用于执行例行操作任务的书面程序，并形成关于从不同类型灾难恢复所需步骤的文档。这些操作程序文档通常称为“运行手册”。缺少足够的文档会导致服务中断的不精确性恢复，并且增加了漏掉所需步骤的可能性，因此也增加了实行整个恢复所需的总时间。同样，缺少足够的例行操作程序文档也会增加操作错误的可能性，特别是在由于疾病或其他诸如职责重新分配引起人员变更的情形下更是如此。缺少操作程序也会影响问题的诊断。没有标准化的程序，不同的人执行各种任务会有所差别，使正确地确定处理给定情形的步骤顺序变得困难。有效的运行手册将使新手 DBA 可以像有经验的团队成员一样有效地执行例行操作。 

    问题解决方案文档不足是缺少适当程序而影响可用性的另一个方面。建立标准的问题解决方案程序有助于操作人员识别通常的问题场景，并使他们能在各种情况下更快地进行诊断和解决问题。缺少标准化事件管理程序将会在每次出现常见问题时需要帮助台和操作人员进行重复的工作。这样就增加了从本应该已知的情形中恢复所花费的时间，也增加了错误诊断问题的可能性。最终结果是很可能增加停机时间，甚至会导致其他问题。 

    更改管理程序不足也可以成为高可用性的重要阻碍。更改管理程序使组织可以跟踪在应用程序生存期中进行的应用程序更改和数据库架构更改。除了提供跟踪源代码和数据库架构更改的标准机制外，创建足够的更改管理程序使组织必须建立质量保证环境，更改在部署到生产环境中之前，可以在质量保证 (QA) 设置中进行测试。如果没有更改管理程序，则可能导致整体恢复错误，使数据库架构和应用程序更新可能丢失，或者被没有合并更多当前更新的后续更改所取代。类似地，缺少 QA 环境可能导致应用程序和数据库部署错误，而这会使应用程序不可用。 

    其他两个高可用性的流程障碍是缺少标准化硬件和软件配置。只要可能，就要对数据中心所使用的硬件和软件配置进行标准化。标准化的硬件组件使硬件故障下的系统维修和/或替换更容易。同样，标准化的软件配置使例行操作更容易，并且减小了操作员错误的可能性。 

    例如在可能的情况下，所有服务器应使用标准命名方案，并应具有标准化的驱动器盘符、映射目录和共享名。另外，所有数据库服务器应使用相同的操作系统、数据库和中间件数据访问层的服务包级别运行。 

    缺少标准硬件和软件配置将会增加错误可能性，从而引起故障解决时间的延长和引入操作与恢复错误的增多。 

    创建高可用性环境过程中的最后一个流程障碍就是不正确的或过时的制度知识。为所有 IT 人员建立定期的培训计划有助于保证组织的技术技能保持先进，并且使组织更有可能采用最有效的技术和工具。 

    •技术障碍 

    在技术领域中，达到可用性的最高水平需要解决几个问题。服务器单元的任何组件都可能发性硬件故障。应用程序错误也会影响数据库访问。需要准备好恰当的数据库恢复机制来还原信息，否则数据将会被破坏。有计划的硬件升级和数据库维护也是可能降低系统可用性的因素。利用可用数据库技术可以减小或消除与计划维护相关的停机时间。最后，基础结构故障或站点灾难对数据库可用性也有重大的影响。 

    •基础结构故障 

    现在的数据库应用程序依赖于网络连接，这些网络连接用于客户端计算机，也供将应用程序服务器连接到数据库，在很多情况下是一同连接到多个数据库服务器。网络基础结构故障可以对任一或所有的这些不同数据库层的可用性造成影响，而不管实现的是什么数据库平台。网络基础结构故障可以由多种不同网络组件引起，包括域名系统 (DNS) 服务器、应用程序故障和设备中（如交换机、集线器、路由器和网卡）的网络硬件故障。 

    处理硬件故障是这些问题的最直接方法。创建多个资源访问路径是解决网络硬件故障潜在问题的关键。在数据库服务器级别，通过在数据库服务器和应用程序服务器中放置冗余的网卡，可以保证即使一张网卡出现故障时服务器连接继续可用，从而避免网络基础结构故障带来的影响。因为一张网卡出故障后网络将继续可用，所以需要定期监视系统事件日志来检查硬件故障事件消息并进行维修。 

    在数据中心级别，可以通过设置多个路由器和交换机，创建多条数据库服务器资源访问路径，从而防止网络组件故障或网段故障引起的网络中断所造成的影响。如果到数据库服务器的所有网络连接都通过单个交换机路由，而该交换机出现故障，即使数据库服务器和它的应用程序运行没有问题，数据库也将不可用。实现诸如交换机等网络设备的冗余，并且确保每个设备具有自己的 UPS，可有助于建立到数据库的多个网络路由。这有助于保证网络硬件故障不会对系统可用性造成负面影响。 

    设置一个网络负载平衡 (NLB) 集群可以保证网络基础结构不被应用程序故障或Web 服务器故障引起的基础结构故障所影响。NLB 集群提供了可伸缩性，并且改善了可用性。NLB 是通常由 Web 服务器使用的 Windows 服务，用于创建冗余的和可升级的数据库系统前端。Windows NLB 是一项内置 Windows 服务，支持对那些使用虚拟服务器名称和 IP 地址访问的物理服务器进行组合。客户端连接到 NLB 虚拟服务器，该服务器根据一组预先设置的条件（如物理服务器的当前资源利用率）负责对到不同服务器的连接进行路由。NLB 将传入连接分散到多个物理服务器上，从而增加了可伸缩性。NLB 对请求进行路由时还能绕过属于 NLB 集群的一个或多个故障物理服务器，从而改善网络基础结构的可用性。 

    网络的域名服务 (DNS) 对数据库可用性具有重要的影响。为了访问其资源，网络化的客户端系统和应用程序服务器必须能够定位网络上的数据库服务器。网络的 DNS 服务器能够提供这些至关重要的网络功能。DNS 服务器的故障会阻止用户定位包含他们应用程序所需的数据库资源。改善 DNS 可用性的最佳方法是通过在自己的网络上实现多个 DNS 服务器。用这种方法，如果其中一个 DNS 服务器出现故障，网络名称的解析仍然可以由一个或多个从DNS 系统来提供。 

    需要多个域控制器用来保证网络用户具有网络身份验证服务。冗余域控制器使网络用户即使在一个或多个域名控制器不可用的情况下也能够继续进行网络的身份验证。 

    •站点灾难 

    最后一个（当然不是最次要的）高可用性障碍，是对会导致整个站点不可用的灾难进行防护。所有的主企业数据库平台中进行灾难保护的步骤都很相似。对站点故障的全面保护需要创建冗余的数据中心设备。冗余数据中心的建立可以保护组织免受由于火灾、地震或一些其他导致主数据中心不能操作的非预知事件引起的站点全面停机的影响。备份数据中心不需要成为主数据中心的镜像映像，它也不需要设计为处理主数据中心的处理要求。在很多情况下，主数据中心设计的容量可以适应将来增长。备份数据中心不需要该额外的容量，但它一定需要能够处理主数据中心当前的最大工作负荷。 

    当实现备份数据中心时，务必确保为主数据中心和备份数据中心配备多个 Internet 载体。这保证了服务的可用性，而不受那些影响了很大的地理区域的事件影响，比如电网损耗或导致其中一个 Internet 载体中断服务的事件。如果其中一个载体中断服务，则数据库服务仍然可以通过备用的载体进行访问。实现冗余的数据中心显然是昂贵的预防措施，但是对于很多组织来说，实现冗余数据中心和 Internet 载体所需的费用与长时的停机时间相比是很值得的。 

    很多解决服务器可用性障碍的企业数据库技术也可以保护组织免受站点故障的影响。例如，数据库复制功能和日志传送功能都可以用于镜像一个或多个地理位置上分散站点上的生产数据库。 

    克服站点灾难障碍的另一个工具是基于 IP 的存储区域网络 (SAN) 复制。基于 IP 的存储区域网络数据复制可以创建并维护镜像本地存储区域网络存储系统的远程存储区域网络磁盘存储系统，从而提供磁盘冗余性能。因为 IP 是数据传送，所以本地和远程存储区域网络可以在地理上远距离分散，并且本地事务可能通过 Internet 或专用的基于 IP 的网络设备传送到远程存储区域网络。如果主站点出现故障，则数据不会丢失，因为远程存储区域网络具有数据的镜像副本。

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

   
    毫无疑问，在高可用性环境中的主要技术考虑就是针对服务器故障提供保护。服务器故障可以定义为一个计划外事件，会导致用户无法访问服务器系统。一系列不同的因素都可能导致服务器故障。各种不同的硬件和软件原因都可能导致服务器故障，包括： 硬件故障（CPU、RAM、存储设备、I/O 或电源）、操作系统或设备驱动程序故障、数据库服务器故障。 

   
    针对硬件故障提供保护的第一步就是投资购置提供关键组件冗余的硬件平台。例如，目前主要硬件供应商提供的大部分服务器都提供高可用性功能，如冗余电源，内置不间断电源 (UPS) 以及可以热切换的 RAM 和 RAID 驱动器。 

   
    在软件方面，确保高可用性的最重要步骤就是使用最新的服务包使操作系统、设备驱动程序和应用程序软件保持为最新。这确保您的系统将具有最新的软件更新和安全更新。Microsoft 提供了大量处理系统更新问题的技术。System Management Server (SMS) 产品可提供企业级的软件更新和目录功能。对于中型企业，新的 Windows Server Update Services (WSUS) 可提供在组中分发 Microsoft Windows® 和 Microsoft Windows Server 更新的功能。而 Windows Update 可为小型企业提供系统更新。 

   
    保持最新的修补程序是非常重要的步骤，还需要具有适当的质量保证过程，以将软件更新部署到生产环境中之前在测试环境中严格对所有软件更新进行测试。 

   
    处理这些基本的系统必备是提高数据库和服务器可用性非常重要的步骤，不过这措施本身并不能确保带来高可用性。为了进一步提供针对服务器故障的保护和确保高数据库可用性，需要采用由各个竞争数据库平台支持的某项高可用性技术。这些技术设计用于帮助系统更好地应对系统故障，并能在出现服务器故障时更快地进行恢复。 

   
    充分利用集群技术和日志传送是创建高可用性数据库平台的重要技术手段。集群技术主要涉及到在这样一种环境中使用多台服务器，即一台或多台备份服务器可以无缝地接过出现故障的主服务器的工作负载。除了集群技术之外，目前的竞争企业数据库平台都支持大量的其他针对服务器故障提供保护的技术。其中包括日志传送和复制技术。本节将对每种备选技术进行分析，并讨论每个企业数据库产品是如何实现这些技术的。

•  SQL Server 2005 N 路集群

    由于利用了 Windows Server 2003 提供的增强集群支持，SQL Server 2005 在Windows Server 2003 Datacenter Edition 上支持多达 8 个节点的集群；在 Windows Server 2003 Enterprise Edition 和 Windows 2000 Datacenter Server 上支持 4 节点集群；在 Windows 2000 Advanced Server 上支持两节点集群。其安装过程和管理工具都支持集群。

    Microsoft Windows Clustering Services 是用于保护数据库平台不受服务器故障影响的一项重要技术。Windows Clustering Services 对所有企业数据库应用程序都可用，包括SQL Server、Oracle 和 DB2。Windows Server 操作系统版本不同，它们支持节点数的能力也不相同。下表说明了Windows 2000 Server 和 Windows Server 2003 不同版本的基本集群性能。

    Windows 2000 Server 和 Windows Server 2003 Standard Edition 不支持故障转移集群。Windows 2000 Advanced Server 支持两节点集群；Windows Datacenter Server 2000 和 Windows 2003 Enterprise Edition 支持 4 节点集群；Windows Server 2003 Datacenter Edition 支持多达 8 个节点的集群。所支持的节点数量取决于主机操作系统的功能。 

    对于 Windows Clustering，集群中的每个物理服务器称为“节点”。节点共同工作组成“集群”。集群中的所有节点都处于持续的通信状态。如果其中一个节点不可用，那么其他节点将自动承担其服务，并且开始向用户提供与故障节点相同的服务。这个过程称为“故障转移”。与可以提供无间断服务专业容错的第三方硬件解决方案不同，Windows 集群的故障转移过程的完成需要约20秒的短时间隔（取决于所使用的硬件）。另外，必须恢复故障转移节点上的数据库，从而保持事务一致性。该恢复时间的长短很大程度上取决于故障转移时正在进行的数据活动的水平和所使用的硬件类型。连接到故障节点的客户将被断开连接。当他们试图重新连接时，将可以访问备用节点上的集群资源。Windows Clustering 具有下列优势： 

    •自动故障转移。当检测到故障时，集群将自动从主节点切换到从节点。 

    •对客户透明。故障转移完成后，客户可以使用相同的虚拟名称和（或） IP 地址重新连接到集群中。 

    •事务完整性。所有提交的事务将被保存，并且在故障转移处理完成后可以使用。 

    •快速故障转移。在大多数情况下，系统的故障转移过程大约在 30 秒内可以完成。后续数据库可用性取决于需要前滚或回滚的事务数量。

在图 2 中，可以看到 Windows Clustering Services 的基本概况。

图2：基本集群

    每个集群节点需要下列硬件： 

    • 一个用于 Windows Server 操作系统的硬盘。该硬盘不共享，并且不连接到用于连接共享存储的控制器。该磁盘使用它自己的控制器，并且应该被镜像，以提高可用性。 

    •SCSI 或 Fibre Channel 适配器，连接到集群的共享磁盘存储器。 

    • 二张网卡 (NIC)。一张网卡用于将集群节点连接到外部网络；另外一张网卡用于专用集群网络，它维持集群的“心跳”——表明节点可用的信号。

    因为集群中的节点使用共享存储子系统，所以它们通常需要放置于相对较近的位置。节点之间的距离取决于用于存储子系统的节点的连接情况。使用共享 SCSI 连接的集群必须相对较近（数米范围内）；而使用 Fibre Channel 连接的节点可以相隔数英里。该解决方案减小了服务器故障引起停机的可能性，但仍然易受影响整个位置的事件的影响。地理集群（多站点集群）通过按地理位置上分散集群节点解决了这个问题。该方法通过同步镜像不同位置之间的 Quorum 磁盘来实现。集群实际上并不需要知道其节点之间的地理距离，所以这些解决方案必须在组织的基础架构的网络级和存储级上实现。

    为了实现 Windows Clustering 解决方案，必须使用 Microsoft 认证的服务器系统和 Windows Clustering 软件。可以在 Windows HCL Home 网页上找到受支持的硬件平台列表。确保使用的是经过认证的集群系统很重要，不要使用现有部件自行构建集群。这是因为硬件供应商将对这些系统进行有力的测试，以便符合 Microsoft 所定义的要求，并且作为一个整体对系统进行认证。 使用部件自行构建的集群（而非经过认证的系统）是不受支持的配置。

    使用 N+1 配置（N 活动节点+1 后备节点）的 SQL Server 2005 和 Windows Server 2003 组合可提供非常灵活且极具成本效益的的集群方案，能实现高可用性应用。例如，在 N+1 配置的 8 节点集群中，8 个节点中的 7 个可以设置为活动状态以提供不同的服务，而剩下的 1 个节点设置为被动节点，当7 个活动节点中任何一个服务器出现故障时，它将承担起该服务器的服务。图 3 所示为一个 8 节点集群，其中 7 个节点为活动的，1 个节点备用，等待 7 个活动节点之一发生故障时切入。

图3：N 路集群

•  数据库镜像

    SQL Server 2005 中的新 Database Mirroring 功能是另一个重要的选项，它可以防止服务器或数据库故障引起的计划外停机。顾名思义，Database Mirroring 提供数据库级的故障转移。在主数据库发生故障的情况下，Database Mirroring 将启用从 SQL Server 系统上的备用数据库，使系统几乎可以立即恢复可用性。单个数据库上可以设置 Database Mirroring，同一服务器上的多个数据库也可以设置Database Mirroring。它提供零数据丢失。从数据库将实时地与主数据库服务器上正在进行的当前事务同步更新。运行 Database Mirroring 对事务吞吐量的影响微乎其微，几乎为零。

    与运行在服务器级的 Windows Clustering Services 不同，Database Mirroring 在数据库级实现。Database Mirroring 具有接近实时的故障转移，只需要几秒钟；而集群通常需要约 30 秒的故障转移时间（有时更久，取决于故障服务器上的数据库活动水平和数据库大小）。Database Mirroring 提供对磁盘故障的额外保护，因为其中没有集群解决方案中的共享 Quorum 磁盘。另外，对于 Database Mirroring 实际上没有距离限制；而使用集群的高可用性解决方案有约 100 英里的距离限制，以传输集群节点之间的“心跳”信号。与需要特定硬件配置的集群不同，Database Mirroring 可以与支持 SQL Server 的所有标准硬件一同工作。图 4 所示为新的 Database Mirroring 功能的工作原理概览。

图4：Database Mirroring

    Database Mirroring 使用三套系统来实现：主服务器、从服务器和见证服务器。 

    主服务器是当前提供数据库服务的 SQL Server系统。默认情况下，所有传入的客户端连接都连接到主服务器。从服务器的工作是维护主服务器镜像数据库的一个副本。从服务器不限于只提供后备服务，从服务器上的其他数据库可以活动地支持其他非关联应用程序。见证服务器实质上是作为独立的第三方，负责确定哪个系统将承担主服务器的角色。 

    Database Mirroring 是通过在主服务器和从服务器之间发送事务日志而进行工作的，从而使 Database Mirroring 成为一个实时的日志传送应用程序。当客户端系统向主服务器写入事务时，在该请求被写入数据库文件之前，它被写入到主服务器的日志文件中。随后该事务记录将被发送到从服务器，然后写入到从服务器的事务日志中。从服务器将记录写入其日志后，将向主服务器发送确认消息。这使两个系统都知道记录已被接收到，现在同样的数据在每个服务器日志文件中都存在。当进行提交操作时，在主服务器向客户端回应操作已结束的信息前，它将等待镜像服务器的确认消息。从服务器实质上处于连续恢复的状态，不断地使用传入的事务日志数据对数据文件进行更新。 

    为了提高客户端应用程序的高可用性，Database Mirroring 与 Microsoft Data Access Components (MDAC) 层中称为“Transparent Client Redirection”的更新协同工作。Transparent Client Redirection 使最终用户系统在主服务器的数据库不可用时，可以自动重定向到从服务器。因为新的 Transparent Client Redirection 功能是在 MDAC 层中实现的，所以利用该功能时，不需更改客户端应用程序。MDAC 软件层了解主服务器和从服务器的状态，当初始连接到主服务器时，它会同时取得从服务器的名称。如果客户端失去主服务器连接，MDAC 将进行一次重新连接到主服务器的尝试。如果该连接尝试失败，则 MDAC 将自动将接下来的连接尝试重定向到从服务器。 

    Database Mirroring 可以与 SQL Server 2005 数据库快照组合，用于创建使用镜像服务器数据的报告服务器。数据库快照提供特定时间点的只读数据库快照。图 5 所示为使用 Database Mirroring 和数据库快照的组合创建只读的报告数据库的示例。

图5：报告服务器

     通常，镜像服务器上的数据总是处于恢复模式，这意味着任何应用程序都不能访问。不过，可以为镜像的数据库创建数据库快照，以创建镜像数据库的一个只读副本。报告应用程序在只读模式下可以自由访问该数据库。

•  SQL Server 2005 日志传送
          

    日志传送是一项高可用性和灾难恢复解决方案，可以用于在主服务器故障情况下保护数据库。在 SQL Server 2005 和 SQL Server 早期版本中均提供了日志传送，提供对服务器故障的低成本保护措施。日志传送可以在任何能够运行 SQL Server 的硬件平台上实现，并且它可以配置为与 SQL Server 的任何版本一起运行。日志传送工作时，首先会在后备服务器上还原主数据库的完全备份。此后，将从主服务器的数据库发送事务日志，并将这些日志自动应用到后备服务器上的数据库。可以为日志传送配置一个在后备服务器上应用事务日志的延迟时间，从而防止用户错误。该用户定义的延时提供一个窗口，可以防止用户错误的传播，如意外删除、不正确的数据输入、应用程序错误和其他数据相关问题。

    日志传送包括下列组件：

    •主服务器。该服务器包含生产数据库。SQL Server Agent 作业将定期进行生产数据库事务日志备份，从而捕捉对生产数据库的更改。

    • 后备服务器。后备服务器包含主数据库的一个未恢复副本。后备服务器上的 SQL Server Agent 作业将定期从主服务器复制事务日志备份，并且将其还原到后备数据库。

    •监视服务器。该服务器监视主服务器和后备服务器的状态。

    与 Windows Clustering Services 或 Database Mirroring 不同，日志传送没有进行主服务器和从服务器角色切换的自动过程。日志传送可以与 Windows Clustering Services 组合使用来提供保护，防止受到站点级灾难和本地服务器故障的影响。日志传送使在一个或多个从服务器上维护生产数据库成为可能，并且在某个服务器或站点发生故障时，可以提升其中一个从服务器，使其成为新的主服务器。

•  SQL Server 2005——复制
          

    事务复制是可以用于解决服务器故障的另一个技术工具。尽管复制可以从主数据库向从数据库发送事务，但并非主要设计用作高可用性解决方案，不过，可以将事务复制作为低成本的数据库服务器备份机制。图 6 所示为 SQL Server 2005 事务复制的概览。

图6：复制

    SQL Server 事务复制包括下面三个主要组件：

    • 发行者。“发行者”是被复制数据的源。

    •订户。“订户”是复制数据的目的地。可以是多个订户中的一个。

    •分发者。“分发者”处理从“发行者”到“订户”之间的数据发送。

    事务复制使用源数据库的快照来初始同步“发行者”和“订户”处的数据库。当事务在“发行者”处提交时，它们被捕获并发送到“订户”。

    使用复制的优点是从服务器的持续可用，并且任何时刻都可作为报告服务器使用。但是，因为事务复制并非为实现高可用性而设计，提升从服务器来承担主服务器角色的过程不是自动的，需要手动操作。另外，故障后将主服务器恢复为其初始角色需要进行完全的数据库还原。与日志传送一样，事务复制可与 Windows Clustering Services 一同使用，通过将事务复制到从站点的服务器，以防止受站点故障的影响。

•  Oracle 10g—Real Application Clusters (RAC)

    Oracle 支持一组与 SQL Server 2005 非常类似的高可用性选项。可以通过称为 Oracle Fail Safe 的功能使用 Windows Clustering Services，最多可达 8 个节点。Oracle 还支持松耦合集群（基本上等同于日志传送）和 Oracle 的事务复制，从而保护组织不受服务器故障的影响。从 Oracle 9i 开始，Oracle 还提供另一个高可用性计算的选项（Oracle 10g 也继续提供了此选项）：Oracle 的 Real Application Clusters (RAC)。Oracle 的 RAC 在 Oracle 10g Standard Edition 和 10g Enterprise Edition 中都可以使用。Oracle 10g Standard Edition 中的 RAC 限制为最多 4 个 CPU。高级 RAC 管理功能（如管理包、监视包和分区操作）只在 Enterprise Edition 中提供。从 Oracle 10g Standard Edition 转向 Oracle 10g Enterprise Edition 的开销很大，Standard Edition 每 CPU 的费用为 15,000 美元，但对于 Enterprise Edition，则飙升到每 CPU 达 40,000 美元。

    Oracle RAC 包括多台互连的计算机（称为“节点”）。Oracle RAC 软件可以使连接的节点作为单独的计算环境工作。与 Windows Clustering Services 很相似， Oracle 仅在有限的硬件平台上支持 RAC。可以在 http://metalink.oracle.com 上找到所支持的硬件和操作系统平台列表。Oracle 支持的 RAC 最多可具有 64 个节点。可以互连的最大实例数取决于宿主操作系统平台。图 7 所示为 Oracle RAC 的概览。

图7：Oracle RAC

    节点发生故障时，将对系统中的锁定进行控制并重新同步 RAC 节点，这期间会使客户端连接短时挂起。Oracle 的 RAC 使用共享磁盘结构，因此，为了提供针对磁盘故障的保护，需要使用 Oracle 的 Data Guard 功能，而此功能仅在 Enterprise Edition 中提供。 

    对于高可用性客户端访问，Oracle RAC 系统提供两种连接故障转移方法： 

    • 连接故障转移。如果在初始连接过程中发生连接故障，则应用程序可以使用相同的虚拟服务器名称重新尝试连接到集群中另外的活动节点。 

    • Transparent Application Failover (TAF) 。如果在连接已经建立后发生通信故障，则该连接可以故障转移到另外的活动节点。因为 TAF 存储有当前事务的状态，所以它比连接故障转移需要更多的系统开销。为了使用 TAF，应用程序代码必须修改为使用最新版的 Oracle Call Interface (OCI) 功能，并且须包括处理丢失会话状态的代码。另外，更新事务将需要回滚，并且对服务器状态不进行故障转移。 

    与 Windows Clustering 类似，RAC 的故障转移需要集群节点具有即时监视或“心跳”机制。此节点监视功能可以使 RAC 集群在故障转移过程中快速同步资源。Oracle RAC 提供快速服务器端故障转移。这是通过 Real Application Clusters 中并发的活动–活动结构来实现的。换句话说，多个 Oracle 实例在多个节点上同时为活动的状态，这些实例同步对相同数据库的访问。所有节点还都具有对所有存储器的并发所有权和访问权限。当其中一个节点发生故障时，所有集群中的其他节点仍然可以访问存储器。这里没有磁盘所有权转移，并且数据库服务器代码已装载到内存中。故障转移后的同步 RAC 节点的进程将首先从集群中移除故障节点，然后夺取由故障节点拥有的资源控制。故障转移后，任何正在进行的查询将从它们的起点处重新运行。

•  Oracle 10g Data Guard

    与 SQL Server 2005 Database Mirroring 很相似，Oracle 的 Data Guard 使用生产数据库事务日志数据在后备服务器上维护一个过渡的一致性副本。在生产服务器上出现服务器故障的情况下，Data Guard 功能可以自动将后备数据库切换成生产数据库。Oracle 的 Data Guard 功能可以维护多达 9 个不同的生产数据库备份副本。Data Guard 以下列三种模式之一进行工作： 

    • 最大保护。在最大保护模式中，数据从主数据库同步发送到后备数据库。直到 redo数据在后备数据库上可用了，才会在主数据库上提交事务。如果 redo 数据不能写入到任何后备服务器，则主服务器上的处理过程将停止。 

    • 最大可用性。最大可用性模式功能很像最大保护模式。不同的是，只要 redo 数据写入到第一台后备服务器，处理就在主数据库上继续进行。备份服务器的不可用不会停止主服务器的处理。 

    • 最大性能。在最大性能模式中，redo 数据异步发送到后备数据库，同时主数据库继续处理事务。不需等待后备数据库确认已接收到 redo 数据，就可在主数据库上提交事务。
注意： Data Guard 仅在Oracle Enterprise Edition 中提供。 

    结束语 

    高可用性并非垂手可得，只有通过增强人员、流程和技术的组合才能实现。纯粹着重技术上的计划将不会达到很高水平的可用性，因为影响可用性的很多重要因素来自人员和流程的交互作用。准备适当的硬件和软件平台只是一个起点。具备这一点后，高可用性则取决于在适当技术组合中的良好规划和实践。 

    对高可用性的需要由业务需求驱动，而非源于某项特定技术的存在。创建高可用性环境通常很有吸引力，但要牢记：所需的可用性水平越高，相关成本也就越高。因此，关键是要真正了解您的业务所需的可用性水平。SQL Server 2005 和 Oracle 10g 均具有可提供很高可用性水平的各种功能。但是，并非两个数据库平台的所有功能都具有相同的成本或易用性。Microsoft SQL Server 2005 能以较低的成本为您的组织提供企业级高可用性功能，而复杂性比Oracle 的 10g要低。