一、事务复制
事务性复制通常从发布数据库对象和数据的快照开始。创建了初始快照后，接着在发布服务器上所做的数据更改和架构修改通常在修改发生时（几乎实时）便传递给订阅服务器。数据更改将按照其在发布服务器上发生的顺序和事务边界，应用于订阅服务器，因此，在发布内部可以保证事务的一致性。
事务性复制通常用于服务器到服务器环境中，在以下各种情况下适合采用事务性复制：
- 希望发生增量更改时将其传播到订阅服务器。
- 从发布服务器上发生更改，至更改到达订阅服务器，应用程序需要这两者之间的滞后时间较短。
- 应用程序需要访问中间数据状态。例如，如果某一行更改了五次，事务性复制将允许应用程序响应每次更改（例如，激发触发器），而不只是响应该行最终的数据更改。
- 发布服务器有大量的插入、更新和删除活动。
- 发布服务器或订阅服务器不是 SQL Server 数据库（例如，Oracle）。
默认情况下，事务性发布的订阅服务器应视为只读，因为更改将不会传播回发布服务器。但是，事务性复制确实提供了允许在订阅服务器上进行更新的选项。
二、快照复制
快照复制将数据以特定时刻的瞬时状态分发，而不监视对数据的更新。发生同步时，将生成完整的快照并将其发送到订阅服务器。
 注意： |
|---|
| 快照复制可由其自身使用，但是快照处理（负责创建由发布所指定的所有对象和数据的副本）通常还用于为事务性发布与合并发布提供初始的数据和数据库对象集。 |
当符合以下一个或多个条件时，使用快照复制本身是最合适的：
- 很少更改数据。
- 在一段时间内允许具有相对发布服务器已过时的数据副本。
- 复制少量数据。
- 在短期内出现大量更改。
在数据更改量很大，但很少发生时，快照复制是最合适的。例如，如果某销售组织维护一个产品价格列表且这些价格每年要在固定时间进行一两次完全更新，那么建议在数据更改后复制完整的数据快照。对于给定的某些类型的数据，更频繁的快照可能也比较适合。例如，如果一天中在发布服务器上更新相对小的表，但可以接受一定的滞后时间，则可以在夜间以快照形式传递更改。
发布服务器上快照复制的连续开销低于事务性复制的开销，因为不用跟踪增量更改。但是，如果要复制的数据集非常大，那么若要生成和应用快照，将需要使用大量资源。评估是否使用快照复制时，需要考虑整个数据集的大小以及数据的更改频率。
三、合并复制
与事务性复制相同，合并复制通常也是从发布数据库对象和数据的快照开始，并且用触发器跟踪在发布服务器和订阅服务器上所做的后续数据更改和架构修改。订阅服务器在连接到网络时将与发布服务器进行同步，并交换自上次同步以来发布服务器和订阅服务器之间发生更改的所有行。
合并复制通常用于服务器到客户端的环境中。合并复制适用于下列各种情况：
- 多个订阅服务器可能会在不同时间更新同一数据，并将其更改传播到发布服务器和其他订阅服务器。
- 订阅服务器需要接收数据，脱机更改数据，并在以后与发布服务器和其他订阅服务器同步更改。
- 每个订阅服务器都需要不同的数据分区。
- 可能会发生冲突，并且在冲突发生时，您需要具有检测和解决冲突的能力。
- 应用程序需要最终的数据更改结果，而不是访问中间数据状态。例如，如果在订阅服务器与发布服务器进行同步之前，订阅服务器上的行更改了五次，则该行在发布服务器上仅更改一次来反映最终数据更改（也就是第五次更改的值）。
合并复制允许不同站点自主工作，并在以后将更新合并成一个统一的结果。由于更新是在多个节点上进行的，同一数据可能由发布服务器和多个订阅服务器进行了更新。因此，在合并更新时可能会产生冲突，合并复制提供了多种处理冲突的方法。