oracle goldengateのパフォーマンス・ベスト・プ …oracle...

Oracle Maximum Availability Architecture Oracle GoldenGateのパフォーマンス・ベスト・プラクティス

Oracle Maximum Availability Architectureベスト・プラクティスに関するホワイト・ペーパー 2013年7月

Oracle GoldenGateのパフォーマンス・ベスト・プラクティス


はじめに ...................................................................................................................................................... 3 Oracleソフトウェア ................................................................................................................................... 4 データベース構成 ...................................................................................................................................... 4

ソース・データベース ........................................................................................................................ 4 ターゲット・データベース ................................................................................................................ 8

Oracle GoldenGateの構成 ........................................................................................................................ 9 Extractの構成 ........................................................................................................................................ 9 Data Pumpの構成 ............................................................................................................................. 10 Replicatの構成 ................................................................................................................................... 13 Database File System（DBFS）の構成 ......................................................................................... 20

Oracle GoldenGateのパフォーマンスのためのデータ収集 ............................................................ 20 1. レポート・ファイルとエラー・ログ ....................................................................................... 20 2. Automatic Workload RepositoryとActive Session History .................................................. 22 3. CPUデータ ...................................................................................................................................... 23 4. I/Oデータ ........................................................................................................................................ 23 5. 統合Extract向けのStreams Performance Advisor（ソース・データベースのみ） ........ 24 6. Integrated Capture Healthcheck（ソース・データベース上の統合キャプチャ・

モードで実行中のExtractのみ） ................................................................................................. 27 Oracle GoldenGateのパフォーマンス・チューニング手法 ............................................................ 27 Oracle GoldenGateのパフォーマンス事例 ........................................................................................ 33

1. PeopleSoft Payrollの事例 ............................................................................................................ 33 2. Swingbenchの事例 ...................................................................................................................... 37

結論 ............................................................................................................................................................ 40 付録A - SPADV統計のリアルタイム表示 ............................................................................................ 42 付録B – Perlコードを使用したReplicatプロセス間での表の分割 ....................................................... 43

2


はじめに

Oracle Exadata Database MachineとOracle Maximum Availability Architecture（Oracle MAA）のベス

ト・プラクティスを戦略的に統合（Exadata MAA）することで、もっとも包括的で最善のOracle

Database可用性ソリューションが実現されます。Oracle GoldenGateはMAAの主要コンポーネントの

1つであり、迅速なプラットフォームの移行を実現する論理的なレプリケーション・ソリューション

と、停止時間をほとんど必要としないアプリケーションおよびデータベースのアップグレードを実

現するソリューションを提供します。Oracle GoldenGateは、障害耐久性を持つその他のOracle MAA

ソリューションを補完することで、Oracle Real Application Clusters（Oracle RAC）、Oracle Automatic

Storage Management（Oracle ASM）、Oracle Active Data Guardを介したオンライン保守およびロー

リング・アップグレードを可能にします。

このホワイト・ペーパーでは、Oracleデータベースで最高のパフォーマンス、管理性、単純性、安定

性を実現するためのOracle GoldenGateのベスト・プラクティス構成について説明します。また、

Oracle GoldenGateのチューニング方法論を適用することで、オラクルのMAA検証中に達成されたパ

フォーマンス・スループットの向上例もいくつか示します。Oracle以外のデータベースは本書の対象

外です。

Oracle GoldenGateのおもな構成ベスト・プラクティスは、次のとおりです。

• サプリメンタル・ログ・グループを有効化して、競合を検出する

• Oracle GoldenGate Extractを統合キャプチャ・モードに設定することで、データベースのLogMinerサーバー機能を活用し、管理を簡素化する

• バッチ化したSQLを使用して複数のReplicatプロセスをパラレル構成することで、適用パフォーマンスを向上する

インストール、共有Oracle GoldenGateファイルのDBFS構成、Oracle Real Application Clustersのサー

ビス構成を含むOracle GoldenGateの初期構成については、ホワイト・ペーパー『Oracle Exadata

Database MachineでのOracle GoldenGateの構成』を参照してください。

http://www.oracle.com/technetwork/jp/database/maa-wp-gg-oracledbm-1708092-ja.pdf

3



Oracleソフトウェア

追加された機能とパフォーマンス強化機能を活用するため、Oracle GoldenGateバージョン11.2.1以

降を使用します。Oracle GoldenGateバージョン11.2.1のExtractに対しては、Oracleデータベースとの

統合キャプチャ・モードを使用できます。ExtractはOracleデータベースのログ・マイニング・サーバー

と統合されており、データベースから論理変更レコード（LCR）形式で変更データを受信します。

Extractを構成して、ローカルまたはダウンストリームのマイニング・データベースから取得できま

す。統合キャプチャはデータベースと完全に統合されており、Oracle RAC、Oracle ASM、TDE、およ

びデータ圧縮と連携するための追加設定は不要であるため、パフォーマンスを犠牲にすることなく

設定を大幅に簡素化できます。

最新バージョンのOracle GoldenGateはMy Oracle Supportのパッチと更新版からダウンロードでき

ます。

統合キャプチャ・モードのExtractを利用するために必要なデータベース機能は、11.2.0.3以降のデー

タベース・リリースとデータベース・パッチ・バンドルで提供されています。11.2.0.3に必要な個別

のパッチ番号リストは、My Oracle Support Note 1411356.1に記載されています。また、統合キャプ

チャ・モードのExtractを使用して、バージョン10.2.0.4以降のOracleデータベースと11.2.0.3のマイニ

ング・データベースを使用したダウンストリームのマイニングから変更を取得することもできます。

データベース構成

ここでは、Oracle GoldenGateのレプリケーション環境で使用されるソース・データベースとター

ゲット・データベース向けのベスト・プラクティス構成について説明します。Extractプロセスおよ

びData Pumpプロセスの両方がソース環境で実行されており、1つ以上のReplicatプロセスがター

ゲット上で実行されているものとします。アクティブ-アクティブの双方向Oracle GoldenGate環境や

ターゲット・データベースをソース・データベースに変換するケースでは、ターゲット・データベー

スとソース・データベースの両方の構成手順を組み合わせて使用してください。

ソース・データベース

ソース・データベースに対する構成は次のとおりに実施します。

1. ARCHIVELOGモードでのデータベースの実行

Oracle GoldenGate ExtractはOracleのREDOをマイニングして、レプリケーション対象データを

探します。データベースはARCHIVELOGモードで実行する必要があります。統合キャプチャ・モー

ドでExtractを使用する場合、LogMinerサーバーはオンライン・ログ・ファイルおよびアーカイ

ブ・ログ・ファイルからREDOをマイニングします。

4


2. FORCE LOGGINGの有効化

レプリケートするセグメントに必要なREDO情報がOracle REDOログに含まれるようにするには、

必要なREDO情報の生成を妨げるNOLOGGING処理を無効にすることが重要です。

データベース全体をレプリケートする場合、データベースのFORCE LOGGINGを有効化します。

既存のFORCE LOGGINGステータスを確認します。

SQL> SELECT force_logging FROM v$database;

データベースが現在FORCE LOGGINGで実行されていない場合は、これを有効化します。

SQL> ALTER DATABASE FORCE LOGGING;

SQL> ALTER SYSTEM SWITCH LOGFILE;

NOLOGGING処理を使用してロードされたアプリケーション・データがレプリケートの対象では

ない場合もあるでしょう。このような場合、これらの表と索引を独立した表領域に分離し、要

件に応じてロギングを有効化または無効化します。はじめに、データベースのFORCE LOGGING

を無効化する必要があります。

ALTER DATABASE NO FORCE LOGGING;

ALTER TABLESPACE <tablespaces_replicated> FORCE LOGGING;

ALTER TABLESPACE <tablespace_not_replicated> NOLOGGING;

Oracle GoldenGateの構成を開始する前に、FORCE LOGGINGによるデータベースへの影響をテス

トすることが重要です。

3. 競合検出に必要なサプリメンタル・ログ・グループの作成

Oracle GoldenGateでは、ソース・データベースで更新または削除されたものと同じ行をター

ゲット・データベースで見つけるために、キー列の値をREDOにロギングする必要があります。

Oracle GoldenGateコマンドのADD SCHEMADATAを使用して、表レベルでサプリメンタル・ロ

ギングを追加します。

サプリメンタル・ログ・グループの作成について、詳しくは次のWebサイトで『Oracle GoldenGate Oracle Installation and Setup Guide』を参照してください。

http://docs.oracle.com/cd/E35209_01/doc.1121/e35957.pdf

5



4. ストリーム・プールの構成

推奨された統合キャプチャ・モードのExtractを使用する場合、データベースのシステム・グロー

バル領域（SGA）内にストリーム・プールと呼ばれるOracleメモリ領域を構成する必要がありま

す。ストリーム・プールは、LogMinerサーバーが抽出データを探してREDOログをマイニングす

る際に使用されます。（統合キャプチャ・モードではなく）クラシック・モードのExtractを使

用する場合、ストリーム・プールは必要ありません。

ストリーム・プールに必要なサイズは、次の2つの統合キャプチャ・パラメータによって決まり

ます。

• MAX_SGA_SIZEは、LogMinerサーバーが使用する共有メモリのサイズを制御します。デフォルト値は1GBであり、ほとんどの場合、この値で十分です。ピーク時のAWRレポートを監視した上で、多数のバックグラウンド・プロセスが'LogMiner reader: memory'または'LogMiner reader: buffer'を待機しており、平均待機時間が長く（5ミリ秒以上）、bg時間の割合が高い

（25%以上）場合は、MAX_SGA_SIZEを25%増やすことで抽出パフォーマンスが向上する可能性があります。たとえば、次のAWRレポートはMAX_SGA_SIZEの設定が十分でないことを示しています（バックグラウンドの待機イベント）。

イベント待機数

タイム

アウト

の割合

（%）

合計待機

時間（秒）

平均待機時間

（ミリ秒）

待機数/ トランザク

ション

bg時間の割合（%）

LogMiner preparer: memory

512,085 44 6,375 12 28.83 39.86

LogMiner reader: buffer 1,015,017 16 3,564 4 57.15 22.28

MAX_SGA_SIZEを増やしたのち、待機時間は大幅に短縮され、パフォーマンスの低下は発生しなくなりました。

イベント待機数

タイム

アウト

の割合

（%）

合計待機

時間（秒）

平均待機時間

（ミリ秒）

待機数/ トランザク

ション

bg時間の割合（%）

LogMiner reader : buffer 743,701 9 1,375 2 81.15 19.46

LogMiner preparer: memory

1,538 43 786 551 0.17 11.13

6


• parallelismは、LogMinerサーバーが使用するプロセスの数を制御します。デフォルト値は2であり、これはほとんどのワークロードに対して十分な値です。parallelismパラメータの値を増加すべきタイミングを特定するには、Streams Performance Advisor（SPADV）を使用して、すべてのLogMiner PreparerプロセスのCPUが100%に近づいているかどうかを判定します。次に、parallelismパラメータの値を1に設定してデフォルトを無視した場合の例を示します。

PATH 2 RUN_ID 59 RUN_TIME 2013-MAR-21 15:20:34 CCA Y

|<C> OGG$CAP_EXT_1A 129882 129851 57 LMR 0% 73.3% 26.7% "CPU + Wait

for CPU"

LMP (1) 0% 0% 100% "CPU + Wait for CPU" LMB 80% 0% 20% "CPU + Wait

for CPU" CAP

46.7% 0% 53.3% "CPU + Wait for CPU" |<Q>

"STREAMSADMIN"."OGG$Q_EXT_1A"

