哪些客观因素表明是时候实施SQL Server复制了？

我正在努力在数据库的高性能与易于维护之间取得平衡。我们正在考虑通过将SSRS报告复制到与事务数据库物理上分离的数据库中来提高性能。但是，从开发人员的角度来看，启用复制有许多缺点：

• 这使架构更改更加困难
• 它会干扰我们的自动化集成/构建服务器
• 似乎很难实现SQL源代码控制

我的问题是：鉴于这些缺点，您何时知道该进行复制的时候了？您如何确定额外的复杂性是否足以证明收益？

我们之前已经使用过它，所以设置它不是问题。这更多地是关于决定是否启用它的决定。我正在寻找一些其他人在复制中观察到的对象性能指标。

当然，最好的办法是在我们自己的服务器上进行一些模拟的负载测试，然后自己找出来，但我希望那里有一些通用的准则。

在应用程序的设计阶段应考虑复制。如果您的员工/地理位置在地理上分散，那么拥有区域数据库和中央数据库可能很有意义。当笔记本电脑上断开连接的数据库最终与网络重新连接时，它们可以“同步”（想想销售人员在旅途中）。

至于报告目的，复制不是答案。报告环境中的大多数性能问题源于以下事实：报告是针对针对联机事务处理（OLTP）配置的系统编写的。

用于报告目的的复制只是将您的OLTP数据移动到另一台服务器，而保持相同的报告不友好结构。从本质上讲，您在问题上投入了更多的硬件并增加了维护成本，但这只是为了获得少量收益。

您应该查看的是如何获取报表所需的特定数据，并将其转换为更有用的格式。创建一个提要，以从生产数据库中获取新交易并将其存储在报告数据库中，最好是在单独的服务器上。每次提要运行时，它都应获取比上次运行更新的所有数据，并转换并存储它们。当前正在运行的报告将使您对所需的转换类型有一个很好的了解。

通过遵循这种方法，您将获得巨大的性能优势。

对于它的价值，我们发现复制在类似情况下会有所帮助，因为报表编写者可以“拥有”复制数据库上的索引。这使我们能够通过添加索引来提高查询性能，这些索引由于应用程序开发人员对INSERTS和UPDATES的负面影响而无法在生产中获得批准。

也许您的用例的一部分是复制一些事务表，更改一些索引，看看是否值得？

希望这可以帮助！