GoldenGateテクニカルセミナー4「テクニカルコンサルタントが語るOracle GoldenGate現場で使える極意」(2016/5/11)

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. |
プロフェッショナルが語る！Oracle GoldenGate テクニカルセミナー
テクニカル・コンサルタントが語る、
Oracle GoldenGate 現場で使える極意
2016年5月11日
日本オラクル株式会社
クラウド・テクノロジーコンサルティング統括本部
テクニカルアーキテクト本部
プラットフォームアーキテクト部
木皿恵、岡本渉

Safe Harbor Statement
The following is intended to outline our general product direction. It is intended for
information purposes only, and may not be incorporated into any contract. It is not a
commitment to deliver any material, code, or functionality, and should not be relied upon
in making purchasing decisions. The development, release, and timing of any features or
functionality described for Oracle’s products remains at the sole discretion of Oracle.

Agenda
GoldenGate活用事例のご紹介
Conflict Detection and Resolution (CDR) 技術Tips
Oracle GoldenGate Veridata 技術Tips
Appendix A: CDR
Appendix B: Oracle GoldenGate Veridata
1
2
3
4
5

GoldenGate活用事例のご紹介
1

事例１: メンテナンス時間の削減
BUSINESS OBJECTIVES
• 表構成の変更、データの洗い替えを伴うメンテナンス時間を削減したい
 24時間365日稼働するシステム
 メンテナンスに伴うシステム停止許容時間は10分
SOLUTION
• メンテナンスをターゲットDB側であらかじめ実施しておくことで、メンテナンスによるダウンタイムはAP接続先
サーバの切替え時間のみに縮小
• GoldenGateは表構成が異なる表のDML文の連携をサポートするため、表構成の変更にも対応
• 変換テーブル（ルックアップ表）を活用しデータを変換しながら適用することで、データの洗い替えに対応

① 通常時のレプリケーション
Primary StandbyCapture Pump Replicat
Replicat Pump Capture
AP
1 1月
2 2月
1 1月
2 2月
Point
・順同期用、逆同期用のプロセスを事前に準備
・順同期用プロセスのみ稼働させる

② メンテナンス実施
AP
1 1月
2 2月
3 3月
メンテナンス実施
•列構成変更 → 列追加
•データ洗い替え→ 1月からJanへ
Point
・順同期用Replicatを停止し、メンテナンスを実施
・メンテナンス中のAP更新は、順同期用Capture
で継続して情報取得
1 Jan
2 Feb

③ メンテナンス中の更新を反映
AP
1 1月
2 2月
3 3月
4 4月
1 Jan
2 Feb
3 Mar
Point
・メンテナンスを反映させる変換処理（列構成の
違いを吸収、データの洗い替えを反映）をReplicat
に設定しReplicatプロセスを起動

③ メンテナンス中の更新を反映：ルックアップ表を利用したデータ変換の流れ
Primary Standby
Pump Replicat
1 1月
2 2月
3 3月
4 4月
1 Jan
2 Feb
3 Mar
4 Apr
1月 Jan
2月 Feb
3月 Mar
4月 Apr
5月 May
6月 Jun
7月 Jul
8月 Aug
9月 Sep
10月 Oct
11月 Nov
12月 Dec
4 4月 4 4月
Capture
ルックアップ表
① ルックアップ表に問い合わせを行い、デー
タ洗い替え後の値を検索
② データ洗い替え後の値に変換して適用
①
②
Trail File Trail File
“4月” がInsert
“4月” が “Apr”
に変換されて
Insert
AP

④ AP停止、OGGプロセス停止
1 Jan
2 Feb
3 Mar
4 Apr
Point
・ APを停止し、全データが同期されたことを確認
してから順同期用プロセスを停止
1 Jan
2 Feb
3 Mar
4 Apr

⑤ AP切替 & Primary側メンテナンス実施
1 Jan
2 Feb
3 Mar
4 Apr
5 May 日本
Point
・逆同期用Captureの読み取り位置をリセット後、
Standby側で新APを起動
・ Primary側でメンテナンスを実施
メンテナンス実施
•列構成変更 → 列追加
•データ洗い替え→ 1月からJanへ新AP
1 Jan
2 Feb
3 Mar
4 Apr

⑥ メンテナンス中の更新反映
1 Jan
2 Feb
3 Mar
4 Apr
5 May 日本
Point
・両データベースでメンテナンスが完了し、逆同
期用プロセスが起動している状態
・必要に応じて、APの切り戻しを実施
新AP
1 Jan
2 Feb
3 Mar
4 Apr
5 May 日本

事例２: 移行前性能検証
BUSINESS OBJECTIVES
• 業務ダウンタイムは計画停止期間内（週末の48時間）に抑えたい
• 新本番環境相当のAPテストを実施して移行後の処理性能を担保したい
 本番環境相当の環境構築を別途構築し、本番環境相当のデータを投入する必要があり、APテスト準
備のための工数、期間が必要となる
SOLUTION
• GoldenGateでは既存/新システムの並行稼働が可能なため、移行日に行う作業を大幅に削減可能
• GoldenGateの同期期間中に、新本番環境において本番環境データを使用したAPテストが容易に実施可能

事例２: 移行前性能検証
切り替
え作業
新環境
稼働開始
既存環境
稼働中
既存環境
稼働中
ダウンタイム
切り替
え作業
移行作業日
移行作業期間
データの移行(exp/imp)
新環境
稼働開始
既存／新環境での
データ比較
APテスト
APテストバック
アップ
リストア
APテスト
リストア
GG連携は
停止中
GG連携は
停止中
新環境
並行稼働中
差分
同期
差分
同期
差分
同期
Point
新環境で性能検証やAPテストを実施
・GoldenGateを使用しない場合
・GoldenGateを使用する場合

