我们有一个体面的，写得很重的数据库，大约426 GB（包括索引）和大约3亿行。我们目前每隔几分钟从我们的服务器报告的设备收集位置数据，我们服务大约10,000个设备 - 每秒都有大量的写入。存储每个设备位置的位置表大约有2.23亿行。该数据目前按年归档。
当用户在此数据库上运行大型报表时会出现问题，整个数据库几乎停止运行。
我知道我需要一个报告数据库，但我的问题是，是否有人在同等大小的数据库上使用SQL Server事务复制的经验，以及他们使用此技术的经验？
我的粗略计划是将应用程序中的所有报告指向报告数据库，使用事务复制将数据从主服务器复制到从服务器（报告数据库）。
任何人对这个策略以及我可能遇到的问题都有任何想法吗？
非常感谢！
答案 0 :(得分：0)
事务复制在这种情况下应该运行良好（数据库大小的唯一影响是生成初始快照所需的时间）。但是，它可能无法解决您的问题。
我认为，如果您选择事务复制，那么您将遇到的问题是，当应用更改时，从属服务器将与主计算机处于相同的负载下 - 当用户运行大型报告时，它仍会抓取（假设它是类似的规范）。
根据向实时数据报告数据的可接受延迟，这可能对用户有效，也可能不行。
如果某些延迟是可以接受的，那么从日志传送中可以获得更好的性能，因为批量应用了更改。
在获取报告服务器之前，另一种方法是调查用户正在运行的查询，并查看修改其代码或索引策略以更好地匹配他们尝试执行的操作。
答案 1 :(得分：0)
事务复制可以很好地为您服务。需要考虑的事项：
您可以通过从OLTP数据库的备份初始化报告数据库来跳过快照的折磨。见https://msdn.microsoft.com/en-us/library/ms151705.aspx
将Replication中的INSERT / UPDATE / DELETE流量分配到分发和订阅服务器数据库中。这需要考虑，但锁定/阻止问题应该不比从OLTP运行这些报告更糟糕（并且可能更好）。
我在2.6TB数据库上运行多个出版物，每天增长2.5GB，使用纯事务驱动报告（到两个报告服务器）和对等事务处理以在横向扩展中复制数据SaaS产品（另外三台服务器）。因此，我们有一个单独的经销商。
希望这有帮助。
由于 约翰。