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 要低。
** 附录 A — ** ** 高可用性的障碍
**
人员障碍
任何环境下引起停机的最大原因之一是人为错误。快速从人为错误中恢复的能力在数据库可用性要求中处于首位。 David Patterson 的研究论文 A Simple Way to Estimate Downtime 表明， 53% 的停机时间是人为错误的结果。其他研究（如《 Disaster Recovery Journal 》中发表的数据）也表明，组织中发生数据丢失的人为错误占到了 36% 之多。显然，克服人员障碍是达到更高可用性的最重要步骤之一。操作员错误可在数分钟内破坏数据库，而恢复或还原数据则需要数个小时或数天。这些恢复时间的代价巨大，不过却是可以避免的。
人会犯错误 ， 但还是可以主动采取措施来尽可能减少停机时间 ，以 从这些错误中恢复。人为错误主要由两个途径引入：用户错误和操作员错误。如果给予了相关权限，用户可能会因为疏忽而删除重要数据或使用不正确信息错误更新数据库，最终对公司信息造成破坏。培训、创建足够的应用程序文档和建立相关的规程等等是防止用户错误的最佳预防措施。减小由于用户错误引起的可能停机时间的最重要步骤之一是严格限制每个用户对数据和服务的访问权限，仅提供其所需的权限。
操作员或应用程序开发人员的错误也会对数据库和应用程序可用性产生巨大的影响。例如，错误地从数据库删除一个表，或者编写引起数据库写入不正确数据的代码都会影响应用程序的可用性。防止这些类型错误的一个好方法是加强职员对持续信息可用性相关的复杂性和职责的意识，特别是上层管理职员。这些将增加培训预算，并且需要花费时间和投入资源来开发操作指南，还要开发并实施灾难恢复计划。
维护数据库的完整性对数据库管理员来说是一个日益困难的任务。在很多情况下，都需要 DBA 参与整个开发过程的所有阶段。这可能包括结构和数据库设计、应用程序开发、数据库管理，以及灾难和恢复方案的实施。 DBA 需要经过良好培训，能够对问题进行故障诊断，并且具有必需的工具来有效地实行数据恢复计划。
流程障碍
另一个深刻影响创建高可用环境能力的因素是内部流程。制定合适的流程有助于消除不必要的停机时间，在服务中断时可以快速恢复。
高可用性最重要的障碍之一是缺少文档操作程序。组织应制定用于执行例行操作任务的书面程序，并形成关于从不同类型灾难恢复所需步骤的文档。这些操作程序文档通常称为“运行手册”。缺少足够的文档会导致服务中断的不精确性恢复，并且增加了漏掉所需步骤的可能性，因此也增加了实行整个恢复所需的总时间。同样，缺少足够的例行操作程序文档也会增加操作错误的可能性，特别是在由于疾病或其他诸如职责重新分配引起人员变更的情形下更是如此。缺少操作程序也会影响问题的诊断。没有标准化的程序，不同的人执行各种任务会有所差别，使正确地确定处理给定情形的步骤顺序变得困难。有效的运行手册将使新手 DBA 可以像有经验的团队成员一样有效地执行例行操作。
问题解决方案文档不足是缺少适当程序而影响可用性的另一个方面。建立标准的问题解决方案程序有助于操作人员识别通常的问题场景，并使他们能在各种情况下更快地进行诊断和解决问题。缺少标准化事件管理程序将会在每次出现常见问题时需要帮助台和操作人员进行重复的工作。这样就增加了从本应该已知的情形中恢复所花费的时间，也增加了错误诊断问题的可能性。最终结果是很可能增加停机时间，甚至会导致其他问题。
更改管理程序不足也可以成为高可用性的重要阻碍。更改管理程序使组织可以跟踪在应用程序生存期中进行的应用程序更改和数据库架构更改。除了提供跟踪源代码和数据库架构更改的标准机制外，创建足够的更改管理程序使组织必须建立质量保证环境，更改在部署到生产环境中之前，可以在质量保证 (QA) 设置中进行测试。如果没有更改管理程序，则可能导致整体恢复错误，使数据库架构和应用程序更新可能丢失，或者被没有合并更多当前更新的后续更改所取代。类似地，缺少 QA 环境可能导致应用程序和数据库部署错误，而这会使应用程序不可用。
其他两个高可用性的流程障碍是缺少标准化硬件和软件配置。只要可能，就要对数据中心所使用的硬件和软件配置进行标准化。标准化的硬件组件使硬件故障下的系统维修和/或替换更容易。同样，标准化的软件配置使例行操作更容易，并且减小了操作员错误的可能性。
例如在可能的情况下 ， 所有服务器应使用标准命名方案 ， 并应具有标准化的驱动器盘符、映射目录和共享名。另外，所有数据库服务器应使用相同的操作系统、数据库和中间件数据访问层的服务包级别运行。
缺少标准硬件和软件配置将会增加错误可能性 ， 从而引起故障解决时间的延长和引入操作与恢复错误的增多。
创建高可用性环境过程中的最后一个流程障碍就是不正确的或过时的制度知识。为所有 IT 人员建立定期的培训计划有助于保证组织的技术技能保持先进，并且使组织更有可能采用最有效的技术和工具。
技术障碍
在技术领域中 ， 达到可用性的最高水平需要解决几个问题。服务器单元的任何组件都可能发性硬件故障。应用程序错误也会影响数据库访问。需要准备好恰当的数据库恢复机制来还原信息，否则数据将会被破坏。有计划的硬件升级和数据库维护也是可能降低系统可用性的因素。利用可用数据库技术可以减小或消除与计划维护相关的停机时间。最后，基础结构故障或站点灾难对数据库可用性也有重大的影响。
<span style="FONT-FAMILY: 宋体; mso-hansi-