Conflict Detection and Resolution (CDR)
技術Tips
1. 競合とは
2. CDR概要
3. CDR設計時の検討事項
4. CDR設定項目
2

いつ競合が発生するか
更新 – 参照更新 – 更新(競合なし) 更新 – 更新(競合あり)
Application
Read/Write
Application
Read Only
Application
Read/Write
Application
Read/Write
Application
Read/Write
Application
Read/Write
GoldenGate GoldenGateGoldenGate
要件
 ターゲット側がRead Onlyのため
競合は発生しない
要件
 異なる行に対する更新のため、
競合は発生しない
要件
 システムA/B の更新がシステムB/A
に反映されるまでのタイムラグ中に
ターゲット側で同一行に対する更新
があった場合競合検知と解決
単方向連携双方向連携
システムA システムB システムA システムB システムA システムB
1. 競合とは

• データ不整合は Oracle GoldenGateで検知不可
– Oracle GoldenGate Veridata で定期的に整合性確認をすることを推奨
• データ競合はReplicatプロセスがSQL適用時に検知
– ORA-1、ORA-1403にてReplicatがABEND
– CDRによる競合検知、解決が可能
競合とは
1. 競合とは
データ不整合
競合
ORAエラーCDR
CDRで
競合解決を実装
ソース/ターゲット間の
データ整合性が
取れている

• Replicatプロセスがターゲット側でDML文を発行する際に競合を検知
– Replicatが一意制約違反(ORA-1)やデータが見つからない(ORA-1403)エラーを検知し
てABENDする
GoldenGate
GoldenGateで検知する競合
Source DB Target DB
Capture Replicat
EMPNO 0128
ENAME SCOTT
SALARY 1000 → 1500
EMPNO -
ENAME -
SALARY -
EMPNO=0128の列が
存在しない(ORA-1403)
1. 競合とは
EMPNO 2299
ENAME MIKE
SALARY 2000
EMPNO 2299
ENAME MIKE
SALARY 3000
EMPNO=2299の列が
既にある(ORA-1)
update
insert

• Replicatプロセスがターゲット側でDML文を発行する際に競合を検知
– ターゲット側でDML文を実行する際のデータの状況が、ソース側でDML文を実行し
た時点のデータの状態と異なる値となっている状況
GoldenGate
CDRで検知する競合
Source DB Target DB
Capture Replicat
EMPNO 0128
ENAME SCOTT
SALARY 1000 → 1500
EMPNO 0128
ENAME SCOTT
SALARY 1000
Before
Image
EMPNO 0128
ENAME SCOTT
SALARY 1300
ソース側のBefore Imageと比較し、
異なる場合は競合として検知
(UPDATE, DELETE)
1. 競合とは
※ INSERTは一意性競合を検知

Replicat
Conflict Detection and Resolution(CDR)
20
ルールに基づく競合の検出・解決が可能。GoldenGate 11.2からの機能
ケース毎の対応方法の設定
INSERT/DELETE/UPDATE の計5つのシナリオ
処理対象の細分化
列単位での処理の制御
柔軟な条件分岐
処理データの内容に応じた対応方法の制御
Trail file
Before Image
(変更前イメージ)
7369 SMITH 14:00
After Image
(変更後イメージ)
7369 JACK 18:30
ターゲットDBの
データ
7369 JOHN 18:35
比較・競合検知
競合解決
Parameter File
2. CDR概要

CDR競合検知シナリオ
INSERTROWEXISTS
Insert の競合(一意制約違反)
Insert
UPDATEROWMISSING
対象がターゲットに存在しない
Update
UPDATEROWEXISTS
対象がBefore Imageと異なる
DELETEROWMISSING
対象がターゲットに存在しない
Delete
DELETEROWEXISTS
対象がBefore Imageと異なる
競合検知シナリオ競合解消ルール
OVERWRITE
IGNORE
DISCARD
USEMIN,USEMAX,USEMINEQ,USEMAXEQ
OVERWRITE
IGNORE
DISCARD
OVERWRITE
IGNORE
DISCARD
USEMIN,USEMAX,USEMINEQ,USEMAXEQ
USEDELTA
IGNORE
DISCARD
OVERWRITE
IGNORE
DISCARD
2. CDR概要

競合解決ルールの策定事例
• 事例１：優先システムをあらかじめ決めておく
– 例）システムAを優先システムとした場合の例
• OVERWRITE：競合が発生した場合、データを上書きする
• IGNORE ：競合が発生した場合、データは上書きしない
• DISCARD ：競合が発生した場合、データは上書きしない（DISCARDファイルに書き込む）
ソースとターゲットどちらのデータを正とするか？（1/2）
競合検知シナリオシステムA：競合解決ルールシステムB：競合解決ルール
INSERTROWEXISTS DISCARD or IGNORE OVERWRITE
UPDATEROWEXISTS DISCARD or IGNORE OVERWRITE
UPDATEROWMISSING DISCARD or IGNORE OVERWRITE
DELETEROWEXISTS DISCARD or IGNORE OVERWRITE
DELETEROWMISSING DISCARD or IGNORE DISCARD or IGNORE
RESOLVECONFLICT

