データ統合/連携の領域におけるリアリティ

(1)

データ連携のプロフェッショナル陣が語る！

現場で使える、Oracle GoldenGate テクニカルセミナー

Session 4 :

テクニカル・コンサルタントが語る、

Oracle GoldenGate 現場で使える極意

2016年12月06日

日本オラクル株式会社

クラウド・テクノロジーコンサルティング事業本部

テクニカルアーキテクト部

ソリューションプリンシパル

浅井純

(2)

• 以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するも

のです。また、情報提供を唯一の目的とするものであり、いかなる契約にも

組み込むことはできません。以下の事項は、マテリアルやコード、機能を提

供することをコミットメント（確約）するものではないため、購買決定を行う際

の判断材料になさらないで下さい。オラクル製品に関して記載されている機

能の開発、リリースおよび時期については、弊社の裁量により決定されます。

OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。

(3)

Agenda

GoldenGate活用事例のご紹介

イベント・マーカーの活用事例

Conflict Detection and Resolution (CDR) 技術Tips

Appendix

1

2

3

(4)

GoldenGate活用事例のご紹介

(5)

事例１: メンテナンス時間の削減

BUSINESS OBJECTIVES

• 表構成の変更、データの洗い替えを伴う

メンテナンス時間を削減

したい



24時間365日稼働するシステム



メンテナンスに伴うシステム停止許容時間は10分

SOLUTION

• メンテナンスをターゲットDB側であらかじめ実施しておくことで、メンテナンスによる

ダウンタイムはAP接続先

サーバの切替え時間のみに縮小

• GoldenGateは表構成が異なる表のDML文の連携をサポートするため、

表構成の変更にも対応

• 変換テーブル（ルックアップ表）を活用しデータを変換しながら適用

することで、データの洗い替えに対応

(6)

事例１: メンテナンス時間の削減

① 通常時のレプリケーション

Source DB

Capture

Pump

Replicat

Target DB

Replicat

Pump

Capture

AP

1 1月 2 2月 1 1月 2 2月

Point

・順同期用、逆同期用のプロセスを事前に準備

・順同期用プロセスのみ稼働させる

(7)

事例１: メンテナンス時間の削減

② メンテナンス実施

Source DB

Capture

Pump

Replicat

Target DB

Replicat

Pump

Capture

AP

1 1月 2 2月 3 3月

メンテナンス実施

•列構成変更 → 列追加

•データ洗い替え→ 1月からJanへ

Point

・順同期用Replicatを停止し、メンテナンスを実施

・メンテナンス中のAP更新は、順同期用Captureで継続して情報取得

1 Jan 2 Feb

(8)

事例１: メンテナンス時間の削減

③ メンテナンス中の更新を反映

Source DB

Capture

Pump

Replicat

Target DB

Replicat

Pump

Capture

AP

1 1月 2 2月 3 3月 4 4月 1 Jan 2 Feb 3 Mar

Point

・メンテナンスを反映させる

変換処理（列構成の違いを吸収、

データの洗い替えを反映）をReplicatに設定

しReplicatプロセスを起動

(9)

事例１: メンテナンス時間の削減

③ メンテナンス中の更新を反映：ルックアップ表を利用したデータ変換の流れ

Source DB

Target DB

Pump

Replicat

1 1月 2 2月 3 3月 1 Jan 2 Feb 3 Mar 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

“4月” が “Apr”

(10)

事例１: メンテナンス時間の削減

④ AP停止、OGGプロセス停止

Source DB

Capture

Pump

Replicat

Target DB

Replicat

Pump

Capture

1 Jan 2 Feb 3 Mar 4 Apr

Point

・ APを停止し、全データが同期されたことを確認してから順同期用プロセスを停止

1 1月 2 2月 3 3月 4 4月

(11)

事例１: メンテナンス時間の削減

⑤ AP切替 & Primary側メンテナンス実施

Source DB

Capture

Pump

Replicat

Target DB

Replicat

Pump

Capture

1 Jan 2 Feb 3 Mar

Point

・逆同期用Captureの読み取り位置をリセット後、Source DB側で新APを起動

・ Target DB側でメンテナンスを実施

メンテナンス実施

•列構成変更 → 列追加

•データ洗い替え→ 1月からJanへ

新AP

1 Jan 2 Feb 3 Mar

(12)

事例１: メンテナンス時間の削減

⑥ メンテナンス中の更新反映

Source DB

Capture

Pump

Replicat