129844 0.01 0 |<A> OGG$EXT_1A 0.01 0.01 0 |<B> NO BOTTLENECK IDENTIFIED

LogMiner Preparer（LMP）プロセスはCPU 100%でピークに達していますが、データ移動チェーンに含まれる次のプロセスは、その他の負荷を処理するために十分な帯域幅を使用できる状態にあります。LogMinerビルダー（LMB）とアウトバウンドの取得プロセス（CAP）の両方で、十分なアイドル時間（それぞれ80%と46.7%）が示されています。取得プロセスのparallelismパラメータ値を増やすことで、スループットを向上し、アイドル時間を短縮できます。

PATH 2 RUN_ID 52 RUN_TIME 2013-MAR-21 15:50:35 CCA Y

|<C> OGG$CAP_EXT_1A 169413 169361 1 LMR 0% 86.7% 13.3% "" LMP (2)

6.7% 53.3%

140% "CPU + Wait for CPU" LMB 66.7% 0% 33.3% "CPU + Wait for CPU"

CAP 0% 0% 100%

"CPU + Wait for CPU" |<Q> "STREAMSADMIN"."OGG$Q_EXT_1A" 169383 0.01

0 |<A>

OGG$EXT_1A 0.01 0.01 0 |<B> NO BOTTLENECK IDENTIFIED

LogMinerプロセスが使用するCPUは140%（以前より40%増）になり、抽出速度が30%向上しています（1秒あたりのメッセージ件数169,361対129,851）。

データベースのstreams_pool_sizeパラメータを次の値に設定します。

MAX_SGA_SIZE * PARALLELISM + 25%

例：MAX_SGA_SIXEおよびparallelismに対してデフォルト値を使用している場合：

( 1GB * 1 ) + 0.25 = 1.25GB

STREAMS_POOL_SIZE = 1280M

7


5. UTL_SPADVパッケージのインストール

PL/SQLパッケージのUTL_SPADVはLogMinerサーバー・プロセスに対して、統計情報の収集および分析を行うサブプログラムを提供します。この統計情報は、CPUやI/Oなど、現在競合が発生している領域を特定するために役立ちます。

UTL_SPADVパッケージをインストールするには、Oracle GoldenGateの管理者ユーザーを使用して、ソース・データベース上で次のSQLスクリプトを実行します。

SQL> @$ORACLE_HOME/rdbms/admin/utlspadv.sql

本書の後半に、UTL_SPADVを使用したLogMinerサーバー・パフォーマンスのリアルタイム監視の完全な例を示します。

UTL_SPADVパッケージについて、詳しくは次のWebサイトで『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

http://docs.oracle.com/cd/E16338_01/appdev.112/b56262/u_spadv.htm#ARPLS883

データベース構成要件について、詳しくは次のWebサイトで『Oracle GoldenGate Oracle Installation and Setup Guide』を参照してください。


ターゲット・データベース

ターゲット・データベースに対する構成は次のとおりに実施します。

1. ARCHIVELOGモードでのデータベースの実行

ARCHIVELOGモードでのターゲット・データベースの実行は、Oracle GoldenGateの要件ではありませんが、高可用性とリカバリ能力を実現するために推奨されています。ターゲット・データベースからソース・データベースへのフェイルオーバーまたはスイッチオーバーが構成されている場合、ARCHIVELOGモードが必要になります。ソース・データベースでのリカバリ・オプションに合わせるため、ターゲット・データベースはバックアップ戦略にも含める必要があります。ソース環境で障害が発生し、不完全なリカバリが実行された場合、ターゲット・データベースでもリカバリを実行して、ソースよりも先の時点でオブジェクトがレプリケートされていないことを確認する必要があります。

2. FORCE LOGGINGの有効化

双方向でレプリケートする場合や、ときとしてソースとターゲットのロールを切り替える必要がある場合、FORCE LOGGINGを有効化して、Oracle GoldenGate Extractに必要なREDOデータの損失を防止する必要があります。

8

http://docs.oracle.com/cd/E16338_01/appdev.112/b56262/u_spadv.htm%23ARPLS883



FORCE LOGGINGを有効化する方法について、詳しくはソース・データベースの構成の項を参照してください。

3. ターゲットのSGAパラメータ

System Global Area（SGA）に含まれる共有メモリ・コンポーネントのサイズを制御するデータベース・パラメータは、データをレプリケートするソース・データベースと同様に設定します。こうすることで、不適切なメモリ・サイズ設定による予期せぬパフォーマンスの低下を回避できます。たとえば、ソース・データベースに11GBのバッファ・キャッシュが構成されている場合、2GBのバッファ・キャッシュで同じワークロードに対して同様のパフォーマンスを期待することはできません。

ソース・データベースのサブセットをレプリケートする場合は、ターゲットのSGAサイズを小さく設定できます。増加されたレポート・アプリケーションなどで、付加的なデータベース処理をターゲット・データベースで実行している場合、これに応じてSGAサイズを大きくする必要があります。

データベース構成要件について、詳しくは次のWebサイトで『Oracle GoldenGate Oracle Installation and Setup Guide』を参照してください。


Oracle GoldenGateの構成

ここでは、Extract、Data Pump、ReplicatといったOracle GoldenGateのコンポーネントに対する構

成のベスト・プラクティスについて説明します。また、Oracle RAC環境内の各種Oracle GoldenGate

ファイル（証跡ファイル、チェックポイント・ファイルなど）に使用されているDatabase File System

（DBFS）に対する推奨構成も含まれます。

Extractの構成

LogMinerサーバーに対する統合機能を利用するため、統合キャプチャ・モードのExtractを使用する

ことが推奨されています。このモードはOracle GoldenGateバージョン11.2およびOracle RDBMSバー

ジョン11.2.0.3で導入されています。統合キャプチャ・モードのExtractを使用すると、クラシック・

モードのExtractよりも多くのデータ型（基本圧縮、OLTP圧縮、Exadata Hybrid Columnar Compression

で圧縮されたデータなど）をシームレスに抽出できます。Oracle ASMに保存されたログ・ファイル

をExtractが読み取るための追加設定は必要ありません。Oracle RMANのファスト・リカバリ領域ポリ

シーによって、アーカイブ・ログがExtractで不要になるまで、このログの削除は行われません。

統合キャプチャ・モードを使用する場合、ほとんどの環境でデフォルト設定を使用できます。唯一

行うべき調整は、STREAMS_POOL_SIZEパラメータを前述のとおりに正しく設定することです。

9



以前のリリースを使用しており、クラシック・モードのExtractを使用する必要がある場合、Oracle

GoldenGateリリース11.1.1で導入されたOracle ASMの直接読取りAPIを設定することを推奨します。

この設定により、ソース・データベースからのREDOログ・ファイルの読取りパフォーマンスが向上

します。この設定に必要な最低限のデータベース・バージョンは10.2.0.5です。

クラシック・モードのExtractに対してOracle ASMの直接読取りAPIを有効化するには、Extractパラメータ・ファイルでTRANLOGOPTIONS DBLOGREADERパラメータを使用します。

Data Pumpの構成

Data Pumpのおもな役割は、Extractが作成した証跡ファイルを読み取り、ターゲット・ホストにコピーすることです。Data Pumpのパフォーマンスを改善するには、Data Pumpパラメータ・ファイルにPASSTHRUパラメータを設定します。こうすることで、Data Pumpがデータベースまたはデータ定義ファイルの表定義を検索することを防止できます。PASSTHRUパラメータは各表に固有のパラメータですが、ワイルドカードを使用してすべての表に適用することもできます。

マッピングやデータ変換の必要な表がある場合、 NOPASSTHRUパラメータを使用します。NOPASSTHRUを使用する表のリストは、PASSTHRUパラメータの前に指定する必要があります。

次に例を示します。

EXTRACT dpump_1a

USERID psft, PASSWORD ****

RMTHOST sclcfdb02, MGRPORT 8901

RMTTRAIL /home/oracle/goldengate/latest/dirdat_os/aa

REPORTCOUNT EVERY 1 MINUTES, RATE

NOPASSTHRU TABLE SOEADMIN.OPS, WHERE (OPNO < 10);

PASSTHRU TABLE SOESMALL.*;

PASSTHRUパラメータを指定したことで、Data PumpはSOESMALLスキーマに属するすべての表の処理を無視します。ただし、SOEADMIN.OPS表については通常どおりに処理します。

PASSTHRUを使用した場合とNOPASSTHRU（デフォルト）を使用した場合のData Pumpのパフォーマンス比較テストが実施され、経過時間とCPU時間の違いが明らかになりました。ワークロードはSwingbenchによるOLTPタイプのワークロードであり、トランザクションごとに約10のDML文を含み、3つの表に影響を与えます（5件の挿入と5件の更新）。合計34個の証跡ファイルが生成され、サイズは16GBに達しました。

次のグラフに、2回のテストで使用された経過時間とCPU時間（秒）の違いを示します。

10


PASSTHRUを使用した場合の経過時間の違いは6%の短縮に過ぎませんが、より大きな効果はCPU時間の削減であり、37%も減少しています。この効果は、Data Pumpによる変換やマッピングを必要とするレプリケート対象データの量によって異なります。広域ネットワークを通じたレプリケーションでは、次のベスト・プラクティスに従うことが重要です。 1. TCPBUFSIZEおよびTCPFLUSHBYTESの調整

TCPBUFSIZEとTCPFLUSHBYTESという2つのRMTHOSTパラメータは、ソース・システムからターゲット・システムに対して、Data Pumpによってネットワーク経由で送信されるネットワーク・パケットとバッファ・サイズを大きくするために非常に便利です。特に、待機時間の長いネットワークで効果を発揮します。

これらのパラメータには、10MB（10,485,760バイト）または計算値のいずれか大きい方を設定します。

適切な値を決定するには、次の手順を実行します。

a pingコマンドを使用して平均ラウンドトリップ時間（RTT）を取得します。


% ping ggsoftware.com

Pinging ggsoftware.com [192.168.116.171] with 32 bytes of data:

Reply from 192.168.116.171: bytes=32 time=31ms TTL=56


500 450 400 350 300 250 200 150 100

50 0

441

414

309

196

NOPASSTHRU

PASSTHRU

経過時間（秒） CPU時間（秒）

11




Ping statistics for 192.168.116.171:

Packets:Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 31ms, Maximum = 61ms, Average = 39ms

b 帯域幅遅延積（BDP）を計算します。

たとえば、ソースとターゲット間のネットワークが62メガビットであり、待機時間が39ミリ秒である場合、BDPは次のようになります。

BDP = (622,000,000 / 8) * 0.039 = 3,032,250bytes

c 計算結果に3をかけて、3xBDPを求めます。

3xBDP = 3,032,250 x 3 = 9,096,750

この例では結果が10MBを下回っているため、TCPBUFSIZEとTCPFLUSHBYTESに10,485,760を設定します。

これらのパラメータはData Pumpパラメータ・ファイル内に設定します。


RMTHOST target, MGRPORT 7809, TCPBUFSIZE 10485760, TCPFLUSHBYTES

10485760

Windows以外のシステムでは、通常、最大ソケット・バッファ・サイズがデフォルトで制限されています。Oracle GoldenGateのTCPBUFSIZEに設定されたバッファ・サイズを増やすには、ソース・システムとターゲット・システムで最大ソケット・バッファ・サイズを増やすように、システム管理者に依頼します。

2. 非同期ストリーム・プロトコルの有効化