• 事例２：値を比較してから優先システムを決定する
– 例）時刻データが格納された列を比較し、最新であるシステムのデータを優先
• INSERTROWEXSITS、UPDATEROWEXISTS のみ設定可能
• その他の競合検知時は、優先システムを決めておく必要がある(事例１)
• USEMAX/USEMIN ：ソース列の値がターゲット側よりも大きい（小さい）場合は適用する
• USEMAXEQ/USEMINEQ (12.1~) ：ソース列の値がターゲット側と同じか、大きい（小さい）場合は適用する
ソースとターゲットどちらのデータを正とするか？（2/2）
競合検知シナリオシステムA：競合解決ルールシステムB：競合解決ルール
INSERTROWEXISTS USEMAXEQ USEMAXEQ
UPDATEROWEXISTS USEMAXEQ USEMAXEQ
UPDATEROWMISSING DISCARD or IGNORE OVERWRITE
DELETEROWEXISTS DISCARD or IGNORE OVERWRITE
DELETEROWMISSING DISCARD or IGNORE DISCARD or IGNORE
RESOLVECONFLICT

競合発生パターン競合検知シナリオ競合解決ルール
OVERWRITE IGNORE/DISCARD USEMAX[EQ]/USEMIN[EQ]
INSERT – INSERT INSERTROWEXISTS insertをupdateに変換して
既存の行を上書き
insertを実行せずにスキッ
プ
ソース列の値と比較して大
きい（小さい）場合、insert
をupdateに変換して既存
の行を上書き
UPDATE – UPDATE UPDATEROWEXISTS そのままupdateを実行 updateを実行せずにスキッ
プ
ソース列の値と比較して大
きい（小さい）場合、そのま
まupdateを実行
UPDATE – DELETE UPDATEROWMISSING updateをinsertに変換して
実行
updateを実行せずにスキッ
プする
N/A
DELETEROWEXISTS そのままdeleteを実行 deleteを実行せずにスキッ
プする
N/A
DELETE – DELETE DELETEROWMISSING N/A deleteを実行せずにスキッ
プする（deleteするデータ
が削除済)
N/A
(参考)競合解決ルール毎の詳細動作
RESOLVECONFLICT

競合検知列の策定事例
• 方法1: 全ての列を比較し競合を検知（事例1, 2 共にこちらの方法を採用）
– 競合検知を的確に行うため、全ての列を比較することを推奨
– 全列の Before Image をTrailファイル上に保持する必要があるため、Trailファイルサイ
ズは大きくなる
– LOB型の列はBefore Image を取得することができないため使用できない
• CDRでは、NUMERIC, DATE, TIMESTAMP, CHAR/NCHAR, VARCHAR/NVARCHAR をサポート
• 方法2: 一部の列を比較し競合を検知
– UPDATE競合では、列レベルでの整理が必要となるため設計時のコストが高い
– 更新が発生する列に絞ることができるため、方法1と比較してTrailファイルサイズは
抑制できる
UPDATE/DELETE時の競合発生をどの列で検知するか？
COMPARECOLS
GETBEFORECOLS

CDRを使用するために必要となる設定項目（Capture）
• Capture
表レベルサプリメンタル・ロギングの設定(ADD TRANDATA)
‒ 主キーと競合検知に使用する列に、表レベルサプリメンタル・ロギングの設定
EXCLUDEUSER or EXCLUDEUSERIDパラメータの設定
‒ Replicatで適用されたレコードを、Captureが再度取得するループを回避
GETBEFORECOLSパラメータの設定
‒ Before Image を出力する列名の指定（LOB列は除外する必要あり）
‒ UPDATE, DELETEでCDRを使用する場合は必要。INSERTのみの場合は不要。
CDROPTIONS _LOGALLSUPPCOLSパラメータの設定(Doc ID 1460018.1)
‒ UPDATE競合時のデータ不整合を防ぐため、OGG 11.2 でのみ設定が必要
4. CDR設定項目

CDRを使用するために必要となる設定項目（Replicat）
• Replicat
COMPARECOLSパラメータの設定
‒ 競合検知・解決に使用する列名の指定（LOB列は除外する必要あり）
‒ ExtractにGETBEFORECOLSパラメータが指定され、Before Imageが出力されている必要がある。
RESOLVECONFLICTパラメータの設定
‒ 競合検知シナリオと競合解決ルールを指定
4. CDR設定項目

Oracle GoldenGate Veridata技術Tips
1. 製品概要
2. ユースケース
3. メモリのサイジング
4. データ比較のチューニング
3

• Veridataは複製元と複製先の異なるデータベース間に
おけるデータの比較照合・修正を実施するためのソフト
ウェア
• GoldenGate等でレプリケーションしている途中やレプリ
ケーションした結果のデータの同期を確認
• 人為的ミスによるデータ不整合の早期発見が可能
• システムへの影響度少（表ロックなし、DB外でのデータ
ハッシュ・ソート・比較、列・行のサブセット化）
29
本番DB バックアップDB災害対策 / 高可用性
OLTP レポーティングリアルタイム・レプリケーション
現行DB 新DBアップグレード / 移行
様々な環境のデータベース間でデータを比較
1. 製品概要
Oracle GoldenGate Veridata 12c 概要

