10 管理

10.1 Oracle GoldenGate for Distributed Applications and Analyticsの自動ハートビート

この記事では、Oracle GoldenGate for Distributed Applications and Analytics (GG for DAA)に対してハートビートを有効にする方法と、レプリケーション環境全体にわたりハートビートを管理および変更する方法について説明します。

10.1.1 概要

Oracle GoldenGate for Distributed Applications and Analytics (GG for DAA)に対してHEARTBEATTABLEを有効にするには、次のことを実行する必要があります:
  • 任意の値を使用して、GLOBALSGGSCHEMAを指定します(たとえば、GGSCHEMA GGADMIN)。
  • GLOBALSENABLE_HEARTBEAT_TABLEを有効にします。
  • GGSCIからADD HEARTBEATTABLEを実行します。

Oracle GoldenGate for RDBMSでは、HEARTBEATTABLEレコードが次のターゲットHEARTBEATTABLE表に適用されます: GGADMIN.GG_HEARTBEATおよびGGADMIN.GG_HEARBEAT_HISTORY

GG for DAAでのHEARTBEATTABLEの2つのモード:

モード1 (ユーザー・データとして)では、GG for DAAによって処理されるレコードはHEARTBEATTABLEファイルに書き込まれます。たとえば、表GGADMIN.GG_HEARTBEATはファイルdirtmp/<replicat name>-hb.jsonに格納されます。この場合、レコードはReplicatファイルhb.jsonに書き込まれます。表GGADMIN.GG_HEARTBEAT_HISTORYdirtmp/<replicat-name>hb <date>.jsonに格納されています。この場合、履歴レコードはhb-<date>.jsonファイルに書き込まれます。

ユーザー・データとしてHEARTBEATTABLEを適用するには:

  • Replicatパラメータ・ファイルでDISABLEHEARTBEATTABLEを指定して、HEARTBEATTABLEを無効にします。
  • Replicat MAP文でHEARTBEATTABLE表を指定します。
    MAP GGADMIN.GG_HEARTBEAT, TARGET GGADMIN.GG_HEARTBEAT; 
    MAP GGADMIN.GG_HEARTBEAT_HISTORY, TARGET GGADMIN.GG_HEARTBEAT_HISTORY;

ユーザー・データとして適用すると、HEARTBEATレコードGG_HEARTBEATおよびGG_HEARTBEAT_HISTORYがユーザー表であるかのようにハンドラに書き込まれます。HEARTBEATレコードはRDBMSなどの表に格納されず、.jsonファイルに格納されます。

モード2 (パススルーとして)では、最初にGG for DAAによって解釈されることなく、Oracle以外のシステム(Kafkaなど)に文を直接送信できます。Replicatパラメータ・ファイル内のGG_HEARTBEAT GG_HEARTBEAT_HISTORY表のMAPを明示的に追加する必要はありません。GLOBALSファイル内にENABLE_HEARTBEAT_TABLEを追加する必要があります。GLOBALSファイルの変更後は、ggsci、マネージャおよびその他の子プロセスの再起動をお薦めします。

10.1.2 自動ハートビート表

10.1.2.1 ADD HEARTBEATTABLE
ADD HEARTBEATTABLE
[, RETENTION_TIME number in days] |
[, PURGE_FREQUENCY number in days]
RETENTION_TIME

履歴表で保存時間を過ぎたハートビート・エントリをパージするタイミングを指定します。デフォルトは30日です。

PURGE FREQUENCY

保存時間を過ぎた表エントリを履歴表から削除するパージ・スケジューラの実行頻度を指定します。デフォルトは1日です。

例:
GGSCI > ADD HEARTBEATTABLE
HEARTBEAT is now enabled:
HEARTBEAT configuration file in dirprm\heartbeat.properties
heartbeat.enabled=true
heartbeat.frequency=60
heartbeat.retention_time=30
heartbeat.purge.frequency=1
heartbeat.db.name=BigData

ノート:

Replicatを介して証跡ファイルを処理する前に、必ずADD HEARTBEATTABLEコマンドを実行してください。
10.1.2.2 ALTER HEARTBEAT TABLE

ALTER HEARTBEATTABLE

[, RETENTION_TIME number in days] |

[, PURGE_FREQUENCY number in days]
RETENTION_TIME
dirprm/heartbeat.propertiesheartbeat.retention_timeを更新します。次回の再起動時に有効になります。
PURGE_FREQUENCY
保存時間より古いエントリをGG_HEARTBEAT_HISTORYからパージする頻度を指定します。デフォルトは1日です。
10.1.2.3 INFO HEARTBEATTABLE

HEARTBEAT configuration file dirprm\heartbeat.properties
heartbeat.enabled=true
heartbeat.frequency=60
heartbeat.retention_time=30
heartbeat.purge.frequency=1
heartbeat.db.name=BigData
10.1.2.4 LAG

LAG <replicat name>

GGSCI> LAG rtpc
Lag Information From Heartbeat Table
LAG                 AGE                 FROM       TO         PATH
5.77s               10m 22.87s          ORCL       BIGDATA    ETPC ==> PTPC ==> RTPC

LAG <replicat名> HISTORY

GGSCI> LAG rtpc HISTORY


Lag Information From Heartbeat Table 
LAG      AGE          FROM       TO      PATH 
5.77s   10m 22.87s    ORCL       ORCL    ETPC ==> PTPC ==> RTPC 
Lag History 
DATE         MIN        AVG        MAX
2018-07-01   5.77s      5.90s      6.20s 
2018-07-02   6.77s      6.90s      7.20s 
2018-07-03   7.77s      7.90s      8.20s 
2018-07-04   8.77s      9.90s      9.20s
10.1.2.5 DELETE HEARTBEATTABLE

DELETE HEARTBEATTABLE

GGSCI> DELETE HEARTBEATTABLE

10.2 メッセージの解析

10.2.1 解析の概要

パーサーの役割は、JMSテキスト・メッセージ・データとヘッダー・プロパティを適切なトランザクションと操作のセットに翻訳し、VAMインタフェースに渡すことです。これを行うために、パーサーは必ず特定のデータを検出する必要があります。

  • トランザクション識別子

  • シーケンス識別子

  • タイムスタンプ

  • 表名

  • 操作タイプ

  • 特定の表名と操作タイプに固有の列データ

構成で必要とされる場合、他のデータが使用されます。

  • トランザクション・インジケータ

  • トランザクション名

  • トランザクションの所有者

パーサーは、このデータをJMSヘッダー・プロパティ、システム生成値、静的な値から、またはパーサー固有の方法で取得できます。これは、情報の性質によって異なります。

10.2.1.1 パーサー・タイプ

Oracle GoldenGateメッセージ取得アダプタでは、3種類のパーサーがサポートされます。

  • 固定 - メッセージは、連続したテキストに固定幅フィールドとして表されるデータを含みます。

  • 区切り - メッセージは、フィールドとレコード終端文字で区切られたデータを含みます。

  • XML - メッセージは、XPath式でアクセスされるXMLデータを含みます。

10.2.1.2 ソースおよびターゲットのデータ定義

プロパティと外部ファイルの組合せを使用してソース・データ定義を定義する方法はいくつかあります。

選択されたパーサーのデータの取得方法およびソース定義のターゲット定義への変換方法を構成するプロパティがいくつかあります。

10.2.1.3 必須データ

パーサーがメッセージを翻訳するには、次の情報が必要です。

10.2.1.3.1 トランザクション識別子

トランザクション識別子(txid)によって、Oracle GoldenGate証跡ファイルに書き込まれる操作はトランザクションにグループ化されます。Oracle GoldenGateメッセージ取得アダプタでは、連続し、インターリーブされていないトランザクションのみサポートされます。トランザクション識別子は、トランザクションごとに増分される一意の値です。通常、システム生成値が使用されます。

10.2.1.3.2 シーケンス識別子

シーケンス識別子(seqid)によって、各操作が内部で識別されます。これはリカバリ処理時に使用され、Oracle GoldenGate証跡に書込み済の操作が識別されます。シーケンス識別子は、操作ごとに増分される一意の値です。長さは固定です。

プロバイダのメッセージ識別子が増分され、一意の場合、JMSメッセージIDをシーケンス識別子として使用できます。ただし、(クラスタリングの使用や失敗したトランザクションなどのため)JMSでメッセージの順序が保証されない場合やIDは一意ではあるが、増分されない場合があります。システム生成のシーケンスIDを使用できますが、リカバリの状況によってはメッセージが重複する場合があります。推奨される方法は、メッセージをキューに追加するJMSクライアントでメッセージID、ヘッダー・プロパティまたはデータ要素をアプリケーションで生成される一意の増分値に設定することです。

10.2.1.3.3 タイムスタンプ

タイムスタンプ(timestamp)は、Oracle GoldenGate証跡内で操作のコミット・タイムスタンプとして使用されます。増分されますが、増分が必須ではありません。トランザクションまたは操作間で一意である必要はありません。解析可能な任意のデータ形式でかまいません。

10.2.1.3.4 表名

表名を使用して、列データが属する論理表が識別されます。アダプタは、SCHEMA_NAME.TABLE_NAME形式の2つの部分で構成される表名を必要とします。これは、個別に(schemaおよびtable)定義するか、スキーマと表の組合せとして(schemaandtable)定義します。

1つのフィールドにスキーマ名と表名の両方が含まれることも、スキーマ名と表名が別々のフィールドに含まれることも、スキーマがソフトウェア・コードに含まれ、表名のみが必要なこともあります。スキーマ名と表名の指定方法は、パーサーによって異なります。いずれの場合も、2つの部分で構成される論理表名を使用してOracle GoldenGate証跡にレコードが書き込まれ、証跡を表すソース定義ファイルが生成されます。

10.2.1.3.5 操作タイプ

操作タイプ(optype)を使用して、Oracle GoldenGate証跡への書込み時に操作が挿入、更新、削除のいずれであるかが決定されます。特定の操作の操作タイプ値は、各操作タイプに定義された値と照合されます。

各操作タイプについてOracle GoldenGate証跡に書き込まれるデータは、Extractの構成によって異なります。

  • 挿入

    • すべての列のアフター値が証跡に書き込まれます。

  • 更新

    • デフォルト - キーのアフター値が書き込まれます。ビフォア値が存在し、比較可能な場合、変更された列のアフター値が書き込まれます。ビフォア値がない場合、すべての列が書き込まれます。

    • NOCOMPRESSUPDATES - すべての列のアフター値が証跡に書き込まれます。

    • GETUPDATEBEFORES - ビフォア値が存在し、比較可能な場合、変更された列のビフォア値とアフター値が証跡に書き込まれます。ビフォア値がない場合、アフター値のみが書き込まれます。

    • NOCOMPRESSUPDATESGETUPDATEBEFORESの両方が含まれ、ビフォア値が存在する場合、すべての列のビフォア値とアフター値が証跡に書き込まれます。

  • 削除

    • デフォルト - すべてのキーのビフォア値が証跡に書き込まれます。

    • NOCOMPRESSDELETES - すべての列のビフォア値が証跡に書き込まれます。

キーのビフォア値が存在し、アフター値と一致しない場合、主キー更新操作も生成されます。

10.2.1.3.6 列データ

すべてのパーサーは列データをメッセージ・テキストから取得し、Oracle GoldenGate証跡に書き込みます。列は、ソース定義で定義されている索引順に読み取られる場合もあれば、名前でアクセスされる場合もあります。

構成および元のメッセージ・テキストに応じて、列データのビフォア・イメージとアフター・イメージの両方が使用可能な場合とアフター・イメージのみが使用可能な場合があります。更新の場合、更新されていない列が使用可能な場合と使用可能でない場合があります。

すべての列データはテキストとして取得されます。ソース定義に基づいて、その列の正しいデータ型に内部で変換されます。変換に問題があるとエラーになり、プロセスは異常終了します。

10.2.1.4 オプション・データ

次のデータを含めることができますが、必須ではありません。

10.2.1.4.1 トランザクション・インジケータ

トランザクションとメッセージの関係には次のものがあります。

  • 各メッセージに1つのトランザクション

    これは、メッセージのスコープによって自動的に決定されます。

  • 各メッセージに複数のトランザクション

    これは、トランザクション・インジケータ(txind)によって決定されます。トランザクション・インジケータがない場合、XMLパーサーは、対応するトランザクション・ルールに基づいてトランザクションを作成できます。

  • 各トランザクションに複数のメッセージ

    操作がトランザクションの先頭か、中間か、末尾かトランザクション全体かを指定するために、トランザクション・インジケータ(txind)が必要です。特定の操作のトランザクション・インジケータ値は、各トランザクション・インジケータ・タイプに定義された値と照合されます。インジケータ値が先頭または全体の場合はトランザクションが開始され、中間の場合は続行されます。末尾または全体の場合は終了されます。

10.2.1.4.2 トランザクション名

トランザクション名(txname)は、任意の名前とトランザクションとの関連付けに使用できるオプション・データです。これは、GETENV関数を使用してトークンとして証跡に追加できます。

10.2.1.4.3 トランザクションの所有者

トランザクションの所有者(txowner)は、任意のユーザー名とトランザクションとの関連付けに使用できるオプション・データです。これは、GETENV関数を使用してトークンとして証跡に追加したり、EXCLUDEUSER Extractパラメータを使用して特定のトランザクションを処理から除外するために使用できます。

10.2.2 固定幅解析

固定幅解析は、各フィールドの位置と長さを定義するデータ定義に基づきます。この形式は、Cobolコピーブックの形式です。プロパティのセットで、コピーブックをOracle GoldenGate証跡およびソース定義ファイルの論理レコードにマップするためのルールを定義します。

受信データは、標準形式のヘッダーとその後に続くデータ・セグメントで構成されます。両方とも固定幅のフィールドを含みます。データは、コピーブックのPIC定義に基づいて解析されます。「ヘッダーとレコード・データ型の翻訳」の説明のように翻訳されて証跡に書き込まれます。

10.2.2.1 ヘッダー

ヘッダーは、次の情報を含むコピーブック01レベル・レコードによって定義される必要があります。

  • レコードのコミット・タイムスタンプまたは変更時間

  • 操作のタイプ(挿入、更新または削除)を示すコード

  • データ・セグメントの解析時使用するコピーブック・レコード名

Oracle GoldenGateヘッダー・フィールドにマップされないヘッダー・レコードのフィールドは列として出力されます。

次の例では、必須ヘッダー値を含むコピーブック定義を示します。

例10-1 ヘッダーの指定

01 HEADER.
20 Hdr-Timestamp            PIC X(23)
20 Hdr-Source-DB-Function PIC X
20 Hdr-Source-DB-Rec-ID    PIC X(8)

前述の例に対して次のプロパティを設定します。

fixed.header=HEADER
fixed.timestamp=Hdr-Timestamp
fixed.optype=Hdr-Source-DB-Function
fixed.table=Hdr-Source-DB-Rec-Id

この場合の論理名表出力は、Hdr-Source-DB-Rec-Idという値になります。

10.2.2.1.1 複合表名の指定

複数のフィールドを表名に使用できます。たとえば、次のような静的プロパティを介して論理スキーマ名を定義できます。

fixed.schema=MYSCHEMA

コピーブック・ヘッダー定義から複数フィールドのデータ・レコードを定義するプロパティを追加できます。

例10-2 複合表名の指定

01  HEADER.
    20  Hdr-Source-DB              PIC X(8).
    20  Hdr-Source-DB-Rec-Id       PIC X(8).
    20  Hdr-Source-DB-Rec-Version  PIC 9(4).
    20  Hdr-Source-DB-Function     PIC X.
    20  Hdr-Timestamp              PIC X(22).

前述の例に対して次のプロパティを設定します。

fixed.header=HEADER
fixed.table=Hdr-Source-DB-Rec-Id,Hdr-Source-DB-Rec-Version
fixed.schema=MYSCHEMA

フィールドが連結されて、次のような論理スキーマと表名になります。

MYSCHEMA.Hdr-Source-DB-Rec-Id+Hdr-Source-DB-Rec-Version
10.2.2.1.2 タイムスタンプ形式の指定

タイムスタンプは、デフォルトの形式YYYY-MM-DD HH:MM:SS.FFF(FFFはフィールドのサイズよって異なる)を使用して解析されます。

次の例に示すように日時フィールドの前にコメントを入力し、異なる受信形式を指定します。

例10-3 タイムスタンプ形式の指定

01  HEADER. 
* DATEFORMAT YYYY-MM-DD-HH.MM.SS.FF
    20  Hdr-Timestamp       PIC X(23)
10.2.2.1.3 関数の指定

プロパティを使用して、標準のOracle GoldenGate操作タイプをoptype値にマップします。次の例では、操作タイプはHdr-Source-DB-Functionフィールドにあることと、挿入の値はA、更新はU、削除はDであることを指定します。

例10-4 関数の指定

fixed.optype=Hdr-Source-DB-Function
fixed.optype.insert=A
fixed.optype.update=U
fixed.optype.delete=D
10.2.2.2 ヘッダーとレコード・データ型の翻訳

ヘッダーのデータとレコード・データは、翻訳されたデータ型に基づいて証跡に書き込まれます。

  • 日付形式のコメントが前に付いたフィールド定義は、指定されたサイズのOracle GoldenGate日時フィールドに翻訳されます。日付形式のコメントがない場合、フィールドは基になるデータ型によって定義されます。

  • PIC Xフィールドは、指定されたサイズのCHARデータ型に翻訳されます。

  • PIC 9フィールドは、定義された精度と位取りのNUMBERデータ型に翻訳されます。符号付きの数値、符号なしの数値、小数部のある数値、小数部のない数値がサポートされます。

次の例では、様々なPIC定義に対する翻訳を示します。

入力 出力
PIC XX
CHAR(2)
PIC X(16)
CHAR(16)
PIC 9(4)
NUMBER(4)
* YYMMDD
PIC 9(6)
DATE(10)
YYYY-MM-DD
PIC 99.99
NUMBER(4,2)

この例で、入力YYMMDD日付の100522は、2010-05-22に翻訳されます。指定されたPIC 9(5)V99形式の数値1234567は、小数部が2桁の7桁の数値12345.67に翻訳されます。

10.2.2.3 キー識別子

コメントを使用して、データ・レコード内のキー列を識別します。

次の例では、AccountTABLE1のキー列としてマークされています。

01 TABLE1
* KEY
20  Account      PIC X(19)
20  PAN_Seq_Num PIC 9(3)
10.2.2.4 ソース定義ファイルの使用

Oracle GoldenGateソース定義ファイルから取得されるデータ定義に基づいて、固定幅解析を使用できます。これは、COBOLコピーブックに類似しています。ソース定義ファイルには、参加している表の各フィールドの位置と長さが含まれているからです。ソース定義ファイルを使用するには、次のプロパティを設定する必要があります。

fixed.userdefs.tables=qasource.HEADER
fixed.userdefs.qasource.HEADER.columns=optype,schemaandtable
fixed.userdefs.qasource.HEADER.optype=vchar 3
fixed.userdefs.qasource.HEADER.schemaandtable=vchar 30

fixed.header=qasource.HEADER

次の例では、全長が33文字のヘッダー・セクションを定義しています。最初の3文字は操作タイプで、最後の30文字は表名です。解析されるすべてのレコードのレイアウトは、fixed.userdefsプロパティで定義されている完全なヘッダー・セクションで始まる必要があります。各レコードでは、ヘッダー・セクションの直後に、対応する表のすべての列データの内容が続きます。列データは、ソース定義ファイルで定義されているそのオフセットと長さに従って厳密にレイアウトする必要があります。具体的に言うと、オフセット情報は列定義の4番目のフィールド(Fetch Offset)であり、長さ情報は列定義の3番目のフィールド(External Length)です。GG.JMSCAP_TCUSTMERの定義の例を次に示します。

