我们有一个大小适中、写入量大的数据库，大约 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 产品的横向扩展中复制数据（到另外三台服务器）。因此，我们有一个单独的分销商。
希望这可以帮助。
谢谢约翰。
事务复制在这种情况下应该可以很好地工作（数据库大小的唯一影响是生成初始快照所花费的时间）。但是，它可能无法解决您的问题。
我认为如果您选择事务复制，您将遇到的问题是从服务器将在应用更改时与主计算机处于相同的负载下 - 当用户运行大型报告时它仍然会爬行（假设它是类似的规格）。
根据将数据报告到实时数据的可接受延迟，这对您的用户来说可能合适，也可能不合适。
如果可以接受一些延迟，您可能会从日志传送中获得更好的性能，因为更改是分批应用的。
在购买报告服务器之前，另一种方法是调查用户正在运行的查询，并查看修改他们的代码或索引策略以更好地匹配他们正在尝试执行的操作。