• Veridata Server
– 実行エンジン（データの比較、修正、レポート生成等）
– WebLogic Domain上で動作
• Veridata Web
– WebブラウザベースのGUI
– 動作設定、レポートおよび非同期データの参照・修正
• Veridata Agent
– データベースのデータを取得・修正するエージェント
• Veridata Repository
– 設定情報を保持するデータベース
• Veridata Command Line Interface
– Veridata Serverのコマンドライン・インタフェース
• vericom：自動化されたプログラムで比較を実行
• veridata_scripting：リポジトリに設定情報をロード
• reportutil：暗号化されたレポートや非同期データを参照
WebLogic Server
ドメイン
ソースDBVeridata リポジトリDB
比較データ抽出
Webから操作
コマンドライン
から操作
Veridata
Agent
レプリケーション
Veridata Server
Veridata Command-line
Tool
ターゲットDB
Veridata
Agent
JDBC
JDBC
TCP/IP / SSL
1. 製品概要
Oracle GoldenGate Veridata 12c のアーキテクチャ

• Veridataで比較する対象のデータベース、テーブルを設定
• 比較を実行するジョブを作成し、実行開始1
2
3
4
ターゲットの設定と
ジョブの実行
Initial Comparison
（初期比較）
Confirmation
（確認）
Repair
（修復）* オプション
• キー列の値と、非キー列のハッシュ値をDBから取得し、比較を実行
• 不一致の比較セットは、MOOS (maybe out-of-sync)キューに蓄積
• MOOSキューから順次確認処理を実施
• 元データにおける初期比較時から変更の有無を元に、確認処理を実施
• GUI(Web)からレポートを参照
• コマンドラインツールから参照することも可能5
レポートの参照
• Step3で非同期になったデータを修復することが可能（オプション）
1. 製品概要
Oracle GoldenGate Veridata 12cの動作概要

Veridata Server
DB-2DB-1
主キー値ハッシュ値主キー値ハッシュ値
MOOS(Maybe Out-Of-Sync)キュー
比較
比較
比較
比較後、不一致の可能性
があるペアをMOOSキューへ。
 ジョブを実行すると初期比較プロセスに移ります。
 Veridata Agentが主キーの値と、非キー列のハッ
シュ値の組み合わせを行ごとに取得し、Veridata
serverに転送して比較します。
 ソースとターゲットデータベースの列が異なるタイプ
の場合は、正確な比較をするために標準的な
データ型フォーマットに変換されます。
 比較時に不一致と思われるペアはメモリ上の
MOOS（Maybe out-of-sync）キューに保存されま
す。これは、比較実行時にレプリケーションが実行
されている場合（特に遅延がある場合）、データが
転送中の可能性があるためです。
1. 製品概要
Initial Comparison（初期比較）の動作

Veridata Server
DB-2DB-1
MOOS(Maybe Out-Of-Sync)キュー
 MOOSキューから、不一致のペアを取り出し、該当
行の最新状態を取得して確認を行います。
 最終的なステータス判別を行います。
 「in-sync」：この時点で同期状態にあること
を意味します。
 「persistently out-of-sync」：初期比較時
に非同期で、かつその後も変化がなく非同
期であることを意味します。
 「in-flight 」: 初期比較時に非同期で、かつ
その後変更があり同期確認ができなかった
ことを意味します。
 非同期と判定されたデータは、OOS（Out-of-sync）
ファイルに格納されます。
主キー値主キー値
不一致ペアに関する最
新の状態を確認し、
レポートに反映
値値値値値値値値
値値値値値値値値値比較
STEP1 STEP1
STEP2 STEP2
STEP3
1. 製品概要
Confirmation（確認）の動作

本製品を説明するにあたり、頻出する用語を説明します。
• PAIR ： 1つのソーステーブル／1つのターゲットテーブルの比較を
1つのペアとして定義します。
• GROUP ： 1つ以上の PAIR を論理コンテナ化(グループ化)し定義します。
• JOB ： 1つ以上の比較 GROUP の実行を定義します。
PAIR
PAIR
PAIR
PAIR
GROUP
GROUP
JOB
左記の例では、1 つのJOBを
実行した場合、4 つのPAIRが
実行されます。
つまり、4 つのソース／ター
ゲットテーブルが比較されま
す。
1. 製品概要
Oracle GoldenGate Veridata 12c の頻出用語について

Veridata の使用用途としては、以下の場面になります。
• データ移行時
• データレプリケーション時
■データ移行時
GoldenGateによる段階移行を行う際、日次単位で
データを突合し、整合性をチェックします。
■データレプリケーション時
GoldenGateを使用してリアルタイムレプリケーショ
ンを行う際、日次もしくは週次単位でデータを突合
し、整合性をチェックします。
Veridata のユースケース

22:00 0:00 3:00 22:00 0:00 3:00 22:00 0:00 3:00 22:00
DAY1
compare
DAY2
compare
DAY3
compare
DAY4
compare
0:00 3:00
DAY1
difference
DAY2
difference
DAY3
difference
日次でデータ比較を行う場合の事例を紹介します。
・データ比較は３時間（毎日 0:00～3:00） ※時間は例として記載しています
・比較対象データは、2日前の22:00～前日の22:00の比較を行う
データ移行時のデータ比較事例 (1/2)

1日
データの更新頻度に合わせて、データ比較の間隔を調整します。
・更新頻度が高いテーブル ( ) については日次でデータの比較を行います。
・更新頻度が低いテーブル ( ) については週次でデータの比較を行います。
・更新頻度がほとんど無いテーブル( )については移行初期段階と移行終了段階でデータの比較を行います。
2日 3日 4日 5日 6日 7日 8日 9日 10日 11日 12日 13日 14日 15日 16日 17日 18日 19日 20日
データ移行時のデータ比較事例 (2/2)

