SQL Serverレプリケーションが実行されていることを確認するにはどうすればよいですか？

Question

地理的に離れた2つのSQL Server 2005インスタンスがあります。重要なデータベースは、トランザクションレプリケーションを使用してプライマリの場所からセカンダリに複製されます。

この複製を監視し、失敗した場合はすぐにアラートを受け取ることができる方法を探しています。

過去に、2つのインスタンス間のネットワーク接続が一定期間停止することがありました。レプリケーションが発生せず、知らなかったため、トランザクションログが爆発してディスクがいっぱいになり、プライマリデータベースも停止しました。

しばらく前にグーグルで検索した結果、 MSrepl_errors テーブルを監視し、エントリがあったときにアラートを出しましたが、これは単に機能しません。前回レプリケーションが失敗した（昨夜、したがって質問）ので、エラーが発生したのは再起動したときだけです。

他の誰かがレプリケーションを監視し、どのようにそれを行いますか？

---

わずかな追加情報：

昨夜の問題は、ログリーダーエージェントが停止し、再度起動しなかったことでした。このエージェントは、トランザクションログを読み取ってレコードをディストリビューションデータベースに格納し、セカンダリサイトでレプリケートできるようにする必要があると思います。

このエージェントはSQL Server内で実行されるため、Windowsで process が実行されていることを単純に確認することはできません。

Answer 1

マージレプリケーションの失敗に関するメールが送信されています。トランザクションレプリケーションは使用していませんが、同様のアラートを設定できると思います。

最も簡単な方法は、レプリケーションモニターを使用してセットアップすることです。

レプリケーションモニターに移動し、特定のパブリケーションを選択します。次に、[警告とエージェント]タブを選択し、使用する特定のアラートを構成します。この例では、レプリケーション：エージェント障害です。

このアラートには、電子メールを送信するジョブを実行するように応答が設定されています。ジョブは、失敗したものなどの詳細を含めるための作業も実行できます。

これは、問題をすぐに修正できるように、問題を警告するのに十分に機能します。

Answer 2

データの変更が行われていることを定期的に確認できますが、アプリケーションによっては複雑になる場合があります。

非常に定期的に更新される何らかの形式の監査トレインテーブルがある場合（つまり、メイン製品にはデータが更新または削除される all アクションをリストするベース監査テーブルがあります）両方のサーバーでそのテーブルをクエリし、返される結果が同じであることを確認します。次のようなもの：

SELECT CHECKSUM_AGG(*) 
FROM   audit_base 
WHERE  action_timestamp BETWEEN <time1> AND BETWEEN <time2> 

とは、データベースへの接続のさまざまな遅延を考慮したラウンド値です。たとえば、1時間の10時をチェックする場合、最後の1時間の開始からこの時間の開始までの項目をチェックできます。これで、どこかに送信して比較できる2つの小さな値ができました。それらが異なる場合、レプリケーションプロセスで何かが間違っている可能性があります-確認/比較がどのようなプロセスでもメールとSMSを送信して、注意が必要な問題を確認して修正するようにします。

SELECT CHECKSUM_AGG（*）を使用すると、各テーブルのデータ量が非常に少なくなるため、チェックの帯域幅使用量はわずかになります。サーバーに適用される負荷でチェックが高すぎないこと、および開いているレプリケーショントランザクションの一部である可能性があるデータをチェックしないようにする必要があります。監査証跡は、私の例ではなく数分前に遡ります）、そうでない場合は、誤報が多すぎます。

データベース構造によっては、上記の方法は実用的ではない場合があります。チェックの時間枠内で挿入専用（更新または削除なし）ではないテーブルの場合（上記の監査証跡など）、安全に比較できるものを作成し、誤報を回避することは、次の場合に複雑で費用がかかる可能性があります。実際に確実に行うことは不可能ではありません。

ローがない場合は、ローリング挿入専用テーブルを作成できます。1つの行を定期的に追加する小さなテーブル（インデックス付きタイムスタンプ列のみを含む）を使用すると、このデータは存在する以外の目的にはなりません。そのため、テーブルの更新が複製されていることを確認できます。チェックウィンドウよりも古いデータを削除できるため、テーブルが大きくなることはありません。 1つのテーブルだけをテストしても、他のすべてのテーブルが複製されている（または他のテーブルについては任意の）ことは証明されませんが、この1つのテーブルでエラーを見つけることは良い「キャナリー」です;確認します（このテーブルがレプリカで更新されていない場合、他のテーブルもおそらく更新されていません）。

この種のチェックには、レプリケーションプロセスに依存しないという利点があります。レプリケーションプロセスが例外をログに記録するのを待つのではなく、実際のデータの一部を事前にテストします。