pep*_*epr 3 sql-server sql-server-2008
我们使用中央 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服务器位于同一局域网中.
如果您愿意进行心理转换并停止思考表和行,而是考虑数据和消息,那么Service Broker可以处理所有通信,传递和消息处理.而不是本地(在Express机器上),INSERT INTO LocalTable(datetime, temperature) VALUES (...)您在考虑以下方面:
BEGIN CONVERSATION WITH CentralServer ...;
SEND ON conversation MESSAGE TYPE [Measurement] (<datetime...><temperature ...>)
请参阅使用Service Broker而不是Replication或High Volume Contiguous Real Time ETL