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