中央のSQLServer（2008 Standardエディション）といくつかの小さな専用SQL Server（Expressエディション）を使用しています。専用の分散型SQLServer（より大きなボリューム、以下を参照）から非同期*でデータを転送し、中央のSQL Server（いくつかのレコード、基本的にはマシンへの通知と場合によっては最適化のヒント）からデータを転送するためのメカニズムを実装する必要があります。
専用のSQLServerは、物理的にテクノロジーマシンの近くに配置されており、datetime, temperature一定の間隔（数秒間隔と考えてください）でたとえば行を収集しています。1つのジョブには約500のレコードがありますが、次のジョブはすぐに続きます（マシンは、それが新しいジョブであることを認識せず、ある意味で非常に愚かであり、単に温度を継続的に収集します）。
テクノロジマシンは、中央のSQL Serverがなくても動作できる必要があり、中央のSQL Serverは、マシンにアクセスできない場合（つまり、専用のSQLエンジンにアクセスできない場合、マシンでオフになっている場合）にも動作する必要があります。つまり、ソリューションは超高速である必要はありませんが、収集されたデータが失われないという意味で堅牢である必要があります。
基本的な考え方は、収集したデータを専用のSQL Server（マシンのIDを使用して正規化された形式に前処理）から中央のSQLServerの既知のテーブルに移動することです。データ量を最小限に抑えるために、新しいデータのみを送信する必要があります。接続に問題がない場合は、専用のSQL Serverによって定期的に（たとえば1時間）転送を開始する必要があります。接続に問題がある場合は、次の1時間後にデータが送信されます。
中央のSQLServerにある別のよく知られたテーブルを使用して、専用のSQLServerエンジンの通知を送信します。このようにして、専用エンジンに（たとえば）中央SQL Serverですでに処理/アーカイブされたデータ（つまり、専用マシンのローカルデータベースからすでに削除されている可能性のあるレコードのヒント）や、中央からヒントが得られます（リアルタイムの要件ではなく、ヒントまたはその他）。ヒントは、専用のSQL Server（つまり、マシンの責任）によって収集されます。つまり、中央のSQL Serverは、よく知られているローカルテーブルのみを処理します。専用のSQLServerマシンを接続しようとはしません。
このソリューションでは、標準のメカニズム（SQLコマンド（ストアドプロシージャ経由））のみを使用し、外部ソフトウェアは使用しないでください。どのような解決策に焦点を当てるべきですか？
ありがとう、ペトル
[後で編集] SQLサーバーは同じローカルエリアネットワークにあります。