sql >> データベース >  >> RDS >> Sqlserver

DB テーブルの変更 (sql 2005) を Windows サービス (c#) に通知する方法は?

    実際、SQL 2005 の変更を検出する方法はそれほど多くありません。既にそれらのほとんどをリストしました。

    クエリ通知 .これは、SqlDependency とその派生物を強化するテクノロジです。詳細については、謎の通知 .ただし、QN は無効にするように設計されています 変更内容を積極的に通知するためではありません。何が変更されたかを知らなくても、テーブルに変更があることだけがわかります。ビジー状態のシステムでは、通知がほぼ絶え間なく来るため、これは機能しません。

    ログの読み取り .これは、トランザクション レプリケーションで使用されるものであり、変更を検出するための最も介入の少ない方法です。残念ながら、内部コンポーネントでのみ使用できます。ログ形式をなんとか理解できたとしても、問題は、ログを読むまでログを「使用中」としてマークするためにエンジンからのサポートが必要なことです。そうしないと、ログが上書きされる可能性があります。この種の特別なマーキングを実行できるのは、トランザクション レプリケーションだけです。

    データ比較 .変更を検出するには、タイムスタンプ列に依存します。また、プル ベースであり、非常に煩わしく、削除の検出に問題があります。

    アプリケーション層 .これは、アプリケーションの範囲外でデータに変更が加えられない限り、理論的には最良のオプションです。実際には、常に アプリケーションの範囲外で発生する変更。

    トリガー .最終的に、これが実行可能な唯一のオプションです。トリガーに基づくすべての変更メカニズムは同じように機能し、キューを監視するコンポーネントへの変更通知をキューに入れます。

    密結合の同期通知 (xp_cmdshell、xp_olecreate、CLR 経由、WCF による通知など) を行う提案は常にありますが、これらのスキームはすべて、根本的な欠陥があるため実際には失敗します。
    -トランザクションの一貫性とロールバックを考慮する
    - 可用性の依存関係を導入します (通知されたコンポーネントがオンラインでない限り、OLTP システムは処理を続行できません)
    - 各 DML 操作は何らかの形式の RPC 呼び出しを待機する必要があるため、パフォーマンスが低下します完了する

    トリガーが実際にリスナーに積極的に通知せず、通知をキューに入れるだけの場合は、通知キューの監視に問題があります (「キュー」とは、キューとして機能するテーブルを意味します)。監視とは、キュー内の新しいエントリを取得することを意味します。これは、チェックの頻度と変更の負荷を正しく調整し、負荷の急増に対応することを意味します。これは決して些細なことではなく、実際には非常に困難です。ただし、SQL サーバーには、変更が利用可能になるまでプルせずにブロックするセマンティクスを持つステートメントが 1 つあります。 library/ms186963.aspx">WAITFOR(RECEIVE) .つまり、サービス ブローカーです。あなたは投稿の中で何度か SSB について言及しましたが、当然のことながら、大きな未知のために SSB を展開することを恐れています。しかし、実際には、あなたが説明したタスクにはこれが最も適しています。

    完全な SSB アーキテクチャをデプロイする必要はありません。この場合、通知はリモート サービスまでずっと配信されます (これには、とにかくリモート SQL インスタンスが必要であり、Express インスタンスであっても必要です)。共犯する必要があるのは、変更が検出された瞬間 (DML トリガー) と、通知が配信された瞬間 (変更がコミットされた後) を切り離すことだけです。このために必要なのは、ローカルの SSB キューとサービスだけです。トリガーで 送信 ローカル サービスへの変更通知。元の DML トランザクションがコミットされた後、サービス プロシージャ アクティブ化 たとえば、CLR を使用して通知を配信します。 Asynchronous T-SQL .

    その道をたどる場合、高いスループットを達成するために学ぶ必要があるいくつかのトリックがあり、SSB でのメッセージの順序付き配信の概念を理解する必要があります。これらのリンクを読むことをお勧めします:

    変更を検出する手段については、SQL 2008 どうやら 新しいオプションを追加:変更データ キャプチャと変更追跡 .これらは実際には新しい技術ではないため、「明らかに」を強調します。 CDC はログ リーダーを使用し、既存のトランザクション レプリケーション メカニズムに基づいています。 CT はトリガーを使用し、既存の Merge レプリケーション メカニズムに非常に似ています。どちらも時々接続することを目的としています 同期する必要があるため、リアルタイムの変更通知に適していないシステム。彼らは変更テーブルにデータを入力することができますが、これらのテーブルの変更を監視するタスクが残されています。これはまさにあなたが始めたところからです。



    1. SSRS サブスクリプション ファイル名と日付

    2. 逆SQLSELECT-日付範囲の間にコールドコールを行わなかったスタッフを検索します

    3. MYSQL:ifステートメントを使用したプロシージャ

    4. djangoでdb整合性制約を一時的に無効にするにはどうすればよいですか-postgresql