提高可用性
复制可用于向备用服务器复制数据，这样可以在计划的或意外的系统停用情况下提供更高的可用性。 如果备用服务器所需的数据为主服务器所需数据的子集，则应使用复制来提供热备用。 同时还应考虑下列事项：
如果应用程序要求多个站点的数据来提高伸缩性和可用性，请参阅提高可用性和伸缩性。
如果应用程序要求整个数据库都在备用服务器上可用，请使用数据库镜像而不要使用复制。 如果需要同步整个数据库，而且不需要使用辅助服务器处理查询，则数据库镜像会更高效。 有关详细信息，请参阅数据库镜像管理。
下面的关系图显示了一台主服务器和一台备用服务器，主服务器上数据的一个子集在辅助服务器中可用。
.gif "向备用服务器复制数据")
.gif "注意") 注意 |
|---|
复制不提供从一台服务器故障转移到另一台备用服务器的机制。 当第一台服务器不可用时，必须对访问给定服务器的所有应用程序进行编程，以使用另一台服务器。 |
Adventure Works Cycles 示例
Adventure Works Cycles 是一家虚构的制造公司，用于演示数据库概念和方案。 有关详细信息，请参阅AdventureWorks 示例数据库。
Adventure Works Cycles 在整个制造机构中有若干台服务器，用于收集有关生产线中有缺陷的数据。 他们使用复制来为这些服务器提供可用性。 同时还编写了代码以在计划的和意外的停用期间将查询重定向到热备用服务器。
此方案的一般要求
使用复制来提供可用性的应用程序通常具有下列要求，相应的复制解决方案必须处理这些要求：
系统必须保持事务的一致性。
系统的滞后时间应较短：在一台服务器中进行的更新必须能够快速传递到其他服务器。
系统的吞吐量应较高：应能处理大量事务的复制。
复制处理所需的开销应尽量小。
辅助服务器所需的数据可能是主服务器中的可用数据的子集（见上方第一个关系图）。
用于此方案的复制类型
MicrosoftSQL Server 使用出版业术语来说明复制系统的组件。 这些组件包括发布服务器、订阅服务器、发布、项目和订阅。
在上面的关系图中，主服务器为发布服务器。 主服务器中的部分或所有数据都包含在发布中，其中每个数据的表都是一个项目（项目也可以是其他数据库对象，如存储过程）。 备用服务器是发布的订阅服务器，它接收架构和数据作为订阅。 有关系统组件的详细信息，请参阅复制发布模型概述。
SQL Server 针对不同的应用程序要求提供不同的复制类型：快照复制、事务复制以及合并复制。此方案最好用事务复制来实现，事务复制非常适合于处理前一部分所述的要求。 有关事务复制的详细信息，请参阅事务复制概述和事务复制的工作机制。
按照设计，事务复制可处理此方案下列主要要求：
事务的一致性
较短的滞后时间
大吞吐量
最低开销
此方案需要考虑的首要选项是筛选。 通过使用事务复制，可以对列和行进行筛选，因此订阅服务器中的表可以只包含应用程序所必需的数据。 有关详细信息，请参阅筛选已发布数据。
实现此方案的步骤
若要实现此方案，必须先创建一个发布和一些订阅，然后对各个订阅进行初始化。 有关各步骤的详细信息，请单击下面的链接：
在对订阅进行了初始化且数据开始在发布服务器和订阅服务器之间流动之后，您可能需要查阅以下主题，了解常见管理任务和监视任务的有关信息：