Oracle GoldenGateリリース11.2以降では、非同期ネットワーク・ストリーム・プロトコルがデフォルトで有効化されています。このプロトコルはネットワークの使用率と効率を上げ、コレクタ・プロセスから送信される確認応答の数を減らしながら、ネットワーク・パケットの信頼性を維持します。これは、待機時間の長いネットワークに効果的です。このデフォルト設定を有効化したままにし、ストリームを使用することを推奨します。ストリームを無効化するための設定（RMTHOST NOSTREAMING）がData Pumpパラメータ・ファイルに含まれていない場合、ストリーム・プロトコルが使用されます。 RMTHOST STREAMINGパラメータについて、詳しくは『Oracle GoldenGate Windows and UNIXリファレンス・ガイド』を参照してください。

12


3. Data Pump圧縮の使用（ネットワーク帯域幅に制約があり、CPUに余裕がある場合）

Data Pump圧縮は、ネットワーク帯域幅が十分でない場合にのみ使用します。Data Pumpからターゲット上のコレクタ・プロセスに証跡ファイル・データが送信される前に、ソース上でデータが圧縮されます。コレクタ・プロセスは受信したデータを解凍し、解凍したデータをターゲットの証跡ファイルに書き込みます。

圧縮率は証跡ファイルに含まれるデータの種類によって異なります。たとえば、varchar2、日付、数値などのスカラー・データ型は、LOB列のデータよりも大幅に効率的に圧縮されます。

圧縮を有効化すると、ソース上の各Data Pumpプロセスとターゲット上の収集サーバー・プロセスでより多くのCPUが使用されます。

圧縮を有効化するには、Data Pumpパラメータ・ファイルにRMTHOST COMPRESSIONパラメータを設定します。

Data PumpのRMTHOST COMPRESSIONパラメータについて、詳しくは『Oracle GoldenGate Windows and UNIXリファレンス・ガイド』を参照してください。

Replicatの構成

ターゲット上で実行されるOracle GoldenGate Replicatプロセスは、証跡ファイルを読み取り、SQL

DML文を使用して、レプリケートされたオブジェクトにデータを適用します。Replicatのパフォーマ

ンスを最適化するための推奨事項は多数あります。

1. チェックポイント表の使用

Replicatは、リカバリおよび再開のため、既知のポジションを提供するチェックポイントを維持しています。デフォルトでは、このチェックポイント情報はReplicatのチェックポイント・ファイルに格納されます。さらに、チェックポイント情報をターゲット・データベースのチェックポイント表に格納すると、チェックポイント情報をReplicatトランザクション自体に含めることができます。これにより、高いレベルの保護を提供し、チェックポイント・ファイルと適用されるトランザクション間の非一貫性を防止できます。

Replicatでチェックポイント表を使用する場合、Oracle Database 10g Release 2で導入された非同期コミット機能も利用されます。この機能を使用することで、ReplicatはCOMMITを適用した直後に処理を継続できるため、パフォーマンスが向上します。チェックポイント表を使用しない場合、データベース障害によってチェックポイント・ファイルのトランザクション状態がリカバリ後のトランザクション状態とは一致しなくなるケースでの非一貫性を防止するため、ReplicatはCOMMITとともにWAITを使用します。

ターゲット・データベースにチェックポイント表を作成するには、ggsci で次のOracle GoldenGateコマンドを使用します。

13


ADD CHECKPOINTTABLE owner.table

Replicatプロセスでチェックポイント表を使用するには、GLOBALSファイルに次のパラメータを設定します。

CHECKPOINTTABLE <checkpoint_table_owner>.<checkpoint_table>

チェックポイント表の使用について、詳しくは次のWebサイトで『Oracle GoldenGate Oracle Installation and Setup Guide』の第4.9項を参照してください。


2. Replicatパラメータ・ファイルへのBATCHSQLの設定

Replicatはデフォルトでは通常モードで動作し、1度に1行ずつ変更を適用します。コミットはGROUPTRANSOPS（デフォルトは1000）の設定に応じて発行されます。したがって、デフォルトでは約1000のSQL処理後にコミットが発行されます。Replicatは、ソース・トランザクションから処理をトランザクション順に蓄積し、1つのトランザクション内のグループとしてターゲットに適用します。ソース・トランザクションの分割を避けるため、GROUPTRANSOPSに設定される値は絶対値ではなく最小値になります。Replicatはグループ内の最後のソース・トランザクションからすべての処理を受信するまで待機してから、ターゲット・トランザクションを適用します。

BATCHSQLモードを有効化すると、Replicatは同じ表、処理タイプ（挿入、更新、または削除）、列リストに影響するSQL文をまとめてバッチ化し、配列処理として適用します。配列処理を使用することで、適用速度がほとんどのケースで向上し、行あたりのCPU使用率が大幅に低下します。

たとえば、挿入のみのワークロードを通常モードのReplicatで処理した結果を次に示します（AWRレポートから抜粋）。

実行順のSQL

実行数処理行数

1実行

あた

りの

行数

経過時間

（秒）

CPU割合

（%）

I/O割合

（%） SQL ID

SQLモジュール

SQLテキスト

43,068,967 43,068,967 1.00 2,221.71 100 0 19rchjjpb3462 OGG-REP

_1A-OPEN_DATA_S

OURCE

INSERT INTO

“SOESMALL”.ORDER

1実行あたりの行数が1.00になっているため、単一行処理が実施されていることが分かります。

対照的に、OPSPERBATCH（Replicatがバッチとしてまとめる処理の数）をデフォルトの1200に

設定したBATCHSQLの使用例を示します。

14



実行順のSQL

実行数処理行数 1実行あた

りの行数経過時

間（秒） CPU割

合（%） I/O割

合（%） SQL ID

SQLモジュール

SQLテキスト

43,003 43,069,020 1,001.54 461.05 99.9 0 19rchjjpb3462 OGG-REP

_1A-OPEN_DATA_S

OURCE

INSERT INTO

“SOESMALL”.ORDER

1実行あたりの行数が1,000以上に増えており、これらの挿入に対する経過時間とCPU時間が4

分の1未満に減っています。

ほとんどの場合、OPSPERBATCHの設定はデフォルト値の1200のままにすることを推奨します。

ReplicatでBATCHSQLを有効化するには、Replicatパラメータ・ファイルにBATCHSQLパラメー

タを追加します。

BATCHSQLまたはGROUPTRANSOPSを使用すると、さまざまなトランザクションのSQL処理が、

大きなトランザクションとして1つにまとめられますが、トランザクションの順番は維持されま

す。ターゲット・トランザクションとソース・トランザクションを一致させる必要がある場合

（コミットあたりのDML数など）は、GROUPTRANSOPS=1を設定します。トランザクションが

小さい場合、これによってReplicatのパフォーマンスが制限される場合があります。

BATCHSQLとGROUPTRANSOPSについて、詳しくは次のWebサイトで『Oracle GoldenGate Windows and UNIXリファレンス・ガイド』を参照してください。


3. Replicatプロセスのパラレル化

マルチ・プロセスによってワークロードが生成される場合、1つのReplicatプロセスを使用して、生成速度と同じ速度でデータを適用することはほとんど不可能です。適用速度が遅いと、ソース・データベースとターゲット・データベース間の待機時間が長くなりますが、これは回避する必要があります。この待機時間を短くするため、複数のReplicatプロセスを構成して、別々の表に対して並列でデータを適用できます。場合によっては、単一のReplicatプロセスに適切なBATCHSQL設定を使用することで、待機時間を容認可能なレベルに抑えることができます。

複数のReplicatを構成する際に重要なのは、レプリケートされるデータのおもな特性を明らかにすることです。

15



a. （DMLを使用して）頻繁にアクセスされる表

待機時間がほぼゼロになるか、または容認可能な範囲内に収まるまで、多数のReplicat間で適用するデータを均等に分散することを推奨します。これには、頻繁に操作される表を特定する必要があります。このような表を特定するには、次の3つの方法があります。

i. 通常はOracle GoldenGateを本番環境に実装する前のテスト・フェーズで行われる作

業ですが、TESTMAPPINGSPEEDパラメータを使用してExtractを設定し、レプリケートに必要なスキーマまたは表を取得します。このパラメータを使用すると、Extractによる証跡ファイルの作成が阻止され、開発者は取得したデータの種類や量を確認し、Extract構成をテストし、ソース・データベース上のログ・ファイルに対するマイニングのオーバーヘッド・コストを特定できます。Extractを一定期間実行し、適切な量のワークロードが取得された後でExtractを停止すると、Extractレポートが作成されます。レポート・ファイルは、Oracle GoldenGateインストール・ホームのdirrptディレクトリ内に作成されます。レポートには表のリストに加えて、各表に対して実行された挿入、更新、削除の件数が含まれます。次に例を示します。

From Table PSFT.PS_PAY_LINE:

# inserts: 750720

# updates: 1501440

# deletes: 0

# discards: 0

From Table PSFT.PS_PAY_EARNINGS:

# inserts: 2352256

# updates: 4204032

# deletes: 250240

# discards: 0

From Table PSFT.PS_PAY_OTH_EARNS:

# inserts: 1901824

# updates: 1651584

# deletes: 250240

# discards: 0

16


ii. Oracle GoldenGateのSTATS EXTRACTコマンドを使用して、現在実行中のExtractプロセスに対する表の統計情報を収集します。Extractの実行中に次のスクリプトを使用し、最後の15分間の表統計を取得します。

#!/bin/bash cd <GoldenGate Install Home> ./ggsci <<!EOT > /tmp/table_stats.out stats extract ext_1a, reset

pause 60 stats extract ext_1a, total, latest

!EOT

生成された出力には、Extractが開始されてリセットが発行された後、統計が出力される前の15分間の表統計が含まれます。次に出力例を示します。

Start of Statistics at 2013-02-18 15:41:29.

Output to /u01/goldengate/latest/dirdat_os/aa:

Extracting from SOESMALL.ORDERS to SOESMALL.ORDERS:

*** Total statistics since 2013-02-18 15:11:28 ***

Total inserts 2411804.00

Total updates 2411803.00

Total deletes 0.00

Total discards 0.00

Total operations 4823607.00

*** Latest statistics since 2013-02-18 15:21:19 ***

Total inserts 224076.00

Total updates 224075.00

Total deletes 0.00

Total discards 0.00

Total operations 448151.00

iii. Oracle GoldenGateのlogdumpユーティリティを使用して、証跡ファイルから表統計

を取得します。1つ以上の証跡ファイルが作成されたら、次のコマンド例を使用して表統計を取得します。

% cd <GoldenGate installation home> % ./logdump Logdump> count detail <trail_file directory>/<trail file name>

17


ワイルドカードを使用する場合は、次のコマンドを使用します。

Logdump> count detail <trail_file_directory>/aa00000*

出力例：

SOESMALL.INVENTORIES 781788504 Partition 4

Total Data Bytes 42

Avg Bytes/Record 18614012

FieldComp 18614012

After Images

SOESMALL.ORDERS Partition 4

Total Data Bytes 1140800152

Avg Bytes/Record 98

Insert 5790864

FieldComp 5790863

After Images 11581727

SOESMALL.ORDER_ITEMS 1439690630 Partition 4

Total Data Bytes

Avg Bytes/Record 70

Insert 20567009

After Images 20567009

logdumpを使用して表のDML割合を特定する方法について、詳しくはMOS note 1301300.1を参照してください。

各表に対するDML文の合計数を使用して、複数のReplicatプロセス間で表を配分します。この処理は、付録Bに記載されたPerlコード例を使用すると簡単に実行できます。

この方法で構成するReplicatプロセスの数を決定するには、証跡ファイル読取り時のI/O競合やその他のデータベース・パフォーマンスに関する問題を引き起こすことなく、待機時間が許容範囲内に収まるまでReplicatを追加するという反復プロセスを使用します。はじめに、1つのReplicatプロセスを使用して、そのパフォーマンスを測定します。（BATCHSQLを使用した状態でも）容認可能なパフォーマンスが得られない場合、2つまたは3つのReplicatプロセスに対して表を配分し、再度、パフォーマンスをテストします。適切なパフォーマンス・レベルと待機時間に達するまで、この作業を続けます。