Target DB

Replicat

Pump

Capture

Point

・両データベースでメンテナンスが完了し、逆同期用プロセスが起動している

・必要に応じて、APの切り戻しを実施

新AP

(13)

事例２: 移行前性能検証

BUSINESS OBJECTIVES

• 業務

ダウンタイムは計画停止期間内

（週末の48時間）に抑えたい

• 新本番環境相当のAPテストを実施して

移行後の処理性能を担保

したい



本番環境相当の環境構築を別途構築し、本番環境相当のデータを投入する必要があり、

APテスト準

備のための工数、期間が必要

となる

SOLUTION

• GoldenGateでは既存/新システムの並行稼働が可能なため、

移行日に行う作業を大幅に削減可能

• GoldenGateの同期期間中に、新本番環境において

本番環境データを使用したAPテストが容易に実施可能

(14)

事例２: 移行前性能検証

切り替え作業

新環境

稼働開始

既存環境

稼働中

ダウンタイム

切り替え作業

移行作業日

移行作業期間

データ移行(exp/imp)

別環境でAPテスト

新環境

並行稼働中

Point

移行当日のダウンタイムを削減することが可能

・GoldenGateを使用しない場合

・GoldenGateを使用する場合

既存環境

稼働中

データ移

行(exp)

imp/

追いつき処理

新環境

稼働開始

ダウンタイム

既存／新環境の

データ比較

既存／新環境の

データ比較

(15)

事例２: 移行前性能検証

ダウンタイム

切り替え作業

移行作業日

Point

新環境で本番データを利用したAPテストが可能

・GoldenGateを使用する場合

既存環境

稼働中

新環境

稼働開始

既存／新環境の

データ比較

APテスト

バック

アップ

リストア

G

G連携

停止中

APテスト

バック

アップ

リストア

G

G連携

停止中

新環境

並行稼働中

(16)

イベント・マーカーの活用事例

1. MViewのGoldenGateへの置き換え

2. イベント・マーカーを使用した静止断面の提供

(17)

MViewのGoldenGateへの置き換え

DB#1

レプリ#1

TABLE オブジェクト

DB LINK

Materialized View オブジェクト

レプリ#2

Materialized View オブジェクト

1日1回夜間時にデータ断面が必要

Mviewリフレッシュに時間がかかるため、1日4回のリフレッシュによ

り、定期的に差分を伝播していた

【旧システム：MView を使用したレプリケーション】

レプリ#1

TABLE オブジェクト

レプリ#2

Capture プロセス DataPump プロセス Replicat プロセス Replicat プロセス

【新システム：GoldenGate を使用したレプリケーション】

事前にReplicatを起動しデータ断面提供までの時間を短縮

Collector プロセス

(18)

イベント・マーカーを使用し静止断面を提供

• イベント・マーカーを活用することで、ターゲット側にデータの静止断面を提供可能

–

イベント表のデータ更新を検知した際に、事前定義したアクションをもとにReplicatプロセスを自動停止

• 下絵の1.～3.を繰り返す事で実現可能

–

レプリケーション対象表とは別に「イベント表」を事前準備

–

イベント表に対する更新処理適用後に、Replicat プロセスを自動停止し、ターゲット側でのデータ断面を保証

–

データ断面保証期間終了後、Replicat プロセスを起動し同期再開

DB#1

レプリケーション元表

Cap DP

レプリ#1/レプリ#2

レプリケーション先表

Rep

イベント表

1. バッチ処理+マーカー表に更新処理実行 2. ターゲット側の「レプリ対象表」と「イベント表」にデータ適用 3. Replicat プロセス自動停止 Col

(19)

確認ポイント：データ断面の保証期間

• ターゲット側にて業務アプリが必要とするデータ断面の保証期間の確認が必要

–

「例①」では、データ断面保証期間が終了次第Replicatプロセスを起動できるため、事前にデータ同期が行

うことが可能。レプリ長時間化を解消できる。

–

「例②」では、Replicatプロセスが数時間分の更新をまとめて適用することになるため、データ同期に時間が

かかる可能性がある。

0:00

6:00

12:00

Apply

例②

例①

0:00の断面を

保証する期間

6:00の断面を

保証する期間

データ断面提供までの時間が長期化するデータ断面提供までの時間が短縮できる

(20)

No.

サブパラメータ

概要説明

1 STOP

指定のイベント・レコードが検出された際にプロセスを正常に停止させます。

