マージレプリケーションの同期が非常に遅い
サブがダウンするという予期しない問題があり（一般的なエラー、おそらく接続の問題でした）、サブを再接続したので、再同期が非常に遅くなります。約1000の変更をダウンロードし、約1時間そこに座ってから、さらに1000を追加するようです。
なぜこれがとてもゆっくりと進んでいるのでしょうか？これは数十のテーブルの1つにすぎず、月曜日（ユーザーがオンラインになることを意図しているとき）までは追いつかないように感じます。
どんな助けでもありがたいです！ありがとう！
[〜＃〜]更新[〜＃〜]
それは現在24時間以上実行されており、レコードをゆっくりと噛んでいますが、それでも非常に遅いペースです。これで、上のショットと「サブスクライバーに割り当てられたパーティションIDを使用してフィルターされた記事の変更を列挙する」が切り替わります。はい、フィルターは設置されていますが、私が最初に複製をセットアップしてから存在し、以前に問題を引き起こしたことはありません。
2回目の更新
レプリケーションモニターに移動すると、エラーが発生します。
The replication agent has not logged a progress message in 10 minutes. This might indicate an unresponsive agent or high system activity. Verify that records are being replicated to the destination and that connections to the Subscriber, Publisher, and Distributor are still active.
しかし、奇妙なのは、システムアクティビティがゼロであり、このパブリケーションで別のサブスクライバーが機能しており、同じパブリッシャーから完全に機能している同じサブスクライバーへのセカンダリレプリケーションも機能していることです。停止して再起動し、新しいスナップショットを撮って適用しようとしましたが、何も動作しないようです。ブロックされたプロセス、デッドロックを起こしているアクティブなクエリなど、確認したいと思うものはありません。
明確にするために：
- 出版物A =>サブ1：動作
- パブリケーションA =>サブ2：機能しない
- 出版物B =>サブ1：機能
- 出版物B =>サブ2：動作中
誰か助けがあれば、私はそれを感謝します。
レプリケーションに影響を与える可能性のある多くの要因があります。私が遭遇したいくつかの一般的な要因は、遅いネットワーク、ブロッキング、およびストレージの問題に関連しています。ただし、要因となる可能性があるのは、仮想ログファイルのパフォーマンスの問題です。大量のデータを使用してデータベースを初期化し、デフォルトの増加係数が設定されている場合、SQL Serverは一度に1MB、ログは一度に10％増加します。 VLF=の問題を確認するには、dbcc loginfoを実行します。このコマンドが100件を超えるレコードを返す場合、私は心配します。数千件のレコードを返す場合、パフォーマンスに大きな影響があります。このテーマについて書かれた記事はたくさんあります。基本的な修正は、すべてのデータとログファイルの自動拡張設定を適切なサイズに調整し、ログファイルを縮小して初期化して元のサイズに戻すことです。すべてのデータベースをチェックします、ディストリビューションデータベースを含みます。ディストリビューションデータベースがトランザクションを分散するのが遅い他の理由も考えられます。過去にいくつかのトランザクションレプリケーションシステムでこれを経験したことがあり、毎回これを修正することの影響に驚いていました。
出版社でのロックも疑います。レプリケーションに関係するspidを特定し、動的管理ビューsys.dm_os_waiting_tasksを使用して、これらのセッションに関係する待機を決定します。これは、これらのサブスクリプションが待機しているものを識別するのに役立ちます。