次の方法で共有

  • [アーティクル]

マージ レプリケーション パフォーマンスの向上

「レプリケーションの全般的パフォーマンスの向上」で説明した全般的なパフォーマンスのヒントを検討した後、マージ レプリケーションに固有なこれらの項目を併せて検討してください。

データベースの設計

  • 行フィルタおよび結合フィルタ内で使用される列にインデックスを作成する。

    パブリッシュされたアーティクルに行フィルタを使用する際には、フィルタの WHERE 句で使用する各列にインデックスを作成します。インデックスがない場合、MicrosoftSQL Server は、行をパーティション内に含めるかどうかを決定するためにテーブル内の各行を読み取る必要があります。インデックスがあると、SQL Server は、含める行をすばやく見つけられます。レプリケーションがインデックスのみを基にフィルタの WHERE 句を完全に解決できる場合、最高の処理速度になります。

    また、結合フィルタで使用するすべての列に対してもインデックスを作成することが重要です。マージ エージェントは、実行時にベース テーブルを検索して、パーティションに含める親テーブルの行と関連テーブルの行を判断します。結合された列のインデックスを作成すれば、マージ エージェントを実行するたびに SQL Server がテーブルの各行を読み取る必要はなくなります。

    フィルタ選択の詳細については、「マージ レプリケーション用にパブリッシュされたデータのフィルタ選択」を参照してください。

  • Large Object (LOB) データ型を含むテーブルで、正規化を十分に行うことを検討する。

    同期が発生するとき、マージ エージェントはパブリッシャまたはサブスクライバからすべての行を読み取って転送する必要があります。行に LOB を使用する列が含まれている場合、この処理には追加のメモリ割り当てが必要となることがあり、これらの列が更新されていない場合でもパフォーマンスを低下させる可能性があります。このようなパフォーマンス低下が発生する可能性を減らすには、LOB 列を別のテーブルに置き、残りの行データとの一対一リレーションシップを使用することを検討してください。text、ntext、および image の各データ型は非推奨です。LOB が必要な場合は、varchar(max)、nvarchar(max)、および varbinary(max) の各データ型を使用することをお勧めします。

パブリケーションの設計

  • 90RTM (SQL Server 2005 以降のバージョン) のパブリケーション互換性レベルを使用する。

    1 つ以上のサブスクライバが異なるバージョンの SQL Server を使用している場合を除き、パブリケーションが SQL Server 2005 以降のバージョンのみをサポートする必要があるように指定します。これによって、パブリケーションは、新しい機能とパフォーマンスの最適化を利用できるようになります。詳細については、「レプリケーション トポロジにおける複数バージョンの SQL Server の使用」の「マージ パブリケーションの互換性レベル」を参照してください。

  • 適切なパブリケーション保有期間設定を使用する。

    パブリケーションの保有期間は、サブスクリプションが同期されるまでの最長期間を示し、この期間によって追跡メタデータを保存する期間が決定されます。この値を大きくすると、ストレージと処理のパフォーマンスが影響を受ける可能性があります。パブリケーションの保有期間の設定の詳細については、「サブスクリプションの有効期限と非アクティブ化」を参照してください。

  • パブリッシャでのみ変更されるテーブルについては、ダウンロード専用アーティクルを使用する。詳細については、「ダウンロード専用アーティクルを使用したマージ レプリケーションのパフォーマンス最適化」を参照してください。