→ターゲット側のイベント・マーカー・テーブルに更新処理が正常に適用された後に、

プロセスが正常終了(STOPPED)します。

2 LOG

_{[INFO | WARNING]}

指定のイベント・レコードが検出された際にプロセスにこのイベントを記録させ、

_{「ggserr.log」にメッセージが書き込まれます。デフォルト(INFO)です。}

MAP <イベント表(ソース)>, TARGET <イベント表(ターゲット)>,

EVENTACTIONS (STOP,LOG)

;

【EVENTACTIONS の概要説明】

2016-07-26 15:51:21 GGS INFO 123 Oracle GoldenGate Delivery for Oracle, rep01.prm: Processed LOG event fortarget table TEST_TARGET.MARKER010 in file ./dirdat/remote/rt000006, RBA 101963.

【「INFO」と「WARNING」で設定した際のメッセージ違い】

2016-07-26 15:48:46 GGS WARNING 123 Oracle GoldenGate Delivery for Oracle, rep01.prm: Processed LOG eventfor target table TEST_TARGET.MARKER010 in file ./dirdat/remote/rt000006, RBA 101654.

※異なる箇所

※「EVENTACTIONS」設定時特有のメッセージ

• 「EVENTACTIONS」パラメータを設定し、Replicatを自動停止

(21)

Conflict Detection and Resolution (CDR)

技術Tips

1. 競合とは

2. CDR概要

3. CDR設計時の検討事項

4. CDR設定項目

3

(22)

データ不整合

データ連携の2拠点間のレコードが一致していない状態。連携元で発生した更新が連携先で正

しく更新されなかった場合や、双方向連携中に同一レコードに対して異なる更新が発生した場

合に発生する可能性がある。

競合

データ連携時に連携先に更新適用する際にエラーやデータ不整合を招く状況。エラーが伴わな

い競合を検知しないとデータ不整合が発生する可能性がある。

データ連携におけるデータ不整合と競合について

GoldenGateには競合検知/競合解決の仕組みはあるが、

デフォルト機能では、エラーを伴わない競合検知ができない。

1. 競合とは

(23)

• 競合はReplicatプロセスのSQL適用時のエラーで検知可能

ORA-1(一意制約違反)、ORA-1403(対象レコードが存在しない)等のORAエ

ラー発生時にReplicatがABENDすることで検知できる。

• SQL適用時にエラーが発生しないケースでは検知が困難

更新対象レコードが存在するが、連携元と連携先でレコードの一部の値が異

なっている場合、UPDATEは更新対象列のみ更新する。

⇒UPDATE完了後にデータ不整合が発生する可能性がある。

GoldenGateにおける競合

GoldenGateでは、競合検知、および、競合解決のために

Conflict Detection and Resolution(CDR)を使用することが可能

1. 競合とは

(24)

双方向連携で競合が発生するタイミング

更新 – 参照

更新 – 更新(競合なし)

更新 – 更新(競合あり)

Application

Read/Write

Application

Read Only

Application

Read/Write

Application

Read/Write

Application

Read/Write

Application

Read/Write

GoldenGate

競合の有無

 ターゲット側がRead Onlyのため

競合は発生しない

競合の有無

 異なる行に対する更新のため、

競合は発生しない

競合の有無

 システムA/B の更新がシステムB/A

に反映されるまでの

タイムラグ

で

システムB/Aで同一行に対する

更新があった場合に

競合発生

単方向連携

双方向連携

システムA

システムB

システムA

システムB

システムA

システムB

(25)

INSERT

双方向連携で発生する競合例

Case1:新規データ挿入時に重複データが既に存在する場合

1

EMPNO(PK) ENAME LCHANGE_TS

7369 SMITH 01/05 14:00 8274 SCOTT 01/06 15:00

8274 SCOTT 01/06 15:00

7369 SMITH 01/05 14:00 8274 SCOTT 01/06 15:00

7369 SMITH 01/05 14:00

7369 SMITH 01/05 14:00 8274 PAUL 01/06 15:01 8274 PAUL 01/06 15:01

7369 SMITH 01/05 14:00 8274 SCOTT 01/06 15:00

7369 SMITH 01/05 14:00 8274 PAUL 01/06 15:01

一意制約違反でエラー

INSERT

8274 PAUL 01/06 15:01

GoldenGate

２

３

４

Time axis

1. 競合とは

(26)

DELETE

双方向連携で発生する競合例

Case2:データ削除時に対象の行が削除済

1

