概要: SQL Server Service Broker を使用して、サテライト SQL サーバーから確実にデータを収集する必要があります。別のサテライト SQL サーバーに一種のプラグインをスムーズに接続できるプロトコルを設計する必要があります。(写真を含め、あなたの提案に基づいて質問を絞り込むつもりです。しかし、どうにかして始める必要があります。)
背景: 中央の SQL サーバー (Microsoft、SQL 2008 R2 Standard ed.) が 1 つと、運用マシンの近くに小さなサーバー (同じバージョン、Express エディション) がいくつかあります。小型サーバーは、センサーから次のように定義されたテーブルに温度を収集します。
CREATE TABLE dbo.line_sensor_values (
UTC DATETIME NOT NULL,
line_no TINYINT NOT NULL, -- line number: 1, 2, 3, etc.
sensor_no TINYINT NOT NULL, -- sensor number: 1, 2, 3, etc.
sensor_value float NULL, -- the measured value
PRIMARY KEY CLUSTERED (
UTC ASC,
line_no ASC,
sensor_no ASC
)
)
はline_no
、生産ラインの小さな SQL に対して一定です。同じテーブルが中央 SQL サーバーに作成され、小規模サーバーから一時的に物理的に切断することができます。(ご存知のように、実際の物理的な環境です。)
目標は、収集されたすべてのデータを小規模な SQL サーバーから中央のサーバーに転送することです。すべてのサーバーにテーブルが作成されています。ただし、通信相手のデータについては何も知りません。このように、データ収集を機能させるために何らかのプロトコルを設計する必要があります。再接続後またはセンサー データ収集の失敗後にどこでデータ転送を続行するかを知るために、一種のハンシェイクを設計する必要があります。
中央サーバーは、収集されたセンサー データを使用して、いくつかのタスクのファイナライズとして処理します。たとえば、特定のライン (タスクで認識されている) からの特定のセンサーのデータ ポイントを処理して、チャートを作成する必要があります。タスクは、センサー値が収集される時間間隔を認識しています。ただし、タスク データベース環境は、データの収集を伴うイベントによって同期されません。このように、UTC 間隔は、センサー データがタスクに属しているかどうかを判断する唯一の方法です。
ここでも、データ センサーのサンプリング間隔はタスクに依存せず、SQL サーバーは一時的に切断される場合があります。場合によっては、センサーが壊れているか、センサーから物理データが失われる別の理由が考えられます。ただし、UTC 時間のセンサー データがある場合は、以前の値がすべてテーブルに存在するか、存在しないことを意味します。したがって、タスクのデータが完全かどうかを知る方法は、センサーの新しいデータがあることを知ることと同じです (タスクの UTC 範囲間隔の後に生成されます)。
目標は、収集されたセンサー値が失われないことです。理想的な目標は、機能の他の特別な呼び出し (つまり、あらゆる種類のスケジューラーを介して) を必要としないことです。
既に行われたこと:
基本的にセンサーはデータを専用テーブルに挿入します(
dbo.line_sensor_values
上記以外)。トリガーはデータを取得して変換し、dbo.line_sensor_values
. つまり、サテライト マシンのテーブルは既にデータを収集しています。すでに機能しています。このトリガーまたは別の手段を使用して、Service Broker 経由でセンサー値を送信できます。タスクを実行し、中央 SQL サーバーのテーブルでセンサー データをチェックし、データが存在する場合はグラフを作成するストアド プロシージャは既に設計されており、機能します。ただし、概念の証明として手動でのみ使用されました。
Service Broker の設定は、以前に既に提案されています。しかし、この目的のための Service Broker 通信は、まだ設計も部分的なテストもされていません。
これは幅広い質問であることを理解しています。このようにして、質問を個別に分割します...
解決すべき個別の質問:
時間と経験をありがとう、Petr