フィルタの設計および使用方法

  • 複雑な行フィルタ句を制限する。

    フィルタ条件の複雑さを制限することにより、サブスクライバに送信する行の変更をマージ エージェントが評価するときのパフォーマンスが向上することになります。マージ行フィルタ句では、副選択の使用は避けてください。代わりに、結合フィルタの使用を検討してください。一般に結合フィルタは、他のテーブルの行フィルタ句を基に、テーブルのデータをパーティション分割するために使用すると、より効率的です。フィルタ選択の詳細については、「マージ レプリケーション用にパブリッシュされたデータのフィルタ選択」を参照してください。

  • パラメータ化されたフィルタによる事前計算済みパーティションを使用する (これは既定で使用される機能です)。詳細については、「事前計算済みパーティションによるパラメータ化されたフィルタのパフォーマンス最適化」を参照してください。

    事前計算済みパーティションでは、フィルタの動作にさまざまな制限が課せられます。アプリケーションがこれらの制限に従うことができない場合は、keep_partition_changes オプションを True に設定すると、パフォーマンスが向上します。詳細については、「パラメータ化された行フィルタ」を参照してください。

  • フィルタ選択されたデータがユーザー間で共有されていない場合は、重複しないパーティションを使用する。

    レプリケーションは、複数のパーティションまたはサブスクリプションによって共有されていないデータのパフォーマンスを最適化できます。詳細については、「パラメータ化された行フィルタ」を参照してください。

  • 複雑な結合フィルタ階層を作成しない。

    5 個以上のテーブルを使用した結合フィルタは、マージ処理中のパフォーマンスに大きく影響を与える可能性があります。5 個以上のテーブルに結合フィルタを生成するような場合には、他の方法を検討することをお勧めします。

    • テーブルのフィルタ選択で、プライマリ参照テーブル、より小さなテーブル、および変更されないテーブルは回避する。これらのテーブルは、全体をパブリケーションの一部にしてください。結合フィルタは、複数のサブスクライバの間でパーティション分割する必要があるテーブル間のみで使用することをお勧めします。詳細については、「結合フィルタ」を参照してください。

    • 結合内に多数のテーブルが存在する場合は、データベース設計の正規化の低減、またはマッピング テーブルの使用を検討する。たとえば、営業担当者が自分の担当する顧客のデータのみ必要なのに、1 人の顧客を 1 人の営業担当者に関連付けるために 6 個の結合が必要な場合は、顧客テーブルに営業担当者を識別する列を 1 つ追加することを検討してください。この営業担当者データは冗長ですが、レプリケーションのパーティション分割のパフォーマンス向上は、テーブルの正規化が低減されたコストを何らかの形で上回る可能性があります。

    • バッチにデータ変更が多数含まれている場合に事前計算済みパーティションのパフォーマンスを向上させるには、アプリケーションを慎重に設計してください。結合フィルタに含まれる親テーブル内のデータへの変更は、子テーブル内で対応する変更が生じる前に行う必要があります。

  • ロジックで許容される場合は、join_unique_key オプションに「1」を設定する。

    このパラメータを「1」に設定することによって、結合フィルタ内の親テーブルと子テーブルのリレーションシップが一対一または一対多であることが指定されます。一意性を保証する子テーブル内の列の結合についての制約がある場合にのみ、このパラメータを「1」に設定します。このパラメータを誤って「1」に設定した場合は、データの未集約が発生する可能性があります。詳細については、「結合フィルタ」を参照してください。

  • 事前計算済みパーティションを使用する場合は、多数の変更を含むバッチの実行を回避します。

    多数のデータ変更を含むバッチを実行した後でマージ エージェントを実行すると、エージェントは大きいバッチを複数の小さいバッチに分割しようとします。この処理の間に、他のマージ エージェントのプロセスがブロックされる可能性があります。バッチ内の変更の数を減らしてから、バッチとバッチの間でマージ エージェントを実行することを検討してください。この処理を実行できない場合は、パブリケーションの generation_leveling_threshold の値を大きくします。

サブスクリプションに関する注意点

マージ エージェントのパラメータ