Definition for table GG.JMSCAP_TCUSTMER
Record length: 78
Syskey: 0
Columns: 4
CUST_CODE   64      4        0  0  0 1 0      4      4      0 0 0 0 0 1    0 1 0
NAME        64     30       10  0  0 1 0     30     30      0 0 0 0 0 1    0 0 0
CITY        64     20       46  0  0 1 0     20     20      0 0 0 0 0 1    0 0 0
STATE        0      2       72  0  0 1 0      2      2      0 0 0 0 0 1    0 0 0
End of definition

GG.JMSCAP_TCUSTMERの固定幅データは、次のようになります。ここでは、わかりやすくするためにオフセット・ガイドが各セクションに追加されています。

0         1         2         3  0         1         2         3         4         5         6         7         8
012345678901234567890123456789012012345678901234567890123456789012345678901234567890123456789012345678901234567890
I  GG.JMSCAP_TCUSTMER            WILL      BG SOFTWARE CO.                     SEATTLE                   WA    
I  GG.JMSCAP_TCUSTMER            JANE      ROCKY FLYER INC.                    DENVER                    CO    
I  GG.JMSCAP_TCUSTMER            DAVE      DAVE'S PLANES INC.                  TALLAHASSEE               FL    
I  GG.JMSCAP_TCUSTMER            BILL      BILL'S USED CARS                    DENVER                    CO    
I  GG.JMSCAP_TCUSTMER            ANN       ANN'S BOATS                         SEATTLE                   WA    
U  GG.JMSCAP_TCUSTMER            ANN       ANN'S BOATS                         NEW YORK                  NY

より短いデータ・レコードを指定できます。つまり、前の一部の列のみが存在することになります。これを行うには、次の要件が満たされている必要があります。

  • 欠落した列または省略された列がキーの一部になっていない

  • それぞれのExternal Lengthの情報に応じて、存在するすべての列に完全なデータが含まれる

    .

10.2.3 区切り解析

区切り解析は、既存のソース定義ファイルとプロパティのセットに基づきます。プロパティで、使用するデリミタ、および列名とビフォア値があるかどうかなどの他のルールが指定されます。ソース定義ファイルによって、処理される有効な表、および表内の列の順序とデータ型が決まります。

区切りメッセージの形式は次のとおりです。

METACOLSn[,COLNAMES]m[,COLBEFOREVALS]m,{COLVALUES}m\n

説明:

  • メタデータ列はn個含めることができ、各メタデータ列の後に形式文に示すカンマなどのフィールド・デリミタが続きます。

  • 列値はm個含めることができます。各々、カンマなどのフィールド・デリミタがその前に付きます。

  • 列名とビフォア値はオプションです。

  • 各レコードは、\nなどの行末デリミタで終わります。

渡されるメッセージには、少なくともヘッダーとメタデータ列が含まれている必要があります。列の数が、ヘッダーおよびメタデータの列の数より少ない場合には、取得プロセスが終了し、エラー・メッセージが生成されます。

ヘッダーおよびメタデータ列より後の残りの列は、対応する表の列データで、解決されるメタデータの列の順序で指定されます。メッセージに存在する表の列の数は、メタデータに従って想定される列の数と完全に一致しているのが理想的です。ただし、メッセージの終わりのほうでメッセージの列が不足していても構わず、パーサーはこの最後のほうの列(メッセージの残りには存在しない)を列データの欠落としてマークします。

データの欠落は、パーサーでは許可されますが、キー@列が不足している場合は、取得プロセスが終了します。

Oracle GoldenGateの主キーの更新および統一更新は、サポートされていません。サポートされている操作は、挿入、更新、削除、切捨てのみです。

10.2.3.1 メタデータ列

メタデータ列はヘッダーに相当し、特別な意味を持つフィールドを含みます。メタデータ列には、次の情報が含まれます。

  • optypeには、レコードが挿入か、更新か、削除かを示す値が含まれます。デフォルト値は、IUおよびDです。

  • timestampは、レコードのコミット・タイムスタンプに使用する値の型を示します。タイムスタンプの形式のデフォルトは、YYYY-DD-MM HH:MM:SS.FFFです。

  • schemaandtableは、SCHEMA.TABLE形式のレコードの完全表名です。

  • schemaは、レコードのスキーマ名です。

  • tableは、レコードの表名です。

  • txindは、レコードがトランザクションの先頭か、中間か、末尾か、唯一のレコードかを示す値です。デフォルト値は、0、1、2、3です。

  • idは、レコードのシーケンス番号(RSNまたはCSN)として使用される値です。トランザクションの最初のレコード(操作)のidは、トランザクションのシーケンス番号に使用されます。

10.2.3.2 解析プロパティ

デリミタ、値および日時の形式を表すプロパティを設定できます。

10.2.3.2.1 デリミタを表すプロパティ

次のプロパティは、レコードを区切るための解析ルールを決定します。

  • fielddelimは、1つ以上のASCIIまたは16進文字をフィールド・デリミタの値として指定します。

  • recorddelimは、1つ以上のASCIIまたは16進文字をレコード・デリミタの値として指定します。

  • quoteは、引用符付きの値に使用する1つ以上のASCIIまたは16進文字を指定します。

  • nullindicatorは、NULL値に使用する1つ以上のASCIIまたは16進文字を指定します。

