1. Oracle GoldenGate Veridataの使用 12c (12.2.1.4)
  2. パフォーマンスのチューニング

5 パフォーマンスのチューニング

大量のデータを処理する際に、パフォーマンスをモニターして改善する方法を学習します。

5.1 Oracle GoldenGate Veridataのパフォーマンスの改善

Oracle GoldenGate Veridataのパフォーマンスに影響する要因、および大容量のデータを処理する場合にパフォーマンスを改善できる方法は次のとおりです。

データベースおよびネットワークの使用

Oracle GoldenGate Veridataの2つの重要なパフォーマンス要因は、次のとおりです。

  • データがどのようにソートされるか
  • ネットワーク間でデータがどのように送信されるか

これらのパフォーマンス要因のパフォーマンス統計は、終了した比較ごとに比較レポートに出力され、ソースおよびターゲットの初回比較ステップに対して記録されます。比較レポートの使用を参照してください

ネットワークの使用

Oracle GoldenGate Veridataは、効率的なデータ転送にハッシュおよびネットワーク・メッセージ圧縮を使用することで、ネットワークの使用を自動的に最適化します。表またはファイルの平均行のサイズ(バイト)が増加すると(bytes/rowパフォーマンス統計を参照)、ハッシュで達成される圧縮率も増加します(rh bytes/rowおよびhash comp rateパフォーマンス統計を参照)。行が50バイトか1000かに関係なく、非キー値を表す場合に使用されるバイト数は12になります。そのため、表サイズの割合(バイト)が大きい行では、ネットワークを効率的に使用する傾向があります。これらと同じ理由で、行サイズに対してキー・サイズが小さいと、ネットワークの使用が効率的になります。

また、NonStopプラットフォームでは、送受信のTCP/IPバッファ・サイズをチェックします。これらは、32K (Oracle GoldenGate Veridataの場合)に設定するようにしてください。

データベース・アクセス

データベースのソート: 次の要因は、データベースのソート・アルゴリズムのパフォーマンスに影響します。

  • 比較される表の行の数
  • 表に定義される索引
  • 使用中のキー
  • データベースのチューニング方法

テストの実行後、比較のパフォーマンスに満足いかない場合は、サーバー側のソート(デフォルトのソート・タイプ)(Oracle GoldenGate Veridataサーバー自体がソートを実行)を使用すると速くなる可能性があります。

構成オプション

比較パフォーマンスの改善で考慮できるその他の要因は次のとおりです。

大きい表のパーティション化

大きいソースおよびターゲット表は、異なる行サブセットに関連付けられている行パーティションに分割できます。行パーティションでは、データのセットを並行して処理できるため、処理の時間を抑えることもできます。たとえば、一方のパーティションを今日比較し、もう一方のパーティションを明日比較できます。また、サブセット比較の結果から、表全体の同期ステータスを確認できます。

データベースからのバッチとしてのCOOS行のフェッチ

データベースからcoos行を単一行またはバッチ行としてフェッチするには、agent.propertiesにcoos.batch.fetch=trueを設定します。デフォルトでは、このプロパティはfalseに設定されます。coos行の数が多い(>10000)場合は、このプロパティを有効にしてパフォーマンスを向上させることができます。

列の除外

変更されないことが確認できる列が表に含まれている場合、またはそれらの列が同期しているかどうか重要でない場合は、それらの列を比較から除外することで、処理負荷を軽減できます。列は、比較ペアの作成または編集時に除外できます。

デルタ処理の使用

デルタ処理(Oracle GoldenGate Veridataで使用され、表またはファイルのすべての行ではなく、変更されたデルタ・ブロックのみを比較するパフォーマンス機能)を使用するように、比較ペアを構成できます。デルタ処理の詳細は、「デルタ処理の使用」を参照してください。

データベース・トランザクション分離レベルの変更

各Oracle GoldenGate Veridataエージェントでは、環境パラメータを格納するインストール・フォルダのルートに、agent.propertiesファイルがあります。これらのパラメータの1つは、database.transaction.isolationです。このプロパティでは、初回比較ステップの実行中に使用されるトランザクション分離レベルを制御します。SQL ServerおよびTeradataのデフォルト値は READ_UNCOMMITTEDです。つまり、行を選択するために発行される問合せは、他のトランザクションによって変更された行を読み取ることができますが、まだコミットされていません(ダーティ読取り)。他のトランザクションがデータを変更できないように共有ロックを発行したり、他のトランザクションのロックによってロックされることもありません。