8274 SCOTT 01/06 15:00 8274 SCOTT 01/06 15:00

7369 SMITH 01/05 14:00

8274 SCOTT 01/06 15:00

7369 SMITH 01/05 14:00

対象データがなくエラー

DELETE

8274 SCOTT 01/06 15:00

GoldenGate

２

３

４

7369 SMITH 01/05 14:00 8274 SCOTT 01/06 15:00

Replicat はABEND

競合する変更は適用されない

Time axis

1. 競合とは

(27)

UPDATE

双方向連携で発生する競合例

Case3:データ更新時に対象の行が別の値で変更済

1

7369 JACK 01/06 18:30 7369 JACK 01/06 18:30 7369 JOHN 01/06 18:35

意図しないデータに更新

UPDATE

7369 JOHN 01/06 18:35

GoldenGate

２

３

４

7369 SMITH 01/05 14:00 8274 SCOTT 01/06 15:00

7369 JACK 01/06 18:30 8274 SCOTT 01/06 15:00

7369 JOHN 01/06 18:35 8274 SCOTT 01/06 15:00

7369 JACK 01/06 18:30 8274 SCOTT 01/06 15:00 Time axis

(28)

• Replicatプロセスがターゲット側でDML文を発行する際に競合を検知

–

Replicatが一意制約違反(ORA-1)やデータが見つからない(ORA-1403)エラーを検知し

てABENDする

GoldenGate

CDR使用有無に関わらず検知可能な競合

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

EMPNO

2299

ENAME

MIKE

EMPNO=2299の列が

既にある(ORA-1)

update

insert

(29)

• Replicatプロセスがターゲット側でDML文を発行する際に競合を検知

–

ターゲット側でDML文を実行する際のデータの状況が、ソース側でDML文を実行し

た時点のデータの状態と異なる値となっている状況

GoldenGate

CDR使用時に検知可能な競合

Source DB

Target DB

Capture Replicat

EMPNO

0128

ENAME

SCOTT

SALARY

1000 →

1500

EMPNO

0128

ENAME

SCOTT

Before

Image

EMPNO

0128

ENAME

SCOTT

SALARY

1300

ソース側のBefore Imageと比較

し、

異なる場合は競合として検知

(UPDATE, DELETE)

1. 競合とは

(30)

Replicat

Conflict Detection and Resolution(CDR)

ルールに基づく競合の検出・解決が可能。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概要

(31)

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 OVERWRITE IGNORE DISCARD

2. CDR概要

RESOLVECONFLICT

(32)

• INSERTROWEXISTS

ReplicatによるINSERT実行時に一意制約違反(ORA-1)

• UPDATEROWMISSING/DELETEROWMISSING

ReplicatによるUPDATE/DELETE実行時に更新対象レコードが存在しない(ORA-1403)

GoldenGate

CDRの競合検知シナリオについて

Source DB

Target DB

Capture Replicat

EMPNO

0128

ENAME

SCOTT

SALARY

1000 →

1500

EMPNO

-

ENAME

-

SALARY

-

EMPNO=0128の列が

存在しない(ORA-1403)

2. CDR概要

EMPNO

2299

ENAME

MIKE

EMPNO

2299

ENAME

MIKE

EMPNO=2299の列が

既にある(ORA-1)

update

insert

RESOLVECONFLICT

(33)

• UPDATEROWEXISTS/DELETEROWEXISTS

ReplicatによるUPDATE/DELETE実行時に、ソース側DML実行時のBefore Imageとターゲットの更新

対象レコードのSELECT結果を比較した結果、一致しない

GoldenGate

CDRの競合検知シナリオについて

Source DB

Target DB

Capture Replicat

EMPNO

0128

ENAME

SCOTT

SALARY

1000 →

1500

EMPNO

0128

ENAME

SCOTT

Before

Image

EMPNO

0128

ENAME

SCOTT

SALARY

1300

ソース側のBefore Imageと比較

し、

異なる場合は競合として検知

(UPDATE, DELETE)

2. CDR概要

RESOLVECONFLICT

(34)

競合解消ルール毎の詳細動作について

競合発生

パターン

競合検知

シナリオ

競合解決ルール

OVERWRITE

IGNORE

/DISCARD

USEMAX[EQ]

/USEMIN[EQ]

USEDELTA

INSERT実行時

ORA-1発生

INSERTROWEXISTS

insertをupdate

に変換

Insertをスキッ

プ

比較して大きい（小さい）場合、