少数の表が大きいDML割合を占めており、各表をReplicatに配分しても十分なデータ適用速度が得られない場合は、@RANGE関数を使用して、これらの表をさらに複数のReplicatプロセス間で分割できます。

18


たとえば、1つの表を2つのReplicatプロセス間で分割するには、次のMAPパラメータを使用します。

Replicat #1：

MAP SOESMALL.ORDER_ITEMS , TARGET soesmall.ORDER_ITEMS

FILTER (@RANGE (1, 2, ORDER_ID));

Replicat #2：

MAP SOESMALL.ORDER_ITEMS , TARGET soesmall.ORDER_ITEMS

FILTER (@RANGE (2, 2, ORDER_ID));

この例では、主キー列ORDER_IDを使用して、SOESMALL.ORDER_ITEMSという表が 2つのReplicatプロセス間で分割されています。

詳しくは、次の Web サイトで『 Oracle GoldenGate Windows and UNIX Troubleshooting and Tuning Guide』を参照してください。 http://docs.oracle.com/cd/E35209_01/doc.1121/e35180.pdfb.

b. 表同士の参照整合性

データ整合性を維持するため、参照整合性関係を持つ親表と子表は同じReplicatで処理する必要があります。

ほとんどのPeopleSoft Payroll表のように、参照整合性制約に含まれない表については、それぞれのReplicatに対して負荷を均等に分散することで、簡単に複数のReplicatプロセス間で表を配分できます。

c. DDL文の処理

Replicatプロセス間でのロック競合を避けるには、レプリケート対象のオブジェクトに対して実行されるDDL文の特性を理解することが非常に重要です。DDLを適用する際は、この表に対するDMLを適用するものと同じReplicatを使用する必要があります。このようにReplicatが構成されていない場合、同じ表に対してDMLを適用している別のプロセスの終了を待機することでDDL文がタイムアウトになり、Replicatプロセスが異常終了する可能性があります。DDLが表に適用される場合は、@RANGE関数を使用したReplicat間での表分割を避けることを推奨します。DMLが適用される前にすべてのDMLが完了するかどうかを予測することは不可能です。

DDLのタイムアウト問題を緩和するには、DDL EXCLUDE/INCLUDEパラメータを使用して、ReplicatがDDLを適用できる表を指定します。

19

http://docs.oracle.com/cd/E35209_01/doc.1121/e35180.pdfb


DDL文のレプリケートについて、詳しくは次のWebサイトで『Oracle GoldenGate Oracle Installation and Setup Guide』を参照してください。


Database File System（DBFS）の構成

Oracle Exadata Database MachineまたはOracle RAC構成でOracle GoldenGateを実行する場合、Oracle GoldenGateの共有ファイル（証跡ファイル、チェックポイント・ファイル、Bounded Recoveryファイル、パラメータ・ファイル）をDatabaseファイル・システム上に配置することを推奨します。DBFSを使用すると、Cluster Ready Servicesに対する統合機能が提供されます。Cluster Ready Servicesは、Oracle RACクラスタ内の存続ノード上で自動的にDBFSファイル・システムをマウントします。これにより、必要なファイル・システムがマウントされると、Oracle GoldenGateプロセスは自動的に開始されます。

最適なパフォーマンスと可用性を得るためのDBFSの構成方法について、詳しくはホワイト・ペーパー『Oracle Exadata Database MachineでのOracle GoldenGateの構成』を参照してください。


Oracle GoldenGateのパフォーマンスのためのデータ収集

データ・レプリケーションにOracle GoldenGateを使用する場合、さまざまなパフォーマンス管理ツールが提供されています。最初にチューニングを始めるのは、遅延または待機時間（ソース・データベースでデータが作成されてから抽出までの時間）や、行変更のスループットが許容範囲を越えた場合です。Oracle GoldenGateの分離アーキテクチャでは、ソース環境とターゲット環境の両方でパフォーマンス・データを収集することが重要です。

1. レポート・ファイルとエラー・ログ

マネージャのパラメータ・ファイルに次のパラメータを定義すると、マネージャ・プロセス経由で遅延がレポートに出力されます（設定する値は容認可能な待機時間によって異なります）。

マネージャ・パラメータ・ファイル：/$GG_install_dir/dirprm/mgr.prm

LAGREPORTMINUTES 5 -- Interval at which lag is checked

LAGINFOMINUTES 5 -- Threshold at which lag is reported

LAGCRITICALMINUTES 15 -- Critical threshold reporting value

20




待機時間は、Oracle GoldenGateインストール・ディレクトリに自動作成されたggserr.logに書き込まれます（時間:分:秒形式）。

Manager for Oracle, mgr.prm: Lag for REPLICAT REP_1A is 00:00:06

(checkpoint updated 00:00:01 ago).

2011-09-30 23:48:38 WARNING OGG-00947 Oracle GoldenGate Manager for Oracle,

mgr.prm:Lag for REPLICAT REP_1B is 00:06:37 (checkpoint updated 00:00:00

ago).

2011-09-30 23:48:38 WARNING OGG-00947 Oracle GoldenGate Manager for Oracle,

mgr.prm:Lag for REPLICAT REP_1C is 00:05:23 (checkpoint updated 00:00:04

ago).

容認可能な遅延時間は、データがソース・データベースに入力されてからターゲット・データベースに表示されるまでの許容時間を指定した、合意済みの品質保証契約（SLA）によって異なります。非定型の問合せ向けのデータ・オフロードであれば30分以上の遅延が容認されるかもしれませんが、ほぼ0秒の待機時間が要求されることの多い銀行取引アプリケーションではこれは不可能です。

待機時間が許容範囲を越えた場合に、パフォーマンスのボトルネックを特定して解消するには、次のパフォーマンス・チューニング手法に従います。

• Extract、Data Pump、Replicatの各プロセスは、次の内容を含む進行中のレポート・ファイルを生成します。

• 使用されているパラメータ

• 表および列のマッピング

• 実行時のメッセージとエラー

• 実行時統計

Oracle GoldenGateのパフォーマンスを監視するには、REPORTCOUNTパラメータを使用してリアルタイム統計をレポートに出力する必要があります。

REPORTCOUNT EVERY 5 MINUTES, RATE

すべてのExtract、Data Pump、Replicatプロセスに対して、適切な時間隔（最大値は5分）をこのパラメータに設定します。レポート・ファイルには、現在の処理速度を示すエントリが含まれます。

5951537 records processed as of 2011-10-07 12:45:32 (rate 10912,delta

12095)

6685497 records processed as of 2011-10-07 12:46:32 (rate 11040,delta

12202)

21


Oracle GoldenGateプロセスのレポート・ファイルは、$GG_install_dir/dirrpt/<プロセス名>.rptにあります。

この例では、1分の間隔を空けた2つのサンプル時間隔で、Replicatによって12,095行と12,202行のレコードが適用されています。

処理速度と遅延の両方を絶え間なく監視し、Oracle GoldenGateのパフォーマンス・レベルが急変するポイントを探します。

2. Automatic Workload RepositoryとActive Session History

Automatic Workload Repository（AWR）は全般的なデータベース・パフォーマンスを特定するための優れた出発点として、ExtractやReplicatに関する問題を突き止めるための最初の兆候を提供します。AWRを使用すると、ボトルネックがデータベースの内部にあるのか、または外部にあるのかを容易に特定できます。

関連するAWRレポートを分析した後で、Active Session History（ASH）を使用してデータベース内の特定のセッション（Replicatなど）に関する詳細情報を確認します。ReplicatやExtractにはそれぞれ独自のSQLモジュールIDが割り当てられており、AWRレポートやASHレポート内での識別に使用できます。


経過時間

（秒）実行数

1実行あ

たりの

経過時

間（秒）

合計割合

（%）

CPU割合

（%））

I/O割合

（%） SQL ID

SQLモジュール

SQL テキスト

2,338.40 10,697 0.22 20.30 11.45 89.86 bkpt6p42st6dq OGG-REP

_1F2-OPE

N_DATA_SOURCE

INSERT

INTO

“PSFT”.”PS_TAX

_BAL…

1,673.20 16,896 0.10 14.53 19.63 83.02 6xxrj1pzqz5s2 OGG_REP

1A-OPEN_DATA_SO

URCE

INSERT

INTO “PSFT”.”

PS_EARI

NG”

この例でのReplicat名は、REP_1F2とREP_1Aです。

SQL モジュール名を使用して $ORACLE_HOME/rdbms/admin/ashrpti.sql を実行すると、特定のReplicatに対するASHレポートを作成できます。生成されたレポートを使用して、特定のReplicatが期待どおりのパフォーマンスを発揮しない理由を調査できます。

22


3. CPUデータ

topなどのオペレーティング・システム・ツールを使用したCPUデータの収集は、I/Oやその他のデータベース・プロセスではなく、CPUがOracle GoldenGateプロセスのボトルネックとなっているかどうかを確認するためには不可欠です。一般に、少なくとも40～50%の時間、ReplicatがCPUを使用していない場合は、レプリケートされたSQL文に対するデータベース処理やI/O処理など、何か別の制約原因があります。プロセスに含まれるそれぞれの実行スレッドを示すCPUデータを収集することが重要です。たとえば、Extractは複数のスレッドを使用しているため、プロセス全体ではなく各スレッドのCPU消費を特定することが重要です。

スレッド固有のパラメータを指定せずにtopを使用した場合の出力結果は次のようになります。 top - 12:51:02 up 182 days, 20:51, 3 users, load average:0.09, 0.14, 0.09 Cpu(s):5.7%us, 0.9%sy, 0.0%ni, 93.4%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 99060552k total, 42003164k used, 57057388k free, 1219612k buffers Swap:25165816k total, 0k used, 25165816k free, 8591940k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 76001 shaisley 20 0 739m 68m 32m R 117.7 0.1 15:06.70 /goldengate/112105/extract PARAMFILE /goldengate/112105/dirprm/ext_1a.prm

Extractプロセスは148.3%のCPUを使用しており、どのプロセス・スレッドがCPUのボトルネックとなっているのかを確認することはできません。代わりに、プロセス・スレッドを表示するパラメータを使用します（top –H）。

top - 12:51:45 up 182 days, 20:51, 3 users, load average:0.19, 0.16, 0.10 Cpu(s):6.5%us, 1.2%sy, 0.0%ni, 92.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 99060552k total, 42148560k used, 56911992k free, 1219612k buffers Swap:25165816k total, 0k used, 25165816k free, 8583880k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

76001 shaisley 20 0 739m 68m 32m R 81.8 0.1 8:32.61 /goldengate/112105/extract PARAMFILE /goldengate/112105/dirprm/ext_1a.prm 76016 shaisley 20 0 739m 68m 32m R 48.8 0.1 5:03.39 /goldengate/112105/extract PARAMFILE /goldengate/112105/dirprm/ext_1a.prm

4. I/Oデータ

iostatやoswatcherなどのオペレーティング・システム・ツールを使用したI/Oデータの収集は、I/Oボトルネックの原因を把握するために不可欠です。ソース環境に対しては、REDOログ・ファイルの読取りだけでなく、ExtractとData Pumpによる証跡ファイルの同時読取りおよび書込みを考慮に入れる必要があります。また、ターゲット環境では、Data PumpとReplicatプロセスによる証跡ファイルへの同時アクセスを監視する必要があります。通常のデータベース・チューニングと同様にデータベースI/Oを監視し、その結果をAWRおよびASHと併せて使用することで、ボトルネックを特定し、解消できます。

