针对写入繁重的中型数据库的事务复制

Question

我们有一个相当大的、写繁重的数据库，大约有426 GB (包括索引)和大约3亿行。我们目前从设备收集位置数据，每隔几分钟向我们的服务器报告一次，我们为大约10,000台设备提供服务-因此每秒都有大量写入。存储每个设备的位置的位置表大约有2.23亿行。这些数据目前是按年归档的。

当用户在此数据库上运行大型报告时会出现问题，整个数据库几乎停止运行。

我知道我需要一个报告数据库，但我的问题是，是否有人有在同等大小的数据库上使用SQL Server事务复制的经验，以及他们使用这项技术的经验？

我的粗略计划是将应用程序中的所有报告指向报告数据库，使用事务复制将数据从主服务器复制到从服务器(报告数据库)。

有人对这个策略有什么想法和我可能会遇到的问题吗？

非常感谢！

Answer 1

事务复制在这种情况下应该工作得很好(数据库大小的唯一影响是生成初始快照所用的时间)。但是，它可能不能解决您的问题。

我认为，如果您选择事务复制，您将遇到的问题是，当应用更改时，从服务器将处于与主计算机相同的负载下-当用户运行大型报告时，它仍然会爬行(假设它具有类似的规范)。

如果延迟是可以接受的，您可以从日志传送中获得更好的性能，因为更改是批量应用的。

在获取报告服务器之前，另一种方法是调查用户正在运行的查询，并考虑修改他们的代码或索引策略，以更好地匹配他们试图执行的操作。

Answer 2

事务性复制可以很好地为您工作。需要考虑的事情：

通过从OLTP数据库的备份初始化报表数据库，可以跳过快照的痛苦。请参阅https://msdn.microsoft.com/en-us/library/ms151705.aspx

将存在从复制到分发数据库和订阅服务器数据库的插入/更新/删除通信。这需要考虑，但锁/块问题不应该比通过OLTP运行这些报告更糟糕(甚至可能更好)。

我在一个2.6TB的数据库上运行多个发布，每天增长2.5 am，使用纯事务来驱动报告(到两个报告服务器)，使用点对点事务来在SaaS产品的横向扩展中复制数据(到另外三个服务器)。正因为如此，我们有一个单独的分销商。

希望这能有所帮助。

谢谢约翰。