マージ エージェントおよびそのパラメータの詳細については、「レプリケーション マージ エージェント」を参照してください。

  • プル サブスクリプションを行うすべてのサブスクライバを SQL Server 2005 以降のバージョンにアップグレードする。

    サブスクライバを SQL Server 2005 以降のバージョンにアップグレードすることにより、そのサブスクライバのサブスクリプションによって使用されるマージ エージェントが更新されます。新しい機能の多くとパフォーマンスの最適化を利用するには、SQL Server 2005 以降のバージョンのマージ エージェントが必要です。

  • サブスクリプションが高速接続を介して同期され、パブリッシャおよびサブスクライバから変更が送信される場合は、マージ エージェントに対して –ParallelUploadDownload パラメータを使用する。

    SQL Server 2005 で、新しいマージ エージェント パラメータである –ParallelUploadDownload が導入されました。このパラメータを設定することによって、マージ エージェントはパブリッシャにアップロードされた複数の変更およびサブスクライバにダウンロードされた複数の変更を並列処理できるようになります。これは、帯域幅が広いネットワークを使用している大容量環境において役立ちます。エージェント パラメータは、エージェント プロファイルおよびコマンド ラインで指定できます。詳細については、以下を参照してください。

  • 特に同期でサブスクライバにダウンロードするよりもサブスクライバからダウンロードすることが多い場合は、-MakeGenerationInterval パラメータの値を大きくすることを検討する。

  • LOB 列を含む行など、大量のデータを含むデータ行を同期すると、Web 同期から追加メモリの割り当てが要求され、パフォーマンスが低下する場合があります。この動作は、マージ エージェントから生成された XML メッセージに、大量のデータを含むデータ行が過剰に含まれている場合に発生します。マージ エージェントが Web 同期中に使用するリソースが多すぎる場合は、次のいずれかの方法を使用して、1 つのメッセージで送信される行の数を減らします。

    • マージ エージェントで低速リンク エージェント プロファイルを使用する。詳細については、「レプリケーション エージェント プロファイル」を参照してください。

    • マージ エージェントの -DownloadGenerationsPerBatch パラメータと -UploadGenerationsPerBatch パラメータの値を 10 以下に減らす。これらのパラメータの既定値は 50 です。

スナップショットに関する注意点

  • 初期スナップショットを生成する前に大きなテーブルに ROWGUIDCOL 列を作成する。

    マージ レプリケーションでは、パブリッシュされた各テーブルに ROWGUIDCOL 列が必要です。スナップショット エージェントが初期スナップショット ファイルを作成する際に ROWGUIDCOL 列があらかじめテーブルに作成されていない場合、エージェントはまず ROWGUIDCOL 列を作成し、追加しなくてはなりません。マージ レプリケーションでスナップショットを生成および適用するときのパフォーマンスを向上させるには、テーブルをパブリッシュする前に各テーブルで ROWGUIDCOL 列を作成します。列の名前は任意ですが (スナップショット エージェントは既定で rowguid を使用します)、以下のデータ型の特性を持つ必要があります。

    • UNIQUEIDENTIFIER のデータ型。

    • NEWSEQUENTIALID() または NEWID() の既定値。変更および変更の追跡の際にパフォーマンスを向上させることができるため、NEWSEQUENTIALID() の使用をお勧めします。

    • ROWGUIDCOL プロパティ セット。

    • 列の一意なインデックス。

  • スナップショットを事前に生成するか、最初の同期時にサブスクライバからスナップショットの生成および適用を要求できるようにする。

    これらのオプションの両方またはどちらかを使用して、パラメータ化されたフィルタを使用するパブリケーションに対するスナップショットを提供します。これらのオプションのどちらかを指定しないと、bcp ユーティリティではなく一連の SELECT ステートメントおよび INSERT ステートメントを使用して、サブスクリプションが初期化されます。この処理は、かなり低速で実行されます。詳細については、「パラメータ化されたフィルタを使用したマージ パブリケーションのスナップショット」を参照してください。

メンテナンスおよび監視に関する注意点

  • 必要な場合、マージ レプリケーションのシステム テーブルのインデックスを再度作成する。

    マージ レプリケーションのメンテナンスの一環として、マージ レプリケーションに関連付けられたシステム テーブル MSmerge_contents、MSmerge_genhistory、MSmerge_tombstone、MSmerge_current_partition_mappings、および MSmerge_past_partition_mappings の増大を必要に応じて確認します。定期的にこれらのテーブルのインデックスを再設定します。詳細については、「インデックスの再編成と再構築」を参照してください。

  • レプリケーション モニタの [同期の履歴] タブを使用して、同期のパフォーマンスを監視する。

    マージ レプリケーションの場合、レプリケーション モニタの [同期の履歴] タブには、同期中に処理される各アーティクルの詳細な統計情報が表示されます。この統計には、各処理フェーズ (変更のアップロードやダウンロードなど) にかかる時間などが含まれます。この情報によって、速度低下の原因となっているテーブルを特定することができます。マージ サブスクリプションのパフォーマンスに関するトラブルシューティングを、この情報から開始することをお勧めします。詳細な統計情報の表示に関する詳細については、「サブスクリプションに関連付けられているエージェントの情報を表示し、タスクを実行する方法 (レプリケーション モニタ)」を参照してください。