23


5. 統合Extract向けのStreams Performance Advisor（ソース・データベースのみ）

Streams Performance Advisor（SPADV）は、統合キャプチャ・モードのExtractによって使用されるLogMinerサーバー・プロセスの監視を可能にし、これらのプロセスのパフォーマンス情報を提供します。

SPADV統計の収集と分析にはUTL_SPADVを使用します。SPADVをインストールするには、次の手順を実行します。

a. Oracle GoldenGateの管理者として指定されたデータベース・ユーザーに対して、次の権限を付与します。 SQL> exec DBMS_STREAMS_AUTH.GRANT_ADMIN_PRIVILEGE( -

grantee => '<db user name>', grant_privileges => true);

b. ステップaで権限を付与されたユーザー名を使用して、データベースに接続します。

c. utlspadv.sqlスクリプトを実行します。 SQL> @$ORACLE_HOME/rdbms/admin/utlspadv.sql

パフォーマンスをトラブルシューティングしている間、たとえば30～60分間にわたって統計を収集することを推奨します。

15秒ごとに統計を収集するには、SQL*PlusからOracle GoldenGateの管理者ユーザーとして次のコマンドを実行します。

SQL> exec UTL_SPADV.START_MONITORING(interval=>15);

統計収集を停止するには、次のコマンドを実行します。 SQL> exec UTL_SPADV.STOP_MONITORING;

監視しているジョブが現在実行中かどうかを判定するには、次のスクリプトを実行します。 SET SERVEROUTPUT ON DECLARE

is_mon BOOLEAN; BEGIN

is_mon := UTL_SPADV.IS_MONITORING( job_name => 'STREAMS$_MONITORING_JOB', client_name => NULL);

IF is_mon=TRUE THEN DBMS_OUTPUT.PUT_LINE('The monitoring job is running.');

ELSE DBMS_OUTPUT.PUT_LINE('No monitoring job was found.'); END IF;

END; /

SPADV統計をリアルタイムで表示するためのシェル・スクリプト例は、付録Aに含まれています。

24


次に出力例を示します。 PATH 2 RUN_ID 59 RUN_TIME 2013-MAR-21 15:20:34 CCA Y |<C> OGG$CAP_EXT_1A 129882 129851 57 LMR 0% 73.3% 26.7% "CPU + Wait for CPU" LMP (1) 0% 0% 100% "CPU + Wait for CPU" LMB 80% 0% 20% "CPU + Wait for CPU" CAP 46.7% 0% 53.3% "CPU + Wait for CPU" |<Q> "STREAMSADMIN"."OGG$Q_EXT_1A" 129844 0.01 0 |<A> OGG$EXT_1A 0.01 0.01 0 |<B> NO BOTTLENECK IDENTIFIED

この出力例から、次の統計情報が明らかになります。

• LogMinerは、1秒あたり平均128,882件のメッセージを取得した。

• LogMinerの現在の待機時間は57秒である。

• 読取りサーバー（LMR）プロセスが消費した時間の割合は次のとおり

• アイドル時間：0%

• フロー制御時間（チェーン（LMP）内の次のプロセスの待機）：73.4%

• CPU待機時間：26.7%

• 準備サーバー（LMP）プロセスが消費した時間の割合は次のとおり


• フロー制御時間：0%

• CPU待機時間：100%

• ビルダー・サーバー（LMB）プロセスが消費した時間の割合は次のとおり



• CPU待機時間：20%

• 取得プロセス（CAP）セッションが消費した時間の割合は次のとおり

• アイドル時間：46.7%


• CPU待機時間：53.3%

25


いずれかのLogMinerサーバー・プロセスがパフォーマンスのボトルネックとなっている場合、SPADV

統計によってこれが明確に示されます。この例では、準備サーバー（LMP）のCPU待機がボトルネッ

クになっています。

また、一定期間の監視後に、SPADV統計の静的レポートを作成することもできます。リアルタイム

の統計表示と同様にテキスト形式でレポートを生成するか、または書式設定されたHTMLレポートと

して生成できます。

テキスト・レポートを生成するには、Oracle GoldenGateの管理者ユーザーとしてSQL*Plusで次のス

クリプトを実行します。 spool /tmp/spadv.txt begin

utl_spadv.show_stats(path_stat_table=>'STREAMS$_PA_SHOW_PATH_STAT', bgn_run_id=> 1, end_run_id=> 9999, show_legend=> TRUE);

end;

HTMLレポートを生成するには、次のスクリプトを実行します。 create or replace directory SPADVDIR as '/home/oracle/spadv_html'; grant read, write on directory SPADVDIR to <GG admin user>; set linesize 1000 echo off serveroutput on feedback off veri off; SET SERVEROUTPUT ON SIZE UNLIMITED declare

startRun number; stopRun number;

begin select max(advisor_run_id),min(advisor_run_id) into stopRun,startRun from streams$_pa_show_comp_stat;

utl_spadv.show_stats_html(directory=>'SPADVDIR', reportname=>'spadvrpt.html', comp_stat_table=>'STREAMS$_PA_SHOW_COMP_STAT',path_id=>null,

bgn_run_id=> startRun, end_run_id=> stopRun);

end; /

生成済みのレポートに対しては、SPADV統計を消去することを推奨します。 SQL> exec UTL_SPADV.STOP_MONITORING(PURGE=>TRUE);

26


6. Integrated Capture Healthcheck（ソース・データベース上の統合キャプチャ・モー

ドで実行中のExtractのみ）

Integrated Capture Healthcheck（ICHC）は、Oracle GoldenGate統合キャプチャ構成の現在のステー

タスを示すレポートです。このレポートは、次の3つのおもなセクションに分かれています。

a. 構成：Oracle GoldenGateの統合キャプチャExtractに関連する定義情報

b. 分析：ICHCによって実行されたチェックの出力結果

c. 統計：有効化された統合キャプチャ要素の統計情報

これは静的に生成されるレポートであるため、特定の時点でのステータスのみが反映されています。

コンポーネントのフローが正しく実行されていることを確認するため、数分間隔で2、3回、ヘルス

チェック・レポートを収集することを推奨します。

ヘルスチェックのダウンロードと使用法について、詳しくは次のWebサイトでMOS note 1448324.1

を参照してください。

https://support.oracle.com/oip/faces/secure/km/DocumentDisplay.jspx?id=1448324.1&h=Y

Oracle GoldenGateのパフォーマンス・チューニング手法

Oracle GoldenGate環境でパフォーマンス低下を診断するには、はじめにソース・データベースと

ターゲット・データベース間のデータ・フローを理解することが重要です。

次に、パフォーマンス・ボトルネックの原因となりうるコンポーネントを示します。

1. Oracleログ・ファイルは、レプリケーションに必要なすべてのデータを取得するExtractプロセスによって読み取られます。

2. Extractは、データのマッピングや変換がある場合はこれを実行し、証跡ファイルに書き込みます。

27

https://support.oracle.com/oip/faces/secure/km/DocumentDisplay.jspx?id=1448324.1&h=Y


3. Data Pumpは証跡ファイルを読み取り、必要に応じてデータのマッピングや変換を実行します。

4. Data Pumpがソースからターゲットへ証跡ファイルを送信し、コレクタ・プロセスがこれをリモート証跡ファイルへと書き込みます。

5. Replicatは証跡ファイルを読み取り、必要に応じてマッピングや変換を実行し、SQL文を使用してターゲット・データベースにデータを適用します。

次のワークフローでは、Oracle GoldenGateレプリケーション・アーキテクチャ内のどこで待機時間

が発生しており、その結果としてどこにパフォーマンス・ボトルネックが存在するかを特定し、こ

のボトルネックを解決する方法について説明します。パフォーマンス・チューニングは繰り返し実

行するプロセスです。環境内で何かを変更した場合は遅延を監視し、チューニング・プロセスを繰

り返す必要があります。

1. ExtractからReplicatまでの間のどこで、最初に待機時間が報告されているか

• 左側から右側へ向かって上述の手法を使用して、Oracle GoldenGateプロセスの待機時間を

確認します（ggserr.log、ggsci INFO *、LAG EXTRACT/REPLICAT）。

• 左端のプロセスの遅延が確認できたら、次のステップに移動します。

ExtractおよびData Pumpプロセスに対するggserr.logの出力例では、遅延の増加が示されています。

2011-10-01 00:47:30 INFO OGG-01026 Oracle GoldenGate Capture for Oracle, dpump_1a.prm:Rolling over remote file /goldengate/latest/dirdat_os/aa000031.

2011-10-01 00:47:37 WARNING OGG-00947 Oracle GoldenGate Manager for Oracle, mgr.prm:Lag for EXTRACT DPUMP_1A is 00:00:04 (checkpoint updated 00:00:02 ago).

2011-10-01 00:47:37 WARNING OGG-00947 Oracle GoldenGate Manager for Oracle, mgr.prm:Lag for EXTRACT EXT_1A is 00:00:21 (checkpoint updated 00:00:08 ago).

2011-10-01 00:48:37 WARNING OGG-00947 Oracle GoldenGate Manager for Oracle, mgr.prm:Lag for EXTRACT DPUMP_1A is 00:00:21 (checkpoint updated 00:00:08 ago).

2011-10-01 00:48:37 WARNING OGG-00947 Oracle GoldenGate Manager for Oracle, mgr.prm:Lag for EXTRACT EXT_1A is 00:00:27 (checkpoint updated 00:00:01 ago).

興味深いことに、Extractの遅延が大きくなるとData Pumpの遅延も大きくなっています。このこと

から、Extractの遅延を解消すれば、Data Pumpの遅延も緩和されることが予想されます。各プロセ

スのチェックポイントを最後に取得したタイミングによって、遅延の値は異なります。

28


2. Extractプロセス（Data PumpのExtractではなく）に対して待機時間が報告されている場合

a. topに示されているように、Extractプロセス（クラシックまたは統合キャプチャのExtract）

が最大CPU（90～100%）に達している場合は、追加のExtractプロセスを作成し、抽出対象

の処理をプロセス間で分割します。

次に例を示します。 top - 18:22:41 up 184 days, 3:52, 4 users, load average:1.00, 0.66, 0.37 Cpu(s):7.8%us, 1.3%sy, 0.0%ni, 90.5%id, 0.5%wa, 0.0%hi, 0.0%si, 0.0%st Mem:99060552k total, 61840724k used, 37219828k free, 3399436k buffers Swap:25165816k total, 0k used, 25165816k free, 24251384k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

79023 shaisley 20 0 697m 61m 31m R 98.8 0.1 5:17.75 /goldengate/112105/extract PARAMFILE /goldengate/112105/dirprm/ext_1a.prm 79034 shaisley 20 0 697m 61m 31m S 52.1 0.1 2:46.17 /goldengate/112105/extract PARAMFILE /goldengate/112105/dirprm/ext_1a.prm 78929 shaisley 20 0 232m 24m 14m R 38.8 0.0 2:04.78 /goldengate/112105/extract PARAMFILE /goldengate/112105/dirprm/ext_1a.prm

b. 1つ以上のLogMiner準備プロセスが最大CPU（90～100%）に達しており、LogMinerビルダー

（LMB）プロセスにアイドル時間がある場合、Extract parallelismパラメータの値を増やし

ます（詳しくは上述）。これは、topおよびSPADVを使用することで確認できます。