ソースDB
ターゲットDB
Veridata
RepositoryDB
Veridataサーバ
Max Sort Memory
Max comparison
Sort Memory
Maximum Memory
Usage
Java Heap Size
Xmx ,Xms
Veridata
Agent
Java Heap Size
Xmx ,Xms
Java Heap Size
Xmx ,Xms
Veridata サーバ及び Veridata Agent で設定するパラメータ
Veridata
Agent
Veridataで設定するメモリパラメータ

Compare
Compare
Compare
ソースター
ゲット
Maximum Memory Usage
1つのcompare各スレッドで
使用するメモリ
Max comparison Sort
Memory
単一compareのソートで
使用する最大メモリ
Max Sort Memory
複数のcompareが同時に
実行された際、ソート全体で
使用できるメモリ
Java Heap Size
Veridataサーバで使用
するJava Heap Size
Veridataサーバメモリの相関関係

初期移行
初期移行は、9i ⇒ 11g へ Export/Importによるデータ移行を実施
差分移行
初期移行(Export/Import)は24.0h以上かかり、システム停止時間内(6.5h)に
収まらないため、GoldenGate によるデータ移行を実施
差分データ比較
差分移行(GoldenGateで移行したデータ)の内容確認は、Veridataによる
データ比較を実施。1日1回3.0h 枠でデータ比較を実施
過去事例の Veridata サーバのメモリサイズの紹介

1日の最大更新件数
GoldenGate で伝播される1日の最大更新件数は、約730万件。
1日1回3.0h 枠で上記件数のデータ比較を行うために設定した Veridata のメモリの
サイジングは以下になります。
過去事例の Veridata サーバのメモリサイズの紹介
Veridata サーバのメモリパラメータ設定値
Maximum Memory Usage 8 GB
Max comparison Sort Memory 16 GB
Max Sort Memory 16 GB
Java Heap Size 19.6 GB
Veridata Agent のメモリパラメータ設定値
Java Heap Size 2 GB

データ比較時間を高速にする場合の主な手法は以下になります。
① データ比較件数の絞り込み
② データ取得SQLへのヒント句の適用
③ JOBの多重実行
チューニング方法の紹介

Veridata がデータを比較する場合、デフォルトでは全件のデータを比較します。
サイズの大きい表に対して都度全件のデータを比較してしまうと、毎回の比較時間が長く
なってしまいます。
このため、日次でデータ比較を行う場合は、日付列の値でデータの絞り込みを行い、
これらのデータを比較します。
COL1 COL2 COL3
1 User0001 2016-01-01
2 User0002 2016-01-01
… … …
100 User0100 2016-01-02
101 User0101 2016-01-02
… … …
200 User0200 2016-01-03
SELECT * FROM SCOTT.EMP
WHERE COL3 = ‘2016-01-02’

①row_partition設定するPAIRをクリック
②[configure]をクリック
row_partition 設定方法(1/2)

①[New]クリック
②PAIR名を入力
③検索条件(Where句の条件)を入力
④チェックを入れます
⑤[Finish]をクリック
row_partition 設定方法(2/2)

SELECT * FROM SCOTT.EMP x
compare処理で取得するSQL文にヒント句を付与することができます。
Veridataがデータ取得する際に実行されるSQLは、テーブル名のエイリアス「x」を付与して
実行しています。
・Profile設定でヒント句設定ができ、データ取得SQLにヒント句を付与できます。
SELECT /*+ FULL(x) PARALLEL(x,5) */ * FROM SCOTT.EMP x
ヒント句を付与して、データ取得

比較データ取得SQLチューニングヒント句設定方法(1/2)
①「Profile Configuration」
をクリック
②「New」をクリック
③「Profile」設定画面

比較データ取得SQLチューニングヒント句設定方法(2/2)
ヒント句を設定
ソースDB、ターゲットDBと
別々にヒント句を設定
ヒント句を設定
① [Source Oracle optimizer hint]、
[Target Oracle optimizer hint]の
Use Defaultのチェックを外します
②ヒント句を設定
ソースDB、ターゲットDBと
別々にヒント句を設定します
例)設定例
FULL(x) PARALLEL(x,5) または、
/*+ FULL(x) PARALLEL(x,5) */
Initial Comparison (初期比較)
でヒント句設定ができる

JOBに多重度を設定してJOB実行すると、多重度の数compare処理を実行します。
1つのcompare処理が完了した後、多重度を保ちつつ、次のcompare処理を
実行します。
また、compare処理する順番は、GROUP名のアルファベット順の昇順で並べられ、
compare処理を行います。
※但し、PAIR名の処理順番は制御できません。
③JOB の多重実行

JOB 多重度:3
JOB実行イメージ
例)1JOB(多重度:3)の中に、3GROUP設定、各GROUPには3PAIR構成
TBL_A
TBL_B
TBL_C
TBL_D
TBL_E
TBL_F
TBL_G
TBL_H
TBL_I
GROUP名 PAIR
GRP_01
TBL_A
TBL_B
TBL_C
GROUP名 PAIR
GRP_02
TBL_D
TBL_E
TBL_F
GROUP名 PAIR
GRP_03
TBL_G
TBL_H
TBL_I
JOB開始
処理
時間
JOBの多重度を保ちcompare処理を
実行(例では多重度:3)JOB多重度
GROUP名の昇順で
Compare処理が実行される
(ペア名でのソートはされない)

