将某些SQL Server数据脱机存储

Question

我开始设计一个新的实验室测试数据管理系统，有许多（约30个）测试站。

系统必须能够在网络中断时离线收集数据。

每个工作站将保留测试结构（规范，实体类型，业务规则/工作流等）的最新只读副本，但不保留测试数据。如果找不到服务器，实际测试数据将存储在本地。

需要某种同步来准备网络中断。同步将拉出更新的测试结构。另一个同步将推送未保存的测试数据。

您如何推荐我实现这一目标？有什么警告吗？

想法/想法：

1. 在每台计算机上安装SQL Server并编写脚本以同步服务器和客户端（看起来既昂贵又过度）。
2. 使用同步脚本将本地数据副本保存在应用程序定义的原始数据文件中。
3. SQL Server中是否包含任何内容以使客户端能够脱机收集数据？
4. 在本地保存所有数据，然后点击“转移”按钮将数据推送到网络。

环境：在Windows Server 2008上运行的MS SQL Server

Answer 1

我首先想到的是merge replication本地（SQL Server Compact）数据库副本。

Answer 2

使用本地SQL Express实例并通过Service Broker推送数据。请参阅High Volume Contiguos Real Time Audit and ETL，了解为什么从多个角度来看这比复制更好，包括价格，性能和可靠性。

使用复制，您需要在所有外围节点上获得比SQL Express更高的许可证（因为Express只能是复制拓扑中的订户）。使用SSB推送数据允许外围的SQL Express实例，并且只需要中央非快速许可服务器。这意味着您可以轻松地在数十个工作站上部署解决方案，而无需担心SQL Server许可成本。

另一个优点是性能和吞吐量。 SSB旨在处理数百和数千个通信对等设备，并设计了复杂的分层流控制，能够在出现网络故障时处理数千个目的地的重试（我知道这一切都是因为我是SSB的成员球队）。通过比较复制使用TDS协议进行数据交换，它依赖于SQL Agent作业并以简单的方式处理网络中断，这可能导致在重试时烧掉许多周期，使得事情在已经糟糕时更加糟糕。总的来说，SSB可以处理大型部署（我知道部署了+1500服务器，并且MySpace公开了他们的deployment of +500 servers依赖于SSB来交换数据。总的来说，在大规模上，SSB在任何方面都优于复制。

我还认为基于消息而不是表行复制的解决方案更适合于问题的描述：将结果推送到中央服务器。

回退（并且不是次要的）是最初部署SSB所需的陡峭学习曲线。专有技术已经存在但很难找到，SSB缺乏像Replication Monitor那样的优秀工具，这使得部署简单的复制拓扑成为一项直接的工作。另一方面，SSB在升级部署时具有很大的优势，如2005/2008/2008R2 versions are perfectly compatible。

Answer 3

听起来SQL Server复制是您想要检查的解决方案。合并复制将允许本地测试站从服务器接收数据副本，并发回在网络中断期间收集的数据。