SPADVの例： PATH 2 RUN_ID 42 RUN_TIME 2013-MAR-21 15:16:16 CCA Y |<C> OGG$CAP_EXT_1A 125182 125147 94239 LMR 0% 80% 20% "CPU + Wait for CPU" LMP (1) 0% 0% 100% "CPU + Wait for CPU" LMB 60% 0% 40% "CPU + Wait for CPU" CAP 60% 0% 40% "CPU + Wait for CPU" |<Q> "STREAMSADMIN"."OGG$Q_EXT_1A" 125126 0.01 564 |<A> OGG$EXT_1A 0.01 0.01 0 |<B> NO BOTTLENECK IDENTIFIED

topの例： top - 15:16:09 up 71 days, 45 min, 4 users, load average:2.13, 1.39, 0.95 Cpu(s):13.8%us, 1.3%sy, 0.0%ni, 84.7%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 99060552k total, 58834488k used, 40226064k free, 2644064k buffers Swap:25165816k total, 0k used, 25165816k free, 21705628k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 86969 oracle 20 0 18.0g 520m 509m R 99.7 0.5 8:03.73

29


ora_ms02_GGS1 86955 oracle 20 0 18.1g 543m 520m R 55.7 0.6 4:33.26 ora_cp03_GGS1 87064 oracle 20 0 446m 75m 18m R 48.9 0.1 3:58.58 /goldengate/112105/extract PARAMFILE /goldengate/112105/dirprm/ext_1a.prm

LMPプロセスの識別子を確認するには、次の問合せを使用します。

SELECT spid FROM v$logmnr_process WHERE role='preparer';

c. ソース・データベース上でログ・ファイルのI/O待機時間が発生している（AWRで'log file

sequential read'が20ミリ秒を上回る）場合、高速なI/Oシステムにログ・ファイルを配置し

ます。

- Extractの遅延レポートにある現在のログ・ファイル順序番号を使用して、Extractのマイニ

ング対象がアーカイブREDOログまたはオンラインREDOログのいずれであるかを特定しま

す。該当するログ・ファイルのI/Oシステムを調整します。

d. Oracle GoldenGateの証跡ファイル・ロケーションに対してI/O待機時間が発生している場合、

パフォーマンスの高いファイル・システムに証跡ファイルを移動します。

たとえば、証跡ファイルが非DBFSストレージ上にある場合、iostatを使用すると問題を特定

できます。

30


e. 統合キャプチャのExtractを使用しており、ソース・データベースのAWRレポートで、

'LogMiner reader: buffer'または'LogMiner reader: memory'に対して大きいバックグラウン

ド待機（25%以上）が発生している場合、ExtractのMAX_SGA_SIZEパラメータの値を25%

増やします（STREAMS_POOL_SIZEに十分大きい値が設定されていることを確認してくださ

い。メモリ・サイズの正しい設定については、本書の前半を参照してください）。

AWRレポートの例を示します。

3. Data Pumpプロセスに対して待機時間が報告されている場合

a. topに示されているように、Data Pumpプロセスが最大CPU（90～100%）に達している場合、

PASSTHRUパラメータを使用することでCPU消費を低下させることができます（詳しくは前

述）。データ・マッピングのせいでCPU消費が低下しない場合は、追加のData Pumpプロセ

スを作成し、プロセス間で処理を分割します。この方法は、Data Pumpが多数の変換を実

行している場合にのみ使用します。

次にtopの出力例を示します。

b. Oracle GoldenGateの証跡ファイル・ロケーションに対してI/O待機時間が発生している場合、

パフォーマンスの高いファイル・システムに証跡ファイルを移動します。この問題はExtract

のパフォーマンスにおいても発生します。一例として、セクション2dで前述した証跡ファ

イルに対するExtractのI/O待機を参照してください。

31


c. ターゲット上のOracle GoldenGateの証跡ファイル・ロケーションに対してI/O待機時間が発

生している場合、パフォーマンスの高いファイル・システムに証跡ファイルを移動します。

この問題は、Replicatの証跡ファイル読取りパフォーマンスにおいても発生します（以下を

参照）。一例として、セクション2dで前述した証跡ファイルに対するExtractのI/O待機を参

照してください。

d. ネットワーク帯域幅や待機時間に関する問題が、オペレーティング・システム・ユーティ

リティまたはネットワーク監視ツールによって特定された場合、Data Pump圧縮の有効化

（詳しくはData Pumpの構成セクションを参照）を検討します。

4. Replicatプロセスに対して待機時間が報告されている場合

a. topに示されているように、Replicatプロセスが最大CPU（90～100%）に達している場合は、

追加のReplicatプロセスを作成し、ボトルネックが発生しているReplicatプロセスとの間で

処理を分割します（詳しくはReplicatの構成セクションを参照）。多数のデータ変換を実行

している場合、この変換をData Pumpプロセスに移行することを検討します。

b. Oracle GoldenGateの証跡ファイル・ロケーションに対してI/O待機時間が発生している場合、

パフォーマンスの高いファイル・システムに証跡ファイルを移動します。この問題はData

Pumpのパフォーマンスにおいても発生します。複数のReplicatプロセスが同じ証跡ファイ

ルを読み取るように構成されている場合、追加のData Pumpプロセスを使用することを検

討します。こうすることで、同じファイルを同時に読み取るReplicatの数が少なくなります。

一例として、セクション2dで前述した証跡ファイルに対するExtractのI/O待機を参照してく

ださい。

c. ターゲット・データベースのAWRレポートに、Replicatによる単一行処理が示されている場

合、BATCHSQLの使用を検討します。データベース内で配列処理を利用することでCPU使用

量を削減できます。

BATCHSQLを有効化していないAWRレポートの例では、単一行の処理が示されています。

対照的に、OPSPERBATCH（Replicatがバッチとしてまとめる処理数）をデフォルトの1200

に設定したBATCHSQLの使用例を示します。

32


1実行あたりの行数が1,000以上に増えており、経過時間が4分の1未満に減っています。ま

た、結果的にCPU消費も減っています（表示には含まれていません）。

d. BATCHSQLを使用しており、Replicatプロセスのデータ適用速度が十分でない場合は、パ

フォーマンスの向上を目的としたデータベース/オブジェクトのチューニング手法を検討し

ます。次のWebサイトで『Oracle® Databaseパフォーマンス・チューニング・ガイド』を

参照してください。

http://docs.oracle.com/cd/E11882_01/server.112/e16638.pdf

e. データベース/オブジェクトのチューニングで効果が得られない場合、追加のReplicatプロセ

スを構成して、パフォーマンスの低いReplicatの負担を軽減します（前述の方法を参照）。

Oracle GoldenGateのパフォーマンス事例

ここでは、本書で提示したパフォーマンス・チューニング手法を異なる2つのワークロード・タイプ

（バッチの給与支払いとOLTP）に適用した方法について説明します。それぞれのワークロードに対

して使用された方法と収集されたデータに加えて、結果として達成されたパフォーマンス向上を示

します。

これらのパフォーマンスを示す数値は正式なベンチマーク結果ではなく、各種のハードウェア・アー

キテクチャおよびソフトウェア・バージョンを使用した場合の各ワークロードに対して期待される

パフォーマンスの代表例でもありません。

1. PeopleSoft Payrollの事例

ワークロードの説明

この事例で使用するワークロードは、PeopleSoft（北米）のHR Payrollベンチマーク・キットに基づ

きます。ただし、この事例はベンチマークではありません。この事例は、最適なパフォーマンスと

スケーラビリティを実現するベスト・プラクティスを引き出すための、MAA演習として使用します。

payrollのバッチ・ワークロード部分だけを、オンライン・ユーザーなしで実行しました。次のバッ

チ・プロセスを実行しました。

• PaySheet：従業員のpayrollデータ・ワークシートを生成するCOBOLプロセス。このプロセスは約14分間実行され、27.7MB/秒の速度でREDOを生成しました。

33

http://docs.oracle.com/cd/E11882_01/server.112/e16638.pdf


• PayCalc：PaySheetを参照して、これらの従業員のチェックを計算するCOBOLプロセス。このプロセスは約15分間実行され、17MB/秒の速度でREDOを生成しました。

• PayConfirm：Payroll Calculationで生成される情報を取得し、計算額に基づき従業員の残高を更新するCOBOLプロセス。このプロセスは15～16分間実行され、17MB/秒の速度でREDOを生成しました。

これらのバッチ・プロセスは、年間支払いサイクルの最終月（12月）にpayrollを初めて実行したか

のように実行されました。実際にpayrollを初めて実行すると、通常は非常に時間がかかり、人的処

理を行うことはできません。この事例では、所定のpayrollの実行でPayCalcプロセスが反復的に実行

されることはありませんでした。PeopleSoft（北米）のPayrollキットでは、1つの会社内に128個の

支払いグループと500,000人の従業員が含まれており、11ヶ月の支払い履歴があります。

このテスト環境では、HR payrollをSINGLE CHECK = "NO"の設定で構成しました。このため、PayCalc

バッチ・プロセスで、複数の実行制御をパラレルで実行できました（32のスレッドを使用）。

環境の構成

ソース・データベースとターゲット・データベースはともに、それぞれ3つのストレージ・セルを備

えた固有のOracle Exadata Database Machine v2クォーターラック上で実行されました。

使用されたOracle Databaseのリリースは11.2.0.2であり、次の主要なデータベース・パラメータが使

用されました。

• SHARED_POOL_SIZE = 2G

• DB_CACHE_SIZE = 8G

• LOG_BUFFER = 134217728

• FAST_START_MTTR_TARGET = 0

使用されたOracle GoldenGateのリリースは11.1.1.1であり、次のプロセスが構成されました。

- ASM DBLOGREADER APIを使用した単一のExtractプロセス（このリリースでの統合Extractの利用は不可）

- PASSTHRUパラメータが定義された単一のData Pumpプロセス

- BATCHSQLを使用した最大8つのReplicatプロセス

PeopleSoft Payrollの実行中にいくつかの表が作成され、データが移入され、その後、削除されます。

これはOracle GoldenGateにとっては問題になります。DDLをレプリケートすることはできますが、

新しく作成されたオブジェクトに対するサプリメンタル・ロギングは自動的に有効化されません。

34


これによって、補助的にロギングされる必要のあるキー列が欠如していることで、ターゲット・デー

タベース上でReplicatが更新または削除しようとした列が見つからず、問題が発生します。この問題

を解決するには、既存の表や新たに作成した表の補助ログ列に対してOracle GoldenGateのADD

SCHEMATRANDATAを使用します。

データベース・バージョンが11.2.0.3より古い場合、ADD SCHEMATRANDATAを使用する前に、バグ

13794550のためのOracle Databaseパッチを適用する必要があります。

また、Oracle GoldenGateを使用してレプリケートするオブジェクトに対しては、ターゲット・デー

タベース上でトリガーとカスケード制約を無効化する必要があります。これは、トリガーや制約に

よって生成されるDMLが、ソース・データベース上のDMLから先にレプリケートされるためです。

PeopleSoftスキーマには行の挿入や更新に対して多数のトリガーが定義されていますが、Payrollで使

用される表に関連付けられているものはありません。また、レプリケートされる表にはカスケード

制約が付加されていないため、PeopleSoftのPayroll表をレプリケートする際にトリガーやカスケード

制約を無効化する必要はありません。

これらのトピックについて、詳しくは次のWebサイトで『Oracle GoldenGate Oracle Installation and Setup Guide』の第5項を参照してください。


Oracle GoldenGateのパフォーマンス

Payroll全体の実行中、ExtractとData Pumpの遅延は4秒未満を維持していました。

はじめに4つのReplicatプロセスが構成され、プロセス間でPayroll表が均等に分散されました。

PaySheetの実行中に遅延が2分に達し、PayConfirmでは最大6.5分になりました。

次のグラフは、ReplicatプロセスREP_1CおよびREP_1Dに対する待機時間の急増を示しています。

35