insertをupdateに変換

N/A

UPDATE実行時

比較不一致

UPDATEROWEXISTS

updateを実行

updateをス

キップ

比較して大きい（小さい）場合、

updateを実行

Before ImageとAfter

Imageの差を追加

UPDATE実行時

ORA-1403発生

UPDATEROWMISSING

updateをinsert

に変換

Updateをス

キップ

N/A

DELETE実行時

比較不一致

DELETEROWEXISTS

deleteを実行

Deleteをス

キップ

N/A

DELETE 実行時

ORA-1403発生

DELETEROWMISSING

N/A

Deleteをス

キップ

N/A

RESOLVECONFLICT

(35)

双方向連携(競合あり)の競合解決単位

• サイト単位



一方のサイトを優先サイトとして定義する。



サイト単位の競合解決方式は「優先サイトの更新内容を優先」のみ。

• テーブル単位



テーブル毎に競合解決方式を定義する。



競合発生時にはテーブル毎の競合解決方式に従う。



競合解決方式毎に、伝播対象テーブルをグルーピングする。

3. CDR設計時の検討事項

(36)

双方向連携(競合あり)の競合解決方式

• 優先サイトの更新内容を優先



優先サイトで発生した更新が非優先サイトで競合した場合は上書きする。



非優先サイトで発生した更新が優先サイトで競合した場合は無視(IGNORE)

or 破棄(DISCARD)させる。

• 

更新時間列を持つテーブルで採用可能な競合解決方式



競合発生時にソース側DML発行時の更新時間とターゲット側更新対象レコー

ドの更新時間を比較する。



ソース側DML発行時の更新時間が新しい場合はターゲット側を上書きする。



ターゲット側更新対象レコードの更新時間が新しい場合は無視(IGNORE) or

破棄(DISCARD)させる。

3. CDR設計時の検討事項

(37)

双方向連携(競合あり)の競合解決パターン事例

• 事例１：優先サイトの更新を採用／非優先サイトの更新は無視

例）システムAを優先サイトとした場合の例

• 競合解決単位：サイト単位

• 競合解決方式：優先サイトの更新内容を優先

• OVERWRITE：競合が発生した場合、データを上書きする

• IGNORE ：競合が発生した場合、データは上書きしない

競合検知シナリオ システムA側の競合解消ルール （システムB→システムAの伝播） システムB側の競合解消ルール （システム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

(38)

双方向連携(競合あり)の競合解決パターン事例

• 事例２：値を比較してから最新の更新内容を採用

例）時刻データが格納された列を比較し、最新であるシステムのデータを優先

• 競合解決単位：テーブル単位

• 競合解決方式：最新の更新内容を優先

• USEMAX/USEMIN

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

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

競合検知シナリオ システムA側の競合解消ルール （システムB→システムAの伝播） システムB側の競合解消ルール（システム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

(39)

双方向連携(競合あり)の競合解決パターン策定

• 競合解決単位／競合解決方式から競合解決パターンを策定

–

事例１：優先サイトの更新を採用／非優先サイトの更新は無視

–

事例２：値を比較してから最新の更新内容を採用

–

DML種別で優先サイトを決定 etc

• 競合解決パターン毎の競合検知シナリオ/競合解消ルールを整理

–

サイトと競合検知シナリオの組み合わせ毎に競合解消ルールを決定

–

サイト×競合検知シナリオ×競合解消ルールをマトリクスで管理

方式設計フェーズ：競合解決パターンの数と競合解決パターン毎のCDR設定を決定

詳細設計フェーズ：競合解決パターン毎の伝播対象テーブルを決定

3. CDR設計時の検討事項

(40)

競合検知列の策定事例

• 方法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

(41)

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 でのみ設定が必要

(42)

CDRを使用するために必要となる設定項目（Replicat）

• Replicat



COMPARECOLSパラメータの設定

‒

競合検知・解決に使用する列名の指定（LOB列は除外する必要あり）

‒

ExtractにGETBEFORECOLSパラメータが指定され、Before Imageが出力されている必要がある。



RESOLVECONFLICTパラメータの設定

‒

競合検知シナリオと競合解決ルールを指定

4. CDR設定項目

(43)

まとめ

GoldenGate活用事例のご紹介

• メンテナンス時間の短縮

• 本番データを利用したAPテスト

イベント・マーカーの活用事例

• MViewでのレプリケーション長期化をイベント・マーカーで解消

