微软SQL Server的复制功能是一项非常强大的技术，它可以实时地将数据从一个服务器移动到另一个，无论单向还是双向都可以。

　　为确保SQL Server复制功能运行的高效性，你在配置工具时需要做出几个重要决策。

　　推还是拉？

　　这个策略决定了在哪里运行Distribution Agent（或者Merge Agent）。

　　默认情况下，SQL Server的工作是由SQL Agent服务配置并运行的。这称作push设置，因为SQL Agent会将设置变化从Distributor那里推送给Subscriber。如果Agent在Subscriber上面运行，它就称作pull方式订阅，因为数据将从Distributor那里拉过来。

　　当选择Distribution Agent或Merge Agent的存放位置时，你需要考虑以下几个方面。

　　如果你有多个Subscriber和唯一一个Distributor，那你就应该使用push订阅。这将会减轻CPU和内存运行Distribution Agent或Merge Agent时的负载压力，把节省出来资源用在处理配置变更和用户请求上。

　　另外，如果你的Publisher和Distributor存放在物理服务器的同一位置，那么你就会在Subscriber上运行Distribution Agent或Merge Agent。这将减轻Publisher的负载压力，实际上，Publisher是SQL Server复制技术的关键服务器。

　　虽然所有服务器运行在同一个高速局域网情况下，以上的建议还是有效的，但是在广域网情况下进行复制数据，你可能还需要做一些改变。特别是在你有一个比较大的快照需要发送给Subscriber时。

　　SQL Server复制功能允许你控制每次运行的线程数目，这样你就可以一次申请多个事务到你的Subscriber中。然而在使用SQL Server 2005及以下版本时，你会遭遇一个内置的性能瓶颈并会严重阻碍你的工作。

　　在2005和以前的版本中，Distribution Agent同分布式数据库只有一个连接。因此，无论你在推送数据到Subscriber时运行多少个线程，数据传输也只能跟运行一个线程的速度一样。而SQL Server 2008则避免了此种情况的发生。

　　因此，如果在广域网，特别是低速广域网或者有高延迟的广域网中运行SQL Server复制功能时，Distribution Agent从分布式数据库下载数据的速度将极为有限。

　　注意：当使用网络时，速度和延迟完全是两回事。

　　相反地，Distribution Agent应该运行在Distributor上。这将允许单线程从Distributor那里将数据拉过来，同时多线程在Subscriber上交付那些事务。