RANGEメソッドによって一意キー列を使用して表を分割することで（詳しくは前述の説明を参照）、

DMLアクティビティのもっとも多い4つの表が、さらに4つのReplicat間で分割されました。


1番目の新規Replicat：

MAP PSFT.PS_PAY_DEDUCTION , TARGET psft.PS_PAY_DEDUCTION FILTER (@RANGE (1, 2, PAYGROUP));

MAP PSFT.PS_PAY_EARNINGS , TARGET psft.PS_PAY_EARNINGS FILTER (@RANGE (1, 2, PAYGROUP));

2番目の新規Replicat：

MAP PSFT.PS_PAY_DEDUCTION , TARGET psft.PS_PAY_DEDUCTION FILTER (@RANGE (2, 2, PAYGROUP));

MAP PSFT.PS_PAY_EARNINGS , TARGET psft.PS_PAY_EARNINGS FILTER (@RANGE (2, 2, PAYGROUP));

Replicatプロセスの数を8つに増やすことで、最大遅延が6.5分から2分未満に短縮されました。

36


ReplicatプロセスREP_1Bが依然として最大の遅延要因であることは明らかであるため、このプロセス

で使用される表を分割すると、遅延が軽減されると考えられます。

2. Swingbenchの事例

ワークロードの説明

Swingbenchの受注ワークロードは、TPC-Cと非常によく似たOLTPタイプの受注ベンチマークであり、

データベースに対してよりDML集約型のケースを作成するため、多数の問合せとスリープ時間を排

除するように変更されています。

このワークロードは、ORDERS、ORDER_ITEMS、INVENTORIESという3つの表に対してDMLを適用し

ます。スキーマ内の表には次の親子関係が存在します。

37


このワークロードの実行時間は60分であり、32の同時ユーザー・プロセスが絶え間なく

受注DMLを実行しています。次のDMLによって69GBのREDOが生成されます（19MB/秒）。

• ORDERS表に対する13,505,692行の挿入と更新

• ORDER_ITEMS表に対する47,972,484行の挿入

• INVENTORIESに対する43,419,572行の更新

ワークロードはステージングされているため、ワークロードが完了し、どのくらいの速度でデータ

をレプリケートできるかが特定されるまで、Oracle GoldenGateプロセスは開始されませんでした。

ワークロードの完了後にソース・データベース上で保証付きリストア・ポイント（GRP）を作成する

ことで、レプリケーション・テストを何度も再実行できました。ワークロード・スキーマは毎回、

ターゲット・データベース上で再初期化されました。

環境の構成

ソース・ハードウェアはOracle Exadata Database Machine X2-2クォーターラックであり、3つのスト

レージ・セルを使用しています。また、ターゲット・ハードウェアはOracle Exadata Database Machine

v2クォーターラックであり、3つのストレージ・セルを使用しています。

ソース・データベースとターゲット・データベースのソフトウェア・リリースはいずれも11.2.0.3で

あり、Exadataバンドル・パッチ14が適用されています。

両方のデータベースには次の初期化パラメータが設定されました。

• STREAMS_POOL_SIZE = 8G

38


• DB_CACHE_SIZE = 8G

• LOG_BUFFER = 128000000

• SHARED_POOL_SIZE = 1536M

• ARCHIVELOG mode enabled

使用されたOracle GoldenGateのバージョンは11.2.1.0.5であり、次のプロセスが構成されました。

• 次のパラメータを指定した単一の統合Extract

• MAX_SGA_SIZE = 2048

• DBFS上に500MBの証跡ファイルを作成し、『Oracle Exadata Database MachineでのOracle GoldenGateの構成』（http://www.oracle.com/technetwork/database/features/ availability/maa-wp-gg-oracledbm-128760.pdf）の手順に従って構成します。

• CPU使用を軽減するためのPASSTHRUパラメータを使用した単一のData Pump

• 構成およびチューニングを実施した複数のReplicatプロセス（詳しくは後述）

Oracle GoldenGateのパフォーマンス

これはステージングされた60分間のワークロードであるため、Oracle GoldenGateが生成時と同じ速度でデータをレプリケートするには、60分以内に処理を完了する必要があります。

Extractに上述の初期構成を使用してこのワークロードがREDOログから抽出され、証跡ファイルに書き込まれるのに9分9秒かかりました。ワークロードによって生成されたREDOは69GBであるため、REDO読取り速度は128MB/秒になります。

Data PumpはExtractに遅れを取ることなく、Extractがソース証跡ファイルに最後のエントリを書き

出すとすぐに処理を完了しました。

ターゲット・データベースでは、BATCHSQLが無効化された単一Replicatがはじめに構成されました。

この単一プロセスがワークロードを適用するまでに5時間弱かかりましたが、ここまでに概説した手

法を使用することで、22分に短縮されました。次の表に、BATCHSQLを有効化したReplicatの追加が

適用時間に与えた効果を示します。 Replicatの構成

経過時間（時間:分:秒） Replicatの適用速度（MB/秒）*

1つのReplicat（BATCHSQLなし） 4:54:18 4

1つのReplicat（BATCHSQLあり） 1:30:06 13.1

39




3つのReplicat（BATCHSQLあり）

表ごとに（ORDERS、ORDER_ITEMS、INVENTORIES）1つのReplicat

37:35 31.4


表ごとに2つのReplicat（PK列で分

割）

26:03 45.2


ORDERS表に4つのReplicat、ORDER_ITEMS表と

INVENTORIES表のそれぞれに2つのReplicat

23:52 49.4

10のReplicat（BATCHSQLあり）

ORDERS表に4つのReplicat、ORDER_ITEMS表に4つのReplicat、INVENTORIES表に2つのReplicat

22:09 53.2

*Replicatの適用速度は、ソース・データベースでワークロードによって生成されたREDOをReplicat

プロセスが適用する速度です。たとえば、ソース・ワークロードが69GBのREDOを生成し、Replicat

がターゲット上でこのワークロードを約22分で適用した場合、Replicatの適用速度は53.2MB/秒

（69GB/22分）になります。

上の表から、6つのReplicatが作成されるまでは初期パフォーマンスが向上したことが分かります。

その後も引き続きパフォーマンスは向上しましたが、その割合は低く、6つのReplicatを8つに増やし

たことで得られたパフォーマンス向上は9%であり、さらに10まで増やした場合は7%にとどまりまし

た。このようにReplicatの数を増やしていくプロセスは、リソースと時間の許す限り、パフォーマン

スが向上しなくなるまで続けることができます。

結論

本書では、ソース・データベースおよびターゲット・データベースに加えて、Oracle GoldenGateの

Extract、Data Pump、Replicatの各プロセスに対するおもな推奨構成を提示しました。

Oracle GoldenGate環境を最適化するには、次に示す極めて重要なデータを収集する必要があります。

• レポート・ファイルとエラー・ログ

• Active Workload Repository（AWR）とActive Session History（ASH）

• CPUデータ

40


• I/Oデータ

• Streams Performance Advisor（UTL_SPADV）（ソース・データベースのみ）

Integrated Capture Healthcheck（ソース・データベースのみ）これらの情報をすべて収集したら、

本書に提示したチューニング手法に従って、現在の遅延や待機時間を引き起こしている原因を特定

し、解決します。

パフォーマンス・チューニングは反復プロセスであり、遅延の原因を解決したら、再度、データ収

集と分析からプロセスを開始します。

本書では、PeopleSoftのPayrollバッチとSwingbenchのOLTPワークロードに対してこのアプローチを

使用することでパフォーマンスが向上した例を提示しています。PeopleSoftの事例では、50万名の

従業員に対する先月分の給与支払い処理が実行されました。ExtractとData Pumpでの遅延は全体を

通じて4秒未満に抑えられていました。Replicatに関しては8つのプロセスを使用した場合に最善の結

果が得られ、待機時間は2分未満でした。REDOの生成速度にはばらつきがあり、17～27.7MB/秒でし

た。使用されたOracle GoldenGateのリリースは11.1.1.1.1であり、統合キャプチャ・モードではない

Extractが使用されました。

ステージングされた60分間のSwingbenchワークロードによって19MB/秒でREDOが生成され、

Extractによる抽出処理とソース上の証跡ファイル作成に加えて、Data Pumpによるターゲットへの

送信が9分未満で完了しました（REDO読取り速度：128MB/秒）。10のReplicatプロセスを使用する

ことで、ターゲットでのワークロードの適用は22分未満で完了しました（REDOの適用速度：53MB/

秒）。

41


付録A - SPADV統計のリアルタイム表示

このシェル・スクリプト・プログラム例は、監視が開始されるとすぐに、Streams Performance Advisor

（SPADV）の統計情報をリアルタイムで表示します。

# Oracle環境変数の設定

-- 統計の1行目に凡例を表示する

-- CTRL-Cが押されるまでループして15秒ごとに結果を表示するd=0

42


付録B – Perlコードを使用したReplicatプロセス間での表の分割

はじめに、Extract/ReplicatレポートまたはOracle GoldenGateのlogdump出力（詳しくは？の項を参

照）を確認します。

レポート・ファイル例の表統計：

これらの統計を使用して、構成するReplicatプロセス間で行数を分割できます。この付録の最後に記

載したPerlコードは、表統計を含むExtractまたはReplicatのレポート・ファイルを引数として受け取

ります。構成可能なReplicatの最大数は、各Replicatプロセスに均等に割り当てる行数の目標となる

単一表の最大行数によって異なります。

このPerlコードでは、FILTERパラメータを使用したReplicatプロセス間での大規模表の分割について

は考慮されていません。これには、前述のとおり、手動による介入を行って、考えられるDDLコマ

ンドによる結果とFK/PK関係について理解する必要があります。

43


手順1：balance_replicats.plを実行して、表ごとの合計行数を特定します。

手順2：プロンプトに従って、構成したいReplicatの数を入力します。

44


手順3：提供されたMAP文をReplicatパラメータ・ファイルに追加し、指定された表のみを適用しま

す。

注：Replicatプロセス間で表を分割する前に、FK/PK関係を考慮に入れる必要があります。これ

らの関係が存在する場合、関係のある表を同じReplicatに入れるか、もしくは制約を削除または

無効化します。

SwingbenchのOLTPワークロード例を使用したケースでは、このアプローチを使用することで、

Replicatの最大待機時間が31分から3秒に短縮されました。

balance_replicats.pl： #!/usr/bin/perl #

# balance_replicats.pl - Extract/Replicatレポート・ファイルまたはlogdumpの

# 出力ファイルを読み取り、複数のReplicatプロセス間で

# 均等に表を分割する #

# ExtractまたはReplicatのレポート・ファイルには表統計が含まれている、例： # # From Table PSFT.PS_PAY_EARNINGS: # # inserts: 2352256 # # updates: 4204032 # # deletes: 250240 # # discards: 0 #

# または、表データのカウント表示にlogdumpを使用することも可（詳しくはMOS Note 1301300.1

を参照）

# 次のデータを含む必要がある # # SOESMALL.INVENTORIES Partition 4 # Total Data Bytes 46142040 # Avg Bytes/Record 42 # FieldComp 1098620 # After Images 1098620 # #

# 使用法： #

# Linux/Unix：./balance_replicats.pl <レポート・ファイルまたはlogdump出力ファイル> #

# Windows： perl balance_replicats.pl <レポート・ファイルまたはlogdump出力ファイル> # #

# 注：

# - 表の間のFK/PK制約は考慮されていません。

# FK/PK関係を持つ表は同じReplicat内に維持することを推奨します。

45


# レプリケーション中に制約を無効化できる場合は

# 大幅に高い並列度と高速な適用速度が可能になります。

# - ターゲット表に対するDML文のパフォーマンスは

