通过使用日志传送、镜像或其他方式减少主服务器的负载？

Question

我之前曾问过以下有关 LogShipping 频率的问题，但我认为我可能错误地解决了这个问题（LogShipping 频率）

问题

我有一个高容量站点，我想将一些负载从主服务器上转移。我希望转移的主要领域是管理报告查询，它不需要数据是实时的（延迟 5-10 分钟是可以的）。

实验

日志运输

这似乎没问题，但我对它处理连接客户端的两种方式有疑问。

1. 恢复时断开连接。如果我有来自 Web 应用程序的长时间运行的报告，它会在处理过程中终止该报告。
2. 不要断开用户连接。这也不是很好，因为如果 admin db 获得大量流量，它无法在 db 上获得排他锁来进行恢复，并且数据差异的滞后可能会超过 10 分钟以上。

镜像

1. 这看起来很有希望，但似乎更侧重于数据冗余和故障转移数据库的能力，而不是我减少主服务器开销的实际目标。

题

是我在这里缺少的东西，我应该尝试其他东西（只读数据库，更好的硬件，集群），还是我完全错过了上述技术的要点？

Answer 1

既然 SQL Server 2012 已经发布，请不要忘记AlwaysOn，它允许显式读取横向扩展。

镜像适用于您所描述的情况，但是用于报告的数据库快照的编排可能会变得很复杂（镜像数据库不可读，您必须从定期创建的数据库快照进行报告）。

我不喜欢事务复制，但它可以用于您的场景，并且其他比我更有知识的人已经发表了In Defense of Transactional Replication。

AlwaysOn 和事务复制都提供了您想要的功能（横向扩展读取而不造成中断），并且它们都实现了近乎实时的数据延迟。但它们在价格点上有所不同：AlwaysOn 是 SQL Server 企业专用功能，需要 Windows 集群，而 Windows 集群又需要 Windows 企业许可，即。它的成本。另外，它需要升级到 SQL Server 2012。另一方面，除了您已有的内容之外，事务复制基本上不需要任何成本（除非您的整个设置都在 Express Edition 实例上，我对此表示怀疑），但它是有代价的，因为它将会与您的开发/部署周期产生摩擦，现在必须考虑复制影响（必须向出版物添加新文章，某些模式更改操作需要仔细规划等）。

对于一些开箱即用的想法，请考虑一些人如何诉诸使用 Service Broker 而不是复制。