我需要实现SQL Server复制解决方案。现在非常简单。我只需要将一个非常简单的表从200个远程站点复制到一个中央服务器。这些数据本质上不是交易性的。我只是需要它每天一次移动到中央服务器。我无法决定是否应该使用推送或拉动，我不确定分销商是应该在服务器端还是在所有客户端上。
服务器和所有远程站点都存在于相当不错的VPN上。服务器是2005年，目前还没有被推得很厉害。这里和那里只收集一些工作数据（我想要远离它）并每天向各个供应商推送报告/出口。这些网站是2000/2005的混合。
答案 0 :(得分：2)
我建议你先做一些可伸缩性测试。就代理作业和用于读写数据的T-SQL连接而言，复制非常冗长。您正在谈论200个出版物200个发布商代理商，200个订阅代理商，以及分销商维护。大多数网站都抱怨有1个发布者和1个订阅者的维护问题...假设您设法将其关闭并且操作成功，那么您的升级故事会是什么？您将如何实施架构更改？
我听说过（几年前）最大规模的复制部署，我相信有450家出版商，并且由一群微软的现场顾问实施了几个月的出汗，让这个庞然大物成型。您的200个复制站点项目方式比您意识到的更加雄心勃勃。
我建议你也要探索一些替代品。如果您需要周期表快照，那么SSIS可以很好地匹配。如果您需要连续的更改流，那么Service Broker可以比复制更容易扩展。
答案 1 :(得分：1)
如果需要在路上调整复制，让中央服务器启动拉动将比调整200个站点以完成同样的事情更容易管理。此外，这自然会管理负载，而不是一些方案来防止，例如，100个远程站点同时连接。
答案 2 :(得分：0)
如果您希望集中管理应用程序平台的数据分发，那么推送订阅就是您的选择。
根据您的描述，您需要在架构的快照复制和事务复制之间做出选择。
取决于您要推送的数据量以及更新计划将决定您使用的最合适的复制方法。例如，如果您希望同时更新所有订阅，那么根据推送快照复制所需的数据量可能不合适，您可能最好使用事务复制，可能会按特定的确定间隔推送。您的网络甚至可以支持近乎实时的复制，但是对您的环境进行一次小测试将为您确定这一点。例如，在网络上的地理位置不同的位置设置发布服务器，本地分发服务器和少数订阅服务器，以便测试网络传输时间和复制延迟。
需要考虑的事项：