JOB多重度指針
・Veridata Server のCPU数以上にならないように設定。
・Agent(ソースDB/ターゲットDB) で比較データを取得するSQLに
ヒント句を付与してパラレルクエリーでデータ取得することができます。
※パラレルクエリでデータ取得する場合、ソースDB/ターゲットDBの
リソースを考慮してJOBの多重度を設定します。

GROUP設計指針
・PAIRの比較データ量でグループ分けします。（大小、大中小など）
(差分突合の場合は、デーブル全体でなく突合されるデータ量でグループ分け)
・比較データ量の大きいグループから順番に突合を実行するように、
GROUP名の付け方を考慮します。
(compare処理は、GROUP名のアルファベット順に処理されます)
例)GROUP_01(比較データ量(大)) ⇒ GROUP_02 (比較データ量(中)) ⇒
GROUP_03 (比較データ量(小)) ・・・

テーブル大
テーブル大
テーブル大
テーブル中
テーブル中
テーブル中
小
小
小
GROUP名 PAIR
GRP_01
テーブル大
テーブル大
テーブル大
GROUP名 PAIR
GRP_02
テーブル中
テーブル中
テーブル中
GROUP名 PAIR
GRP_03
テーブル小
テーブル小
テーブル小
処理
時間
テーブル大
テーブル中
テーブル大
テーブル中テーブル大
小
テーブル中
GROUP名 PAIR
GRP_01
テーブル大
テーブル中
テーブル小
GROUP名 PAIR
GRP_02
テーブル大
テーブル中
テーブル小
GROUP名 PAIR
GRP_03
テーブル大
テーブル中
テーブル小
小
小
例)GROUPを比較データ量で分類(大、中、小)したケース (JOBの多重度は3)
処理
時間
例)GROUPを比較データ量で分類しないケース (JOBの多重度は3)

Appendix A: CDR
4

表レベルサプリメンタル・ロギングの設定
• 主キーと競合検知に使用する列に、表レベルサプリメンタル・ロギングの
設定が必要
– 全ての列を比較する場合は、全列が対象
– LOB列がある場合は、Oracleデータベースの制限でサプリメンタル・ロギングを設定
できないため、LOB列を除外する必要がある
ADD TRANDATAの実行
--NOKEYなしの場合は、主キー以外の列を指定
GGSCI> ADD TRANDATA <schema>.<table>, COLS (<col1>,<col2>,…)
--NOKEYをつける場合は、主キーを含む列を指定
GGSCI> ADD TRANDATA <schema>.<table>, NOKEY, COLS (<col_pk>,<col1>,<col2>,…)

UPDATE競合時のデータ不整合の対応、OGG11.2のみ(1/2)
• システムAを優先システムとしている場合の例
– 各システムで異なる列が更新されるケースにおいて、更新が発生した列のみの伝播が行われ、データの不
整合が発生
EMPNO F_NAME L_NAME AGE PHONE ADDRESS
------- ------------ ------------- --------- ---------- ---------------
1 ORACLE ORACLE 25 11111 TOKYO
------- ------------ ------------- --------- ---------- ---------------
1 BBBBB ORACLE 30 22222 TOKYO
------- ------------ ------------- --------- ---------- ---------------
1 ORACLE CCCCC 35 33333 OSAKA
------- ------------ ------------- --------- ---------- ---------------
------- ------------ ------------- --------- ---------- ---------------
1 BBBBB CCCCC 30 22222 OSAKA
システムBのUPDATE文は
DISCARDのため未反映
初期値
システムA、システムB
システムA
システムB
UPDATE実行
システムA
システムB
CDR適用後
Replicatが発行するUPDATE文
UPDATE emp
SET f_name=‘BBBBB’
AND age = 30
AND phone=2222
WHERE empno=1
システムAのUPDATE文は
OVERWRITEのため反映

UPDATE競合時のデータ不整合の対応、OGG11.2のみ(2/2)
• 対応方法
– Capture プロセスに「CDROPTIONS _LOGALLSUPPCOLS」パラメータを指定
• 通常、更新が発生した列のみがTrailファイルに出力される
• 本パラメータの設定により、全ての列の情報がTrailファイルに出力されるため、Replicatプロセスが発行す
るSQL文にて、全列をUPDATE文のSET句に指定できるようになる
• <参考> What is the difference of parameter GETBEFORECOLS
version 11.2.1 and the existing GETUPDATEBEFORES? (Doc ID 1460018.1)
------- ------------ ------------- --------- ---------- ---------------
------- ------------ ------------- --------- ---------- ---------------
システムA
システムB
CDR適用後
Replicatが発行するUPDATE文
UPDATE emp
SET f_name=‘BBBBB’
AND l_name=‘ORACLE’
AND age = 30
AND phone=2222
AND address=‘TOKYO’
WHERE empno=1

LOB列がある場合の対応(1/2)
• LOB列以外の列を更新しデータの伝播を行う場合、UPDATEROWMISSINGが発生した際
にLOBデータが欠損することがある。
– UPDATEROWMISSINGの挙動として更新対象行が存在しない場合には、UPDATE文をINSERT文に変換
しデータの挿入を行うが、サプリメンタル・ロギングが設定できないLOB列に値が入らない事象が発生
する
EMPNO F_NAME L_NAME B_LOB
------- ------------ ------------- ---------------------------------------
1 BBBBB ORACLE 89504E470D0A1A0A0000000D49484452…
------- ------------ ------------- ---------------------------------------
------- ------------ ------------- ---------------------------------------
1 BBBBB ORACLE 89504E470D0A1A0A0000000D49484452…
------- ------------ ------------- ---------------------------------------
1 BBBBB ORACLE
システムA
Update実行
システムB
Delete実行
更新実行
システムA
システムB
CDR適用後

