次の方法で共有

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

  • [アーティクル]

このトピックで解説するガイドラインに従うことによって、アプリケーションおよびネットワーク上にある全種類のレプリケーションの全般的なパフォーマンスを向上させることができます。

サーバーおよびネットワーク

  • Microsoft SQL Server データベース エンジンに割り当てるメモリの最大容量と最小容量を設定する。
    既定では、データベース エンジンは使用できるシステム リソースに基づいて、そのメモリ要求を動的に変更します。レプリケーション作業中に使用できるメモリ容量が少なくなるのを防ぐには、min server memory オプションを使用して最小メモリ容量を設定します。オペレーティング システムによるディスクへのメモリ書き出しを防ぐために、max server memory オプションを使用して最大メモリ容量を設定することもできます。詳細については、「サーバー メモリ オプション」を参照してください。
  • データベースのデータ ファイルおよびログ ファイルを適切に配置する。レプリケーションに関係するすべてのデータベースのトランザクション ログを、別のディスク ドライブに格納します。
    データベースの格納に使用するものとは別のディスク ドライブにログ ファイルを保存することで、トランザクションの書き込みにかかる時間を節約できます。フォールト トレランスが必要な場合は、Redundant Array of Inexpensive Disks (RAID)-1 を使用して、そのドライブをミラー化できます。他のデータベース ファイルには RAID 0 または 0+1 (フォールト トレランスの必要性によって異なります) を使用してください。これは、レプリケーションを使用するかどうかとは無関係に、良い方法です。詳細については、「RAID レベルと SQL Server」を参照してください。
  • レプリケーションで使用するサーバー、特にディストリビュータにメモリを追加する。
  • マルチプロセッサ コンピュータを使用する。
    レプリケーション エージェントはサーバー上の追加プロセッサを利用できます。実行時の CPU 使用量が高いレベルにある場合、より高速の CPU または複数の CPU のインストールを検討してください。
  • 高速ネットワークを使用する。
    特にトランザクション レプリケーションでは、ネットワークがパフォーマンスの重大なボトルネックになる場合があります。サブスクライバへの変更の反映は、100 メガバイト/秒 (Mbps) 以上の高速ネットワークを使用することで大幅に高速化されます。ネットワークが低速な場合は、適切なネットワーク設定とエージェント パラメータを指定してください。詳細については、「低速ネットワークが引き起こす問題」を参照してください。

データベースの設計

  • データベース設計の推奨事項に従う。
    レプリケートされたデータベースにおけるパフォーマンス最適化の手順は、レプリケートされていないデータベースの場合と同じです。ただし、サブスクライバでインデックスを作成する場合は注意が必要です。サブスクライバの主キー列にはインデックスを作成しますが、その他の列にインデックスを作成すると、挿入、更新、および削除処理のパフォーマンスに影響する場合があります。データベース最適化の詳細については、「データベースの最適化」を参照してください。

  • READ_COMMITTED_SNAPSHOT データベース オプションを設定する。
    ユーザーの処理とレプリケーション エージェントの処理との競合を削減するには、パブリケーションおよびサブスクリプション データベースに対してこのオプションを設定します。

    ALTER DATABASE AdventureWorks
SET READ_COMMITTED_SNAPSHOT ON

    詳細については、「ALTER DATABASE (Transact-SQL)」を参照してください。

  • トリガのアプリケーション ロジックに注意する。
    サブスクライバのユーザー定義トリガ内のビジネス ロジックによって、サブスクライバへの変更のレプリケーション速度が低下する可能性があります。

    サブスクライバでトリガを使用する場合の詳細については、「NOT FOR REPLICATION を使用した制約、ID、およびトリガの制御」および「トランザクション レプリケーションに関する注意点」を参照してください。マージ レプリケーションにパブリッシュされるテーブルの参照整合性を維持する目的でトリガを使用する場合は、テーブルの処理順序を指定してマージ エージェントが必要とする再試行の回数を削減します。詳細については、「マージ アーティクルの処理順序の指定」を参照してください。

  • Large Object (LOB) データ型の使用を制限する。
    列の他のデータ型と比較して、LOB はより大きな記憶域とより多くの処理を必要とします。アプリケーションで必要でない限り、LOB 型の列をアーティクルに含めないようにしてください。text、ntext、および image の各データ型は非推奨です。LOB が必要な場合は、varchar(max)、nvarchar(max)、および varbinary(max) の各データ型を使用することをお勧めします。
    トランザクション レプリケーションの場合は、OLEDB ストリームのディストリビューション プロファイルと呼ばれるディストリビューション エージェント プロファイルの使用を検討してください。詳細については、「レプリケーション エージェント プロファイル」を参照してください。

