我们使用中央 SQL Server（2008标准版）和几个较小的专用 SQL Server（Express版本）。我们需要实现一些机制，用于从专用的分散式SQL Server（更大的卷，见下文）和从中央SQL Server返回数据异步* （几个记录，基本上是机器的一些通知，可能一些优化提示）。
专用SQL Server实际位于技术计算机附近，它们定期收集说datetime, temperature行（考虑几秒间隔）。一项工作大约有500条记录，但下一项工作立即进行（机器不知道这是一项新工作 - 从某种意义上来说是非常愚蠢的 - 只是简单地收集温度）。
技术机器必须能够在没有中央SQL Server的情况下工作，并且中央SQL Server也必须在机器不可访问时工作（即无法访问其专用SQL引擎，使用机器关闭）。换句话说，解决方案不需要超快，但在没有收集的数据丢失的意义上必须是健壮的。
基本思想是将收集的数据从专用 SQL Server（预处理到带有计算机ID的规范化格式）移动到中央SQL Server上的众所周知的表。只应发送较新的数据以最小化数据量。如果连接正常，则应由专用SQL Server以固定间隔（例如一小时）启动该传输。如果连接不正常，数据将在下一小时后发送，等等。
中央SQL Server上的另一个众所周知的表将用于发送专用SQL Server引擎的通知。通过这种方式，可以告知专用引擎（例如）在中央SQL Server上已经处理/存档了哪些数据（即，可以从专用机器上的本地数据库中删除哪些记录的提示），或者是什么信息。从中央暗示（只是提示或其他不是实时要求）。提示将由专用SQL Server收集（即机器责任）。换句话说，中央SQL Server只处理众所周知的本地表。它不会尝试连接专用的SQL Server计算机。
解决方案应该只使用标准机制 - SQL命令（通过存储过程），不使用外部软件。我应该关注什么样的解决方案？
谢谢， 彼得
[稍后编辑] SQL服务器位于同一局域网中。
答案 0 :(得分：5)
如果您愿意进行心理转换并停止考虑表和行，而是考虑数据和消息，那么Service Broker可以处理所有通信，传递和消息处理。而不是本地（在Express机器上）执行INSERT INTO LocalTable(datetime, temperature) VALUES (...)，你会想到：
BEGIN CONVERSATION WITH CentralServer ...;
SEND ON conversation MESSAGE TYPE [Measurement] (<datetime...><temperature ...>)
请参阅Using Service Broker instead of Replication或High Volume Contiguous Real Time ETL
答案 1 :(得分：0)
听起来像是merge replication的工作。