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% 之多。显然，克服人员障碍是达到更高可用性的最重要步骤之一。操作员错误可在数分钟内破坏数据库，而恢复或还原数据则需要数个小时或数天。这些恢复时间的代价巨大，不过却是可以避免的。