Conflict Detection and Resolution(CDR)技術Tips

(44)

Appendix

(45)

表レベルサプリメンタル・ロギングの設定

• 主キーと競合検知に使用する列に、表レベルサプリメンタル・ロギングの

設定が必要

–

全ての列を比較する場合は、全列が対象

–

LOB列がある場合は、Oracleデータベースの制限でサプリメンタル・ロギングを設定

できないため、LOB列を除外する必要がある

ADD TRANDATAの実行

--NOKEYなしの場合は、主キー以外の列を指定

GGSCI> ADD TRANDATA <schema>.<table>, COLS (<col1>,<col2>,…)

--NOKEYをつける場合は、主キーを含む列を指定

(46)

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

システム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文は

(47)

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

(48)

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

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

更新実行

システムA システムB

CDR適用後

(49)

LOB列がある場合の対応(2/2)

• 対応方法

–

CaptureプロセスのTABLEパラメータに、FETCHCOLS、FETCHMODCOLSを指定

• FETCHCOLS (<LOB列名>)

–

Trail ファイルに値が存在しない場合に、データベースから列値をFETCHします。LOBデータを強制的に

FETCHさせる場合、本パラメータは必須。

• FETCHMODCOLS(<LOB列名>)

–

Trail ファイルに値がに存在する場合でも、列値をデータベースからFETCHする。

(50)

Oracle Digitalは、オラクル製品の導入をご検討いただく際の総合窓口。

電話とインターネットによるダイレクトなコニュニケーションで、どんなお問い合わせにもすばやく対応します。

もちろん、無償。どんなことでも、ご相談ください。

(51)

(52)

(53)

データ統合/連携の領域におけるリアリティ

データ連携のプロフェッショナル陣が語る！

現場で使える、Oracle GoldenGate テクニカルセミナー

Session 4 :

テクニカル・コンサルタントが語る、

Oracle GoldenGate 現場で使える極意

2016年12月06日

日本オラクル株式会社

クラウド・テクノロジーコンサルティング事業本部

テクニカルアーキテクト部

ソリューションプリンシパル

浅井 純

•

以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するも

のです。また、情報提供を唯一の目的とするものであり、いかなる契約にも

組み込むことはできません。以下の事項は、マテリアルやコード、機能を提

供することをコミットメント（確約）するものではないため、購買決定を行う際

の判断材料になさらないで下さい。オラクル製品に関して記載されている機

能の開発、リリースおよび時期については、弊社の裁量により決定されます。

Agenda

GoldenGate活用事例のご紹介

イベント・マーカーの活用事例

Conflict Detection and Resolution (CDR) 技術Tips

Appendix

1

2

3

GoldenGate活用事例のご紹介

事例１: メンテナンス時間の削減

BUSINESS OBJECTIVES

•

表構成の変更、データの洗い替えを伴う

メンテナンス時間を削減

したい



24時間365日稼働するシステム



メンテナンスに伴うシステム停止許容時間は10分

SOLUTION

•

メンテナンスをターゲットDB側であらかじめ実施しておくことで、メンテナンスによる

ダウンタイムはAP接続先

サーバの切替え時間のみに縮小

•

GoldenGateは表構成が異なる表のDML文の連携をサポートするため、

表構成の変更にも対応

•

変換テーブル（ルックアップ表）を活用しデータを変換しながら適用

することで、データの洗い替えに対応

事例１: メンテナンス時間の削減

① 通常時のレプリケーション

Source DB

Capture

Pump

Replicat

Target DB

Replicat

Pump

Capture

AP

Point

・ 順同期用、逆同期用のプロセスを事前に準備

・ 順同期用プロセスのみ稼働させる

事例１: メンテナンス時間の削減

② メンテナンス実施

Source DB

Capture

Pump

Replicat

Target DB

Replicat

Pump

Capture

AP

メンテナンス実施

•列構成変更 → 列追加

•データ洗い替え→ 1月からJanへ

Point

・ 順同期用Replicatを停止し、メンテナンスを実施

・メンテナンス中のAP更新は、順同期用Captureで継続して情報取得

浅井純

・順同期用、逆同期用のプロセスを事前に準備

・順同期用プロセスのみ稼働させる

・順同期用Replicatを停止し、メンテナンスを実施

・メンテナンスを反映させる

③ メンテナンス中の更新を反映：ルックアップ表を利用したデータ変換の流れ

・逆同期用Captureの読み取り位置をリセット後、Source DB側で新APを起動