適用対象:
SQL Server
注
この機能は、 SQL Serverの将来のバージョンで削除される予定です。 新規の開発作業ではこの機能を使用しないようにし、現在この機能を使用しているアプリケーションは修正することを検討してください。
デフォルトでは、マージレプリケーションはデータの変更を行ごとに処理します。 多くの場合、この方法は適切ですが、一部の用途では関連する行を単位として処理することが不可欠です。 マージレプリケーションの論理レコード機能により、異なるテーブル内の関連する行間の関係を定義し、各行を単位として処理できるようにします。
注
論理レコード機能は単独でも、結合フィルターと組み合わせて使うこともできます。 結合フィルターの詳細については、「 Join Filters」を参照してください。 論理レコードを使用するには、パブリケーションの互換性レベルが少なくとも 90 RTM である必要があります。
以下の 3 つの関連テーブルについて考えてみます。
Customers テーブルは、このリレーションシップの親テーブルであり、主キー列 CustIDを持ちます。 Orders テーブルは、主キー列 OrderIDを持ちます。また、 Customers テーブルの CustID 列を参照する CustID 列に、外部キー制約が設定されています。 同様に、 OrderItems テーブルは主キー列 OrderItemIDを持ちます。また、 Orders テーブルの OrderID 列を参照する OrderID 列に、外部キー制約が設定されています。
この例の論理レコードは、単一の CustID 値に関連付けられている Orders テーブルのすべての行と、 Orders テーブル内の行に関連付けられている OrderItems テーブルのすべての行で構成されます。 次の図は、Customer2 の論理レコードに含まれる、3 つのテーブルのすべての行を示しています。
アーティクル間で論理レコード リレーションシップを定義するには、「 マージテーブル記事間の論理レコード関係を定義する」を参照してください。
論理レコードの利点
論理レコード機能には、2 つの主な利点があります。
データ変更が 1 つの単位として適用されます。
競合の検出および解決が、複数のテーブルの複数の行で同時に実行されます。
単位としての変更の適用
接続切断などマージ処理が中断された場合、論理レコードが使用された場合、プロセスは関連する複製変更の部分的に完了したセットをロールバックします。 たとえば、サブスクライバーが OrderID = 6 で新しい注文を追加し、 OrderItems テーブルに OrderID = 6 用の新しい 2 つの行を OrderItemID = 10 および OrderItemID = 11 で追加したとします。
OrderID = 6のOrder行が完了した後、かつOrderItems 10と11が完成する前にレプリケーションプロセスが中断され、論理レコードが使用されていない場合、OrderID = 6のOrderTotal値はOrderItems行のOrderAmount値の合計と整合しません。 論理レコードを使用する場合、OrderID = 6のOrder行は関連するOrderItemsの変更が複製されるまでコミットされません。
別のシナリオでは、論理レコードが使われていて、マージプロセスが変更を適用しているときに誰かがテーブルをクエリしている場合、ユーザーはすべてが完成するまで部分的に複製された変更を見ることができません。 例えば、レプリケーションプロセスはOrderID = 6のOrder行をアップロードしますが、ユーザーがレプリケーションプロセスがOrderItemsの行を複製する前にテーブルをクエリした場合、OrderTotalの値はOrderAmountの値の合計とは異なります。 論理レコードを使用する場合、OrderItemsの行が完成しトランザクションがユニットとしてコミットされるまでOrder行は見えません。
複数のテーブルへのコンフリクト処理の適用
2つのサブスクライバーが前のデータセットを持っている場合を考えてみましょう:
最初のサブスクライバーのユーザーは、 OrderItemID 5 の OrderAmount を 100 から 150 に変更し、 OrderID 3 の OrderTotal を 200 から 250 に変更します。
2 番目のサブスクライバーのユーザーは、 OrderItemID 6 の OrderAmount を 25 から 125 に変更し、 OrderID 3 の OrderTotal を 200 から 300 に変更します。
これらの変更が論理レコードを使わずに再現されると、異なる OrderTotal の値が競合し、そのうち1つだけが複製されます。 しかし、 OrderItems テーブル内の矛盾しない変更は競合なく複製されるため、最終的な OrderTotal 値は OrderItems の行に対して一貫性のない状態のままです。 このシナリオで論理レコードを使用すると、失われるOrdersテーブルの変更に関連付けられたOrderItemsの変更もロールバックされ、最終的なOrderTotalの値はOrderItems行を正確に集計した値になります。
論理レコードが使用される場合の競合の検出と解決に関する選択肢については、「Detecting and Resolving Conflicts in Logical Records」 (論理レコードの競合の検出および解決) を参照してください。
論理レコードを使用する際の考慮事項
論理レコードを使用するときは、以下の点に注意してください。
一般的な考慮事項
論理的記録のテーブル数はできるだけ少なく保ちましょう。 テーブルは5台以下にしましょう。
論理レコードは以下のデータ型のいずれかで列を参照することはできません:
varchar(max) および nvarchar(max)
varbinary(max)
text および ntext
image
XML
UDT
CASCADEオプションを使って公開テーブル内の外部キー関係を定義することはできません。 詳細については、「CREATE TABLE (Transact-SQL)」および「ALTER TABLE (Transact-SQL)」を参照してください。
論理関係節で使われている列は更新できません。
ビジネスロジックハンドラーやカスタムリゾルバを用いたカスタム競合解決は、論理レコードに含まれる記事にはサポートされていません。
パラメータ化されたフィルターを含む出版で論理レコードを使用する場合、各サブスクライバーにそのパーティション用のスナップショットを初期化しなければなりません。 別の方法でSubscriberを初期化すると、マージ エージェントは失敗します。 詳しくは、「パラメーター化されたフィルターを使用するマージ パブリケーションのスナップショット」をご覧ください。
論理的記録に関わる競合はConflict Viewerには表示されません。 これらの競合に関する情報を表示するには、レプリケーション ストアド プロシージャを使用します。 詳細については、「マージ パブリケーションの競合情報の表示 (レプリケーション Transact-SQL プログラミング)」を参照してください。
出版環境
パブリケーションの互換性レベルは 90 RTM 以上である必要があります。 詳細については、Replication Backward Compatibility の「Publication Compatibility Level」セクションを参照してください。
パブリケーションではネイティブ スナップショット モードを使用する必要があります。 このモードは、論理レコードをサポートしていないSQL Server Compactへのレプリケートを除き、デフォルトです。
出版側はウェブ同期を許可できません。 Web 同期の詳細については、「 Web Synchronization for Merge Replication」を参照してください。
フィルタリングされた出版物で論理レコードを使用するには:
また、事前に計算されたパーティションも使用する必要があります。 事前計算済みパーティションの要件は、論理レコードにも適用されます。 詳細については、「事前計算済みパーティションによるパラメーター化されたフィルターのパフォーマンス最適化」を参照してください。
重なりのないパラメータ化フィルターは使えません。 詳細については、「 Parameterized Row Filters」の「[パーティションのオプション] の設定」を参照してください。
出版が結合フィルターを使用している場合、論理レコード関係に関わるすべての結合フィルターに対して 、join unique key プロパティを true に設定する必要があります。 詳しくは、「 Join Filters」をご覧ください。
テーブル間のリレーションシップ
論理レコードを介して関連付けられたテーブルは、主キーと外部キーのリレーションシップを持っている必要があります。
外部鍵の制約に対して「NOT FOR REPLICATION」オプションを設定することはできません。
子テーブルは親テーブルを 1 つだけ持つことができます。
たとえば、データベース追跡の Class と Students が、次のような設計になっているとします。
この関係の3つのテーブルを論理レコードで表現することはできません。なぜなら 、ClassMembers の行は単一のプライマリキー行に関連付けられていないからです。 テーブル Classes および ClassMembers で論理レコードを形成することは可能であり、テーブル ClassMembers および Studentsで論理レコードを形成することも可能です。しかし、3 つのテーブルすべてで論理レコードを形成することはできません。
パブリケーションには循環する結合フィルター関係を含めることはできません。
Customers、Orders、OrderItemsというテーブルの例を例にすると、OrderテーブルにもOrderItemsテーブルを参照する外部キー制約がある場合、論理レコードは使用できません。
論理レコードのパフォーマンスへの影響
論理記録機能にはパフォーマンスコストが伴います。 論理レコードを使わない場合、レプリケーションエージェントは特定の記事のすべての変更を同時に処理できます。 変更は行ごとに適用されるため、変更を適用するために必要なロックやトランザクションログの要件は最小限です。
論理レコードを使用する場合、マージ エージェントは各論理レコード全体の変更を同時に処理しなければなりません。 このプロセスはマージ エージェントが行を複製するのにかかる時間に影響します。 さらに、エージェントは各論理レコードに対して個別にトランザクションを開くため、ロックの要件が増大します。