マージ レプリケーションアーティクルの処理順序について

この記事では、マージ レプリケーションアーティクルの処理順序を理解する方法について説明します。

元の製品バージョン: SQL Server
元の KB 番号: 307356

概要

マージ エージェントは、同期プロセス中にマージ プロセスがアーティクルに変更を適用する順序を制御する特定の規則のセットに従います。

この記事では、アーティクルの処理順序が重要な理由について説明します。

詳細

アーティクルの処理順序が重要な主な理由は 2 つあります。

• 多くの場合、マージ エージェントは、最適なパフォーマンスを実現するために、特定の宣言型参照整合性 (DRI) 制約に参加するアーティクルに対する変更を処理する必要があります。 そうでない場合は、マージ エージェントが正しくない順序で試行したデータ操作言語 (DML) 操作を再試行する必要があります (つまり、親の前に子行を挿入してみてください)。

• 参照整合性を維持するためにトリガーを使用するアプリケーションでは、変更を特定の順序で送信するためにマージ エージェントが必要です。 マージ エージェントが正しくない順序で変更を送信した場合、トリガーは変更をロールバックする可能性が最も高く、変更はレプリケーション トポロジ全体に反映されません。

前述の 2 つの理由から、マージ エージェントがパートナー レプリカに変更を配信する順序が重要です。

記事の処理順序の説明を始める前に、2 つの重要な概念を理解することが重要です。 2 つの重要な概念は次のとおりです。

• 記事のニックネーム。

• 世代。

2 つの概念の説明を次に示します。

• 記事のニックネーム

  ニックネームは、レプリケーションをマージするためにマージ エージェントがアーティクル (SQL Server テーブル) を識別するために使用する整数値です。 マージ セットアップ プロセスでは、アーティクルをマージ パブリケーションに追加するときにアーティクルのニックネームが割り当てられます。 アーティクルが DRI 制約に参加する場合、マージ セットアップ プロセスは、定義された DRI 制約を反映するアーティクル ニックネームの生成を試みます。 マージ プロセスでは、FOREIGN KEY 制約 (親) によって参照されるテーブルに、参照元テーブル (子テーブル、または FOREIGN KEY 制約が定義されているテーブル) よりも小さいアーティクル ニックネームが割り当てられます。

  テーブルが DRI 制約に参加していない場合、マージ 設定プロセスでは、アーティクルをパブリケーションに追加する順序 (昇順) に基づいてアーティクルのニックネームが割り当てられます。

• Generation

世代は、特定のアーティクルに対する変更の論理グループを追跡するためにマージ エージェントが使用する整数値です。 マージ同期間の特定のレプリカで特定のアーティクルに加えられた変更はすべて、同じ世代に関連付けられます。 マージ エージェントが実行されるたびに、既存のオープン世代が閉じられ、次の一連の変更を関連付ける新しい世代が開きます。

INSERT、UPDATEs、および DELET の処理

マージ エージェントは、特定のパブリケーションのアーティクルを 2 つの異なるグループに分割します。

• マージ エージェントは、結合フィルターリレーションシップに関与せず、DRI を介して 1 つのグループにフィルターを結合するアーティクルに関連しない記事を配置します。

• マージ エージェントでは、結合フィルターリレーションシップに明示的に関与するアーティクルと、DRI を介してフィルターアーティクルを 2 つ目の個別のグループに結合するために関連するアーティクルを配置します。

マージ エージェントは、パブリケーションに定義されている各アーティクルを、上記のグループの 1 つだけに追加します。

マージ エージェントでは、グループを使用して、パブリケーションに定義されているすべてのアーティクルにUPDATEs対する 、、INSERTsおよび DELETEs の全体的な処理順序を決定します。

それぞれの 2 つのグループでは、マージ エージェントは昇順のアーティクルニックネーム順で処理INSERTsUPDATEsされ、降順のアーティクルニックネーム順で処理DELETEsされます。 まず、マージ エージェントは、特定のグループで全体DELETEsを処理し、次に UPDATEs および INSERTs (特定のグループでも) 処理します。 概念的には、マージ エージェントは、前述の 2 つのグループを前に示した順序で相互に追加します (マージされません)。 マージ エージェントは、最初のグループの処理DELETEsから始まり、2 番目のグループに処理を拡張DELETEし、2 つのグループの残りの変更が並列に処理されます。 マージ エージェントは各グループのアーティクル処理順序を保持しますが、マージ エージェントでは、2 つのグループ間で厳密なアーティクル処理順序は維持されません。 そのため、 または UPDATEのINSERT場合は、より高い記事のニックネームを持つ最初のグループからの変更が、ニックネームが低い 2 番目のグループのグループよりも先に到着する可能性があります。 逆の状況は、 に対しても発生する DELETE可能性があります。 これらの動作はどちらも設計上の動作です。

生成バッチ処理がアーティクル処理順序に及ぼす可能性のある影響

前に説明したように、世代では、同期セッション間の特定のレプリカで特定のアーティクルに対して発生する変更 (INSERTsUPDATEsおよびDELETEs) を論理的にグループ化できます。 最終的に、マージ エージェントは、2 つのレプリカ間で交換する必要がある変更を決定するときに、世代と連携します。 マージ エージェントは、同期プロセスの次の時点で共通の世代をネゴシエートします。

• サブスクライバーからパブリッシャーに変更をアップロードする前。

• パブリッシャーからサブスクライバーに変更をダウンロードする前に。

マージ エージェントでは、マージ同期のアップロードフェーズとダウンロード フェーズ中にパートナー レプリカに送信する世代を列挙するときに、この一般的な世代を出発点として使用します。

マージ エージェントは、世代をバッチで処理します。これは生成バッチとも呼ばれます。 既定では、マージ エージェントがサブスクライバーからパブリッシャーにアップロードするか、パブリッシャーからサブスクライバーにダウンロードする各世代バッチに 100 世代が含まれます。 生成バッチ サイズは、 パラメーターと -DownloadGenerationsPerBatch マージ エージェント パラメーター、またはマージ エージェント プロファイルを使用して構成できます-UploadGenerationsPerBatch。 既定のケースでは、パブリッシャー (または再パブリッシャー) とサブスクライバーの間で交換する必要がある世代が 100 を超える場合 (つまり、ダウンロードとアップロード、またはその両方) が必要な場合、マージ エージェントは複数の世代バッチを処理します。 バッチの数は、マージ エージェントが交換する必要がある世代の数と、特定のマージ セッションに対するバッチ設定ごとの生成数によって異なります。

複数の世代のバッチが交換される状況では、マージ エージェントは関連する親子の変更を 2 つの異なる世代のバッチに分割することがあります。 その場合、マージ エージェントは、関連付けられた親の変更を含む世代バッチの前に、世代バッチで子の変更を提供する可能性があります。 リパブリッシャーを使用する階層マージ トポロジでは、世代バッチ間で親子の変更を分割すると、非収束が発生する可能性があるまれな状況が 1 つあります。 非収束の詳細については、次の記事を参照してください。

SQL Serverが別の世代バッチで子世代と親世代を処理する場合の非収束。

前に説明した パラメーターと パラメーターを-DownloadGenerationsPerBatch増や-UploadGenerationsPerBatchして、世代バッチ間で親子の変更を分割しないようにすることができます。

アーティクル処理順序は、前に説明した規則に従って、特定の生成バッチで保持されます。 ただし、マージ エージェントでは、生成バッチ間でアーティクル処理順序を維持することはできません。