デリミタのエスケープ文字を定義し、その文字がテキスト内にあった場合に置き換えられるようにすることができます。たとえば、バックスラッシュとアポストロフィ(\')が指定されている場合、入力"They used Mike\'s truck" は"They used Mike's truck"に翻訳されます。また、2つの引用符("")が指定されている場合、"They call him ""Big Al"""は"They call him "Big Al""に翻訳されます。

レコード内に引用符なしのデータ値が存在することがありますが、引用符付きの値内のエスケープ文字のみシステムで削除されます。nullインジケータと一致する引用符なしの文字列は、nullとして処理されます。

10.2.3.2.2 値を表すプロパティ

次のプロパティで詳細情報が提供されます。

  • hasbeforesは、各レコードにビフォア値が存在することを示します。

  • hasnamesは、各レコードに列名が存在することを示します。

  • afterfirstは、列のアフター値がビフォア値の前に来ることを示します。

  • isgroupedは、すべての列名、ビフォア値およびアフター値が列ごとに順にではなく、3つのブロックにまとめられることを示します。

10.2.3.2.3 日時を表すプロパティ

デフォルトの形式YYYY-DD-MM HH:MM:SS.FFFがデータの解析に使用されます。プロパティを使用してグローバル、表または列レベルでこれをオーバーライドできます。形式の変更の例を次に示します。

delim.dateformat.default=MM/DD/YYYY-HH:MM:SS
delim.dateformat.MY.TABLE=DD/MMM/YYYY
delim.dateformat.MY.TABLE.COL1=MMYYYY
10.2.3.3 解析ステップ

区切り解析のステップは次のとおりです。

  1. パーサーはまず各レコードのメタデータ列を読み取り、確認します。
  2. これによって表名が取得され、これを使用してソース定義ファイル内の表の列定義が検索されます。
  3. 表の定義が見つからない場合、処理は停止します。
  4. それ以外の場合、列が解析され、ソース定義に定義されている順序と形式で証跡に出力されます。

10.2.4 XML解析

XML解析は、既存のソース定義ファイルとプロパティのセットに基づきます。プロパティによって、トランザクション、操作および列に対応するXML要素および属性を決定するルールが指定されます。ソース定義ファイルによって、処理される有効な表、およびそれらの表内の列の順序とデータ型が決まります。

10.2.4.1 XMLのスタイル

XMLメッセージは動的または静的なXMLにフォーマットされます。実行時、動的XMLのコンテンツは、サンプルXMLまたはXSDドキュメントを使用してあらかじめ決定できないデータ値です。表および列の要素または属性名を決定する静的XMLのコンテンツは、それらのサンプル・ドキュメントを使用してあらかじめ決定できます。

次の2つの例には同じデータが含まれています。

例10-5 静的XMLの例

<NewMyTableEntries> 
  <NewMyTableEntry> 
    <CreateTime>2010-02-05:10:11:21</CreateTime> 
    <KeyCol>keyval</KeyCol> 
    <Col1>col1val</Col1>
  </NewMyTableEntry>
</NewMyTableEntries>

NewMyTableEntries要素は、トランザクション境界をマークします。NewMyTableEntryは、MY.TABLEへの挿入を表します。タイムスタンプは要素テキスト値内にあり、列名は要素名で表されます。

XPathに似た形式のプロパティのセットを介してこれらの2つのスタイルのXMLを解析するルールをプロパティ・ファイルに定義できます。プロパティの目的は、XPath照合を介してあらかじめ定義されたソース定義ファイルにXMLをマップすることです。

例10-6 動的XMLの例

<transaction id="1234" ts="2010-02-05:10:11:21">
  <operation table="MY.TABLE" optype="I">
    <column name="keycol" index="0">
      <aftervalue><![CDATA[keyval]]></aftervalue>
    </column>
    <column name="col1" index="1">
      <aftervalue><![CDATA[col1val]]></aftervalue>
    </column>
  </operation> 
</transaction>

各表に対する各操作は、トランザクション、操作および列の各要素で構成される同じ基本的メッセージ構造を持ちます。表名、操作タイプ、タイムスタンプ、列名、列値などは属性または要素テキスト値から取得されます。

10.2.4.2 XML解析ルール

XMLのスタイルに関係なく、解析プロセスは次の事項を決定する必要があります。

  • トランザクション境界

  • 次のような操作エントリとメタデータ

    • 表名

    • 操作タイプ

    • タイムスタンプ

  • 次のような列エントリとメタデータ

    • 列名または索引のいずれか。両方が指定されている場合、システムは、指定されたデータを含む列の名前が指定された名前かをチェックします。

    • 列のビフォア値またはアフター値(両方の場合も)。

これは、相互に関係のあるルールのセットを介して行われます。処理される各タイプのXMLメッセージに対して、必要なデータの取得に使用されるルールを指定します。指定されたこれらの各ルールに対し、次の目的のプロパティを追加します。

  • トランザクション、操作または列ルール・タイプとしてルールを指定します。どのタイプのルールも、指定された名前とタイプが必要です。

  • 処理されるドキュメントに対してルールがアクティブかどうかを確認するために照合するXPath式を指定します。これはオプションです。定義されていない場合、パーサーは親ルールのノードを照合し、これが最初のルールの場合はドキュメント全体を照合します。

  • リストされた順で処理される詳細ルール(subrules)をリストします。有効なsubrulesは、ルール・タイプによって決まります。Subrulesはオプションです。

次の例では、最上位レベルのルールはgenericruleと定義されています。これは、transactionタイプ・ルールです。そのsubrulesopruleで定義され、このタイプはoperationです。

xmlparser.rules=genericrule
xmlparser.rules.genericrule.type=tx
xmlparser.rules.genericrule.subrules=oprule
xmlparser.rules.oprule.type=op
10.2.4.3 XPath式

XMLパーサーでは、要素およびExtractデータの照合に必要なXPath式のサブセットがサポートされます。式は、特定の要素の照合またはExtractデータに使用されます。

データ抽出の際、パスの大部分が照合に使用されます。式の末尾が抽出に使用されます。

10.2.4.3.1 サポートされるコンストラクト:
サポートされるコンストラクト 説明
/e

ドキュメントのルートからの絶対パスを使用してeを照合します。

./e or e

処理対象の現在のノードからの相対パスを使用してeを照合します。

../e

現在のノードの親に基づいたパスを使用して(繰返し可能)eを照合します。

//e

ドキュメント内の任意の場所にあるeに一致します。

*

どの要素にも一致します。ノート: 部分的にワイルドカードが使用された名前はサポートされません。

[n]

式のn番目の出現に一致します。

[x=v]

xが値vに等しい場合、一致します。ここで、xは次のいずれかです。

  • @att - 属性値

  • text() - テキスト値

  • name() - 名前の値

  • position() - 要素の位置

10.2.4.3.2 サポートされる式
サポートされる式 説明

ルート要素に一致

/My/Element 

現在のノードのサブ要素に一致

./Sub/Element 

n番目の要素に一致

 /My/*[n] 

n番目のSome要素に一致

/My/Some[n] 

任意のテキスト値に一致

/My/*[text() ='value'] 

Some要素のテキストに一致

/My/Some[text() = 'value'] 

どの属性にも一致

/My/*[@att = 'value'] 

Some要素の属性に一致

/My/Some[@att = 'value'] 
10.2.4.3.3 データ値の取得

パスの照合以外に、XPath式は、データ値の取得にも使用できます(絶対または処理対象の現在のノードとの相対)。データ値の式には前の表のパス要素を含めることができますが、後述のいずれかの値アクセッサで終わる必要があります。

値アクセッサ 説明
@att 

属性値。

text() 

要素のテキスト・コンテンツ(値)。

content() 

任意の子XMLノードを含む、要素のフル・コンテンツ。

name() 

要素の名前。

position() 

親内の要素の位置。

例10-7 データ値の抽出の例

相対要素テキスト値を抽出する場合:

/My/Element/text()

絶対属性値を抽出する場合:

/My/Element/@att

照合を使用して要素テキスト値を抽出する場合:

/My/Some[@att = 'value']/Sub/text()

ノート:

ancestor、descendent、selfなどのパス・アクセッサはサポートされません。

10.2.4.4 他の値式

XMLパーサーによって抽出される値は、列値、またはトランザクションまたは操作のプロパティ(表、タイムスタンプなど)です。これらの値はXPathを使用するか、JMSメッセージのプロパティ、システム値またはハードコードされた値を介してXMLから取得されます。XMLパーサー・プロパティは、これらのオプションのうち、そのプロパティの値を取得するために有効なオプションを指定します。

次の例では、timestampは、XPath式、JMSプロパティまたはシステム生成タイムスタンプであることを指定します。

{txrule}.timestamp={xpath-expression}|${jms-property}|*ts

次の例では、tableは、XPath式、JMSプロパティまたはハードコードされた値であることを指定します。

{oprule}.table={xpath-expression}|${jms-property}|"value"

最後の例では、nameは、XPath式またはハードコードされた値であることを指定します。

{colrule}.timestamp={xpath-expression}|"value"
10.2.4.5 トランザクション・ルール

トランザクションの境界を指定するルールが最上位です。メッセージには、1つのトランザクション、複数のトランザクションまたは複数メッセージにわたるトランザクションの一部を含めることができます。これらは次のように指定されます。

  • single - トランザクション・ルール照合は定義されません。

  • multiple - 各トランザクション・ルール照合は新規トランザクションを定義します。

  • span - トランザクション・ルールは定義されません。かわりに、トランザクション・インジケータが操作ルールに指定されます。

トランザクション・ルールの場合、XPathまたは他の式を介して次のルールのプロパティも定義できます。

  • timestamp - トランザクションが発生した時間。

  • txid - トランザクションの識別子。

トランザクション・ルールは複数のsubrulesを持つことができますが、各サブルールは操作タイプのルールである必要があります。

次の例では、メッセージ全体であるトランザクションを指定し、JMSプロパティから取得されるタイムスタンプを含めます。

例10-8 JMSタイムスタンプ

singletxrule.timestamp=$JMSTimeStamp

次の例はルート要素トランザクションに一致し、ts属性からタイムスタンプを取得します。

例10-9 tsタイムスタンプ

dyntxrule.match=/Transaction
dyntxrule.timestamp=@ts
10.2.4.6 操作ルール

操作ルールはトランザクション・ルールのサブルールまたは最上位ルール(トランザクションが操作のプロパティの場合)のいずれかです。

標準ルール・プロパティ以外に、操作ルールは、XPathまたは他の式を介して次のものも定義します。

  • timestamp - 操作のタイムスタンプ。トランザクション・ルールが定義されている場合、これはオプションです。

  • table - この操作の対象の表の名前。これをスキーマと組み合せて使用します。

  • schema - 表のスキーマの名前。

  • schemaandtable - SCHEMA.TABLEの形式のスキーマ名と表名の両方。これは、個々の表およびスキーマのプロパティのかわりに使用できます。

  • optype - optype値に基づいて、これが挿入、更新、削除のいずれの操作かを指定します。

    • optype.insertval - 挿入を表す値。デフォルトは、Iです。

    • optype.updateval - 更新を表す値。デフォルトは、Uです。

    • optype.deleteval - 削除を表す値。デフォルトは、Dです。

  • seqid - 操作の識別子。txidがトランザクション・レベルで定義されていない場合、これがトランザクション識別子になります。

  • txind - この操作がトランザクションの先頭か、中間か、末尾か、操作全体かを指定します。このプロパティはオプションで、操作ルールがトランザクション・ルールのサブルールの場合、無効です。

操作ルールは、操作タイプまたは列タイプの複数のサブルールを持つことができます。

次の例では、/Transaction/Operation要素から操作情報を動的に取得します。

例10-10 操作

dynoprule.match=./Operation
dynoprule.schemaandtable=@table
dynoprule.optype=@type

次の例は、/NewMyTableEntry要素をMY.TABLE表に対する挿入操作に静的に対応付けます。

例10-11 操作例

statoprule.match=./NewMyTableEntry
statoprule.schemaandtable="MY.TABLE"
statoprule.optype="I"
statoprule.timestamp=./CreateTime/text()
10.2.4.7 列ルール

列ルールは、操作ルールのサブルールである必要があります。標準ルール・プロパティ以外に、列ルールは、XPathまたは他の式を介して次のものも定義します。

  • name - 表定義内の列の名前。
  • index - 表定義内の列の索引。

    ノート:

    nameindexのいずれか一方のみが定義されている場合、他方が決定されます。
  • before.value - 列のビフォア値。これは、削除の場合必須ですが、更新の場合オプションです。
  • before.isnull - 列のビフォア値がnullかどうかを示します。
  • before.ismissing - 列のビフォア値が欠落しているかどうかを示します。
  • after.value - 列のビフォア値。これは、削除の場合必須ですが、更新の場合オプションです。
  • after.isnull - 列のビフォア値がnullかどうかを示します。
  • after.ismissing - 列のビフォア値が欠落しているかどうかを示します。
  • value - 特定のビフォア値またはアフター値でオーバーライドされない場合にbefore.valueafter.valueの両方に使用する式。これは、更新に対する異なるビフォア値をサポートしないことに注意してください。
  • isnull – オーバーライドされない場合にbefore.isnullとafter.isnullの両方に使用する式。
  • ismissing – オーバーライドされない場合にbefore.ismissing after.ismissingの両方に使用する式。

列情報の動的抽出

次の例では、/Operation/Column要素から列情報を動的に取得します。

dyncolrule.match=./Column
dyncolrule.name=@name
dyncolrule.before.value=./beforevalue/text()
dyncolrule.after.value=./aftervalue/text()

列との要素の静的対応

次の例は、/KeyColおよび/Col1要素をMY.TABLEの列に静的に対応付けます。

statkeycolrule.match=/KeyCol
statkeycolrule.name="keycol"
statkeycolrule.value=./text()
statcol1rule.match=/Col1
statcol1rule.name="col1"
statcol1rule.value=./text()
10.2.4.8 ルール全体の例

次の例では、前述のXMLサンプルおよび適切なルールを使用して、MY.TABLEに対する同じ結果の操作を生成します。

動的XML 静的XML
<transaction id="1234"
    ts="2010-02-05:10:11:21">
  <operation table="MY.TABLE" optype="I">
    <column name="keycol" index="0">
      <aftervalue>
<![CDATA[keyval]]>
      </aftervalue>
    </column>
    <column name="col1" index="1">
      <aftervalue>
         <![CDATA[col1val]]>
      </aftervalue>
    </column>
  </operation>
</transaction>
NewMyTableEntries>
  <NewMyTableEntry>
    <CreateTime>
       2010-02-05:10:11:21
    </CreateTime>
    <KeyCol>keyval</KeyCol>
    <Col1>col1val</Col1>
  </NewMyTableEntry>
</NewMyTableEntries>
動的 静的
dyntxrule.match=/Transaction
dyntxrule.timestamp=@ts 
dyntxrule.subrules=dynoprule 
dynoprule.match=./Operation 
dynoprule.schemaandtable=@table
dynoprule.optype=@type 
dynoprule.subrules=dyncolrule
dyncolrule.match=./Column 
dyncolrule.name=@name 
stattxrule.match=/NewMyTableEntries
stattxrule.subrules= statoprule 
statoprule.match=./NewMyTableEntry 
statoprule.schemaandtable="MY.TABLE"
statoprule.optype="I" 
statoprule.timestamp=./CreateTime/text()
statoprule.subrules= statkeycolrule,
statcol1rule
statkeycolrule.match=/KeyCol 
INSERT INTO MY.TABLE (KEYCOL, COL1)
VALUES ('keyval', 'col1val')

10.2.5 ソース定義生成ユーティリティ

デフォルトでは、JMS取得プロセスは生成される証跡ファイルにメタデータ情報を書き込むので、証跡ファイルのコンシューマは、外部定義ファイルを利用しなくても、証跡レコードの構造を理解することができます。

出力ソース定義ファイルをポンプまたは配信プロセスで使用し、VAMを介して作成された証跡データを解釈します。

10.3 メッセージ取得プロパティ

10.3.1 ロギングおよび接続のプロパティ

次のプロパティは、JMSへの接続、ログ・ファイル名、エラー処理およびメッセージ出力を制御します。

10.3.1.1 ロギング・プロパティ

ロギングは次のプロパティによって制御されます。

10.3.1.1.1 gg.log

使用されるロギングのタイプを指定します。デフォルトの実装は、JDKオプションです。これは、java.util.logging (JUL)という名前の組込みJavaロギングです。その他のロギング・オプションは、log4jまたはlogbackです。構文は次のとおりです:

gg.log={JDK|log4j|logback}

たとえば、ロギングのタイプをlog4jに設定するには、次のようにします。

gg.log=log4j 

ログ・ファイルは、インストールのレポート・サブディレクトリに作成されます。デフォルトのログ・ファイル名には、関連付けられているExtractのグループ名が含まれ、ファイル拡張子はlogです。

10.3.1.1.2 gg.log.level

すべてのモジュールを対象とする全体的なログ・レベルを指定します。構文は次のとおりです:

gg.log.level={ERROR|WARN|INFO|DEBUG}

ログ・レベルは次のように定義されています。

  • ERROR - エラーが発生した場合にのみメッセージを書き込ます。

  • WARN - エラーおよび警告メッセージを書き込みます。

  • INFO - エラー、警告および情報メッセージを書き込みます。

  • DEBUG - デバッグ・メッセージを含むすべてのメッセージを書き込みます。

デフォルトのロギング・レベルはINFOです。この場合、メッセージは、起動時、停止時および操作中に定期的に生成されます。レベルをDEBUGに切り替えると、メッセージが大量に生成され、パフォーマンスに影響する場合があります。たとえば、次の例ではグローバル・ロギング・レベルをINFOに設定します。

# global logging level
gg.log.level=INFO
10.3.1.1.3 gg.log.file

ログ・ファイルのパスを指定します。構文は次のとおりです:

gg.log.file=path_to_file

ここで、path_to_fileは完全に定義されたログ・ファイルの場所です。これによってログの名前の変更が可能になりますが、複数のReplicatがある場合、誤って他のログを上書きすることがないようReplicat名を含める必要があります。

10.3.1.1.4 gg.log.classpath

ロギングの実装に使用されるJARのクラスパスを指定します。

gg.log.classpath=path_to_jars
10.3.1.2 JMS接続プロパティ

JMS接続プロパティでは、JMS統合用のJVMの起動方法など、接続を設定します。

10.3.1.2.1 jvm.boot options

JVMの起動時に適用されるクラスパスおよび起動オプションを指定します。パスには、UNIX/Linuxの場合コロン(:)、Windowsの場合セミコロン(;)の区切り文字が必要です。

構文は次のとおりです:

jvm.bootoptions=option[, option][. . .]

optionsは、コマンドラインから実行されるJavaに渡されるものと同じです。これには、クラスパス、システム・プロパティ、使用されているJavaのバージョンに対して有効なJVMメモリー・オプション(最大メモリー、初期メモリーなど)などがあります。有効なオプションは、JVMのバージョンおよびプロバイダによって異なります。

たとえば (1行ですべて指定):

jvm.bootoptions= -Djava.class.path=ggjava/ggjava.jar
-Dlog4j.configuration=my-log4j.properties

log4j.configurationプロパティには、log4jプロパティ・ファイルの完全修飾URLを指定できます。デフォルトでは、このファイルはクラスパスで検索されます。独自のlog4j構成を使用することも、あらかじめ構成されたlog4j設定であるlog4j.properties(デフォルト・レベルのロギング)、debug-log4j.properties(デバッグ・ロギング)またはtrace-log4j.properties (非常に詳細なロギング)のいずれかを使用することもできます。

10.3.1.2.2 jms.report.output

JMSレポートを書き込む場所を指定します。構文は次のとおりです:

jms.report.output={report|log|both}

Where:

  • reportは、JMSレポートをOracle GoldenGateレポート・ファイルに送信します。これはデフォルトです。

  • logは、Javaログ・ファイル(構成されている場合)に書き込みます。

  • bothは、両方の場所に送信します。

10.3.1.2.3 jms.report.time

レポート生成の頻度を時間に基づいて指定します。

jms.report.time=time_specification

次の例では、30秒ごと、45分ごと、8時間ごとにレポートを書き込みます。

jms.report.time=30sec
jms.report.time=45min
jms.report.time=8hr
10.3.1.2.4 jms.report.records

レポート生成の頻度をレコード数に基づいて指定します。構文は次のとおりです:

jms.report.records=number

次の例では、1000レコードごとにレポートを書き込みます。

jms.report.records=1000
10.3.1.2.5 jms.id

指定された形式の一意の識別子がJMS統合からメッセージ取得VAMに渡されることを指定します。これをレコードの一意のシーケンスIDとしてVAMで使用できます。

jms.id={ogg|time|wmq|activemq|message_header|custom_java_class}

Where:

  • ogg - Oracle GoldenGate JMS配信によって設定されるメッセージ・ヘッダー・プロパティGG_IDを返します。

  • time - システム・タイムスタンプをメッセージIDの開始点として使用します。

  • wmq - WebSphere MQ Message IDをVAMとともに使用するために再フォーマットします。

  • activemq - ActiveMQ Message IDをVAMとともに使用するために再フォーマットします。

  • message_header - カスタマイズしたJMSメッセージ・ヘッダー(JMSMessageIDJMSCorrelationIDJMSTimestampなど)を含めるよう指定します。

  • custom_java_class - IDとして使用される文字列を作成するカスタムJavaクラスを指定します。

たとえば:

jms.id=time
jms.id=JMSMessageID

返されるIDは、一意、増分かつ固定長です。数字が重複する場合、重複はスキップされます。メッセージIDの長さを変更すると、Extractプロセスが異常終了します。

10.3.1.2.6 jms.destination

JNDIを使用して検索されるキュー名またはトピック名を指定します。

jms.destination=jndi_name

たとえば:

jms.destination=sampleQ
10.3.1.2.7 jms.connectionFactory

JNDIを使用して検索される接続ファクトリ名を指定します。

jms.connectionFactory=jndi_name

jms.connectionFactory=ConnectionFactory
10.3.1.2.8 jms.user、jms.password

JMSプロバイダで指定される、JMS接続のユーザー名とパスワードを設定します。

jms.user=user_name
jms.password=password

これは、JNDIセキュリティに使用されません。JNDI認証を設定するには、JNDI java.naming.securityプロパティを参照してください。

たとえば:

jms.user=myuser
jms.password=mypasswd
10.3.1.3 JNDIプロパティ

JMS統合では、メッセージ取得VAMの特定のプロパティ以外に、接続ファクトリと宛先を検索するための初期コンテキストへの接続に必要なJNDIプロパティの設定もサポートされます。次のプロパティを設定する必要があります。

java.naming.provider.url=url
java.naming.factory.initial=java_class_name

JNDIセキュリティが有効な場合、次のプロパティを設定できます。

java.naming.security.principal=user_name
java.naming.security.credentials=password_or_other_authenticator

たとえば:

java.naming.provider.url= t3://localhost:7001
java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory
java.naming.security.principal=jndiuser
java.naming.security.credentials=jndipw

10.3.2 パーサー・プロパティ

プロパティで、各タイプのパーサー(固定、区切り、XML)のメッセージの形式および翻訳ルールを指定します。parser.typeプロパティを設定して、使用するパーサーを指定します。残りのプロパティは、パーサー固有です。

10.3.2.1 パーサーのタイプの設定

次のプロパティはパーサー・タイプを設定します。

10.3.2.1.1 parser.type

使用するパーサーを指定します。

parser.type={fixed|delim|xml}

Where:

  • fixedは、固定幅パーサーを起動します。

  • delimは、区切りパーサーを起動します。

  • xmlは、XMLパーサーを起動します。

たとえば:

parser.type=delim
10.3.2.2 固定パーサー・プロパティ

固定パーサーには次のプロパティが必要です。

10.3.2.2.1 fixed.schematype

メッセージ取得のメタデータとして使用されるファイルのタイプを指定します。有効なオプションは、sourcedefsおよびcopybookの2つです。

fixed.schematype={sourcedefs|copybook}

たとえば:

fixed.schematype=copybook

このプロパティの値によって、受信データを正常に解析するために設定する必要がある他のプロパティが決まります。

10.3.2.2.2 fixed.sourcedefs

fixed.schematype=sourcedefsの場合、このプロパティで、使用されるソース定義ファイルの場所を指定します。

fixed.sourcedefs=file_location

たとえば:

fixed.sourcedefs=dirdef/hrdemo.def
10.3.2.2.3 fixed.copybook

fixed.schematype=copybookの場合、このプロパティで、メッセージ取得プロセスで使用されるコピーブック・ファイルの場所を指定します。

fixed.copybook=file_location

たとえば:

fixed.copybook=test_copy_book.cpy
10.3.2.2.4 fixed.header

データ・ブロック構造の決定に使用されるヘッダー情報を含むsourcedefsエントリまたはコピーブック・レコードの名前を指定します。

fixed.header=record_name

たとえば:

fixed.header=HEADER
10.3.2.2.5 fixed.seqid

各レコードを一意に識別するために使用されるseqidを含むヘッダー・フィールドの名前、JMSプロパティまたはシステム値を指定します。この値は継続的に増分され、最後の文字が最下位である必要があります。

fixed.seqid={field_name|$jms_property|*seqid}

Where:

  • field_nameは、seqidを含むヘッダー・フィールドの名前を示します。

  • jms_propertyは、指定されたJMSヘッダー・プロパティの値を使用します。これの特別な値は$jmsidで、 jms.idプロパティで選択されたメカニズムによって返される値を使用します

  • seqidは、システムによって生成される、単純増分の64ビット整数を示します。

たとえば:

fixed.seqid=$jmsid
10.3.2.2.6 fixed.timestamp

タイムスタンプを含むフィールドの名前、JMSプロパティまたはシステム値を指定します。

fixed.timestamp={field_name|$jms_property|*ts}

たとえば:

fixed.timestamp=TIMESTAMP
fixed.timestamp=$JMSTimeStamp
fixed.timestamp=*ts
10.3.2.2.7 fixed.timestamp.format

タイムスタンプ・フィールドの形式を指定します。

fixed.timestamp.format=format

形式には、句読文字と次のものを含めることができます。

  • YYYY - 4桁の年

  • YY - 2桁の年

  • M[M] - 1桁または2桁の月

  • D[D] - 1桁または2桁の日

  • HH - 24時間表記の時間

  • MI – 分

  • SS – 秒

  • Fn - n個の小数部

デフォルトの形式は、"YYYY-MM-DD:HH:MI:SS.FFF"です。

たとえば:

fixed.timestamp.format=YYYY-MM-DD-HH.MI.SS
10.3.2.2.8 fixed.txid

トランザクションを一意に識別するために使用されるtxidを含むフィールドの名前、JMSプロパティまたはシステム値を指定します。この値は、トランザクションごとに増分されます。

fixed.txid={field_name|$jms_property|*txid}

ほとんどの場合、システム値*txidを使用することが推奨されます。

たとえば:

fixed.txid=$JMSTxId
fixed.txid=*txid
10.3.2.2.9 fixed.txowner

トランザクションに関連付けられているユーザー名を含むフィールドの名前、JMSプロパティまたは静的値を指定します。この値は、特定のトランザクションを処理から除外する場合に使用できます。これは、オプションのプロパティです。

fixed.txowner={field_name|$jms_property|"value"}

たとえば:

fixed.txowner=$MessageOwner
fixed.txowner="jsmith"
10.3.2.2.10 fixed.txname

トランザクションに関連付けられている任意の名前を含むフィールドの名前、JMSプロパティまたは静的値を指定します。これは、オプションのプロパティです。

fixed.txname={field_name|$jms_property|"value"}

たとえば:

fixed.txname="fixedtx"
10.3.2.2.11 fixed.optype

操作タイプを含むフィールドの名前またはJMSプロパティを指定します。これは、後述の項で指定されるfixed.optype値に対して検証されます。

fixed.header.optype={field_name|$jms_property}

たとえば:

fixed.header.optype=FUNCTION
10.3.2.2.12 fixed.optype.insertval

この値は、挿入操作を識別します。デフォルトは、Iです。

fixed.optype.insertval={value|\xhex_value}

たとえば:

fixed.optype.insertval=A
10.3.2.2.13 fixed.optype.updateval

この値は、更新操作を識別します。デフォルトは、Uです。

fixed.optype.updateval={value|\xhex_value}

たとえば:

fixed.optype.updateval=M
10.3.2.2.14 fixed.optype.deleteval

この値は削除操作を識別します。デフォルトは、Dです。

fixed.optype.deleteval={value|\xhex_value}

たとえば:

fixed.optype.deleteval=R
10.3.2.2.15 fixed.table

表の名前を指定します。これによって、ヘッダー以外のデータ部分の翻訳に必要なデータ・レコード定義をパーサーが検索できます。

fixed.table=field_name|$jms_property[, . . .]

カンマ区切りの複数のフィールド名を使用して表の名前を決定できます。各フィールド名は、fixed.headerプロパティまたはJMSプロパティによって定義されるヘッダー・レコード内のフィールドに対応します。これらのフィールドの値は連結されてデータ・レコードを識別します。

たとえば:

fixed.table=$JMSTableName
fixed.table=SOURCE_Db,SOURCE_Db_Rec_Version
10.3.2.2.16 fixed.schema

SCHEMA.TABLE表名を生成する際のスキーマの静的な名前を指定します。

fixed.schema="value"

たとえば:

fixed.schema="OGG"
10.3.2.2.17 fixed.txind

トランザクション・インジケータ値に対して検証される、トランザクション・インジケータを含むフィールドの名前またはJMSプロパティを指定します。これが定義されていない場合、1つのメッセージ内のすべての操作がトランザクション全体に出現するとみなされます。定義されている場合、これによってトランザクションの先頭、中間および末尾が決まります。このように定義されたトランザクションは複数メッセージにわたることができます。これは、オプションのプロパティです。

fixed.txind={field_name|$jms_property}

たとえば:

fixed.txind=$TX_IND
10.3.2.2.18 fixed.txind.beginval

この値は、操作をトランザクションの先頭として識別します。デフォルトは、Bです。

fixed.txind.beginval={value|\xhex_value}

たとえば:

fixed.txind.beginval=0
10.3.2.2.19 fixed.txind.middleval

この値は、操作をトランザクションの中間として識別します。デフォルトは、Mです。

fixed.txind.middleval={value|\xhex_value}

たとえば:

fixed.txind.middleval=1
10.3.2.2.20 fixed.txind.endval

この値は、操作をトランザクションの末尾として識別します。デフォルトは、Eです。

fixed.txind.endval={value|\xhex_value}

たとえば:

fixed.txind.endval=2
10.3.2.2.21 fixed.txind.wholeval

この値は、操作をトランザクション全体として識別します。デフォルトは、Wです。

fixed.txind.wholeval={value|\xhex_value}

たとえば:

fixed.txind.wholeval=3
10.3.2.3 区切りパーサー・プロパティ

特に記載のないかぎり、区切りパーサーには次のプロパティが必要です。

10.3.2.3.1 delim.sourcedefs

使用するソース定義ファイルの場所を指定します。

delim.sourcedefs=file_location

たとえば:

delim.sourcedefs=dirdef/hrdemo.def
10.3.2.3.2 delim.header

データの前に配置される値のリストを指定し、各々に名前を割り当てます。

delim.header=name[,name2][. . .]

名前は一意である必要があります。これらは、他のdelimプロパティまたはヘッダー・フィールドが使用可能な場所で参照されます。

たとえば:

delim.header=optype, tablename, ts
delim.timestamp=ts
10.3.2.3.3 delim.seqid

各レコードを一意に識別するために使用されるseqidを含むヘッダー・フィールドの名前、JMSプロパティまたはシステム値を指定します。この値は増分され、最後の文字が最下位である必要があります。

delim.seqid={field_name|$jms_property|*seqid}

Where:

  • field_nameは、seqidを含むヘッダー・フィールドの名前を示します。

  • jms_propertyでは、指定されたJMSヘッダー・プロパティの値を使用します。この特別な値は$jmsidで、jms.idプロパティで選択されたメカニズムによって返される値を使用します。

  • seqidは、システムによって生成される、単純で継続的に増分される64ビット整数を示します。

たとえば:

delim.seqid=$jmsid
10.3.2.3.4 delim.timestamp

タイムスタンプを含むJMSプロパティの名前、ヘッダー・フィールドまたはシステム値を指定します。

delim.timestamp={field_name|$jms_property|*ts}

たとえば:

delim.timestamp=TIMESTAMP
delim.timestamp=$JMSTimeStamp
delim.timestamp=*ts
10.3.2.3.5 delim.timestamp.format

タイムスタンプ・フィールドの形式を指定します。

delim.timestamp.format=format

formatには、句読文字と次のものを含めることができます。

  • YYYY - 4桁の年

  • YY - 2桁の年

  • M[M] - 1桁または2桁の月

  • D[D] - 1桁または2桁の日

  • HH - 24時間表記の時間

  • MI – 分

  • SS – 秒

  • Fn - n個の小数部

デフォルトの形式は、"YYYY-MM-DD:HH:MI:SS.FFF"です。

たとえば:

delim.timestamp.format=YYYY-MM-DD-HH.MI.SS
10.3.2.3.6 delim.txid

トランザクションを一意に識別するために使用されるtxidを含むJMSプロパティの名前、ヘッダー・フィールドまたはシステム値を指定します。この値は、トランザクションごとに増分されます。

delim.txid={field_name|$jms_property|*txid}

ほとんどの場合、システム値*txidを使用することが推奨されます。

たとえば:

delim.txid=$JMSTxId
delim.txid=*txid
10.3.2.3.7 delim.txowner

トランザクションに関連付けられている任意のユーザー名を含むJMSプロパティの名前、ヘッダー・フィールドまたは静的値を指定します。この値は、特定のトランザクションを処理から除外する場合に使用できます。これは、オプションのプロパティです。

delim.txowner={field_name|$jms_property|"value"}

たとえば:

delim.txowner=$MessageOwner
delim.txowner="jsmith"
10.3.2.3.8 delim.txname

トランザクションに関連付けられている任意の名前を含むJMSプロパティの名前、ヘッダー・フィールドまたは静的値を指定します。これは、オプションのプロパティです。

delim.txname={field_name|$jms_property|"value"}

たとえば:

delim.txname="fixedtx"
10.3.2.3.9 delim.optype

操作タイプを含むJMSプロパティの名前またはヘッダー・フィールドを指定します。これは、delim.optype.insertval、delim.optype.updatevalおよびdelim.optype.deletevalの値と比較されて、操作が決まります。

delim.optype={field_name|$jms_property}

たとえば:

delim.optype=optype
10.3.2.3.10 delim.optype.insertval

この値は、挿入操作を識別します。デフォルトは、Iです。

delim.optype.insertval={value|\xhex_value}

たとえば:

delim.optype.insertval=A
10.3.2.3.11 delim.optype.updateval

この値は、更新操作を識別します。デフォルトは、Uです。

delim.optype.updateval={value|\xhex_value}

たとえば:

delim.optype.updateval=M
10.3.2.3.12 delim.optype.deleteval

この値は、削除操作を識別します。デフォルトは、Dです。

delim.optype.deleteval={value|\xhex_value}

たとえば:

delim.optype.deleteval=R
10.3.2.3.13 delim.schemaandtable

SCHEMA.TABLE形式でスキーマおよび表の名前を含むJMSプロパティの名前またはヘッダー・フィールドを指定します。

delim.schemaandtable={field_name|$jms_property}

たとえば:

delim.schemaandtable=$FullTableName
10.3.2.3.14 delim.schema

スキーマ名を含むJMSプロパティの名前、ヘッダー・フィールドまたはハードコードされた値を指定します。

delim.schema={field_name|$jms_property|"value"}

たとえば:

delim.schema="OGG"
10.3.2.3.15 delim.table

表名を含むJMSプロパティまたはヘッダー・フィールドの名前を指定します。

delim.table={field_name|$jms_property}

たとえば:

delim.table=TABLE_NAME
10.3.2.3.16 delim.txind

beginvalmiddlevalendvalまたはwholevalに対して検証される、トランザクション・インジケータを含むJMSプロパティまたはヘッダー・フィールドの名前を指定します。このプロパティが設定されていない場合、1つのメッセージ内のすべての操作が1つのトランザクション内にあるとみなされます。設定されている場合、これによってトランザクションの先頭、中間および末尾が決まります。このように定義されたトランザクションは複数メッセージにわたることができます。これは、オプションのプロパティです。

delim.txind={field_name|$jms_property}

たとえば:

delim.txind=txind
10.3.2.3.17 delim.txind.beginval

操作をトランザクションの先頭として識別する値。デフォルトは、Bです。

delim.txind.beginval={value|\xhex_value}

たとえば:

delim.txind.beginval=0
10.3.2.3.18 delim.txind.middleval

操作をトランザクションの中間として識別する値。デフォルトは、Mです。

delim.txind.middleval={value|\xhex_value}

たとえば:

delim.txind.middleval=1
10.3.2.3.19 delim.txind.endval

操作をトランザクションの末尾として識別する値。デフォルトは、Eです。

delim.txind.endval={value|\xhex_value}

たとえば:

delim.txind.endval=2
10.3.2.3.20 delim.txind.wholeval

操作をトランザクション全体として識別する値。デフォルトは、Wです。

delim.txind.wholeval={value|\xhex_value}

たとえば:

delim.txind.wholeval=3
10.3.2.3.21 delim.fielddelim

データ内のフィールド(列)の区切りに使用されるデリミタ値を指定します。この値は、文字または16進値を使用して定義されます。

delim.fielddelim={value|\xhex_value}

たとえば:

delim.fielddelim=,
delim.fielddelim=\xc7
10.3.2.3.22 delim.linedelim

データ内の行(レコード)の区切りに使用されるデリミタ値を指定します。この値は、文字または16進値を使用して定義されます。

delim.linedelim={value|\xhex_value}

たとえば:

delim.linedelim=||
delim.linedelim=\x0a
10.3.2.3.23 delim.quote

引用符付きのデータの識別に使用される値を指定します。この値は、文字または16進値を使用して定義されます。

delim.quote={value|\xhex_value}

たとえば:

delim.quote="
10.3.2.3.24 delim.nullindicator

NULLデータの識別に使用される値を指定します。この値は、文字または16進値を使用して定義されます。

delim.nullindicator={value|\xhex_value}

たとえば:

delim.nullindicator=NULL
10.3.2.3.25 delim.fielddelim.escaped

入力フィールドにフィールド・デリミタが出現する場合にフィールド・デリミタを置き換える値を指定します。構文は次のとおりです:

delim.fielddelim.escaped={value|\xhex_value}

たとえば、プロパティ設定が次のとおりであるとします。

delim.fielddelim=-
delim.fielddelim.escaped=$#$

データのいずれのフィールド値にもハイフンのデリミタが含まれていない場合:

one two three four

結果の区切りデータは次のようになります。

one-two-three-four

フィールド値にハイフン(-)のデリミタが含まれている場合:

one two three four-fifths two-fifths

結果の区切りデータは次のようになります。

one-two-three-four$#$fifths-two$#$fifths
10.3.2.3.26 delim.linedelim.escaped

入力データに行デリミタが出現する場合に行デリミタを置き換える値を指定します。構文は次のとおりです:

delim.linedelim.escaped={value|\xhex_value}

たとえば、プロパティ設定が次のとおりであるとします。

delim.linedelim=\
delim.linedelim.escaped=%/%

入力行が次のような場合:

These are the lines and they
do not contain the delimiter.

行にバックスラッシュ(\)が含まれていないため、結果は次のようになります。

These are the lines and they\
do not contain the delimiter.\

ただし、入力行にデリミタが含まれる場合:

These are the lines\data values
and they do contain the delimiter.

結果は次のとおりです。

These are the lines%/%data values\
and they do contain the delimiter.\
10.3.2.3.27 delim.quote.escaped

入力データに引用符デリミタが出現する場合に引用符デリミタを置き換える値を指定します。構文は次のとおりです:

delim.quote.escaped={value|\xhex_value}

たとえば、プロパティ設定が次のとおりであるとします。

delim.quote="
delim.quote.escaped="'"

入力データに引用符(")デリミタが含まれない場合:

It was a very original play.

結果は次のとおりです:

"It was a very original play."

ただし、入力データに引用符デリミタが含まれる場合:

It was an "uber-original" play.

結果は次のとおりです:

"It was an "'"uber-original"'" play."
10.3.2.3.28 delim.nullindicator.escaped

入力データにnullインジケータが出現する場合にnullインジケータを置き換える値を指定します。構文は次のとおりです:

delim.nullindicator.escaped={value|\xhex_value}

たとえば、プロパティ設定が次のとおりであるとします。

delim.fielddelim=,
delim.nullindicator=NULL
delim.nullindicator.escaped=$NULL$

入力データにNULL値またはNULLインジケータが含まれない場合:

1 2 3 4 5

結果は次のとおりです

1,2,3,4,5

入力データにNULL値が含まれる場合:

1 2 4 5

結果は次のとおりです

1,2,NULL,4,5

入力データにNULLインジケータが含まれる場合:

1 2 NULL 4 5

結果は次のとおりです:

1,2,$NULL$,4,5
10.3.2.3.29 delim.hasbefores

データ内にビフォア値が存在するかどうかを指定します。

delim.hasbefores={true|false}

デフォルトはfalseです。delim.hasbeforesがtrueに設定されている場合、パーサーは、すべてのレコードについて列のビフォア値とアフター値があると想定します。ビフォア値は更新と削除に使用され、アフター値は更新と挿入に使用されます。afterfirstプロパティは、ビフォア・イメージがアフター・イメージの前か後かを指定します。delim.hasbeforesがfalseの場合、ビフォア値は想定されません。

たとえば:

delim.hasbefores=true
10.3.2.3.30 delim.hasnames

データ内に列名が存在するかどうかを指定します。

delim.hasnames={true|false}

デフォルトは、falseです。trueの場合、パーサーはすべてのレコードに対して列名を検出すると想定します。パーサーは、想定される列名に対して列名を検証します。falseの場合、列名は想定されません。

たとえば:

delim.hasnames=true
10.3.2.3.31 delim.afterfirst

アフター値がビフォア値の前に配置されているか、後に配置されているかを指定します。

delim.afterfirst={true|false}

デフォルトは、falseです。trueの場合、パーサーは、アフター値をビフォア値の前に検出すると想定します。falseの場合、アフター値はビフォア値の前にあります。

たとえば:

delim.afterfirst=true
10.3.2.3.32 delim.isgrouped

すべての列の列名、ビフォア・イメージおよびアフター・イメージがグループ化されるか、列ごとに順に配置されるかを指定します。

delim.isgrouped={true|false}

デフォルトは、falseです。trueの場合、パーサーは、列名のグループ(hasnamesがtrueの場合)、次にビフォア値のグループ(hasbeforesの場合)、その次にアフター値のグループがある(afterfirst設定によってはビフォア値とアフター値の順序が逆になる)と想定します。falseの場合、パーサーは、列名(hasnamesの場合)、ビフォア値(hasbeforesの場合)およびアフター値が列ごとにあると想定します。

たとえば:

delim.isgrouped=true
10.3.2.3.33 delim.dateformat | delim.dateformat.table | delim.dateform.table.column

列データの日付形式を指定します。これは、グローバル・レベル、表レベルまたは列レベルで指定されます。日付の解析に使用される形式は、parser.timestamp.formatに使用される形式のサブセットです。

delim.dateformat=format
delim.dateformat.TABLE=format
delim.dateformat.TABLE.COLUMN=format

Where:

  • formatは、parser.timestamp.formatに定義された形式です。

  • tableは、現在処理されている表の完全修飾名です。

  • columnは、指定された表の列です。

たとえば:

delim.dateformat=YYYY-MM-DD HH:MI:SS
delim.dateformat.MY.TABLE=DD/MM/YY-HH.MI.SS
delim.dateformat.MY.TABLE.EXP_DATE=YYMM
10.3.2.4 XMLパーサー・プロパティ

次のプロパティがXMLパーサーによって使用されます。

10.3.2.4.1 xml.sourcedefs

ソース定義ファイルの場所を指定します。

xml.sourcedefs=file_location

たとえば:

xml.sourcedefs=dirdef/hrdemo.def
10.3.2.4.2 xml.rules

メッセージの解析とトランザクション、操作および列の変換のXMLルールのリストを指定します。

xml.rules=xml_rule_name[, . . .]

指定されたXMLルールは、リストされた順に処理されます。特定のXMLドキュメントに対応するすべてのルールによって、トランザクション、操作および列を作成できます。指定されるXMLルールは、トランザクション・タイプまたは操作タイプのルールである必要があります。

たとえば:

xml.rules=dyntxrule, statoprule
10.3.2.4.3 rulename.type

XMLルールのタイプを指定します。

rulename.type={tx|op|col}

Where:

  • txは、トランザクション・ルールを示します。

  • opは、操作ルールを示します。

  • colは、列ルールを示します。

たとえば:

dyntxrule.type=tx
statoprule.type=op
10.3.2.4.4 rulename.match

ルールが特定のドキュメントに対してアクティブ化されるかどうかの決定に使用されるXPath式を指定します。

rulename.match=xpath_expression

XPath式がドキュメントからノードを返す場合、ルールが対応付けられ、後続の処理が行われます。ノードを返さない場合、そのドキュメントに対してルールは無視されます。

次の例では、ドキュメントにルート要素Transactionがある場合、dyntxruleがアクティブ化されます。

dyntxrule.match=/Transaction

statoprulestattxtuleのサブルールです。次の例では、親ルールの一致ノードに子要素NewMyTableEntryがある場合、statopruleがアクティブ化されます。

statoprule.match=./NewMyTableEntry
10.3.2.4.5 rulename.subrules

親ルールが一致によってアクティブ化された場合、一致をチェックするルール名のリストを指定します。

rulename.subrules=xml_rule_name[, . . .]

指定されたXMLルールは、リストされた順に処理されます。すべての一致ルールで、トランザクション、操作および列が作成される場合があります。

有効なサブルールは、親タイプによって決まります。トランザクション・ルールは、操作サブルールのみ持つことができます。操作ルールは、操作または列サブルールを持つことができます。列ルールは、サブルールを持つことはできません。

たとえば:

dyntxrule.subrules=dynoprule
statoprule.subrules=statkeycolrule, statcol1rule
10.3.2.4.6 txrule.timestamp

1) 指定されたXPath式またはJMSプロパティに含まれたトランザクション・コミット・タイムスタンプの使用、または2) 現在のシステム時間の使用をアダプタに指定することで、トランザクションのタイムスタンプを制御します。これは、オプションのプロパティです。

txrule.timestamp={xpath_expression|$jms_property|*ts}

トランザクションのタイムスタンプは操作レベルでオーバーライドすることも、操作レベルでのみ存在することもできます。XPath式は、@atttext()などの値アクセッサで終わる必要があります。

たとえば:

dyntxrule.timestamp=@ts
10.3.2.4.7 txrule.timestamp.format

タイムスタンプ・フィールドの形式を指定します。

txrule.timestamp.format=format

形式には、句読文字と次のものを含めることができます。

  • YYYY - 4桁の年

  • YY - 2桁の年

  • M[M] - 1桁または2桁の月

  • D[D] - 1桁または2桁の日

  • HH - 24時間表記の時間

  • MI – 分

  • SS

  • Fn - n個の小数部

デフォルトの形式は、"YYYY-MM-DD:HH:MI:SS.FFF"です。

たとえば:

dyntxrule.timestamp.format=YYYY-MM-DD-HH.MI.SS
10.3.2.4.8 txrule.seqid

特定のトランザクションのseqidを指定します。これは、各メッセージに複数のトランザクションがある場合に使用できます。トランザクションのseqidを含むXPath式、JMSプロパティまたはシステム値を決定します。XPath式は、@atttext()などの値アクセッサで終わる必要があります。

txrule.seqid={xpath_expression|$jms_property|*seqid}

たとえば:

dyntxrule.seqid=@seqid
10.3.2.4.9 txrule.txid

トランザクションを一意に識別するために使用されるtxidを含むXPath式、JMSプロパティまたはシステム値を指定します。この値は、トランザクションごとに増分されます。

txrule.txid={xpath_expression|$jms_property|*txid}

ほとんどの場合、システム値*txidを使用することが推奨されます。

たとえば:

dyntxrule.txid=$JMSTxId
dyntxrule.txid=*txid
10.3.2.4.10 txrule.txowner

トランザクションに関連付けられている任意のユーザー名を含むXPath式、JMSプロパティまたは静的値を指定します。この値は、特定のトランザクションを処理から除外する場合に使用できます。

txrule.txowner={xpath_expression|$jms_property|"value"}

たとえば:

dyntxrule.txowner=$MessageOwner
dyntxrule.txowner="jsmith"
10.3.2.4.11 txrule.txname

トランザクションに関連付けられている任意の名前を含むXPath式、JMSプロパティまたは静的値を指定します。これは、オプションのプロパティです。

txrule.txname={xpath_expression|$jms_property|"value"}

たとえば:

dyntxrule.txname="fixedtx"
10.3.2.4.12 oprule.timestamp

1) 指定されたXPath式またはJMSプロパティに含まれたトランザクション・コミット・タイムスタンプの使用、または2) 現在のシステム時間の使用をアダプタに指定することで、操作のタイムスタンプを制御します。これは、オプションのプロパティです。

oprule.timestamp={xpath_expression|$jms_property|*ts}

操作のタイムスタンプは、トランザクション・レベルのタイムスタンプをオーバーライドします。

XPath式は、@atttext()などの値アクセッサで終わる必要があります。

たとえば:

statoprule.timestamp=./CreateTime/text()
10.3.2.4.13 oprule.timestamp.format

タイムスタンプ・フィールドの形式を指定します。

oprule.timestamp.format=format

formatには、句読文字と次のものを含めることができます。

  • YYYY - 4桁の年

  • YY - 2桁の年

  • M[M] - 1桁または2桁の月

  • D[D] - 1桁または2桁の日

  • HH - 24時間表記の時間

  • MI – 分

  • SS – 秒

  • Fn - n個の小数部

デフォルトの形式は、"YYYY-MM-DD:HH:MI:SS.FFF"です。

たとえば:

statoprule.timestamp.format=YYYY-MM-DD-HH.MI.SS
10.3.2.4.14 oprule.seqid

特定の操作のseqidを指定します。操作のseqidを含むXPath式、JMSプロパティまたはシステム値を使用します。これは、親トランザクション・ルールで定義されたseqidをオーバーライドします。親トランザクション・ルールがない場合、必須です。

XPath式は、@atttext()などの値アクセッサで終わる必要があります。

oprule.seqid={xpath_expression|$jms_property|*seqid}

たとえば:

dynoprule.seqid=@seqid
10.3.2.4.15 oprule.txid

トランザクションを一意に識別するために使用されるtxidを含むXPath式、JMSプロパティまたはシステム値を指定します。これは、親トランザクション・ルールで定義されたtxidをオーバーライドし、親トランザクション・ルールがない場合、必須です。この値は、トランザクションごとに増分されます。

oprule.txid={xpath_expression|$jms_property|*txid}

ほとんどの場合、システム値*txidを使用することが推奨されます。

たとえば:

dynoprule.txid=$JMSTxId
dynoprule.txid=*txid
10.3.2.4.16 oprule.txowner

トランザクションに関連付けられている任意のユーザー名を含むXPath式、JMSプロパティまたは静的値を指定します。この値は、特定のトランザクションを処理から除外する場合に使用できます。これは、オプションのプロパティです。

oprule.txowner={xpath_expression|$jms_property|"value"}

たとえば:

dynoprule.txowner=$MessageOwner
dynoprule.txowner="jsmith"
10.3.2.4.17 oprule.txname

トランザクションに関連付けられている任意の名前を含むXPath式、JMSプロパティまたは静的値を指定します。これは、オプションのプロパティです。

oprule.txname={xpath_expression|$jms_property|"value"}

たとえば:

dynoprule.txname="fixedtx"
10.3.2.4.18 oprule.schemandtable

SCHEMA.TABLE形式でスキーマおよび表の名前を含むXPath式、JMSプロパティまたはハードコードされた値を指定します。XPath式は、@atttext()などの値アクセッサで終わる必要があります。値を検証して表がソース定義に存在するかどうかが確認されます。

oprule.schemaandtable={xpath_expression|$jms_property|"value"}

たとえば:

statoprule.schemaandtable="MY.TABLE"
10.3.2.4.19 oprule.schema

スキーマ名を含むXPath式、JMSプロパティまたはハードコードされた値を指定します。XPath式は、@atttext()などの値アクセッサで終わる必要があります。

oprule.schema={xpath_expression|$jms_property|"value"}

たとえば:

statoprule.schema=@schema
10.3.2.4.20 oprule.table

表名を含むXPath式、JMSプロパティまたはハードコードされた値を指定します。XPath式は、@atttext()などの値アクセッサで終わる必要があります。

oprule.table={xpath_expression|$jms_property|"value"}

たとえば:

statoprule.table=$TableName
10.3.2.4.21 oprule.optype

optype insertvalについて評価されるoptypeを含むXPath式、JMSプロパティまたはリテラル値を指定します。XPath式は、@atttext()などの値アクセッサで終わる必要があります。

oprule.optype={xpath_expression|$jms_property|"value"}

たとえば:

dynoprule.optype=@type
statoprule.optype="I"
10.3.2.4.22 oprule.optype.insertval

挿入操作を識別する値を指定します。デフォルトは、Iです。

oprule.optype.insertval={value|\xhex_value}

たとえば:

dynoprule.optype.insertval=A
10.3.2.4.23 oprule.optype.updateval

更新操作を識別する値を指定します。デフォルトは、Uです。

oprule.optype.updateval={value|\xhex_value}

たとえば:

dynoprule.optype.updateval=M
10.3.2.4.24 oprule.optype.deleteval

削除操作を識別する値を指定します。デフォルトは、Dです。

oprule.optype.deleteval={value|\xhex_value}

たとえば:

dynoprule.optype.deleteval=R
10.3.2.4.25 oprule.txind

beginvalまたはトランザクション内の位置を識別する他の値に対して検証されるトランザクション・インジケータを含むXPath式またはJMSプロパティを指定します。このプロパティが定義されていない場合、1つのメッセージ内のすべての操作がトランザクション全体に出現するとみなされます。トランザクションの先頭、中間および末尾を指定します。XPath式は、@atttext()などの値アクセッサで終わる必要があります。このように定義されたトランザクションは複数メッセージにわたることができます。これは、オプションのプロパティです。

oprule.txind={xpath_expression|$jms_property}

たとえば:

dynoprule.txind=@txind
10.3.2.4.26 oprule.txind.beginval

操作をトランザクションの先頭として識別する値を指定します。デフォルトは、Bです。

oprule.txind.beginval={value|\xhex_value}

たとえば:

dynoprule.txind.beginval=0
10.3.2.4.27 oprule.txind.middleval

操作をトランザクションの中間として識別する値を指定します。デフォルトは、Mです。

oprule.txind.middleval={value|\xhex_value}

たとえば:

dynoprule.txind.middleval=1
10.3.2.4.28 oprule.txind.endval

操作をトランザクションの末尾として識別する値を指定します。デフォルトは、Eです。

oprule.txind.endval={value|\xhex_value}

たとえば:

dynoprule.txind.endval=2
10.3.2.4.29 oprule.txind.wholeval

操作をトランザクション全体として識別する値を指定します。デフォルトは、Wです。

oprule.txind.wholeval={value|\xhex_value}

たとえば:

dynoprule.txind.wholeval=3
10.3.2.4.30 colrule.name

列名を含むXPath式またはハードコードされた値を指定します。指定しない場合、列索引を指定する必要があります。列索引から列名が解決されます。指定された場合、列名がソース定義ファイルに対して検証されます。XPath式は、@atttext()などの値アクセッサで終わる必要があります。

colrule.name={xpath_expression|"value"}

たとえば:

dyncolrule.name=@name
statkeycolrule.name="keycol"
10.3.2.4.31 colrule.index

列索引を含むXPath式またはハードコードされた値を指定します。指定しない場合、列名を指定する必要があります。列名から列索引が解決されます。指定された場合、列索引がソース定義ファイルに対して検証されます。XPath式は、@atttext()などの値アクセッサで終わる必要があります。

colrule.index={xpath_expression|"value"}

たとえば:

dyncolrule.index=@index
statkeycolrule.index=1
10.3.2.4.32 colrule.value

列値を含むXPath式またはハードコードされた値を指定します。XPath式は、@atttext().などの値アクセッサで終わる必要がありますノードまたは属性が存在しないためにXPath式でデータを返せない場合、列値はnullとみなされます。nullと欠落値を区別するために(更新の場合)、isnullおよびismissingプロパティを設定する必要があります。返される値は、ビフォア値の削除およびアフター値の更新/挿入に使用されます。

colrule.value={xpath_expression|"value"}

たとえば:

statkeycolrule.value=./text()
10.3.2.4.33 colrule.isnull

列値がnullかどうかの検出に使用されるXPath式を指定します。XPath式は、@atttext()などの値アクセッサで終わる必要があります。XPath式が値を返す場合、列値はnullです。これは、オプションのプロパティです。

colrule.isnull=xpath_expression

たとえば:

dyncolrule.isnull=@isnull
10.3.2.4.34 colrule.ismissing

列値が欠落しているかどうかの検出に使用されるXPath式を指定します。XPath式は、@att text()などの値アクセッサで終わる必要があります。XPath式が値を返す場合、列値は欠落しています。これは、オプションのプロパティです。

colrule.ismissing=xpath_expression

たとえば:

dyncolrule.ismissing=./missing
10.3.2.4.35 colrule.before.value

colrule.valueをオーバーライドし、更新または削除に使用されるビフォア値の取得方法を明示的に指定します。この形式は、colrule.valueと同じ形式です。これは、オプションのプロパティです。

たとえば:

dyncolrule.before.value=./beforevalue/text()
10.3.2.4.36 colrule.before.isnull

colrule.isnullをオーバーライドし、更新または削除用のビフォア値がnullかどうかの決定方法を明示的に指定します。この形式は、colrule.isnullと同じ形式です。これは、オプションのプロパティです。

たとえば:

dyncolrule.before.isnull=./beforevalue/@isnull
10.3.2.4.37 colrule.before.ismissing

colrule.ismissingをオーバーライドし、更新または削除用のビフォア値が欠落しているかどうかの決定方法を明示的に指定します。この形式は、colrule.ismissingの形式と同じです。これは、オプションのプロパティです。

たとえば:

dyncolrule.before.ismissing=./beforevalue/missing
10.3.2.4.38 colrule.after.value

colrule.valueをオーバーライドし、更新または削除に使用されるアフター値の取得方法を明示的に指定します。この形式は、colrule.valueと同じ形式です。これは、オプションのプロパティです。

たとえば:

dyncolrule.after.value=./aftervalue/text()
10.3.2.4.39 colrule.after.isnull

colrule.isnullをオーバーライドし、更新または削除用のアフター値がnullかどうかの決定方法を明示的に指定します。この形式は、colrule.isnullと同じ形式です。これは、オプションのプロパティです。

たとえば:

dyncolrule.after.isnull=./aftervalue/@isnull
10.3.2.4.40 colrule.after.ismissing

colrule.ismissingをオーバーライドし、更新または削除用のアフター値が欠落しているかどうかの決定方法を明示的に指定します。この形式は、colrule.ismissingの形式と同じです。これは、オプションのプロパティです。

たとえば:

dyncolrule.after.ismissing=./aftervalue/missing

10.4 Oracle GoldenGate Java配信

この部では、Oracle GoldenGate for Distributed Applications and Analytics (GG for DAA)を使用してトランザクション・レコードを処理し、Javaモジュールを利用して各種ターゲットにそれを適用する方法について説明します。

詳細は、「Oracle GoldenGate for Distributed Applications and Analyticsの理解」を参照してください。

10.4.1 Java配信の構成

10.4.1.1 プロパティ・ファイルでのJREの構成

現在のリリースのOracle GoldenGate Java配信には、Java 8が必要です。Javaと必須のJava共有ライブラリに正しくアクセスする方法は、Javaの構成に関する項を参照してください。Java用Oracle GoldenGateメインJAR(ggjava.jar)の場所を指すようアダプタ・プロパティ・ファイルを変更します。必要に応じて追加のJVMランタイム起動オプション(起動時にJVMに直接渡される)を設定します。

jvm.bootoptions=-Djava.class.path=.:ggjava/ggjava.jar -Xmx512m -Xmx64m

特に次のオプションに注意してください。

  • java.class.pathには、コア・アプリケーション(ggjava/ggjava.jar)へのパス指定が含まれている必要があります。現在のディレクトリ(.)は、クラスパスにも含まれている必要があります。ロギングはJVMのロード時に初期化されるので、java.class.path変数はロギング・プロパティ・ファイル(log4jプロパティ・ファイルなど)への任意のパス指定を含んでいる必要があります。ロギング機能に必要な依存関係JARはggjava.jarに含まれており、明示的に含める必要はありません。パス指定では、Oracle GoldenGateインストール・ディレクトリを基準にファイルおよびディレクトリを参照し、Javaプロパティ・ファイル、Velocityテンプレートおよびdirprmサブディレクトリ内の他のクラスパス・リソースを格納できます。Javaアプリケーション・プロパティ・ファイルでクラスパスに追加することもできます。ハンドラ依存関係JARのパス指定は、ここでも追加できます。ただし、ハンドラの依存関係はgg.classpath変数を使用して追加するほうが、ベスト・プラクティスと考えられています。

  • jvm.bootoptionsプロパティでは、JVM (Xmx)の初期ヒープ・サイズとJVM (Xmx)の最大ヒープ・サイズも制御できます。最大ヒープ・サイズを増やすと、ガベージ・コレクションの頻度が減るため、パフォーマンスが向上することがあります。また、Javaのメモリー不足例外が発生する場合には、最大ヒープ・サイズを増やす必要があります。

システム用にプロパティ・ファイルを正しく構成したら、通常変更しません。構成オプションの詳細は、「共通プロパティ」を参照してください。

10.4.1.2 Java配信のためのOracle GoldenGateの構成

Java配信は、Oracle GoldenGate Replicatプロセスと互換性があります。トランザクション・データは、Oracle GoldenGate証跡ファイルから読み込まれ、JNIインタフェースを超えてOracle GoldenGate Java配信モジュールに配信されます。データは、JNIインタフェースを使用してOracle GoldenGate Java配信モジュールに転送されます。Java配信モジュールは、データを各種のターゲットにストリーミングできるように構成が可能です。Oracle GoldenGate Javaアダプタ製品でサポートされているターゲットには、JMS、ファイル書込み、カスタム統合が含まれます。Oracle GoldenGate for Distributed Applications and Analytics (GG for DAA)には、そのターゲットへのそれらの統合およびストリーミング機能がすべて含まれています。

10.4.1.2.1 Java配信のためのReplicatの構成

Oracle GoldenGate Replicatプロセスは、トランザクション・データをJavaモジュール用のOracle GoldenGateに送信するように構成できます。Replicatは、ローカルの証跡(dirdat/aaなど)を消費して、データをJava配信モジュールに送信します。Javaモジュールは、すべてのデータを処理して、それを必要なターゲットに適用します。

次に、Replicatプロセスを追加する例を示します。

ADD REPLICAT javarep, EXTTRAIL ./dirdat/aa

前述のプロセス名と証跡名は、任意の有効な名前で置き換えます。プロセス名は8文字以下、証跡名は2文字である必要があります。Replicatパラメータ・ファイル(javarep.prm)で、ユーザー・イグジット・ライブラリの場所を指定します。

Replicatプロセスは、アプリケーションにトランザクションのグループ化が組み込まれています。トランザクションのグループ化は、データをターゲット・データベースにストリーミングするとき、パフォーマンスを大きく改善する場合があります。トランザクションのグループ化により、データをOracle GoldenGate for Distributed Applications and Analytics (GG for DAA)にストリーミングするときも、パフォーマンスが大幅に向上することがあります。トランザクションのグループ化を制御するReplicatパラメータは、Replicat構成ファイルにあるGROUPTRANSOPS変数です。この変数のデフォルト値は1000で、Replicatプロセスは1000個の操作を1つのターゲット・トランザクションにグループ化しようとします。パフォーマンス・テストによると、GROUPTRANSOPSを大きくするほど、GG for DAAにデータをストリーミングするときのパフォーマンスが向上することがわかっています。GROUPTRANSOPS変数を1に設定すると、ソース証跡ファイル(ソース・データベース)からの元のトランザクション境界が維持されます。

表10-1 ユーザー・イグジットReplicatのパラメータ

パラメータ 説明
REPLICAT javarep

すべてのReplicatパラメータ・ファイルはReplicat名で始まります

SOURCEDEFS ./dirdef/tcust.def

(オプション)入力の証跡ファイルにメタデータ・レコードが含まれていない場合、Replicatプロセスには証跡データを記述したメタデータが必要です。これは、データベースまたはソース定義ファイルから取得します。このメタデータは、読み取る対象の証跡(./dirdat/aa)の列名およびデータ型を定義します。

TARGETDB LIBFILE libggjava.so SET properties= dirprm/javarep.properties

TARGETDB LIBFILE libggjava.soパラメータは、Javaモジュールを初期化するトリガーとして機能します。Javaプロパティ・ファイルを指定するSET句は、オプションです。指定した場合、これにはJavaモジュールのプロパティ・ファイルを示す絶対パスまたは相対パス(Replicat実行可能ファイルからの相対パス)が含まれます。デフォルト値は、dirprmディレクトリのreplicat_name.propertiesです。

MAP schema.*, TARGET *.*;

Javaモジュールに渡す表。含まれていない表はスキップされます。ソース表からターゲット表へのマッピングが必要な場合は、Oracle GoldenGateの管理for Windows and UNIXの「データのマッピングと操作」の説明に従って、MAP source_specification TARGET target_specificationを使用できます。

GROUPTRANSOPS 1000

ソース・トランザクションを1つの大きいターゲット・トランザクションにグループ化して、パフォーマンスを改善します。GROUPTRANSOPSの1000はデフォルト設定です。GROUPTRANSOPSでは、ソース・トランザクションの分割を回避するために、絶対値ではなく最小値を設定します。Replicatは、グループ内の最後のソース・トランザクションからすべての操作を受信するまで待機してから、ターゲット・トランザクションを適用します。

たとえば、トランザクション1に200の操作が含まれ、トランザクション2に400の操作が含まれ、トランザクション3に500の操作が含まれている場合、GROUPTRANSOPSがデフォルトの1,000に設定されているとしても、Replicatトランザクションには1,100すべての操作が含まれることになります。逆に、トレイルに処理するデータが残っていなければ、ReplicatはGROUPTRANSOPSに設定されている値に到達する前にトランザクションを適用することがあります。

10.4.1.3 Javaハンドラの構成

ハンドラは、Oracle GoldenGate Java配信モジュールにプラグインされるターゲット・アプリケーションとの統合機能です。統合ターゲット(JMSやOracle GoldenGate for Distributed Applications and Analytics (GG for DAA)など)にデータをプッシュする機能を提供するのがJavaハンドラです。Java配信とJavaハンドラを構成するには、Javaアダプタ・プロパティ・ファイルが使用されます。構成をテストするには、組込みファイル・ハンドラを使用できます。次に、プロパティ例とプロパティの説明(#で始まるコメント行)を示します。

# the list of active handlers
gg.handlerlist=myhandler
# set properties on 'myhandler'
gg.handler.myhandler.type=file
gg.handler.myhandler.format=tx2xml.vm
gg.handler.myhandler.file=output.xml

このプロパティ・ファイルでは、次のように宣言しています。

  • アクティブ・イベント・ハンドラ。この例では、myhandlerという名前の1つのイベント・ハンドラがアクティブです。複数のハンドラをカンマで区切って指定できます。たとえば、gg.handlerlist=myhandler, yourhandlerです。

    ノート:

    Oracle GoldenGate for Distributed Applications and Analytics (GG for DAA) 23aiリリース以降では、1つのハンドラのみを指定できます。
  • ハンドラの構成。この例では、myhandlerfileタイプのハンドラと宣言されています(gg.handler.myhandler.type=file)。

    ノート:

    設定可能な有効なプロパティのリストは、各タイプのハンドラ(JMSハンドラ、ファイル・ライター・ハンドラなど)のドキュメントを参照してください。

  • 出力の形式は、Velocityテンプレートtx2xml.vmによって定義されます。メッセージ形式を定義する独自のカスタム・テンプレートを指定できます。Javaクラスパスを基準としてテンプレートのパスを指定します。

このプロパティ・ファイルは、実際、取得されたトランザクションを出力ファイルoutput.xmlに書き込む完全な例です。他のハンドラ・タイプは、キーワードjms_text(またはjms)、jms_mapsinglefile (ロールしないファイル)などを使用して指定できます。カスタム・ハンドラを実装できます。この場合、タイプはハンドラのJavaクラスの完全修飾名です。GG for DAAパッケージには、組込みのDAAターゲット・タイプも含まれています。

ノート:

設定可能な有効なプロパティのリストは、各タイプのハンドラ(JMSハンドラ、ファイル・ライター・ハンドラなど)のドキュメントを参照してください。

10.4.2 Java配信の実行

10.4.2.1 アプリケーションの起動

Java配信を実行し、Javaアプリケーションを実行する場合に必要なのは、既存のOracle GoldenGate証跡ファイルのみです。証跡ファイルにメタデータ・レコードが含まれていない場合、証跡ファイルでの操作のスキーマを記述したソース定義ファイルも必要です。次の例では、TCUSTMERTCUSTORDという単純な証跡を使用しています(Oracle GoldenGateソフトウェアのダウンロードに属するデモのSQLに対応しています)。

10.4.2.1.1 Replicatの使用の開始

Replicatを使用してJava配信を実行するには、GGSCIからReplicatを起動するだけです。

GGSCI> START REPLICAT javarep
GGSCI> INFO REPLICAT javarep

INFOコマンドでは、次のような情報が返されます。

REPLICAT JAVAREP            Last Started 2015-09-10 17:25 Status RUNNING
Checkpoint Lag              00:00:00 (updated 00:00:00 ago)
Log Read Checkpoint File    ./dirdat/aa0000002015-09-10 17:50:41.000000 
                             RBA 2702
10.4.2.2 Java配信の再起動

Replicatを使用して実行する場合に使用可能なチェックポイント・ファイルには、Replicatプロセス・チェックポイント・ファイルおよびJava配信チェックポイント・ファイルの2つがあります。どちらのファイルもdirchkディレクトリにあり、次の命名規則を使用して作成されます。

Replicatチェックポイント・ファイル

group_name.cpr

Java配信チェックポイント・ファイル:

group_name.cpj

Java配信チェックポイントの作成および使用を抑制するには、次の構文を使用してReplicatプロセスを作成する必要があります。

ADD REPLICAT myrep EXTTRAIL ./dirdat/tr NODBCHECKPOINT

これは、Java配信チェックポイント・ファイルの作成および使用を無効にするNODBCHECKPOINT構文です。

10.4.2.2.1 ReplicatでのJava配信の再起動

2つのチェックポイント情報のうち、どちらの優先度が高いかを選択できるロジックがあるため、Replicatでのチェックポイント処理のほうが直接的です。ロジックは次のようになります。

  • ユーザーがADDまたはALTER REPLICATを手動で実行した後でJava配信を起動した場合は、Replicatプロセスによって保持されているチェックポイント情報が、出発点として使用されます。

  • 手動の操作で事前にチェックポイントが変更されずにJava配信を起動した場合(たとえば、正常停止または異常終了)は、Javaモジュールによって保持されているチェックポイント情報が、出発点として使用されます。

    たとえば、証跡の最初にReplicatを使用してJava配信を再起動する場合は、次のようになります。

    1. Replicatを証跡データの先頭にリセットします。

      GGSCI> ALTER REPLICAT JAVAREP, EXTSEQNO 0, EXTRBA 0

    2. Replicatをリセットします

      GGSCI> START JAVAREP
      GGSCI> INFO JAVAREP
      REPLICAT   JAVAREP    Last Started 2015-09-10 17:25   Status RUNNING
      Checkpoint Lag       00:00:00 (updated 00:00:00 ago)
      Log Read Checkpoint  File ./dirdat/aa000000
      2015-09-10 17:50:41.000000  RBA 2702
      

      Replicatプロセスのステータスが実行中になるには、数秒かかる場合があります。レポート・ファイルをチェックして、異常終了したか、起動中のままかを確認します。

      GGSCI> VIEW REPORT JAVAREP

      クラッシュまたは異常終了の後でJava配信を再起動した場合は、アプリケーションを再起動したとき、Javaモジュールによって保持されている最後の位置キーが使用されます。

10.4.3 イベント・ハンドラの構成

この章では、各種イベント・ハンドラ、使用するイベント・ハンドラの指定方法およびオプションについて説明します。出力のフォーマット方法およびOracle GoldenGateレポート・ファイルの内容について説明します。
10.4.3.1 イベント・ハンドラの指定

トランザクション、操作およびメタデータ・イベントのJavaでの処理は次のようになります。

  • Oracle GoldenGate ReplicatまたはExtractプロセスがローカル証跡データを読み取り、トランザクション、操作およびデータベース・メタデータをJava配信モジュールに渡します。メタデータは、証跡自体のソース定義ファイルから取得できます。

  • Javaフレームワークがイベントを発行します。イベントは、オプションでカスタム・イベント・フィルタによってフィルタされます。

  • ハンドラ(イベント・リスナー)がこれらのイベントを処理し、トランザクション、操作およびメタデータを処理します。特定のタイプのターゲットにカスタム・フォーマッタが適用される場合があります。

既存のハンドラがいくつかあります。

  • 様々な組込みOracle GoldenGate for Distributed Applications and Analytics (GG for DAA)ハンドラでの、サポートされているGG for DAAターゲットへのレコードの適用については、「データの複製」で、GG for DAAでサポートされている様々なハンドラの構成を参照してください。

  • MapMessageを使用するか、TextMessageをカスタマイズ可能なフォーマッタと組み合せて使用し、JMSプロバイダに送信するJMSメッセージ・ハンドラ。

  • JMSメッセージをOracleアドバンスト・キューイング(AQ)に送信する、専用のメッセージ・ハンドラ。

  • 1つのファイルまたはローリング・ファイルに書き込むファイル・ライター・ハンドラ。

    ノート:

    ファイル・ライターはJMS TextMessageハンドラと完全に同じフォーマッタを使用できるため、ファイル・ライター・ハンドラは開発ユーティリティとして特に有用です。ファイル・ライターを使用すると、JMSに実際にメッセージを送らずにJMS用のフォーマッタのテストとチューニングを簡単に行えます。

イベント・ハンドラはメインJavaプロパティ・ファイルを使用して構成できます。あるいは、オプションで別のプロパティ・ファイルから直接プロパティを読み込む場合もあります(ハンドラの実装によって異なります)。ハンドラのプロパティは次の構文を使用して設定されます。

gg.handler.{name}.someproperty=somevalue

これによって、プロパティ・ファイルでnameで識別されるハンドラ・インスタンスのプロパティsomepropertyが値somevalueに設定されます。このnameはプロパティ・ファイルで使用され、アクティブ・ハンドラを定義し、そのプロパティを設定します。これはユーザー定義です。

実装上のノート(Java開発者向け): 前述の例の後、ハンドラがインスタンス化されると、メソッドvoid setSomeProperty (String value)がハンドラ・インスタンスでコールされ、文字列値somevalueが渡されます。JavaBean PropertyEditorもハンドラに対して定義できます。この場合、文字列は、セッター・メソッドに対して適切な型に自動的に変換されます。たとえば、Javaアプリケーション・プロパティ・ファイルで次のような設定だとします。

# the list of active handlers: only two are active
gg.handlerlist=one, two
# set properties on 'one'
gg.handler.one.type=file
gg.handler.one.format=com.mycompany.MyFormatter
gg.handler.one.file=output.xml
# properties for handler 'two'
gg.handler.two.type=jms_text
gg.handler.two.format=com.mycompany.MyFormatter
gg.handler.two.properties=jboss.properties
# set properties for handler 'foo'; this handler is ignored
gg.handler.foo.type=com.mycompany.MyHandler
gg.handler.foo.someproperty=somevalue

タイプによってハンドラ・クラスが識別されます。他のプロパティは、作成されるハンドラのタイプによって異なります。別個のプロパティ・ファイルがハンドラ(JMSハンドラなど)の初期化に使用される場合、プロパティ・ファイルはクラスパスにあります。たとえば、プロパティ・ファイルが{gg_install_dir}/dirprm/foo.propertiesにある場合、プロパティ・ファイルでgg.handler.name.properties=foo.propertiesのように指定します。

10.4.3.2 JMSハンドラ

メインJavaプロパティ・ファイルは、アクティブ・ハンドラを識別します。JMSハンドラは、必要に応じてJMS固有の構成用の個別のプロパティ・ファイルを使用できます。これによって、複数のJMSハンドラが同時に稼働するよう構成できます。

いくつかのJMSプロバイダ(JBoss、TIBCO、Solace、ActiveMQ、WebLogic)用にサンプルが含まれています。使用している環境用の出発点として特定のJMSプロバイダに適したプロパティ・ファイルを選択できます。JMSプロバイダごとに設定は多少異なります。環境に特有の設定もあります。

Java JAR (ggjava)のインストール・ディレクトリには、コア・アプリケーションJAR (ggjava.jar)とそのその依存性がresources/lib/*.jarに含まれています。リソース・ディレクトリはすべての依存性と構成を含み、クラスパス内にあります。

JMSクライアントJARがシステムにすでにある場合、コピーせずに直接参照し、クラスパスに追加できます。

次のタイプのJMSハンドラを指定できます。

  • jms - テキスト・メッセージをトピックまたはキューに送信します。メッセージはVelocityテンプレートを使用するか、Javaでフォーマッタを記述してフォーマットします。ファイルへの書込みの際、同じフォーマッタをjms_text messageに使用できます。(jms_textjmsと同義です。)

  • aq - テキスト・メッセージをOracleアドバンスト・キューイング(AQ)に送信します。aqハンドラは、AQへの配信用に構成されたjmsハンドラです。メッセージはVelocityテンプレートまたはカスタム・フォーマッタを使用してフォーマットできます。

  • jms_map - JMS MapMessageをトピックまたはキューに送信します。メッセージのJMSTypeを表の名前に設定します。メッセージの本体は次のメタデータとそれに続く列名と列値のペアで構成されます。

    • GG_ID - この操作を一意に識別するレコードの位置

    • GG_OPTYPE - SQLのタイプ(挿入/更新/削除)

    • GG_TABLE - 操作が行われた表の名前

    • GG_TX_TIMESTAMP – 操作のタイムスタンプ

10.4.3.3 ファイル・ハンドラ

ファイル・ハンドラは、実際のターゲットがJMSで、メッセージ形式がカスタムJavaまたはVelocityテンプレートを使用して開発されている場合にメッセージ形式の確認に使用されることが多くあります。ファイル・ハンドラを使用するプロパティ・ファイルを次に示します。

# one file handler active, using Velocity template formatting
gg.handlerlist=myfile
gg.handler.myfile.type=file
gg.handler.myfile.rollover.size=5M
gg.handler.myfile.format=sample2xml.vm
gg.handler.myfile.file=output.xml

この例では、1つのハンドラを使用して、(JMSハンドラとファイル・ハンドラが同時に使用されることはある)output.xmlという名前のファイルに書き込みます。sample2xml.vmという名前のVelocityテンプレートを使用します。テンプレートはクラスパスを使用して特定されます。

10.4.3.4 カスタム・ハンドラ

カスタム・ハンドラのコーディングの詳細は、「Javaでのカスタム・ハンドラのコーディング」を参照してください。

10.4.3.5 出力のフォーマット

前述のとおり、既存のJMSおよびファイル出力ハンドラはプロパティ・ファイルを使用して構成できます。各ハンドラには、設定可能な固有のプロパティがあります。たとえば、出力ファイルをファイル・ハンドラに設定したり、JMS宛先をJMSハンドラに設定できます。これらの両ハンドラでカスタム・フォーマッタも指定できます。同じフォーマッタを両方のハンドラに使用できます。カスタム・フォーマットのためにJavaコードを書くかわりに、Velocityテンプレートを指定できます。詳細は、「イベントのフィルタリング」を参照してください。

10.4.3.6 レポート

ReplicatまたはExtractプロセスが停止すると、スループットおよび処理されたデータの量に関するサマリー統計が生成されます。また、統計は、定期的に(指定した時間の経過後または指定した数のレコードの処理後)書き込まれます。時間とレコード数の両方が指定された場合、いずれかのイベントが発生すると、レポートが生成されます。これらの統計サマリーは、Oracle GoldenGateレポート・ファイルおよびログ・ファイルに書き込まれます。

10.4.4 Java配信プロパティ

10.4.4.1 共通プロパティ

次のプロパティは、ReplicatとExtractのどちらを使用するJava配信でも共通です。

10.4.4.1.1 ロギング・プロパティ

ロギングは次のプロパティによって制御されます。

10.4.4.1.1.1 gg.log

使用されるロギングのタイプを指定します。Oracle GoldenGate for Distributed Applications and Analytics (GG for DAA)のデフォルト実装は、jdkオプションです。これは、java.util.logging (JUL)という名前の組込みJavaロギングです。その他のロギング・オプションは、log4jまたはlogbackです。

たとえば、ロギングのタイプをlog4jに設定するには、次のようにします。

gg.log=log4j 

推奨される設定はlog4jです。ログ・ファイルは、インストールのdirrptサブディレクトリに作成されます。デフォルトのログ・ファイル名には、関連付けられているExtractのグループ名が含まれ、ファイル拡張子は.logです。

<process name>_<log level>_log4j.log

したがって、Oracle GoldenGate Replicatプロセスはjavaueと呼ばれ、gg.log.leveldebugに設定されるため、ログ・ファイルの名前は次のようになります。

javaue_debug_log4j.log

10.4.4.1.1.2 gg.log.level

すべてのモジュールを対象とする全体的なログ・レベルを指定します。構文は次のとおりです:

gg.log.level={ERROR|WARN|INFO|DEBUG|TRACE}

ログ・レベルは次のように定義されています。

  • ERROR - エラーが発生した場合にのみメッセージを書き込ます。

  • WARN - エラーおよび警告メッセージを書き込みます。

  • INFO - エラー、警告および情報メッセージを書き込みます。

  • DEBUG - デバッグ・メッセージを含むすべてのメッセージを書き込みます。

  • TRACE - 最高レベルのロギングで、すべてのメッセージが含まれます。

デフォルトのロギング・レベルはINFOです。この場合、メッセージは、起動時、停止時および操作中に定期的に生成されます。レベルをDEBUGに切り替えると、メッセージが大量に生成され、パフォーマンスに影響する場合があります。たとえば、次の例ではグローバル・ロギング・レベルをINFOに設定します。

# global logging level
gg.log.level=INFO
10.4.4.1.1.3 gg.log.file

ログ・ファイルのパスを指定します。構文は次のとおりです:

gg.log.file=path_to_file

ここで、path_to_fileは完全に定義されたログ・ファイルの場所です。これによってログの名前の変更が可能になりますが、複数のReplicatがある場合、誤って他のログを上書きすることがないようReplicat名を含める必要があります。

10.4.4.1.1.4 gg.log.classpath

ロギングの実装に使用されるJARのクラスパスを指定します。ggjava.jarライブラリは必要なロギングの依存関係ライブラリを含んでいるため、この構成プロパティは通常、使用しません。

gg.log.classpath=path_to_jars
10.4.4.1.2 JVM Bootオプション

次のオプションでは、Java Runtime Environmentを構成します。Javaクラスパスとメモリーのオプションは構成可能です。

10.4.4.1.2.1 jvm.bootoptions

JVMの起動時に適用される初期Javaクラスパスおよびその他の起動オプションを指定します。java.class.pathには、UNIX/Linuxの場合コロン(:)、Windowsの場合セミコロン(;)の区切り文字が必要です。ここでは、初期および最大のヒープ・サイズ、クラスパスなど、JVMに対する様々なオプションを指定します。

  • -Xms: 初期Javaヒープ・サイズ

  • -Xmx: 最大Javaヒープ・サイズ

  • -Djava.class.path: 最低でもメイン・アプリケーションJARであるggjava.jarを指定するクラスパス。JMSプロバイダJARなどのその他のJARもここで指定できます。また、これらをJavaアプリケーション・プロパティ・ファイルで指定することもできます。個別のlog4jプロパティ・ファイルを使用する場合、プロパティ・ファイルの場所が、起動オプション変数に含まれているbootoptions java.class.pathに含まれる必要があります。

  • -verbose:jni: 詳細モードで実行します(JNI用)

たとえば (1行ですべて指定):

jvm.bootoptions= -Djava.class.path=ggjava/ggjava.jar 
-Dlog4j.configuration=my-log4j.properties -Xmx512m

log4j.configurationプロパティは、クラスパスの検索によって解決されるlog4jプロパティ・ファイルを示します。独自のlog4j構成を使用することも、あらかじめ構成されたlog4j設定であるlog4j.properties(デフォルト・レベルのロギング)、debug-log4j.properties(デバッグ・ロギング)またはtrace-log4j.properties(非常に詳細なロギング)のいずれかを使用することもできます。Replicatプロセスでlog4jロギングを使用するには、gg.log=log4jを設定する必要があります。

これらのファイルはすでにクラスパスに指定されているので、事前構成されたlog4j設定のいずれかを使用すれば、クラスパスの変更は必要ありません。-Djava.class.path変数には、*ワイルドカードを指定せずに、カスタムのlog4j構成ファイルを含むディレクトリへのパスが含まれている必要があります

10.4.4.2 配信プロパティ

次のプロパティはJava配信に使用可能です。

10.4.4.2.1 一般プロパティ

次のプロパティは、すべてのライター構成に適用されます。

10.4.4.2.1.1 goldengate.userexit.writers

ライターの名前を指定します。これは常にjvmで、変更しないでください。

たとえば:

goldengate.userexit.writers=jvm

ファイル内の他のすべてのプロパティにライター名jvmを接頭辞として付けます。

10.4.4.2.1.2 goldengate.userexit.chkptprefix

Javaチェックポイント・ファイル名に追加される接頭辞の文字列値を指定します。たとえば:

goldengate.userexit.chkptprefix=javaue_

10.4.4.2.1.3 goldengate.userexit.nochkpt

チェックポイント・ファイルを無効または有効にします。デフォルトは、falseで、チェックポイント・ファイルはenabledです。トランザクションがサポートされ、ターゲットで有効な場合、このプロパティをtrueに設定します。

たとえばJavaアダプタ・プロパティは、JMSがターゲットで、JMSローカル・トランザクションがenabled (デフォルト)の場合、goldengate.userexit.nochkpt=trueを設定し、ユーザー・イグジット・チェックポイント・ファイルを無効にします。ハンドラでlocalTx=falseを設定することで、JMSトランザクションが無効になっている場合は、goldengate.userexit.nochkpt=falseを設定してチェックポイント・ファイルを有効にします。

goldengate.userexit.nochkpt=true|false

10.4.4.2.1.4 goldengate.userexit.usetargetcols

ターゲット列へのマッピングが可能かどうかを指定します。デフォルトはfalseで、ターゲット・マッピングなしです。

goldengate.userexit.usetargetcols=true|false

10.4.4.2.2 統計およびレポート

チェックポイント・ファイル処理を無効または有効にします。これによって、標準のOracle GoldenGateレポーティングは不完全になります。Java用Oracle GoldenGateでは、独自のレポートを追加し、この問題に対応します。

統計は、t秒ごとまたはnレコードごとに(両方が指定された場合、先に満たされた方の基準)、レポートされます。

記録される統計には、Replicatモジュールによって保持されるものとJavaモジュールから取得されるものの2つがあります。Java側から受信されるレポートは、個々のハンドラによってフォーマットされ、返されます。

統計には、操作の合計数、トランザクションおよび対応するレートが含まれています。

10.4.4.2.2.1 jvm.stats.display

統計のOracle GoldenGateレポート・ファイルおよびユーザー・イグジット・ログ・ファイルへの出力を制御します。

次の例では、これらの統計を出力します。

jvm.stats.display=true
10.4.4.2.2.2 jvm.stats.full

C側からの統計に加え、Java側からの統計の出力を制御します。

Java側の統計はより詳細ですが、オーバーヘッドも増えます。このため、統計のレポートの頻度が高い場合、詳細度の低いサマリーで十分です。stats.fullプロパティはfalseに設定することをお薦めします。

次の例では、C以外にJava統計を出力します。

jvm.stats.full=true
10.4.4.2.2.3 jvm.stats.time | jvm.stats.numrecs

統計がレポートされる間隔(秒)またはレコード数を指定します。デフォルトでは、毎時または10000レコードごと(いずれか先に起きた方)にレポートします。

たとえば、10分ごとまたは1000レコードごとにレポートするには、次のように指定します。

jvm.stats.time=600
jvm.stats.numrecs=1000

Javaアプリケーション統計は、ハンドラに依存します。

  • すべてのハンドラについて、少なくとも総経過時間、処理時間、操作数、トランザクション数があります。

  • JMSハンドラの場合、送受信されたバイト数合計もあります。

  • レポートはテンプレートを使用してカスタマイズできます。

10.4.4.3 Javaアプリケーション・プロパティ

Javaアプリケーション・プロパティ・ファイルで設定できるプロパティを次に定義します。

10.4.4.3.1 すべてのハンドラ用のプロパティ

次のプロパティがすべてのハンドラに適用されます。

10.4.4.3.1.1 gg.handlerlist

ハンドラ・リストは、アクティブ・ハンドラのカンマ区切りのリストです。これらの値はプロパティ・ファイルの以降の部分で使用され、各ハンドラが構成されます。たとえば:

gg.handlerlist=name1, name2
gg.handler.name1.propertyA=value1
gg.handler.name1.propertyB=value2
gg.handler.name1.propertyC=value3
gg.handler.name2.propertyA=value1
gg.handler.name2.propertyB=value2
gg.handler.name2.propertyC=value3

handlerlistプロパティを使用すると、完全に構成されたハンドラをプロパティ・ファイルに含めることができ、handlerlistから削除することで無効にすることができます。

10.4.4.3.1.2 gg.handler.name.type

このタイプのハンドラ。組込みハンドラ用にあらかじめ定義された値または完全修飾Javaクラス名です。構文は次のとおりです:

gg.handler.name.type={jms|jms_map|aq|singlefile|rollingfile|custom_java_class}

説明:

最後のハンドラ以外すべて、事前定義のハンドラです。

  • jms - トランザクション、操作およびメタデータをフォーマットされたメッセージとしてJMSプロバイダに送信します。

  • aq - トランザクション、操作およびメタデータをフォーマットされたメッセージとしてOracleアドバンスト・キューイング(AQ)に送信します。

  • jms_map - JMSマップ・メッセージを送信します。

  • singlefile - ディスク上の1つのファイルに書き込みますが、ファイルをロールしません。

  • rollingfile - トランザクション、操作およびメタデータをディスク上のファイルに書き込み、特定のサイズ、時間、またはその両方を超えると、ファイルをロールオーバーします。たとえば:

    gg.handler.name1.rolloverSize=5000000
    gg.handler.name1.rolloverTime=1m
    
    
  • custom_java_class - Java用Oracle GoldenGateのAbstractHandlerクラスを拡張する任意のクラス。トランザクション、操作、メタデータ・イベントを処理できます。

    Oracle GoldenGate for Distributed Applications and Analytics (GG for DAA)のパッケージには、様々なGG for DAAターゲットに書き込むための事前定義されたハンドラも含まれています。

10.4.4.3.2 フォーマットされた出力用のプロパティ

次のプロパティは、フォーマットされた出力を生成できるすべてのハンドラに適用されます。これには、次のようなものがあります。

  • jms_text handlerハンドラ(jms_map handlerハンドラではない)

  • aqハンドラ

  • フォーマットされた出力をファイルに書き込むsinglefileおよびrollingハンドラ

  • 事前定義されているOracle GoldenGate for Distributed Applications and Analytics (GG for DAA)ハンドラ

10.4.4.3.2.1 gg.handler.name.format

JMS、Oracle GoldenGate for Distributed Applications and Analytics (GG for DAA)ターゲットまたはファイルに送信するメッセージに操作とトランザクションを変換するために使用する形式を指定します。形式はハンドラごとに一意に指定されます。値は次のとおりです。

  • Velocityテンプレート

  • Javaクラス名(完全修飾。指定されるクラスはフォーマッタのタイプである必要があります)

  • 区切られた値の場合のcsv(カンマ区切り値など。デリミタはカスタマイズできます)

  • 固定長フィールドの場合のfixed

  • 次のような組込みフォーマッタ

    • xml – デモXMLフォーマット

    • xml2 – 内部XMLフォーマット

たとえば、カスタムJavaクラスを指定するには、次のようにします。

gg.handlerlist=abc
gg.handler.abc.format=com.mycompany.MyFormat

または、Velocityテンプレートの場合:

gg.handlerlist=xyz
gg.handler.xyz.format=path/to/sample.vm

テンプレートを使用する場合、クラスパス内のディレクトリまたはJARを基準にファイルが検索されます。デフォルトでは、Oracle GoldenGateインストール・ディレクトリがクラスパス内にあるため、前述のテンプレートは、Oracle GoldenGateのインストール場所のdirprmディレクトリに配置できます。

デフォルトの形式は、組込みXMLフォーマッタを使用することです。

10.4.4.3.2.2 gg.handler.name.includeTables

このハンドラによって含められる表のリストを指定します。

表のスキーマ(または所有者)が指定される場合、そのスキーマのみが表名に一致します。それ以外の場合、表名は任意のスキーマに一致します。表のカンマ区切りのリストを指定できます。たとえば、ハンドラに表foo.customerおよびbar.ordersのみを処理させるには、次のようにします。

gg.handler.myhandler.includeTables=foo.customer, bar.orders

表のカタログおよびスキーマ(または所有者)が指定される場合、そのスキーマのみが表名に一致します。それ以外の場合、表名は任意のカタログおよびスキーマに一致します。表のカンマ区切りのリストを指定できます。たとえば、ハンドラに表dbo.foo.customerおよびdbo.bar.ordersのみを処理させるには、次のようにします。

gg.handler.myhandler.includeTables=dbo.foo.customer, dbo.bar.orders

ノート:

表単位で表での操作を選択的に処理するには、ハンドラは操作モードで処理している必要があります。ハンドラがトランザクション・モードで処理しており、1つのトランザクションに複数の表にまたがる複数の操作が含まれている場合、いずれかの表が表のリストに一致すれば、トランザクションは含められます。

10.4.4.3.2.3 gg.handler.name.excludeTables

このハンドラによって除外される表のリストを指定します。

表のスキーマ(または所有者)が指定される場合、そのスキーマのみが表名に一致します。それ以外の場合、表名は任意のスキーマに一致します。表のリストはカンマ区切りで指定されます。たとえば、すべてのスキーマの表date_modified以外のすべての表に対するすべての操作をハンドラが処理するには、次のようにします。

gg.handler.myhandler.excludeTables=date_modified

表のカタログおよびスキーマ(または所有者)が指定される場合、そのスキーマのみが表名に一致します。それ以外の場合、表名は任意のカタログおよびスキーマに一致します。表のリストはカンマ区切りで指定されます。たとえば、カタログdboおよびスキーマbarの表date_modified以外のすべての表に対するすべての操作をハンドラが処理するには、次のようにします。

gg.handler.myhandler.excludeTables=dbo.bar.date_modified
10.4.4.3.2.4 gg.handler.name.mode、gg.handler.name.format.mode

1メッセージ当たり1つの操作を出力する(op)か、1メッセージ当たり1つのトランザクションを出力する(tx)か指定します。デフォルトは、opです。カスタム・フォーマッタの場合、gg.handler.name.format.modeを使用します。

10.4.4.3.3 CSVおよび固定形式の出力用プロパティ

ハンドラがコンマ区切り値(CSV) CSVまたはfixed形式の出力を使用するよう設定されている場合、次のプロパティも設定できます。

10.4.4.3.3.1 gg.handler.name.format.delim

フィールド間に使用するデリミタを指定します。これに値を設定しない場合、デリミタは使用されません。たとえば:

gg.handler.handler1.format.delim=,
10.4.4.3.3.2 gg.handler.name.format.quote

列値が引用符付きの場合、使用する引用文字を指定します。たとえば:

gg.handler.handler1.format.quote='
10.4.4.3.3.3 gg.handler.name.format.metacols

レコードの先頭、すべての列データの前に出現するメタデータ列値を指定します。次のものを出現順に指定します。

  • position - 証跡内のレコードの一意の位置インジケータ

  • opcode - レコードの挿入、更新または削除を表すIUまたはD(「insertChar」、「updateChar」、「deleteChar」を参照)

  • txind - 0=先頭、1=中間、2=末尾、3=トランザクション全体などのトランザクション・インジケータ(「beginTxChar」、「middleTxChar」、「endTxChar」、「wholeTxChar」を参照)

  • opcount - 0から始まるトランザクション内のレコードの位置

  • catalog – レコードのスキーマのカタログ

  • schema - レコードの表のスキーマ/所有者

  • tableonly - 表のみ(スキーマ/所有者なし)

  • table – 表の完全名、catalog.schema.table

  • timestamp - レコードのコミット・タイムスタンプ

たとえば:

gg.handler.handler1.format.metacols=opcode, table, txind, position
10.4.4.3.3.4 gg.handler.name.format.missingColumnChar

ソース・データベース・トランザクション・ログから取得されなかった列値に対する特別な列接頭辞を指定します。列値は証跡になく、値があるか、NULLかは不明です。

列値の欠落状態を表すために使用される文字はカスタマイズできます。たとえば:

gg.handler.handler1.format.missingColumnChar=M

デフォルトでは、欠落している列値には空の文字列が設定され、表示されません。

10.4.4.3.3.5 gg.handler.name.format.presentColumnChar

証跡にあり、NULLではない列値に対する特別な列接頭辞を指定します。

列の状態を表すために使用される文字はカスタマイズできます。たとえば:

gg.handler.handler1.format.presentColumnChar=P

デフォルトでは、存在している列値には空の文字列が設定され、表示されません。

10.4.4.3.3.6 gg.handler.name.format.nullColumnChar

証跡にあり、NULLに設定されている列値に対する特別な列接頭辞を指定します。

列の状態を表すために使用される文字はカスタマイズできます。たとえば:

gg.handler.handler1.format.nullColumnChar=N

デフォルトでは、nullの列値には空の文字列が設定され、表示されません。

10.4.4.3.3.7 gg.handler.name.format.beginTxChar

レコードをトランザクションの先頭と識別するために使用されるヘッダー・メタデータ文字(「metacols」を参照)を指定します。たとえば:

gg.handler.handler1.format.beginTxChar=B
10.4.4.3.3.8 gg.handler.name.format.middleTxChar

レコードをトランザクションの中間と識別するために使用されるヘッダー・メタデータ文字(「metacols」を参照)を指定します。たとえば:

gg.handler.handler1.format.middleTxChar=M
10.4.4.3.3.9 gg.handler.name.format.endTxChar

レコードをトランザクションの末尾と識別するために使用されるヘッダー・メタデータ文字(「metacols」を参照)を指定します。たとえば:

gg.handler.handler1.format.endTxChar=E
10.4.4.3.3.10 gg.handler.name.format.wholeTxChar

レコードを完全なトランザクション(トランザクション全体と呼ばれる)と識別するために使用されるヘッダー・メタデータ文字(「metacols」を参照)を指定します。たとえば:

gg.handler.handler1.format.wholeTxChar=W
10.4.4.3.3.11 gg.handler.name.format.insertChar

挿入操作を識別する文字を指定します。デフォルトは、Iです。

たとえば、挿入操作の場合、IのかわりにINSを使用するには、次のようにします。

gg.handler.handler1.format.insertChar=INS
10.4.4.3.3.12 gg.handler.name.format.updateChar

更新操作を識別する文字を指定します。デフォルトは、Uです。

たとえば、更新操作の場合、UのかわりにUPDを使用するには、次のようにします。

gg.handler.handler1.format.updateChar=UPD
10.4.4.3.3.13 gg.handler.name.format.deleteChar

削除操作を識別する文字を指定します。デフォルトは、Dです。

たとえば、削除操作の場合、DのかわりにDELを使用するには、次のようにします。

gg.handler.handler1.format.deleteChar=DEL
10.4.4.3.3.14 gg.handler.name.format.truncateChar

切捨て操作を識別する文字を指定します。デフォルトは、Tです。

たとえば、切捨て操作にTではなくTRUNCを使用するには、次のようにします。

gg.handler.handler1.format.truncateChar=TRUNC
10.4.4.3.3.15 gg.handler.name.format.endOfLine

行末文字を指定します。

  • EOL - ネイティブ・プラットフォーム

  • CR - ニュートラル(UNIXスタイル\n)

  • CRLF - Windows (\r\n)

たとえば:

gg.handler.handler1.format.endOfLine=CR
10.4.4.3.3.16 gg.handler.name.format.justify

固定フィールドを左詰めにするか、右詰めにするかを指定します。たとえば:

gg.handler.handler1.format.justify=left
10.4.4.3.3.17 gg.handler.name.format.includeBefores

ビフォア・イメージを出力に含めるかどうかを制御します。証跡にビフォア・イメージがある必要があります。たとえば:

gg.handler.handler1.format.includeBefores=false
10.4.4.3.4 ファイル・ライター・プロパティ

次のプロパティは、出力をファイルに書き込むハンドラ(fileハンドラおよびsinglefileハンドラ)にのみ適用されます。

10.4.4.3.4.1 gg.handler.name.file

指定されたハンドラの出力ファイルの名前を指定します。ハンドラがローリング・ファイルの場合、この名前は、ロールされたファイルの名前の導出に使用されます。デフォルトのファイル名は、output.xmlです。

10.4.4.3.4.2 gg.handler.name.append

ファイルが追加(true)されるか、再起動時に上書き(false)されるかを制御します。

10.4.4.3.4.3 gg.handler.name.rolloverSize

ファイル・ハンドラを使用する場合、ロールオーバーが試行されるファイルのサイズを指定します。ファイル・サイズは最低このサイズですが、ほとんどの場合、これより大きいです。操作およびトランザクションはファイル間で分割されません。サイズはバイト数で指定されますが、接尾辞を指定してMBまたはKBを識別できます。たとえば:

gg.handler.myfile.rolloverSize=5MB

デフォルトのロールオーバー・サイズは、10MBです。

10.4.4.3.5 JMSハンドラ・プロパティ

次のプロパティがJMSハンドラに適用されます。これらの値のいくつかは、ハンドラの名前を使用してJavaアプリケーション・プロパティ・ファイルで定義できます。他のプロパティは、個別のJMSプロパティ・ファイルに含めることができますが、これは、一度に複数のJMSハンドラを使用する場合、有用です。たとえば:

gg.handler.myjms.type=jms_text
gg.handler.myjms.format=xml
gg.handler.myjms.properties=weblogic.properties

Velocityテンプレートおよびフォーマット・プロパティ・ファイル同様、この追加JMSプロパティ・ファイルはクラスパスで検索されます。dirprmディレクトリはデフォルトでクラスパスに含まれているため、前述のプロパティ・ファイルweblogic.propertiesは、{gg_install_dir}/dirprm/weblogic.propertiesで検索できます。

Javaアプリケーション・プロパティ・ファイルの設定は、追加のJMSプロパティ・ファイル(前述の例のweblogic.properties)で設定された対応する値をオーバーライドします。次の例では、宛先プロパティがJavaアプリケーション・プロパティ・ファイルで指定されています。これは、2つのハンドラmyjms1およびmyjms2に同じデフォルト接続情報を使用しますが、ターゲット宛先キューをカスタマイズします。

gg.handlerlist=myjms1,myjms2
gg.handler.myjms1.type=jms_text
gg.handler.myjms1.destination=queue.sampleA
gg.handler.myjms1.format=sample.vm
gg.handler.myjms1.properties=tibco-default.properties
gg.handler.myjms2.type=jms_map
gg.handler.myjms2.destination=queue.sampleB
gg.handler.myjms2.properties=tibco-default.properties

プロパティを設定するには、次のようにハンドラ名を接頭辞として指定します。

gg.handlerlist=sample
gg.handler.sample.type=jms_text
gg.handler.sample.format=my_template.vm
gg.handler.sample.destination=gg.myqueue
gg.handler.sample.queueortopic=queue
gg.handler.sample.connectionUrl=tcp://host:61616?jms.useAsyncSend=true
gg.handler.sample.useJndi=false
gg.handler.sample.connectionFactory=ConnectionFactory
gg.handler.sample.connectionFactoryClass=\
    org.apache.activemq.ActiveMQConnectionFactory
gg.handler.sample.timeToLive=50000
10.4.4.3.5.1 標準JMS設定

次に、設定可能なJMSプロパティと許容される値について簡単に説明します。これらは、jms_text (TextMessage)およびjms_map (MapMessage)の両方のJMSハンドラ・タイプに適用されます。

10.4.4.3.5.1.1 gg.handler.name.destination

メッセージが送信されるキューまたはトピック。これは、JMSサーバーで適切に構成される必要があります。一般的な値は、queue/Aqueue.Testexample.MyTopicなどです。

gg.handler.name.destination=queue_or_topic
10.4.4.3.5.1.2 gg.handler.name.user

(オプション)JMSサーバーへのメッセージの送信に必要なユーザー名。

gg.handler.name.user=user_name
10.4.4.3.5.1.3 gg.handler.name.password

(オプション)JMSサーバーへのメッセージの送信に必要なパスワード

gg.handler.name.password=password
10.4.4.3.5.1.4 gg.handler.name.queueOrTopic

ハンドラがキューに送信する(単一受信者)か、トピックに送信する(パブリッシュ/サブスクライブ)か。これは、JMSプロバイダで適切に構成される必要があります。このプロパティは、gg.handler.name.destinationの別名です。構文は次のとおりです:

gg.handler.name.queueOrTopic=queue|topic

説明:

  • queue - メッセージは読み取られると、削除されます。これはデフォルトです。

  • topic - メッセージはパブリッシュされ、複数のサブスクライバに配信されます。

10.4.4.3.5.1.5 gg.handler.name.persistent

配信モードが永続に設定されているかどうか。メッセージが永続の場合、クライアントの送信操作の一環としてメッセージを安定的なストレージに記録するようJMSプロバイダを構成する必要があります。構文は次のとおりです:

gg.handler.name.persistent={true|false}
10.4.4.3.5.1.6 gg.handler.name.priority

JMSで、0を最低、9を最高とする10段階の優先度の値が定義されます。デフォルトでは優先度は4に設定されます。構文は次のとおりです:

gg.handler.name.priority=integer

たとえば:

gg.handler.name.priority=5
10.4.4.3.5.1.7 gg.handler.name.timeToLive

生成されたメッセージがメッセージ・システムによって保持される時間のディスパッチ時間からの長さ(ミリ秒)。値0は、時間が無制限であることを指定します。デフォルトは、0です。構文は次のとおりです:

gg.handler.name.timeToLive=milliseconds

たとえば:

gg.handler.name.timeToLive= 36000
10.4.4.3.5.1.8 gg.handler.name.connectionFactory

JNDIを使用して検索する接続ファクトリの名前。ConnectionFactoryJNDINameは別名です。構文は次のとおりです:

gg.handler.name.connectionFactory=JNDI_name
10.4.4.3.5.1.9 gg.handler.name.useJndi

gg.handler.name.usejndifalseの場合、JNDIはJMSクライアントの構成に使用されません。かわりに、ファクトリおよび接続が明示的に構築されます。構文は次のとおりです:

gg.handler.name.useJndi=true|false
10.4.4.3.5.1.10 gg.handler.name.connectionUrl

JNDIを使用しない場合にのみ接続URLを使用して明示的に接続を作成します。構文は次のとおりです:

gg.handler.name.connectionUrl=url
10.4.4.3.5.1.11 gg.handler.name.connectionFactoryClass

JNDIを使用しない場合にのみ接続ファクトリ・クラスを使用してファクトリにアクセスします。このプロパティの値は、ファクトリ・オブジェクトを明示的にインスタンス化および構築するJavaクラス名です。

gg.handler.name.connectionFactoryClass=java_class_name
10.4.4.3.5.1.12 gg.handler.name.localTX

ローカル・トランザクションを使用するかどうかを指定します。デフォルトはtrueで、ローカル・トランザクションが使用されます。構文は次のとおりです:

gg.handler.name.localTX=true|false
10.4.4.3.5.1.13 gg.handlerlist.nop

JMSメッセージの送信を無効にし、メッセージ生成のテストをできるようにします。これは、テスト目的でのみ使用されるグローバル・プロパティです。イベントは従前どおり生成されて処理され、メッセージが構築されます。デフォルトはfalseで、メッセージの送信を無効にしません。構文は次のとおりです:

gg.handlerlist.nop=true|false

ユーザーはこのオプションを利用して、ハンドラ・モジュールを伴わずに処理する証跡レコードのパフォーマンスを測定できます。このアプローチを使うと、証跡レコードをターゲット・システムに適用するとき、パフォーマンスに問題が生じる可能性を下げられます。

10.4.4.3.5.1.14 gg.handler.name.physicalDestination

JNDIプロバイダではなくConnectionFactory APIから取得した、キューまたはトピック・オブジェクトの名前。

gg.handler.name.physicalDestination=queue_name

10.4.4.3.5.2 グループ・トランザクション・プロパティ

これらのプロパティは、トランザクションのグループ化に限度を設定します。

10.4.4.3.6 JNDIプロパティ

これらのJNDIプロパティは、接続ファクトリと初期宛先を検索するための初期コンテキストへの接続に必要です。

java.naming.provider.url=url
java.naming.factory.initial=java-class-name

JNDIセキュリティがenabledな場合、次のプロパティを設定できます。

java.naming.security.principal=user-name
java.naming.security.credentials=password-or-other-authenticator

たとえば:

java.naming.provider.url= t3://localhost:7001
java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory
java.naming.security.principal=jndiuser
java.naming.security.credentials=jndipw
10.4.4.3.7 一般プロパティ

次のプロパティは、Javaフレームワーク用に使用される一般プロパティです。

10.4.4.3.7.1 gg.classpath

クラスパスに追加するディレクトリまたはJARの追加パスのカンマ区切りのリストを指定します。オプションで、Windowsシステムの場合はセミコロン、UNIXの場合はコロンでリストを区切ることができます。たとえば:

gg.classpath=C:\Program Files\MyProgram\bin;C:\Program Files\ProgramB\app\bin;

カスタムJava JARへのパス指定、またはOracle GoldenGate for Distributed Applications and Analytics (GG for DAA)の外部依存関係へのパス指定を構成するには、このアダプタ・プロパティ・ファイル構成プロパティを使用する必要があります。

10.4.4.3.7.2 gg.report.time

統計を計算してExtractに送信し、レポートを処理する頻度を指定します。Extractがレポートを出力するよう構成されている場合、これらの統計が含められます。構文は次のとおりです:

gg.report.time=report_interval{s|m|h}

説明:

  • report_intervalは整数です。

  • 有効な時間単位は、次のとおりです。

    • s - 秒

    • m - 分

    • h - 時間

値が入力されない場合、デフォルトは24時間ごとの計算および送信です。

10.4.4.3.7.3 gg.binaryencoding

バイナリ・エンコーディング・タイプを指定します。このプロパティを使用して、バイナリ・データの必要な出力エンコーディングを構成できます。たとえば:

gg.binaryencoding=base64|hex

デフォルト値はbase64です。バイナリ・データを表す有効な値は次のとおりです。

  • base64 - base64文字列 

  • hex - 16進数文字列

10.4.4.3.8 Java配信のトランザクションのグループ化

トランザクションのグループ化により、Java統合(特にOracle GoldenGate for Distributed Applications and Analytics (GG for DAA)統合)のパフォーマンスが大幅に向上する可能性があります。Java配信には、トランザクションのグループ化を実行する機能があります。Java配信がReplicatプロセスにホストされている場合、トランザクションのグループ化にはGROUPTRANSOPS Replicat構成を使用する必要があります。

10.4.5 カスタム・フィルタ、フォーマッタおよびハンドラの開発

10.4.5.1 イベントのフィルタリング

デフォルトでは、すべてのトランザクション、操作およびメタデータ・イベントがDataSourceListenerイベント・ハンドラに渡されます。イベント・フィルタを実装して、ハンドラに送信するイベントをフィルタできます。たとえば、フィルタで、特定の列値を含む特定の表に対する特定の操作を選択できます。

フィルタは相加的です。複数のフィルタがハンドラに設定されている場合、イベントがハンドラに渡されるには、すべてのフィルタがtrueを返す必要があります。

フィルタは、Javaアプリケーション・プロパティ・ファイルを使用して構成できます。

# handler "foo" only receives certain events
gg.handler.one.type=jms
gg.handler.one.format=mytemplate.vm
gg.handler.one.filter=com.mycompany.MyFilter

フィルタをアクティブにするには、フィルタを記述し、ハンドラに設定します。追加のロジックを特定のハンドラに追加する必要はありません。

10.4.5.2 カスタム・フォーマット

次のようにして、組込みハンドラの出力フォーマットをカスタマイズできます。

  • Javaでのカスタム・フォーマッタの記述。または

  • Velocityテンプレートの使用

10.4.5.2.1 Javaでのカスタム・フォーマッタのコーディング

前述の例では、同じフォーマッタ(com.mycompany.MyFormatter)を使用するJMSハンドラとファイル出力ハンドラを示しています。次の例は、このフォーマッタの実装方法の例です。

例10-12 カスタム・フォーマットの実装

package com.mycompany.MyFormatter;
import oracle.goldengate.datasource.DsOperation;
import oracle.goldengate.datasource.DsTransaction;
import oracle.goldengate.datasource.format.DsFormatterAdapter;
import oracle.goldengate.datasource.meta.ColumnMetaData;
import oracle.goldengate.datasource.meta.DsMetaData;
import oracle.goldengate.datasource.meta.TableMetaData;
import java.io.PrintWriter;
public class MyFormatter extends DsFormatterAdapter {
        public MyFormatter() { }
        @Override
        public void formatTx(DsTransaction tx,
DsMetaData meta,
PrintWriter out)
        {
            out.print("Transaction: " );
            out.print("numOps=\'" + tx.getSize() + "\' " );
            out.println("ts=\'" + tx.getStartTxTimeAsString() + "\'");
            for(DsOperation op: tx.getOperations()) {
TableName currTable = op.getTableName();
TableMetaData tMeta = dbMeta.getTableMetaData(currTable);
String opType = op.getOperationType().toString();
String table = tMeta.getTableName().getFullName();
out.println(opType + " on table \"" + table + "\":" );
int colNum = 0;
for(DsColumn col: op.getColumns())
{
ColumnMetaData cMeta = tMeta.getColumnMetaData( colNum++ );
out.println(
cMeta.getColumnName() + " = " + col.getAfterValue() );
}
        }
        @Override
        public void formatOp(DsTransaction tx,
DsOperation op,
TableMetaData tMeta,
PrintWriter out)
        {
            // not used...
        }
}

フォーマッタは、トランザクション全体のフォーマット(コミット後)、または各操作のフォーマット(受信後、コミット前)の方法を定義します。フォーマッタが操作モードの場合、formatOp(...)がコールされます。そうではない場合、トランザクション・コミット時にformatTx(...)がコールされます。

このカスタム・フォーマッタをコンパイルして使用するには、Java用Oracle GoldenGate JARをクラスパスに含め、コンパイルした.classファイルをgg_install_dir/dirprmに配置します。

javac -d gg_install_dir/dirprm
-classpath ggjava/ggjava.jar MyFormatter.java

結果のクラス・ファイルは、resources/classesに(正しいパッケージ構造で)配置されます。

gg_install_dir/dirprm/com/mycompany/MyFormatter.class

あるいは、カスタム・クラスをJARに含めることもできます。この場合、JARファイルをユーザー・イグジット・プロパティを使用してJVMクラスパスに含める(jvm.bootoptionsプロパティでjava.class.pathを使用)か、Javaアプリケーション・プロパティ・ファイルを設定してカスタムJARを含めます。

# set properties on 'one'
gg.handler.one.type=file
gg.handler.one.format=com.mycompany.MyFormatter
gg.handler.one.file=output.xml
gg.classpath=/path/to/my.jar,/path/to/directory/of/jars/*
10.4.5.2.2 Velocityテンプレートの使用

Velocityテンプレートは、カスタム・フォーマット用のJavaコードを記述するかわりの方法として、フォーマッタのプロトタイプを簡単に作成するよい代替方法です。たとえば、次のテンプレートをJMSまたはファイル・ハンドラの形式として指定します。

Transaction: numOps='$tx.size' ts='$tx.timestamp'
#for each( $op in $tx )
operation: $op.sqlType, on table "$op.tableName":
#for each( $col in $op )
$op.tableName, $col.meta.columnName = $col.value
#end
#end

テンプレートの名前がsample.vmとすると、次のようにクラスパスに配置します。

gg_install_dir/dirprm/sample.vm
	

テンプレートを使用するようJavaアプリケーション・プロパティ・ファイルを更新します。

# set properties on 'one'
gg.handler.one.type=file
gg.handler.one.format=sample.vm
gg.handler.one.file=output.xml

テンプレートを変更する場合、Javaソースを再コンパイルする必要はありません。テンプレートを保存してJavaアプリケーションを再実行するのみです。アプリケーションを実行すると、次の出力が生成されます(表の名前はSCHEMA.SOMETABLEで、列はTESTCOLAおよびTESTCOLBとします)。

Transaction: numOps='3' ts='2008-12-31 12:34:56.000'
operation: UPDATE, on table "SCHEMA.SOMETABLE":
SCHEMA.SOMETABLE, TESTCOLA = value 123
SCHEMA.SOMETABLE, TESTCOLB = value abc
operation: UPDATE, on table "SCHEMA.SOMETABLE":
SCHEMA.SOMETABLE, TESTCOLA = value 456
SCHEMA.SOMETABLE, TESTCOLB = value def
operation: UPDATE, on table "SCHEMA.SOMETABLE":
SCHEMA.SOMETABLE, TESTCOLA = value 789
SCHEMA.SOMETABLE, TESTCOLB = value ghi
10.4.5.3 Javaでのカスタム・ハンドラのコーディング

カスタム・ハンドラは、次の例で示すように、AbstractHandlerを拡張することで実装できます。

import oracle.goldengate.datasource.*;
import static oracle.goldengate.datasource.GGDataSource.Status;
public class SampleHandler extends AbstractHandler {
        @Override
        public void init(DsConfiguration conf, DsMetaData metaData) {
            super.init(conf, metaData);
            // ... do additional config...
        }
        @Override
        public Status operationAdded(DsEvent e, DsTransaction tx, DsOperation op) { ... }
        @Override
        public Status transactionCommit(DsEvent e, DsTransaction tx) { ... }
        @Override
        public Status metaDataChanged(DsEvent e, DsMetaData meta) { .... }
        @Override
        public void destroy() { /* ... do cleanup ... */ }
        @Override
        public String reportStatus() { return "status report..."; }
        @Override
        public Status ddlOperation(OpType opType, ObjectType objectType, String objectName, String ddlText) }

AbstractHandler内のメソッドは、抽象的ではなく、それどころか本体があります。本体では、それは、メタデータ・オブジェクトをダーティとマークすることで、キャッシュ済メタデータの無効化を実行します。また、ddlOperationメソッドが指定されている場合は、DDLイベントのTRACEレベル・ロギングを提供します。カスタム・ハンドラの実装では、このメソッドをオーバーライドできます。AbstractHandler内の機能が実行されることを確認するために、カスタム処理の前にスーパー・メソッドを必ずコールする必要があります。

トランザクションがExtractから処理される際、ハンドラへのコール順序は次のようになります。

  1. 初期化:

    • まず、ハンドラが構築されます。

    • 次に、インスタンスでプロパティ・ファイルの値を使用してすべてのセッターがコールされます。

    • 最後に、ハンドラが初期化されます。トランザクションを受信する前にinit(...)メソッドがコールされます。init(...)メソッドでsuper.init(...)をコールして基底クラスを適切に初期化することが重要です。

  2. その後、メタデータが受信されます。Javaモジュールが、この実行時にまだ出現していない表での操作を処理する場合、メタデータ・イベントが発行され、metadataChanged(...)メソッドがコールされます。通常は、このメソッドを実装する必要はありません。DsMetaDataは、新規データ・ソース・メタデータが受信されると自動的に更新されます。

  3. トランザクションが開始されます。トランザクション・イベントが発行され、ハンドラでtransactionBegin(...)メソッドが呼び出されます(これについては記載していません)。この時点ではトランザクションに操作がないため、これは通常使用されません。

  4. 操作が順次トランザクションに追加されます。これによって、各操作の追加のたびにハンドラでoperationAdded(...)メソッドがコールされます。処理済のすべての表メタデータを含むデータ・ソース・メタデータとともに、これを含むトランザクションもメソッドに渡されます。トランザクションはまだコミットされておらず、コミットが受信される前に異常終了される可能性があります。

    各操作には、トランザクションから得た列値が含まれます(Extractが圧縮更新を処理する場合、変更された値のみの可能性があります)。列値には、ビフォア値とアフター値の両方が含まれることがあります。

    ddlOperationメソッドの場合、オプションは次のとおりです。

    • opType - 出現しているDDL操作タイプ(CREATEALTERなど)を特定する列挙値です。

    • objectType - DDLのターゲットのタイプ(TABLEVIEWなど)を特定する列挙値です。

    • objectName - 完全修飾ソース・オブジェクト名です。一般には、完全修飾表名です。

    • ddlText - ソース・リレーショナル・データベースで実行された未加工のDDLテキストです。

  5. トランザクションがコミットされます。これによって、transactionCommit(...)メソッドがコールされます。

  6. 定期的にreportStatusがコールされます。プロセスの停止時にもコールされます。通常、これによって処理の統計が表示されます(処理された操作とトランザクションの数、およびその他の詳細)。

単純なプリンタ・ハンドラの例を次に示します。これは、単にトランザクション、操作およびメタデータについて非常に基本的なイベント情報を出力します。ハンドラには、出力ファイル名を設定するためのプロパティmyoutputもあります。これは、Javaアプリケーション・プロパティ・ファイルで次のように設定できます。

gg.handlerlist=sample
# set properties on 'sample'
gg.handler.sample.type=sample.SampleHandler
gg.handler.sample.myoutput=out.txt

カスタム・ハンドラを使用するには、次のようにします。

  1. クラスをコンパイルします

  2. クラスをアプリケーション・クラスパスに含めます。

  3. Javaアプリケーション・プロパティ・ファイルのアクティブ・ハンドラのリストにハンドラを追加します。

ハンドラをコンパイルするには、Java用Oracle GoldenGate JARをクラスパスに含め、コンパイルした.classファイルをgg_install_dir/javaue/resources/classesに配置します。

javac -d gg_install_dir/dirprm
-classpath ggjava/ggjava.jar SampleHandler.java

結果のクラス・ファイルは、次のようにresources/classesに(正しいパッケージ構造で)配置されます。

gg_install_dir/dirprm/sample/SampleHandler.class

ノート:

サンプルhello world以外のJavaアプリケーションの開発では、AntまたはMavenを使用してアプリケーションをコンパイル、テストおよびパッケージ化します。javacを示した例は、例示目的のみです。

あるいは、カスタム・クラスをJARに含め、クラスパスに含めることができます。Javaプロパティを使用してカスタムJARファイルをJVMクラスパスに含める(jvm.bootoptionsプロパティでjava.class.pathを使用)か、Javaアプリケーション・プロパティ・ファイルを設定してカスタムJARを含めます。

# set properties on 'one'
gg.handler.one.type=sample.SampleHandler
gg.handler.one.myoutput=out.txt
gg.classpath=/path/to/my.jar,/path/to/directory/of/jars/*

任意のハンドラで、追加の個別JAR、ディレクトリ(リソースまたは抽出したクラス・ファイルを含む)またはJARのディレクトリ全体を含めるようクラスパス・プロパティを設定できます。JARのディレクトリ全体を含めるには、Java 6形式の構文を使用します。

c:/path/to/directory/* (or on UNIX: /path/to/directory/* )

ワイルドカード*のみ指定できます。ファイル・パターンは使用できません。これは、.jar接尾辞で終わるディレクトリ内のすべてのファイルに自動的に一致します。複数のJARまたは複数のディレクトリを含めるには、システム固有のパス・セパレータ(UNIXではコロン、Windowsではセミコロン)を使用するか、前述の例で示したようにプラットフォームに依存しないカンマを使用します。

ハンドラに多数のプロパティを設定する必要がある場合、パラメータ・ファイルにプロパティを含めるだけで、ハンドラの対応するセッターがコールされます。たとえば:

gg.handler.one.type=com.mycompany.MyHandler
gg.handler.one.myOutput=out.txt
gg.handler.one.myCustomProperty=12345

前述の例では、カスタム・ハンドラ内の次のメソッドが起動されます。

public void setMyOutput(String s) {
        // use the string...
} public void setMyCustomProperty(int j) {
        // use the int...
}

int、long、String、booleanなど、任意の標準Javaデータ型を使用できます。カスタム・データ型の場合、カスタム・プロパティ・エディタを作成して、Stringをカスタムのデータ型に変換することができます。

10.4.5.4 追加のリソース

Java APIにはJavadocが用意されています。Javadocは、カスタマイズおよび拡張に有用なインタフェースおよびクラスのみを配布するために、コア・パッケージ、クラスおよびインタフェースのセットに意図的に縮小されています。

各パッケージでは、わかりやすくするために一部のクラスが意図的に省略されています。重要なクラスは次のとおりです。

  • oracle.goldengate.datasource.DsTransaction: データベース・トランザクションを表します。トランザクションには、0個以上の操作が含まれます。

  • oracle.goldengate.datasource.DsOperation: データベース操作(挿入、更新、削除)を表します。操作には、データ変更イベントを表す0個以上の列値が含まれます。列索引は、Java APIで0でオフセットされます。

  • oracle.goldengate.datasource.DsColumn: 列値を表します。列値は、ビフォア値とアフター値のコンポジットです。列値は存在する(値があるかnull)場合も欠落している(ソース証跡に含まれていない)場合もあります。

    • oracle.goldengate.datasource.DsColumnCompositeは、コンポジットです

    • oracle.goldengate.datasource.DsColumnBeforeValueは、操作前の列値です(これはオプションで、操作に含まれていない場合があります)。

    • oracle.goldengate.datasource.DsColumnAfterValueは、操作後の値です

  • oracle.goldengate.datasource.meta.DsMetaData: 出現するすべてのデータベース・メタデータを表します。オブジェクトは最初空です。DsMetaDataには、TableNameをキーとして使用するTableMetaDataの0個以上のインスタンスのハッシュ・マップが含まれます。

  • oracle.goldengate.datasource.meta.TableMetaData: 1つの表のすべてのメタデータを表します。0個以上のColumnMetaDataを含みます。

  • oracle.goldengate.datasource.meta.ColumnMetaData: データベースまたはOracle GoldenGateソース定義ファイルに定義されている列名およびデータ型を含みます。

詳細は、Javadocを参照してください。

10.4.6 データ変換の構成

データ変換は、分散アプリケーションおよび分析のためのOracle GoldenGateモジュールであり、Replicatプロセスの間の列レベルのデータ変換に役立ちます。

これは、次の2ステップのプロセスです:

  1. マッチャの構成:

    マッチャ構成は、データ変換を適用するターゲット列の識別に役立ちます。

  2. コンバータの構成:

    コンバータにより、一致したターゲット列をターゲットへのその書込みの前に変換するために使用するロジックを定義します。

10.4.6.1 組込みの正規表現ベースのデータ変換

Oracle GoldenGate for Distributed Applications and Analytics (GG for DAA)では、デフォルトで、マッチャとコンバータの両方について、正規表現ベースの実装が提供されます。

データ変換構成

# Transform name (To be referred in the subsequent configs)
gg.transforms=t1

# Configure the matcher implementation (using the built-in regex type in this ex)
gg.transform.t1.matcher=regex

# Configure the converter implementation (using the built-in regex type in this ex)
gg.transform.t1.converter=regex

# These matcher configs correspond to the buit-in regex matcher

# Target catalogs to match. Default value is *
gg.transform.t1.matcher.catalogRegex={}

# Target schema to match. Default value is *
gg.transform.t1.matcher.schemaRegex={}

# Target tables to match (*Required field)
gg.transform.t1.matcher.tableRegex={}

# Target columns to match (*Required field)
gg.transform.t1.matcher.columnRegex={}



# These converter configs correspond to the buit-in regex converter

# Content search regex (from the columns selected, filter only specific values matching this regex)
gg.transform.t1.converter.replaceRegex={}

# Content replacement value
gg.transform.t1.converter.replaceString={}

ノート:

tableRegexパラメータとcolumnRegexパラメータにはデフォルト値がありません。tableRegexcolumnRegexも定義されていない場合は、表にも列にも一致しません。

組込みの正規表現ベースのデータ変換を使用する方法の例

次の構成では、次のようなターゲット・オブジェクトすべてを識別する、データ変換が作成されます:

マッチャ

  1. tabで始まる表名。
  2. colで終わる列名。

コンバータ

  1. 前述の条件に一致した列の値を固定値(たとえば、TestValue)に変換します。
gg.transforms=t1  

gg.transform.t1.matcher=regex
gg.transform.t1.converter=regex


gg.transform.t1.matcher.catalogRegex=.*
gg.transform.t1.matcher.schemaRegex=.*

# Table name staring with 'tab'
gg.transform.t1.matcher.tableRegex=^tab.*

# Column name ending with 'col'
gg.transform.t1.matcher.columnRegex=.*col$


gg.transform.t1.converter.replaceRegex=.*

# Replacement value
gg.transform.t1.converter.replaceString=TestVal
10.4.6.2 カスタム・データ変換の開発

カスタム・データ変換の実装は、次の例で示すように、マッチャ・インタフェースとコンバータ・インタフェースを実装することで実現できます。

Replicatプロセスの間に機密フィールドの値をマスクするというシナリオについて考えてみます。
  1. ターゲット列(次の基準に一致する)を構成します:
    1. カタログ名: Cat1
    2. スキーマ名: Sch1
    3. 表名: Sample_Table
    4. 列名: Sample_Column
  2. 変換の実装を含めてコンバータを構成します。
    1. 前述の条件に一致した列の列値を、マスクした値に置き換えます
@Matcher(id = "matcher1", description = "Custom target column matcher.")
public class CustomTargetMatcher implements TargetMatcher {
    @Override
    public boolean matches(final TableMetaData tableMetaData) {
        return tableMetaData.getCatalogName().equals("Cat1") && tableMetaData.getSchemaName().equals("Sch1") && tableMetaData.getTableName().equals("Sample_Table");
    }
    @Override
    public boolean matches(final ColumnMetaData columnMetaData) {
                return columnMetaData.getColumnName().equals("Sample_Column");
    }
}

@Converter(id = "converter1", description = "Custom data converter.")
public class CustomConverter implements DataConverter {
    
    public String convert(String originalData, final TableMetaData tableMetaData, final ColumnMetaData columnMetaData) {
         return "********"; // Masked Value
    }
}

この実装のアダプタ・プロパティ

gg.transforms=t1

# This config corresponds to the @Matcher => id param
gg.transform.t1.matcher=matcher1
# This config corresponds to the @Converter => id param
gg.transform.t1.converter=converter1

カスタム・クラスを使用するには:

カスタム・クラスをJARに配置し、それらをクラスパスに含めます。Javaプロパティ(jvm.bootoptionsプロパティでのjava.class.pathを使用)を使用して、またはgg.classpathで、カスタムJARファイルをJVMクラスパスに含めます。

10.4.6.3 トラブルシューティングと診断
  1. 必要な変換パラメータすべてがReplicatプロパティ・ファイルで宣言されていることを確認してください。

    データ変換が適切に構成されておらず、Replicatプロパティ・ファイルでgg.transformプロパティが欠落しているか無効である場合、Replicatでは、この変換がスキップされ、続行されます。

    また、このようなシナリオの場合は、Replicatによって次の警告メッセージがスローされます。

    変換プロパティが設定されていません[gg.transform.{name}.matcher.tableRegex]

    変換プロパティが設定されていません[gg.transform.{name}.matcher.columnRegex]

  2. マッチャ/コンバータの各プロパティで指定されている正規表現が有効な正規表現文字列であることを確認してください。

    無効な正規表現が構成されている場合は、Replicatによって次のエラー・メッセージおよび例外がスローされます: パターン構文例外 – 正規表現の構文が正しくない場合

    Replicatプロセスを続行するには、正規表現エラーを修正します。

  3. カスタム変換の場合は、実装したカスタム・クラスがクラスパスに正しく追加されていることを確認してください。

    この場合はReplicatによって次のエラー・メッセージがスローされ、この変換がスキップされ、続行されます:

    タイプ{type}の変換クラス・インスタンスが見つかりませんでした

    必ずそのカスタム・クラスをgg.classpathプロパティに追加してください。