使用SQL Server复制的性能影响是什么？

要添加更多关于事务复制的信息，

它使用SQL代理日志读取器作业从发布数据库的事务日志中获取已提交的事务。这意味着在日志logging被读取之前日志不能被清除。如果日志读取器代理的周期性发生改变，那么您的日志可能会意外增长。日志阅读器代理也可能导致大批量OLTP系统上的事务日志争用，当然取决于您的IO子系统。
复制不能保证零数据丢失，因为在读取日志logging和将其通过分发器传递给订阅者时会有延迟。对于零数据丢失，请查看同步数据库镜像或同步SAN复制
点对点复制是扩展查询工作负载的好方法，也可以为数据添加一些冗余
您必须采取点对点的方式进行谨慎的模式devise，以避免由于不同节点的类似变化而导致的冲突。不要使用分区标识。使用复合代理键（例如node-identifier + bigint）
在对等的情况下，向拓扑中的各个节点添加额外的冗余可能是困难的。发行商可以被镜像，订阅者可以被镜像（在2008年相当容易，2005年不是那么容易），但是分发者不能。必须将其集群以增加冗余。

编辑：好的 – 这是午餐时间，我还有一些补充：

点对点复制：在2005年，如果您想要更改拓扑（添加或删除节点），则必须静止整个拓扑。在2008年你不需要。
对等复制直到2008年才会有冲突检测，但即使如此，冲突解决scheme也是非常糟糕的 – 具有最高ID（称为对等始发者ID）的节点获胜 – 可能不是您想要的。
点对点复制：所有节点都可以看到来自其他节点的所有更改。这意味着在西雅图，伦敦，东京等三维拓扑结构 – 如果西雅图倒下，伦敦和东京继续前进。如果东京然后倒下，西雅图上线，伦敦将从伦敦获得伦敦的所有最新消息，并从伦敦获得伦敦所知道的所有东京最新消息。很简约。
没有任何forms的故障检测或自动故障转移与复制。也许看看镜像。我想你可以使用某种forms的NLB。

在select任何types的高可用性解决scheme时（现在我正在为内部Microsoft DBA教授高可用性课程），您需要在评估技术之前从需求分析开始。如果不知道所有的要求，提出build议是有点困难的。

再次编辑：

它的一个例子是：中间层负载平衡的数据层中的各种服务器。点对点允许所有节点保持（最终）同步。
讨厌的问题，但：如果用户路由到节点1，并进行交易，数据复制到其他节点多久之前，因为repl延迟可以改变？如果用户再次连接到服务，哪个节点将她路由到？与以前相同的节点还是有足够的时间能够安全地路由到任何节点，并保证她所做的上一个事务已被复制到所有节点？

好 – 不要再编辑了！ 🙂

复制是一种相当多样化的技术，可用于满足多种不同的场景，其select将决定所实施的特定复制types。

例如，通过将应用程序的工作负载分散到多个服务器（即分布式处理体系结构），可以使用合并复制来支持分布式处理。

合并复制通常需要一个相对意识到其环境的应用程序。诸如冲突解决之类的技术也必须被考虑，以确保整个集成环境中的数据一致性。

事务复制可以以类似的方式用于日志传送，但是可以限制复制到订户的特定对象。如果报表需要只有一部分表格用于报表，这可能很有用。

有关可用体系结构的完整列表，请参阅以下Microsoft复制参考。

您使用的复制风格将决定您可能遇到并需要考虑的问题的types。例如，合并复制要求架构更改到您的数据库。

还有一些需要考虑的安全因素，比如你的数据是通过公共互联网复制的，还是需要encryption通信等。

复制是一个很大的话题，但是我希望这些信息能让你走向正确的方向。

如果由于任何原因必须closures复制并重新启动（或者刚开始时），则往往会导致两个服务器在处理过程中几乎不响应。一旦开始运行（并且一个人留下），它不是显而易见的（至less对我们来说不是）。