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 的概览。

节点发生故障时，将对系统中的锁定进行控制并重新同步 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要低。

附录A — 高可用性的障碍

人员障碍

任何环境下引起停机的最大原因之一是人为错误。快速从人为错误中恢复的能力在数据库可用性要求中处于首位。David Patterson 的研究论文 表明，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 的网络设备传送到远程存储区域网络。如果主站点出现故障，则数据不会丢失，因为远程存储区域网络具有数据的镜像副本。

Michael Otey 是Windows IT Pro Magazine的技术总监和SQL Server Magazine的资深技术编辑。他还是 TECA, Inc 公司的总裁，该公司是一家软件开发和咨询公司，专门从事互操作性和数据库应用方面的开发。Michael 是SQL Server 2005 New Features Guide的作者（该书由 Osborne McGraw Hill 公司出版）。

Denielle Otey 是 TECA, Inc. 公司的副总裁和软件顾问，她具有 C、Visual C++®、Visual Basic® 和 Visual Studio® .NET 软件设计、实现、测试和调试方面的丰富经验。她也是多个 SQL Server 实用程序的开发者和ADO.NET The Complete Reference的合著者（该书由 Osborne McGraw Hill 公司出版）。

本文是与 A23 Consulting 合作完成的。