条件付き削除トラッキングによるマージレプリケーション性能の最適化

適用対象:SQL Server

この機能は、 SQL Serverの将来のバージョンで削除される予定です。 新規の開発作業ではこの機能を使用しないようにし、現在この機能を使用しているアプリケーションは修正することを検討してください。

マージレプリケーションを使うことで、レプリケーショントリガーやシステムテーブルが1つ以上の記事の削除を追跡しないことを指定できます。 この記事のこのオプションを選択すると、Publisherや他の購読者からの削除は追跡または複製されません。 このオプションは多くのアプリケーションシナリオをサポートし、削除の再現が不要または望ましい場合に最適化を提供します。 パフォーマンスは3つの点で向上しています。システムは削除のためのメタデータを保存しない。同期中に削除を列挙しない。そして削除をサブスクライバーに複製したり適用したりしない。

ダウンロード専用アーティクルを使用するためには、90RTM 以上の互換性レベルが必要になります。

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

  • 移動営業部門向けのアプリケーションには、通常、 SalesOrderHeaderSalesOrderDetail 、および Productなどのテーブルがあります。 注文は、サブスクライバーで入力され、次にパブリッシャーにレプリケートされます。パブリッシャーは、頻繁にデータを注文確定システムに送ります。 モバイル ワーカーの多くは、記憶域が制限されたハンドヘルド デバイスを使用しています。パブリッシャーで注文を受けると、サブスクライバーではこれを削除できます。 注文がシステム内ではまだアクティブであるため、削除はパブリッシャーに反映されません。

    このシナリオでは、 SalesOrderHeader および SalesOrderDetail テーブルに対して、削除は追跡されません。 Product テーブルについては、削除を追跡します。これは、パブリッシャーで製品が削除された場合、製品リストを最新に保つために削除をサブスクライバーに送信する必要があるためです。

  • アプリケーションは、 TransactionHistoryなどのテーブルに履歴データを格納できます。テーブルでは、1 年を経過したレコードを定期的に削除します。 サブスクライバーが今月のトランザクションのデータのみを受信するように、テーブルをフィルター選択することもできます。 パブリッシャーで毎月バッチで行われる古いデータの削除は、サブスクライバーとは関係がありませんが、既定では、これらを追跡および列挙します。

    このシナリオでは、バッチ処理が発生する前に、システムでの処理を停止し、アプリケーションで削除の追跡を無効にできます。 処理が完了したら、追跡を再度有効にできます。

重要

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

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