次の方法で共有

  • [アーティクル]

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

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

データベースの設計

  • アプリケーションの設計で、トランザクションのサイズを最小化する。

    既定では、トランザクション レプリケーションはトランザクションの境界に従って変更を反映させます。トランザクションが小さくなると、ネットワークの問題によりディストリビューション エージェントがトランザクションを再送信しなければならなくなる可能性は低くなります。エージェントがトランザクションを再送信する必要があっても、送信されるデータは少なくなります。

ディストリビュータの構成

  • ディストリビューション専用サーバーを構成する。

    リモート ディストリビュータを構成することにより、パブリッシャの処理オーバーヘッドを減らすことができます。詳細については、「ディストリビューションの構成」を参照してください。

  • ディストリビューション データベースのサイズを適切に設定する。

    システムの典型的な負荷でレプリケーションをテストし、コマンドを格納するために必要な領域を決定します。データベースが頻繁に自動拡張しなくてもコマンドを格納できるだけの大きさを備えていることを確認します。データベースのサイズの変更に関する詳細については、「ALTER DATABASE (Transact-SQL)」を参照してください。

パブリケーションの設計

  • パブリッシュされたテーブルに対してバッチ更新を行う場合は、ストアド プロシージャの実行をレプリケートする。

    バッチ更新がサブスクライバで多数の行に影響することがある場合には、パブリッシュされたテーブルをストアド プロシージャで更新することを検討して、ストアド プロシージャの実行をパブリッシュしてください。ディストリビューション エージェントは、影響を受けたすべての列に対する更新または削除を送信するのではなく、サブスクライバで同じパラメータ値を使用して同じプロシージャを実行します。詳細については、「トランザクション レプリケーションにおけるパブリッシング ストアド プロシージャの実行」を参照してください。

  • 複数のパブリケーションにアーティクルを分散する。

    -SubscriptionStreams パラメータ (このトピックで後ほど説明します) を使用できない場合は、複数のパブリケーションを作成することを検討してください。これらのパブリケーションにアーティクルを分散させると、サブスクライバに対する変更をレプリケーションで並列的に適用できます。

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

  • 同一のパブリッシャに複数のパブリケーションがある場合は、共有エージェントの代わりに独立エージェントを使用する (これはパブリケーションの新規作成ウィザードの既定の設定です)。

  • エージェントを連続して実行し、高い頻度のスケジュールにはしない。

    エージェントを連続的に実行するようにし、高い頻度のスケジュール、たとえば毎分などのスケジュールの作成を避けることで、レプリケーションのパフォーマンスが向上します。これは、エージェントが開始および停止する必要がなくなるからです。ディストリビューション エージェントを連続的に実行するように設定すると、トポロジ内で接続しているその他のサーバーに、短い待機時間で変更が反映されます。詳細については、以下を参照してください。

ディストリビューション エージェントおよびログ リーダー エージェントのパラメータ

  • ログ リーダー エージェントに対して –MaxCmdsInTran パラメータを使用する。

    –MaxCmdsInTran パラメータは、ログ リーダーがディストリビューション データベースにコマンドを書き込む際に、トランザクションにグループ化されるステートメントの最大数を指定します。このパラメータを使用すると、ログ リーダー エージェントおよびディストリビューション エージェントは、サブスクライバでコマンドを適用するときに、パブリッシャで (多数のコマンドで構成される) 大きなトランザクションを複数の小さなトランザクションに分割できます。このパラメータを指定すると、ディストリビュータでの競合を減らし、パブリッシャとサブスクライバの間の待機時間を減らすことができます。元のトランザクションはより小さな単位で適用されるため、サブスクライバは元のトランザクションが終了する前に、大きな論理パブリッシャ トランザクションの行にアクセスし、トランザクションの厳密な原子性を損なうことがあります。既定値は 0 です。この場合、パブリッシャのトランザクション境界が保護されます。このパラメータは、Oracle パブリッシャには適用されません。

  • ディストリビューション エージェントの –SubscriptionStreams パラメータを使用する。

    –SubscriptionStreams パラメータを使用すると、集計レプリケーションのスループットを大幅に向上できます。このパラメータを使用すると、単一のスレッドを使用するときに存在するトランザクション特性の多くを維持しつつ、変更のバッチをサブスクライバへの複数の接続で並列的に適用できます。いずれかの接続が実行またはコミットに失敗する場合、すべての接続が現在のバッチを中止し、エージェントは単一のストリームを使用して失敗したバッチを再試行します。この再試行フェーズが完了する前に、サブスクライバで一時的なトランザクションの不一致が発生することがあります。失敗したバッチのコミットに成功すると、サブスクライバはトランザクションの一貫性を保った状態に戻ります。

    このエージェント パラメータの値は、sp_addsubscription (Transact-SQL) の @subscriptionstreams を使用して指定できます。

  • ログ リーダー エージェントの -ReadBatchSize パラメータの値を大きくする。

    ログ リーダー エージェントとディストリビューション エージェントは、トランザクションの読み取りとコミット操作のバッチ サイズをサポートしています。バッチ サイズの既定値は 500 トランザクションです。ログ リーダー エージェントは、レプリケーション用にマークが付けられているかどうかにかかわらず、一定の数のトランザクションをログから読み取ります。多数のトランザクションがパブリケーション データベースに書き込まれているが、その中のごくわずかなサブセットだけにレプリケーションのマークが付いている場合、-ReadBatchSize パラメータでログ リーダー エージェントの読み取りバッチ サイズを増やす必要があります。このパラメータは、Oracle パブリッシャには適用されません。

  • ディストリビューション エージェントの -CommitBatchSize パラメータの値を大きくする。

    一連のトランザクションをコミットすると、一定のオーバーヘッドが生じます。より多くのトランザクションを、より低い頻度でコミットするほど、オーバーヘッドは多くのデータに分散されます。しかし、変更を適用するコストは、ログを含むディスクの最大 I/O などのその他の要因によって制限されるため、このパラメータを大きくする利点は少なくなります。さらに、検討すべきトレード オフもあります。ディストリビューション エージェントのやり直しの原因となる失敗をすべてロールバックし、多くのトランザクションを再適用する必要があります。信頼性の低いネットワークでは、値を小さくすると失敗が少なくなり、失敗が発生した場合にロールバックおよび再適用するトランザクションの数が減ります。

  • ログ リーダー エージェントの -PollingInterval パラメータの値を小さくする。

    -PollingInterval パラメータは、トランザクションをレプリケートするために、パブリッシュされたデータベースのトランザクション ログを照会する頻度を指定します。既定値は 5 秒です。この値を小さくすると、ログを呼び出す頻度は高くなります。これにより、パブリケーション データベースからディストリビューション データベースへのトランザクションの配信の待機時間を減らすことができます。しかし、待機時間を減らす必要性と、照会の頻度が高くなることによるサーバーの負荷の増加とのバランスをとる必要があります。

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