条件付き削除の追跡によるマージ レプリケーション パフォーマンスの最適化

マージ レプリケーションでは、1 つ以上のアーティクルに対する削除が、レプリケーション トリガおよびシステム テーブルにより追跡されないように指定することができます。アーティクルに対してこのオプションを指定すると、削除は、パブリッシャやサブスクライバから追跡またはレプリケートされません。このオプションは、多くのアプリケーション シナリオをサポートしたり、削除のレプリケーションが不要または望ましくない場合にパフォーマンスの最適化を行うために利用できます。パフォーマンスは、削除のメタデータを格納しない、削除を同期中に列挙しない、削除をサブスクライバにレプリケートせずサブスクライバでも適用しない、という 3 つの方法により向上します。

メモ :
ダウンロード専用アーティクルを使用するためには、90RTM 以上の互換性レベルが必要になります。詳細については、「レプリケーション トポロジにおける複数バージョンの SQL Server の使用」の「マージ パブリケーションの互換性レベル」を参照してください。

オプションはパブリケーションを作成する際に指定できます。一部の削除をレプリケートし、バッチによる削除などその他の削除はレプリケートしないことがアプリケーションで必要な場合には、オプションのオン/オフを切り替えられます。以下の例では、このオプションがどのようにアプリケーションで使用されるかを示します。

• 移動営業部門向けのアプリケーションには、通常、SalesOrderHeader、SalesOrderDetail、および Product などのテーブルがあります。注文は、サブスクライバで入力され、次にパブリッシャにレプリケートされます。パブリッシャは、頻繁にデータを注文確定システムに送ります。モバイル ワーカーの多くは、記憶域が制限されたハンドヘルド デバイスを使用しています。パブリッシャで注文を受けると、サブスクライバではこれを削除できます。注文がシステム内ではまだアクティブであるため、削除はパブリッシャに反映されません。
  このシナリオでは、SalesOrderHeader および SalesOrderDetail テーブルに対して、削除は追跡されません。Product テーブルについては、削除を追跡します。これは、パブリッシャで製品が削除された場合、製品リストを最新に保つために削除をサブスクライバに送信する必要があるためです。
• アプリケーションは、TransactionHistory などのテーブルに履歴データを格納できます。テーブルでは、1 年を経過したレコードを定期的に削除します。サブスクライバが今月のトランザクションのデータのみを受信するように、テーブルをフィルタ選択することもできます。パブリッシャで毎月バッチで行われる古いデータの削除は、サブスクライバとは関係がありませんが、既定では、これらを追跡および列挙します。
  このシナリオでは、バッチ処理が発生する前に、システムでの処理を停止し、アプリケーションで削除の追跡を無効にできます。処理が完了したら、追跡を再度有効にできます。

重要 :
パブリッシャで他の処理が継続している場合は、削除の追跡が無効の間に、サブスクライバへの反映が必要な削除が発生しないようにする必要があります。

削除が追跡されないように指定するには

• レプリケーション Transact-SQL プログラミング : 削除を追跡しないように指定する方法 (レプリケーション Transact-SQL プログラミング)

参照

概念

マージ レプリケーションのアーティクルのオプション
ダウンロード専用アーティクルを使用したマージ レプリケーションのパフォーマンス最適化

ヘルプおよび情報

SQL Server 2005 の参考資料の入手