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 Standby Capture 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 GoldenGate GoldenGate

要件ターゲット側が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

3. CDR設計時の検討事項 RESOLVECONFLICT



• 事例２：値を比較してから優先システムを決定する –例）時刻データが格納された列を比較し、最新であるシステムのデータを優先

• INSERTROWEXSITS、UPDATEROWEXISTS のみ設定可能

• その他の競合検知時は、優先システムを決めておく必要がある(事例１)

• USEMAX/USEMIN ：ソース列の値がターゲット側よりも大きい（小さい）場合は適用する

• USEMAXEQ/USEMINEQ (12.1~) ：ソース列の値がターゲット側と同じか、大きい（小さい）場合は適用する

ソースとターゲットどちらのデータを正とするか？（2/2）

3. CDR設計時の検討事項

競合検知シナリオシステム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

(参考)競合解決ルール毎の詳細動作

3. CDR設計時の検討事項 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時の競合発生をどの列で検知するか？

3. CDR設計時の検討事項 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 ドメイン

ソースDB Veridata リポジトリ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-2 DB-1

主キー値ハッシュ値主キー値ハッシュ値

MOOS(Maybe Out-Of-Sync)キュー




比較

比較

比較

比較後、不一致の可能性があるペアをMOOSキューへ。

ジョブを実行すると初期比較プロセスに移ります。

Veridata Agentが主キーの値と、非キー列のハッシュ値の組み合わせを行ごとに取得し、Veridata serverに転送して比較します。

ソースとターゲットデータベースの列が異なるタイプの場合は、正確な比較をするために標準的なデータ型フォーマットに変換されます。

比較時に不一致と思われるペアはメモリ上のMOOS（Maybe out-of-sync）キューに保存されま

す。これは、比較実行時にレプリケーションが実行されている場合（特に遅延がある場合）、データが転送中の可能性があるためです。

1. 製品概要

Initial Comparison（初期比較）の動作


Veridata Server

DB-2 DB-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を使用してリアルタイムレプリケーションを行う際、日次もしくは週次単位でデータを突合し、整合性をチェックします。

2. ユースケース

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



Veridata サーバ及び Veridata Agent で設定するパラメータ

Veridata Agent

3. メモリのサイジング

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の多重実行

4. データ比較のチューニング

チューニング方法の紹介


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

EMPNO F_NAME L_NAME AGE PHONE ADDRESS ------- ------------ ------------- --------- ---------- --------------- 1 BBBBB ORACLE 30 22222 TOKYO EMPNO F_NAME L_NAME AGE PHONE ADDRESS ------- ------------ ------------- --------- ---------- --------------- 1 ORACLE CCCCC 35 33333 OSAKA

EMPNO F_NAME L_NAME AGE PHONE ADDRESS ------- ------------ ------------- --------- ---------- --------------- 1 BBBBB ORACLE 30 22222 TOKYO EMPNO F_NAME L_NAME AGE PHONE ADDRESS ------- ------------ ------------- --------- ---------- --------------- 1 BBBBB CCCCC 30 22222 OSAKA

システムBのUPDATE文はDISCARDのため未反映

初期値システムA、システムB

システムA システムB

UPDATE実行


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)

EMPNO F_NAME L_NAME AGE PHONE ADDRESS ------- ------------ ------------- --------- ---------- --------------- 1 BBBBB ORACLE 30 22222 TOKYO EMPNO F_NAME L_NAME AGE PHONE ADDRESS ------- ------------ ------------- --------- ---------- --------------- 1 BBBBB ORACLE 30 22222 TOKYO


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… EMPNO F_NAME L_NAME B_LOB ------- ------------ ------------- ---------------------------------------

EMPNO F_NAME L_NAME B_LOB ------- ------------ ------------- --------------------------------------- 1 BBBBB ORACLE 89504E470D0A1A0A0000000D49484452… EMPNO F_NAME L_NAME B_LOB ------- ------------ ------------- --------------------------------------- 1 BBBBB ORACLE

システムA Update実行システムB Delete実行

更新実行


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）

名称設定内容


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、比較する行サイズ、比較データ行数の情報から算出します。


Dataset Size 比較する行サイズ

比較データ行数

Max Sort Memory

Max comparison sort

memory


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


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


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


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


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


Java Heap Size


メモリパラメータ算出例


ジョブが1つ作成されているケースでのメモリ算出例 (PAIR毎にプロファイルを設定)

Max Sort Memory

Max comparison sort

memory


Java Heap Size

ジョブ名ジョブ多重度

比較テーブル

Dataset Size

JOB_01 6 TBL_A 100MB TBL_B 80MB

…

…


(2 * 250) = 500MB


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


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


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（エージェント）


Max comparison sort

memory


Java Heap Size


メモリパラメータ設定方法


Max comparison sort

memory


Java Heap Size

名称設定場所


Profileに設定・設定方法は、差分突合設定(3/6)のスライド参照


サーバーパラメータに設定・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 あなたにいちばん近いオラクル

http://www.oracle.com/jp/direct/index.html


Technology

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