SQL Server データベース テーブルと Informix データベース テーブルを同時に追加/更新/削除できるかどうか疑問に思っていました。
両方のデータベースには同じテーブル (データとすべて) があるため、クエリはどちらのデータベースに移動するかに基づいてのみ変更されます。何らかの理由で、両方のデータベース内のデータをリアルタイムで保持する必要があります。
これを SQL トリガーまたは SProc で行うことは可能ですか?
これを行う方法についての洞察、または正しい方向へのプッシュは非常に高く評価されます。
同期更新を行います。リンクサーバーを使用した分散トランザクションは、トリガーの可能性がありますが、技術的には可能ですが、絶対に反対することをお勧めします。Aaron は、一般的に XA がどれほど信頼できるかという問題を提起していますが、私の主張は異なります: 可用性です。Informix で接続および更新できない場合、SQL Server での更新は失敗します。Informix サイトのダウンタイム (パッチ適用、メンテナンス、災害は言うまでもありません) は、SQL Server サイトのダウンタイムを意味し、ファイブ ナインからナイン 5 へとかなり速く進みます...これが、更新プログラムの適用を分離することを強く推奨する理由です。トランザクション レプリケーションはそのような分離の例であり、異種環境をサポートします (つまり、変更を受け入れる Informix クライアント ダウンストリーム)。
更新の可視性に遅延が生じます (SQL Server の状態は、ミリ秒、秒、分、場合によっては数時間の遅延の後に Informix に反映されます)。また、更新は一方向であり、Informix から SQL Server に戻ることはありません。しかし、異機種混在環境でマスター マスター レプリケーションを行うことは、Chuck Norris でさえ試みようとはしないでしょう。
1 つのトランザクションで 2 つの異なる DBMS を維持するには、トランザクションを調整する XA システムなどのトランザクション モニターが必要です。そのようなシステムがあります。XA 仕様は、通常、基礎となる標準です。Microsoft の SQL Server と IBM の Informix の両方がこのようなシステムで動作し、SQL Server と Informix を同じトランザクション モニターで制御することができます。そのようなシステムの技術的能力については、回答した他の人よりも不安が少ないです。それがあなたに適しているかどうかについての彼らの懸念を共有します。
このようなシステムは非常に重量があります。一貫性が必要な場合は、質問で説明されている単一のテーブルを変更するすべてのトランザクションで、同じ XA サービス (複数、おそらく挿入用、更新用、削除用) を使用する必要があります。さらに、同じトランザクションで他のテーブルも管理する必要がある場合は、それらのテーブルにもサービスを追加して使用する必要があります。このようなシステムの管理を困難にする傾向があるのは、この側面です。
サイトが一貫性を保つまでに遅延が生じる可能性がある複製システムを使用することは、完全な同期性を求めるよりもおそらく優れています。
絶対的な同期性が本当に必要な場合は、トランザクション モニターを使用します。
それらを正しく理解するのは困難です。すべての特殊なケースを処理するのは難しいです。そして（絶対的なシンクロニシティが必要であるという仮説の下で）それを間違って行うとコストがかかりますが、簡単です。
それは「可能」の定義に依存します。技術的には、「 2 フェーズ コミット」と呼ばれる手法を使用できます。
アイデアは、データを両方のデータベースに送信してから、データをコミットする以外にデータをコミットするために必要なすべてを実行する「準備コミット」コマンドを送信することです。準備が失敗すると、コミットも失敗します。準備が成功した場合、コミットは成功する必要があります。
素晴らしいアイデアですが、実際には機能しません。一般的なケースの 1 つは、コミットを両方のデータベースに送信し、そのうちの 1 つが途中で失われる (ネットワークの停止) ことです。めったに発生しませんが、発生した場合、一貫性のない状態になり、このステップが失敗してはならないため、クリーンアップする良い方法はありません.
したがって、私のソリューションは次のように機能します。
「サーバーXはこのレコードを見ました」と言うことができる2つの余分な列を持つ新しいテーブルにデータをロードします
サーバー X のすべてのジョブをサーバー X にコピーし、それぞれの列を更新するジョブを追加します。いつでも中止および再開できるようにジョブを記述します (つまり、ターゲット側にデータが既に存在する場合に対処できる必要があります)。
こうすることで、一貫性のあるフォールト トレラントな方法で、任意の数のサーバーにデータを配布できます。