READ UNCOMMITTEDオプションを使用する利点は、ロックによって影響されないためにデータの初期読取りが高速になることです。これの悪影響は、(トランザクションの間にデータが変更される場合があるため)多くのレコードがpossibly out-of-syncとしてラベル付けされる可能性があり、確認ステップで再度の比較が必要になることです。確認ステップで比較する行が多すぎると考える場合は、プロパティ・ファイルを編集して、database.transaction.isolationをCOMMITED (コミットされたレコードのフェッチのみを許可)に設定できます。読取り一貫性を維持するために、ロックの影響により初回比較ステップが遅くなる可能性よりも、改善する方を重視する必要があります。

ノート:

(この段階では、ダーティ読取りが許可されないため、Oracleでサポートされている値はREAD_COMMITTEDのみで、確認ステップでは常にREAD_COMMITTEDが使用されます。)

プロファイル・オプション

パフォーマンスの改善に役立つ初期および確認ステップの特定のパラメータを制御できます。

初回比較ステップのパラメータ

  • 比較する行数を制限する: 特定のジョブ・プロファイルに「入力行数の上限」パラメータを使用することで、処理でフェッチされる行数を制約できます。これにより、少ない行数を処理して、表全体がどの程度非同期か(またはそうでないか)を確認できます。結果に基づき、完全な比較を実行するか、データの再同期化のみを実行するかについて決定できます。「入力行数の上限」パラメータは、初回比較プロセスの一般パラメータです。

  • プロセスの優先度を上げる(NonStopのみ): Oracle GoldenGate Veridataエージェントに、NonStopシステムで可能な最高のプロセス優先度を割り当てます。優先度(およびプロセス名とCPU番号)は、ジョブ・プロファイルの初期および確認ステップのNonStop設定を使用して割り当てることができます。

  • 処理スレッドを増加する: デフォルトは4スレッドです。Oracle GoldenGate Veridataサーバーが実行されているマシンに多くのプロセッサがある場合は、必要に応じて「最大同時比較スレッド」パラメータの値を変更することで、同時比較を実行して、すべてのスレッドをビジー状態に維持できます。このパラメータは、初回比較プロセスの一般プロファイル設定にあります。

確認ステップのパラメータ

  • 各比較ステップを別々に実行する: デフォルトでは、Oracle GoldenGate Veridataは、初回比較および確認プロセスを同時に実行します。順に実行すると、使用するシステム・リソースが少なくなりますが、結果が得られるまで時間がかかります。この機能は、比較ステップの一般プロファイル設定の「初回比較と同時に実行」パラメータで制御します。

  • 各人ステップをスキップする: デフォルトでは、確認ステップを常に実行します。このステップは、データベースが停止した場合、またはレプリケーションでデータ変更がアクティブにレプリケートされない場合にスキップできます。確認ステップの一般プロファイル設定の「確認ステップを実行する」パラメータを使用します。

  • プロセスの優先度を上げる(NSK): Oracle GoldenGate Veridataエージェントに、NonStopシステムで可能な最高のプロセス優先度を割り当てます。優先度(およびプロセス名とCPU番号)は、ジョブ・プロファイルの初期および確認ステップのNonStop設定を使用して割り当てることができます。

接続手順

フェッチされる行のバッチ・サイズを増やしてスループットを上げてください。これを行うには、初期および確認ステップの「初回比較フェッチ・バッチ・サイズ」パラメータのサイズを増やします。

親トピック: パフォーマンスのチューニング

5.2 パフォーマンス統計

Oracle GoldenGate Veridataパフォーマンスの最も重要な2つの側面は、データベース・アクセスとネットワークの使用です。これらの側面の両方のパフォーマンス統計は、実行した比較ごとに比較レポートに出力され、ソースおよびターゲット・システムの初回比較ステップに対して記録されます。これらの統計の説明は次のとおりです。これらの統計の結果に応じて、データベース・アクセスとネットワークの使用を最適化する方法があります。

duration

フェッチされる行の処理にかかる時間。

rows fetched

データベースからフェッチされる行数。

rows/sec

1秒当たりの処理行数。

bytes fetched

処理されたバイトの合計数。

bytes/sec

1秒当たりの処理行数(バイト)。

lob chunks fetched

フェッチされたLOBデータの32Kブロックの数。

batches fetched

フェッチされた行バッチの数。デフォルトは、バッチ当たり10行です。

ipc msgs

サーバーとエージェントのプロセス間のメッセージの数。

ipc bytes

サーバーとエージェントのプロセス間で転送されるバイト数。

bytes applied

適用されたメッセージ当たりのバイト数。

lob chunks applied

ターゲット・データベースに適用される32KバイトのLOBチャンクの数。

lob fetch time duration (secs)

LOBデータのフェッチにかかる時間。

batches applied

処理されたバイトの合計数。

transaction batches

データの適用に使用するトランザクションの数。

transaction single statements

エラー・リカバリ中に適用される単一行のトランザクション数。

親トピック: パフォーマンスのチューニング