LOB列がある場合の対応(2/2)
• 対応方法
– CaptureプロセスのTABLEパラメータに、FETCHCOLS、FETCHMODCOLSを指定
• FETCHCOLS (<LOB列名>)
– Trail ファイルに値が存在しない場合に、データベースから列値をFETCHします。LOBデータを強制的に
FETCHさせる場合、本パラメータは必須。
• FETCHMODCOLS(<LOB列名>)
– Trail ファイルに値がに存在する場合でも、列値をデータベースからFETCHする。

Appendix B: Oracle GoldenGate Veridata
1. Veridata で設定するメモリパラメータ
5

各種メモリ設定の説明
Veridataで設定するメモリパラメータ（1/12）
名称設定内容
Maximum Memory
Usage
1つのcompareで使用する各スレッドあたりのメモリの最大値
※1つのcompareでソース、ターゲットのスレッドが生成されます
(メモリの使用用途は、エージェントからの受信データを格納・ソートを行います)
Max comparison sort
memory
ジョブで定義されている単一compareのソートで使用するメモリの最大値
Max Sort Memory 複数のcompareが同時に実行された際、ソート全体で使用できるメモリの最大値
Java Heap Size
(Xmx、Xms)
Veridataで使用するメモリの最大値(Xmx)、初期起動サイズ(Xms)を設定
※Veridataサーバ、エージェントに設定します

Maximum Memory Usageの算出方法
Maximum Memory Usageは、エージェントから送信される行データを格納・ソートで使用する
メモリー最大値を設定します。
1つのcompareで、ソース・ターゲットのスレッドが2つ実行され、Maximum Memory Usageは、
1スレッドあたりのメモリ使用量を設定します。
Maximum Memory Usageを算出するにあたり、Dataset Size、比較する行サイズ、
比較データ行数の情報から算出します。
Maximum Memory
Usage
Dataset Size比較する行サイズ
比較データ行数
Max Sort
Memory
Max
comparison sort
memory
Maximum
Memory Usage
Java Heap Size

Dataset Sizeの算出方法
比較キー列の形式データサイズ
数値有効桁ごとに1バイト。先頭のゼロおよび小数点以下の末尾のゼロ(1234.00)は数えない
タイムスタンプ端数の精度に応じて19バイトから32バイト
日付 10バイト
時間端数の精度に応じて8バイトから18バイト
文字列 1文字あたり1バイトから4バイト
Dataset Sizeは、比較する行サイズと比較する行数から算出します。
算出方法： (((比較キーの列数 + 1) * 4) + 16 + (比較キー列のデータサイズ)) * 行数
例) 比較キー1列で数値データ、有効桁数が8桁、行数が100万件で使用するメモリー(バイト)
(( 1 * 1 ) * 4 + 16 + 8) = 33 バイト * 1000000 = 31.4MB
Max Sort
Memory
Max
comparison sort
memory
Maximum
Memory Usage
Java Heap Size

ソート処理の種類
エージェントからデータを受け取ると、行データをメモリでソートします。メモリーが足りない場合
行データはディスクに書き出してソート処理を実行します。
なお、使用可能なメモリ量によって、実行されるソート処理に違いがあります。
ソート処理データサイズ
メモリー内ソートデータをメモリ内でソートします。最も早い方法。必要なメモリはDataset Sizeの2.5倍必要
1ディスクパスソートデータをソートし、ディスクに1回のみ書込みます。Dataset Sizeと同じソートディスクが必要
2ディスクパスソートデータをソートし、ディスクに2回書込みます。Dataset Sizeの2倍のソートディスクが必要
ディスク書き出し先の指定は、以下のパラメータで設定
・Temporary Storage Directory for Source Data(ソースDB用)
・Temporary Storage Directory for Target Data(ターゲットDB用)
Max Sort
Memory
Max
comparison sort
memory
Maximum
Memory Usage
Java Heap Size

各ソート処理で必要なメモリサイズ
Dataset Sizeが100GBのケースで、
各ソート処理を実行するに必要なMaximum Memory Usageのサイズ
ソート処理
Maximum
Memory
Usage
算出式
メモリ内ソート 238GB 2.5 * (Dataset size/(1024 * 1024) )
1ディスクパスソート 773MB 2.5 * (Square Root of (Dataset size/(1024 * 1024) ) )
2ディスクパスソート 115MB 2.5 * (Cube Root of (Dataset size /(1024*1024) ) )
Max Sort
Memory
Max
comparison sort
memory
Maximum
Memory Usage
Java Heap Size

Max comparison sort memoryの算出方法
ジョブで定義されている単一compareのソートで使用するメモリの最大値を設定します。
同時実行されるジョブが複数存在する場合、各ジョブのMaximum Memory Usageの値を
合算します。
算出方法： 2 * (ジョブに設定されている Maximum Memory Usage)
例)JOBがあり、それぞれのPAIRのMaximum Memory Usageが
50MB、30MB、20MBと設定されているケース
(2 * 50) = 100MB ※PAIRのMaximum Memory Usage最大値を使用
Max Sort
Memory
Max
comparison sort
memory
Maximum
Memory Usage
Java Heap Size