パブリケーションの設計

  • 必要なデータのみをパブリッシュする。
    レプリケーションは簡単にセットアップできるので、実際に必要なデータ以外もパブリッシュされる傾向があります。これによって、ディストリビューション データベースとスナップショット ファイル内でリソースが余計に消費され、必要なデータに対するスループットが低下する恐れがあります。不要なテーブルのパブリッシュを避け、パブリケーションの更新頻度を低くすることを検討してください。
  • パブリケーションの設計とアプリケーションの動作により競合を最小化する。
    マージ レプリケーション、更新可能なサブスクリプションを使用したトランザクション レプリケーション、およびピア ツー ピア トランザクション レプリケーションでは、サブスクライバでデータを変更できます。マージ レプリケーションおよび更新可能なサブスクリプションを使用したトランザクション レプリケーションは、指定した行が同期中に複数のノードで更新された場合のデータの競合をサポートしています。ピア ツー ピア トランザクション レプリケーションはデータの競合をサポートしていません。データの変更はパーティション分割されます。使用するレプリケーションの種類にかかわらず、できる限りデータの変更をパーティション分割することをお勧めします。これにより、競合の検出と解決に必要な処理を減らすことができます。
    変更をパーティション分割するには、各サブスクライバにデータのサブセットをパブリッシュするか、またはアプリケーションを使用して、指定した行の変更を所定のノードに転送します。
    • マージ レプリケーションは、単一パブリケーションで、パラメータ化されたフィルタを使用したデータのサブセットのパブリッシュをサポートしています。詳細については、「パラメータ化された行フィルタ」を参照してください。
    • トランザクション レプリケーションは、複数のパブリケーションで、静的フィルタを使用したデータのサブセットのパブリッシュをサポートしています。詳細については、「パブリッシュされたデータのフィルタ選択」を参照してください。
  • 行フィルタの使用は慎重に行う。
    トランザクション パブリケーションに行フィルタを使用したアーティクルが 1 つ以上格納されている場合、ログ リーダー エージェントはトランザクション ログをスキャンする際に、テーブルの更新の影響を受ける各行にフィルタを適用する必要があります。このため、ログ リーダー エージェントのスループットが影響を受けます。
    同様に、マージ レプリケーションは、変更または削除された行を評価して、これらの行をどのサブスクライバが受け取るかを決定する必要があります。サブスクライバで要求されるデータを減らすために行フィルタを使用する場合、この処理はテーブルのすべての行をパブリッシュする場合よりも複雑になり、速度が低下する可能性があります。各サブスクライバに必要な記憶域の削減と、最高スループット達成の間でのトレードオフを慎重に検討してください。フィルタ選択の詳細については、「パブリッシュされたデータのフィルタ選択」を参照してください。

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

  • サブスクライバの数が多い場合はプル サブスクリプションを使用する。
    ディストリビューション エージェントとマージ エージェントは、プッシュ サブスクリプションの場合はディストリビュータ側で、プル サブスクリプションの場合はサブスクライバ側で実行されます。プル サブスクリプションを使用して、エージェントの処理をディストリビュータからサブスクライバに移動すると、パフォーマンスを向上させることができます。詳細については、「パブリケーションのサブスクライブ」を参照してください。
  • サブスクライバの処理が遅すぎる場合はサブスクリプションを再初期化する。
    大量の変更をサブスクライバに送信する必要があるときには、サブスクライバを新しいスナップショットで再初期化する方が、レプリケーションを使用して個々の変更を移動するよりも高速な場合があります。詳細については、「サブスクリプションの再初期化」を参照してください。
    トランザクション レプリケーションの場合は、レプリケーション モニタの [未配布のコマンド] タブに、サブスクライバにまだ配布されていないディストリビューション データベース内のトランザクションの数と、これらのトランザクションの予測配布時間が表示されます。詳細については、「サブスクリプションに関連付けられているエージェントの情報を表示し、タスクを実行する方法 (レプリケーション モニタ)」を参照してください。

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

  • 必要に応じて、データベースの利用状況が少ないときにのみスナップショット エージェントを実行する。
    スナップショット エージェントは、パブリッシャでパブリッシュされたテーブルから、ディストリビュータのスナップショット フォルダにあるファイルにデータを一括コピーします。スナップショットの生成には大量のリソースが必要となる場合があるため、利用状況が少ないときにスケジュールするのが最適です。
  • キャラクタ モードのスナップショットが必要ない場合は、ネイティブ モードのスナップショットを使用する。
    すべてのサブスクライバに対して既定のネイティブ モードのスナップショットを使用します。ただし、SQL Server 以外のサブスクライバと SQL Server 2005 Compact Edition が動作しているサブスクライバは除きます。これらのサブスクライバでは、キャラクタ モードのスナップショットを使用する必要があります。
  • パブリケーションごとに単一のスナップショット フォルダを使用する。
    スナップショットの場所に関係するパブリケーション プロパティを指定するときには、既定のスナップショット フォルダにスナップショット ファイルを生成するか、別のスナップショット フォルダに生成するか、またはその両方を選択できます。両方の場所にスナップショット ファイルを生成する場合は、スナップショット エージェントを実行するときに追加のディスク領域と処理が必要になります。
  • データベースまたはログ ファイルの格納に使用しないディストリビュータのローカル ドライブにスナップショット フォルダを配置する。
    スナップショット エージェントは、スナップショット フォルダに対してデータの順次書き込みを実行します。データベースやログ ファイルとは別のドライブにスナップショット フォルダを配置することによって、ディスク間の競合が減少し、スナップショット処理がより高速に実行されます。
  • サブスクライバにサブスクリプション データベースを作成する場合は、単純復旧モデルまたは一括ログ復旧モデルを指定する。これによって、サブスクライバでのスナップショットの適用中に実行される一括挿入のログを最小限に抑えることができます。スナップショットがサブスクリプション データベースに適用されたら、必要に応じて別の復旧モデルに変更できます (レプリケートされたデータベースでは、すべての復旧モデルを使用できます)。復旧モデルの選択の詳細については、「SQL Server での復元と復旧の概要」を参照してください。
  • 低帯域ネットワークでは、リムーバブル メディア上での代替スナップショット フォルダおよび圧縮スナップショットを使用する。
    代替スナップショット フォルダに圧縮スナップショット ファイルを格納することにより、スナップショットに必要なディスク領域を節約して、スナップショット ファイルをリムーバブル メディアに容易に移動できるようになります。
    圧縮スナップショットを使用すると、ネットワーク経由でスナップショット ファイルを移動する際のパフォーマンスが向上する場合があります。ただし、スナップショットを圧縮すると、スナップショット ファイル生成時のスナップショット エージェント、およびスナップショット ファイル適用時のディストリビューション エージェントまたはマージ エージェントで、追加の処理が必要になります。これにより、スナップショット生成が遅くなり、スナップショットを適用するための時間が延びることもあります。また、ネットワークに障害が発生した場合、圧縮スナップショットを復旧することはできません。したがって、信頼性の低いネットワークには向いていません。ネットワーク経由で圧縮スナップショットを使用するときは、これらのトレードオフを慎重に検討してください。詳細については、「スナップショット フォルダの代替位置」および「圧縮スナップショット」を参照してください。
  • サブスクリプションを手作業で初期化する。
    巨大な初期データセットを扱うようなシナリオでは、スナップショット以外の方法を使用して、サブスクリプションを初期化することをお勧めします。詳細については、「スナップショットを使用しないトランザクション サブスクリプションの初期化」および「スナップショットを使用しないマージ サブスクリプションの初期化」を参照してください。

