BLOB（タイプimage）を複製するためのマージパブリケーションがあり、私のデータサイズに対して非常に高いtempdbディスクI / Oを取得しました。パブリケーションはダウンロード専用であり、フィルターはありません。
高いディスクI / Oは同期によって引き起こされ（サブスクライバーが同期していない場合はすべて問題ありません）、サブスクライバーの数と強く相関しています。同期の間にパブリッシャーでデータが変更されていない場合でも発生します。
- 複製されたテーブルのサイズ：7MB（行の総数は約100）
- tempdb I / O：書き込み（ログおよびデータファイル）の場合、最大30 MB /秒
- サブスクライバーの数：100をわずかに超え、それぞれが30分ごとに（ほぼ均等に）同期しています。
- 保存期間を14日に設定
パブリッシャーではSQL Server 2008を、サブスクライバーではSQL Server 2005-2008R2を使用します。すべてのサブスクライバーはWeb同期を使用します。
さらに、サブスクライバーでの同期には多くの時間がかかり、replmerg.log次のように複数回発生します。
DatabaseReconciler, 2015/04/21 12:13:40.348, 3604, 25088, S2, INFO: [WEBSYNC_PROTOCOL] Sending client ReconcilerPhase WebSyncReconcilerPhase_RegularDownload DatabaseReconciler, 2015/04/21 12:13:47.063, 3604, 25194, S2, INFO: [WEBSYNC_PROTOCOL] Received server ReconcilerPhase WebSyncReconcilerPhase_LastRegularDownload
@stream_blob_columns効果なしで設定のオンとオフを試みた。
質問がある：それは加入者にこれらのブロブを送信するためにマージレプリケーションを使用することをお勧めしますか？tempdbの問題のない大量のデータを含む他のパブリケーション（BLOB列はありません）があります。それはSQL Serverの欠陥ですか、それとも不適切な設定ですか？
パブリッシャーとディストリビューターは同じインスタンス、SQL Server 2008 SP4上にあり、サブスクライバーについて確信が持てません。それらの一部は最新でない可能性があります。とにかく、それが役立つと思われる場合は、バージョンを制御しているサブスクライバーが少ないテスト環境を準備できます。
の実行が原因でtempdbが過度に使用されていることを確認しましたsys.sp_MSenumgenerations90。チェックされたMSMerge_genhistoryテーブル。120 万以上のレコードpubidがnull であることがわかりました。
レプリケーションの達人とのこの会話を見つけました：
sp_mergemetadataretentioncleanup影響なしに実行されます。
このようなケース（の行が多すぎるMSmerge_genhistory）について、pubidnullとgenstatus= 1の行を削除するとレプリケーションの修正に役立つというコメントが見つかりました。
pubidnullの行を削除し（すべてのサブスクライバーが同期され、同期されないことを意味します。「手動モード」で再初期化されます）、ディスクIOが再び通常に戻ります。
この状況は、すべてのサブスクライバーがWebSyncを介して匿名であり、それらのほとんどが同じホスト名を持っているという事実が原因である可能性があると感じています。-hostnameキーがでレコードを乗算しないようにするのに役立つかどうかを確認してみますMSmerge_genhistory。