离线存储一些SQL Server数据

Question

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

系统必须能够在网络中断的情况下脱机收集数据。

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

需要进行某种同步才能准备网络中断。同步会拉动更新的测试结构。另一个同步会推送未保存的测试数据。

你如何推荐我做到这一点？任何警告？

想法/思考：

1. 每一台机器上安装SQL Server和编写脚本来同步服务器和客户端（似乎昂贵和矫枉过正）。
2. 使用同步脚本在应用程序定义的原始数据文件中保存本地数据副本。
3. SQL Server中内置了什么让客户端能够离线收集数据？
4. 本地保存所有数据，然后单击“传输”按钮将数据推送到网络。

环境：MS SQL服务器的Windows Server上运行2008

Answer 1

使用本地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缺乏像复制监视器这样的优化工具，这使得部署简单的复制拓扑结构变得非常简单。另一方面，SSB在升级部署方面有很大的优势，如2005/2008/2008R2 versions are perfectly compatible。

Answer 2

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

Answer 3

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