エージェント パラメータ

  • 初期テスト、監視、またはデバッグの間を除いて、レプリケーション エージェントの冗長レベルを低く設定する。
    ディストリビューション エージェントまたはマージ エージェントの –HistoryVerboseLevel パラメータおよび –OutputVerboseLevel パラメータを低く設定します。これにより、エージェントの履歴および出力を追跡するために挿入される新しい行の数を減らすことができます。代わりに、同じ状態の既存の履歴メッセージが、新しい履歴情報に更新されます。テスト、監視、およびデバッグを行うときには、冗長レベルを高く設定して、エージェントの動作に関する情報をできるだけ多く得られるようにしてください。
  • スナップショット エージェント、マージ エージェント、およびディストリビューション エージェントの –MaxBCPThreads パラメータを使用します (コンピュータのプロセッサ数を超えるスレッド数は指定できません)。このパラメータには、スナップショットの作成および適用時に並列実行できる一括コピーの操作数を指定します。
  • ディストリビューション エージェントおよびマージ エージェントの –UseInprocLoader パラメータを使用します (パブリッシュされたテーブルに XML 列が含まれる場合、このパラメータは使用できません)。このパラメータを指定すると、スナップショットの適用時にエージェントが BULK INSERT コマンドを実行します。

エージェント パラメータは、エージェント プロファイルおよびコマンド ラインで指定できます。詳細については、以下を参照してください。

参照

概念

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

ヘルプおよび情報

SQL Server 2005 の参考資料の入手