使用 SQL Server 复制对性能有何影响？

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

• 它使用 SQL 代理日志读取器作业从发布数据库的事务日志中收集已提交的事务。这意味着在读取日志记录之前无法清除日志。如果日志阅读器代理周期发生变化，那么您的日志可能会意外增长。日志读取器代理也可能导致大容量 OLTP 系统上的事务日志争用，当然这取决于您的 IO 子系统。
• 复制不保证零数据丢失，因为在读取日志记录并将它们通过分发器传递给订阅者时存在延迟。为了实现零数据丢失，请查看同步数据库镜像或同步 SAN 复制
• 点对点复制是扩展查询工作负载的好方法，还可以为您的数据添加一些冗余
• 您必须对点对点进行一些仔细的架构设计，以避免由不同节点上的类似更改引起的冲突。不要为此使用分区身份。使用复合代理键（例如 node-identifier + bigint）
• 对于点对点，很难为拓扑中的各个节点添加额外的冗余。发布者可以镜像，订阅者可以镜像（在 2008 年相当容易，在 2005 年不那么容易），但分发者不能。它必须集群化以增加冗余。

只是一些想法。您还可以查看我去年在http://download.microsoft.com/download/d/9/4/d948f981-926e-40fa-a026-5bfcf076d9b9/ReplicationAndDBM.docx上写的关于镜像 + repl 的白皮书

编辑：好的 - 现在是午餐时间，我还有一些要补充的：

• 对等复制：在 2005 年，如果您想完全更改拓扑（添加或删除节点），您必须停止整个拓扑。在 2008 年，您不需要这样做。
• 对等复制直到 2008 年才进行冲突检测，但即便如此，它的冲突解决也相当脑残——具有最高 ID（称为对等发起者 ID）的节点获胜——也许不是你想要的。
• 对等复制：所有节点都可以看到来自其他节点的所有更改。这意味着在具有西雅图、伦敦、东京的 3 路拓扑中 - 如果西雅图出现故障，伦敦和东京将继续运行。如果东京随后宕机，西雅图上线，它将从伦敦获取所有伦敦更新以及伦敦知道的所有东京更新。挺整洁的。
• 没有任何形式的故障检测或复制的自动故障转移。也许看看镜像。我想你可以使用某种形式的 NLB。

在选择任何类型的 HA 解决方案时（我今天正在为内部 Microsoft DBA 教授 HA 课程的好时机），您需要在评估技术之前从需求分析开始。在不了解您的所有要求的情况下提出建议有点困难。

在提出 HA 策略时，我写了一些问题要问自己：请参阅http://www.sqlskills.com/BLOGS/PAUL/post/HA-Where-do-you-start-when-choosing-a-high-可用性解决方案.aspx

再次编辑：

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

好的 - 没有更多的编辑！:-)

复制是一种非常多样化的技术，可用于满足许多不同的场景，其中的选择将决定所实现的特定复制类型。

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

合并复制通常需要一个相对了解其环境的应用程序。还必须考虑冲突解决等技术，以确保整个集成环境中的数据一致性。

事务复制可以以与日志传送类似的方式使用，但是您可以限制复制到订阅者的特定对象。如果报告目的只需要表格的一个子集，这将很有用。

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

http://msdn.microsoft.com/en-us/library/ms151827.aspx

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

还需要考虑安全因素，例如，如果您的数据要通过公共互联网复制，或者是否需要加密通信等。

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

如果您出于任何原因必须关闭复制并重新启动它（或者，只是第一次启动），它往往会导致两个服务器在进程中变得几乎没有响应。一旦启动并运行（并且不理会），它并不明显（至少对我们来说不是）。