# 考慮されていません。一部の表に対する挿入、更新、削除のパフォーマンスは

# 選択する索引戦略によって大きく異なる可能性があります。 #

# 表データ my %table_data;

my %Replicat; # 表およびReplicatの数を格納するためのハッシュ表

$logdump=0; # logdumpの場合は1を、レポート・ファイルの場合は0を設定

# 右トリム関数によって末尾の空白を削除sub rtrim($) {

my $string = shift; $string =~ s/¥s+$//; return $string;

}

# 'grep'なしでもWindowsで実行できるようにするためのPerlバージョンのgrepsub pgrep {

# はじめに、読み取るファイルの種類（ReportまたはLogdump）を決定する

# Extract/Replicatレポート・ファイル内の表ごとに次の文字列が含まれる

# From Table <所有者>.<表名>

# logdumpの場合、次の文字列が含まれる # Current LogTrail is #

$rpt_string="From Table"; $logdmp_string="Current LogTrail is"; open(FH, $filename); while(my $line = <FH>) { if($line =~ m/$rpt_string/) {

close FH; return(1);

} elsif ($line =~ m/$logdmp_string/) {

close FH; return(2);

} }

# レポートからもlogdumpからも見つからない場合return(0); }

# readReportFile - ExtractまたはReplicatのレポート・ファイルを読み取り、

# table_dataハッシュを移入

46


sub readLogDump {

print "¥nReading Logdump file:$filename¥n";

open(FILE, "<$filename") || # セグメント・ヘッダー・トレース・ファイルを

読取り用にオープンdie "Can't open file: $filename¥n";

$found = 0; # "Run Time Statistics"の開始位置を発見 $done = 0; $table_count = 0;

while ($done != 1) { # ファイル末尾に達するまでのWhileループ

$line = <FILE>; # 1行読み込む

$where = index("$line", "*FileHeader*"); # エントリの開始位置を検索

if ($where != -1) { $done = 1;

# ファイルの処理を続行

while ($line = <FILE>) { # ファイル末尾に達するまで

$where = index("$line", "Partition 4"); # 表を意味する

if ($where != -1) { # 新しい表 @words = split (' ',$line);

$tablename=$words[0];

#DML数の読込み $line = <FILE>; @words = split (' ',$line); $bytes = rtrim($words[3]); $total = $bytes;

# ハッシュ表への追加 $table_data{$tablename} = $total;

if ( $total > $max_total ) { $max_total = $total; } $table_count++; $row_total = $row_total + $total;

} }

} } print "¥nNumber of tables read in file:$table_count¥n"; close FILE;

} # readReportFileの終了

# readReportFile - ExtractまたはReplicatのレポート・ファイルを読み取り、

# table_dataハッシュを移入sub readReportFile {

47


print "¥nReading Extract report file:$filename¥n";

open(FILE, "<$filename") || # セグメント・ヘッダー・トレース・ファイ

ルを読取り用にオープンdie "Can't open file:$filename¥n";

$found = 0; # "Run Time Statistics"の開始位置を発見 $done = 0; $table_count = 0;

while ($done != 1) { # ファイル末尾に達するまでのWhileループ

$line = <FILE>; # 1行読み込む

$where = index("$line", "** Run Time Statistics **"); #最初の間隔の開始位

置を検索

if ($where != -1) { # セクション開始位置の発見

$done = 1; # 発見！

# ファイルの処理を続行

while ($line = <FILE>) { # ファイル末尾に達するまで $where = index("$line", "From Table");

if ($where != -1) { # 新しい表 @words = split (' ',$line);

$tablename=$words[2]; chop($tablename); # Remove the ":" from each tablename

#DML数の読込み $line = <FILE>; @words = split (':',$line); $ins = rtrim($words[1]); $line = <FILE>; @words = split (':',$line); $upd = rtrim($words[1]); $line = <FILE>; @words = split (':',$line); $del = rtrim($words[1]); $total = int($ins + $upd + $del);

# ハッシュ表への追加

# 重複を避けるため、該当する表がすでにハッシュ表に含まれていないことを確認する

if (exists $table_data{$tablename}) { print "** WARNING:Table $tablename already found in report file.This shouldn't happen.¥n"; } else {

48


$table_data{$tablename} = $total;

if ( $total > $max_total ) { $max_total = $total; } $table_count++; $row_total = $row_total + $total;

} }

} }

} print "¥nNumber of tables read in report file:$table_count¥n"; close FILE;

} # readReportFileの終了 ################ # ** MAIN ** # ################

# 受け取った引数の確認

if ($#ARGV !=0) { # パラメータが1つ渡されたことを確認print "Usage:$0 <dir/filename>¥n"; print "¥nExample:./balance_replicats.pl /home/goldengate/dirrpt/ext_1a.rpt¥n¥n";

exit 1; } ($filename) = @ARGV; $max_total = 0; $row_total = 0;

#処理対象ファイルを特定（レポートまたはLogdump） $result=pgrep; if ( $result == 1 ) {

# Extrac/Replicatレポート・ファイルの読取り readReportFile(); $logdump=0; $which='Rows';

} elsif ( $result == 2 ) {

readLogDump(); $logdump=1; $which='Bytes';

} else { print "¥n*** ERROR:Cannot determine if file is Report file or Logdump file - check

file correctness¥n¥n"; exit 1;

} if ( $logdump ) { print "Total Bytes:$row_total¥n"; print "¥n**** ALL tables found in Logdump file (ordered by bytes)***¥n";

}

49


else { print "Total Rows:$row_total¥n"; print "¥n**** ALL tables found in Extract report file (ordered by row count)***¥n";

} foreach $table (reverse sort {$table_data{$a} <=> $table_data{$b} } keys %table_data) {

$perc = ($table_data{$table} / $row_total)*100 ; if ( $perc <= 0 ) {

print "$table ¥t $table_data{$table} ¥t <1%¥n"; } else {

printf "$table ¥t $table_data{$table} ¥t %.1f%¥n", $perc; } }

# Replicatの最大数を特定し、行を割り当てる

# - 1つの表に対する最大行数を取り、

# この値を、1つのReplicatが適用できる

# 最小行数の概算値として設定

# - 合計行数を単一表の最大行数（前のステップ）で割り

#最大Replicat数（端数切上げ）を取得

# - 切上げによって行数の少ないReplicatが生じる場合があるが、

# その場合は手動で変更する

# - 望ましいReplicat数の入力をユーザーに求める

# - 合計行数をReplicat数で割り、Replicatあたりの目標行数を特定

# - Replicatと表リストに対してループ処理を実行し、

# Replicatが目標行数に達するか、表がなくなったら終了する

# - 表が残った場合は、割当て行数がもっとも少ないReplicatに

# この表を割り当てる $max_whole_replicats = int($row_total / $max_total); $rem = $row_total % $max_total; if ( $rem > 0.5 ) {

$max_replicats = $max_whole_replicats + 1; } else {

$max_replicats = $max_whole_replicats; }

# 望ましいReplicat数を入力（$max_replicatsに1を設定）

# 注：レポート/log dumpに複数表が含まれる場合のみ実行する if ( $max_replicats > 1 ) {

$done=0;

50


while ( $done != 1 ) {

print "¥n Enter number of Replicats required (1 to $max_replicats):"; $replicats = <STDIN>;

chomp ($replicats); # キャリッジ・リターンを削除 if ( $replicats > 0 && $replicats <= $max_replicats ) {

$done = 1; }

} } else {

$replicats = $max_whole_replicats; }

# 均等配分を行う

# 1.Replicatあたりの概算行数を特定

# 2.ソートされた配列を横断し、適切な表が見つかったら

# 表名、合計行数、Replicat数を格納した別の表に追加する if ( $replicats > $max_whole_replicats ) {

$max_rows = $max_total; } else {

$max_rows = int($row_total / $replicats); } print "¥n** Target max $which for each replicat = $max_rows¥n¥n"; $table_count = 0; $totals = 0; $minrows = 0; for ($i=1; $i <= $replicats; $i++) {

$rep_rows = 0;

# 現在のReplicatに対する表の配列 my @rep_tables = (); my $entry = $Replicat{$i};

foreach $table (reverse sort {$table_data{$a} <=> $table_data{$b} } keys %table_data) { if ( $rep_rows < $max_rows && ($rep_rows + $table_data{$table}) <= $max_rows ) {

# さらに表を追加可能 $rep_rows = $rep_rows + $table_data{$table}; $totals = $totals + $table_data{$table}; $table_count++;

# 配列に表を追加 push(@rep_tables, $table);

# 重複割当てを防ぐため、全表マスター・ハッシュから要素を削除 delete($table_data{$table});

} }

51


# 現在のReplicatに対する表の配列を保存 $entry->{$tables} = [ @rep_tables ]; $entry->{num_rows} = $rep_rows; $Replicat{$i} = $entry;

# 行数のもっとも少ないReplicatを特定 if ( $rep_rows < $minrows || $minrows < 1 ) {

$minrows = $rep_rows; $minrep = $i;

}

} # すべてのReplicatが終了 $size = keys %table_data; if ( $size > 0 ) {

print "** Tables NOT yet assigned will be assigned to Replicat #$minrep:¥n"; while (($table, $total) = each(%table_data)){

print "Name:$table ¥t $which:$total¥n";

# 残った表があれば、行数のもっとも少ないReplicatに対して追加する my $entry = $Replicat{$minrep}; $entry->{num_rows} = $entry->{num_rows}+$total; push(@{$entry->{$tables}}, $table);

} print "¥n";

} print "** Replicat Configuration **¥n"; foreach my $reps ( sort keys %Replicat ) {

my $entry = $Replicat{$reps}; my $rows = $entry->{num_rows}; my @tabs = @{$entry->{$tables}};

print "Replicat# $reps - $which:$rows¥n";

# 表の出力 foreach ( sort @tabs ) {

print $_ ."¥n"; } $numtabs = @tabs; print "Number of tables:$numtabs¥n¥n";

} exit;

52

Oracle GoldenGateのパフォーマンス・

ベスト・プラクティス

2013年7月

著者：Stephan Haisley

共著者：Lawrence To

Oracle Corporation

World Headquarters

500 Oracle Parkway

Redwood Shores, CA 94065

U.S.A.

海外からのお問い合わせ窓口：

電話：+1.650.506.7000

ファクシミリ：+1.650.506.7200

www.oracle.com

Copyright © 2013, Oracle and/or its affiliates.All rights reserved.本文書は情報提供のみを目的として提供されており、ここに記載される内容は予

告なく変更されることがあります。本文書は一切間違いがないことを保証するものではなく、さらに、口述による明示または法律による黙示を

問わず、特定の目的に対する商品性もしくは適合性についての黙示的な保証を含み、いかなる他の保証や条件も提供するものではありません。

オラクルは本文書に関するいかなる法的責任も明確に否認し、本文書によって直接的または間接的に確立される契約義務はないものとします。

本文書はオラクル社の書面による許可を前もって得ることなく、いかなる目的のためにも、電子または印刷を含むいかなる形式や手段によって

も再作成または送信することはできません。

OracleおよびJavaはOracleおよびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。

AMD、Opteron、AMDロゴおよびAMD Opteronロゴは、Advanced Micro Devicesの商標または登録商標です。IntelおよびIntel XeonはIntel

Corporationの商標または登録商標です。すべてのSPARC商標はライセンスに基づいて使用されるSPARC International, Inc.の商標または登録商標

です。UNIXはX/Open Company, Ltd.によってライセンス提供された登録商標です。1010

oracle goldengateのパフォーマンス・ ベスト・プ …oracle...

Documents

oracle goldengateのパフォーマンス・ベスト・プ …oracle...