Max_Sort_Memoryの算出方法
ジョブが同時に実行された際、ソート全体で使用できるメモリの最大値を設定します。
算出方法：
Max_Comparison_Sort_Memory * 同時実行されるジョブの比較スレッド数
例)1JOB(多重度:3)で、GROUPが3つ、各GROUPにはPAIRが２つ構成されているケース
Max_Comparison_Sort_Memoryの値は、100MB
(100 * 3) = 300MB
Max Sort
Memory
Max
comparison sort
memory
Maximum
Memory Usage
Java Heap Size

メモリパラメータ算出例
ジョブが1つ作成されているケースでのメモリ算出例 (PAIR毎にプロファイルを設定)
Max Sort
Memory
Max
comparison sort
memory
Maximum
Memory Usage
Java Heap Size
ジョブ名
ジョブ
多重度
比較
テーブル
Dataset
Size
JOB_01 6
TBL_A 100MB
TBL_B 80MB
…
…
Max comparison
sort memory
(2 * 250)
= 500MB
Maximum
Memory
Usage
250MB
メモリソート
実行する
設定値
250MB
200MB
…
メモリソートを実行する値を算出
2.5 * Dataset Size
Max sort memory
(500 * 6)
= 3000MB
JOB内PAIRの Maximum Memory Usageの
最大値を設定
2 * (ジョブのMaximum Memory Usageの最大値) Max_Comparison_Sort_Memory * 同時実行されるジョブ多重度

Java Heap Size
Java Heap Size（Veridataサーバ）
Veridata サーバ自身が Javaアプリケーションであるため、
その中で使用するメモリ領域は heap内で処理されます。
Veridataサーバのメモリ使用用途はソート処理だけではないため、
Max Sort Memoryより多めのJava Heap Sizeを設定します。
Max Sort
Memory
Max
comparison sort
memory
Maximum
Memory Usage
Java Heap Size
Max Sort Memory
過去案件のPoCでは、以下の設定を実施
- Java Heap Size : 20GB
- Max Sort Memory:16GB
※ Java Heap Sizeは4GB以上に設定する場合、64bit JAVAを使用します

Java Heap Size（エージェント）
Veridataで設定するメモリパラメータ（10/12） Max Sort
Memory
Max
comparison sort
memory
Maximum
Memory Usage
Java Heap Size
エージェントはJDBCドライバを使用して、DBに接続して比較テーブルデータを
抽出します。ヒープ消費の主な要因はJDBCのデータ取得になります。
■JDBCドライバが使用するメモリサイズの計算式
(1)比較テーブルの各列のサイズ最大値を合算してレコード長を算出
※LOBは含まれません。LOBデータはフェッチ時に取得します
(2)(1)で算出されたレコード長 * fetch batch size * 10 で使用するメモリを確保する
(弊社環境での計測値)
(3)同時実行される比較スレッドが存在する場合、比較テーブル毎に使用する
メモリの合計値が、エージェントで使用されるメモリー最大値となります。

・エージェント自身がJavaアプリケーションであるため、その中で使用する
メモリ領域は heap内で処理されます。
・エージェントのメモリ使用用途はJDBCデータ取得以外にも
使用されますので、比較テーブル毎に使用するメモリの合計値が、
エージェントで使用されるメモリー最大値よりも多めのJava heap Sizeを設定します。
・メモリ不足する場合、Java Heap Sizeを増やす or fetch batch sizeを減らします。
Java Heap Size（エージェント）
Memory
Max
comparison sort
memory
Maximum
Memory Usage
Java Heap Size

メモリパラメータ設定方法
Memory
Max
comparison sort
memory
Maximum
Memory Usage
Java Heap Size
名称設定場所
Maximum Memory
Usage
Profileに設定
・設定方法は、差分突合設定(3/6)のスライド参照
Max comparison sort
memory
サーバーパラメータに設定
・Veridataサーバーインストールディレクトリ内の shared/conf/veridata.cfg を編集
Max Sort Memory
サーバーパラメータに設定
・Veridataサーバーインストールディレクトリ内の shared/conf/veridata.cfg を編集
Java Heap Size
(Veridataサーバ)
(Xmx、Xms)
veridata_web.sh、vericom.shを編集
・Veridataインストールディレクトリのweb/bin/veridata_web.shのJAVA_OPTSを編集
・Veridataインストールディレクトリのvericom.shのJAVA_OPTSを編集
Java Heap Size
(エージェント)
(Xmx、Xms)
Agent.shを編集
・Agentインストールディレクトリのagent.shのJAVA_OPTSを編集

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | 73
ご質問・ご相談等ございましたら、終了後もお受けしております
0120-155-096
（平日9:00-12:00 / 13:00-18:00）
http://www.oracle.com/jp/direct/index.html
各種無償支援サービスもございます。
Oracle Direct 検索
Oracle Direct
あなたにいちばん近いオラクル

GoldenGateテクニカルセミナー4「テクニカルコンサルタントが語るOracle GoldenGate現場で使える極意」(2016/5/11)

GoldenGateテクニカルセミナー4「テクニカルコンサルタントが語るOracle GoldenGate現場で使える極意」(2016/5/11)

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (6)

Ähnlich wie GoldenGateテクニカルセミナー4「テクニカルコンサルタントが語るOracle GoldenGate現場で使える極意」(2016/5/11)

Ähnlich wie GoldenGateテクニカルセミナー4「テクニカルコンサルタントが語るOracle GoldenGate現場で使える極意」(2016/5/11) (20)

Mehr von オラクルエンジニア通信

Mehr von オラクルエンジニア通信 (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (7)

GoldenGateテクニカルセミナー4「テクニカルコンサルタントが語るOracle GoldenGate現場で使える極意」(2016/5/11)