DBA & Developer Day 2016 ダウンロード資料

(1)

知ってる人は始めている！

Oracle GoldenGateフル活用！

具体的に説明します！

日本オラクル株式会社

クラウド・テクノロジー事業統括

Cloud/Big Data/DISプロダクト本部

(2)

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

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

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

機能を提供することをコミットメント（確約）するものではないため、

購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関

して記載されている機能の開発、リリースおよび時期については、弊社

の裁量により決定されます。

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

(3)

本日の内容

GoldenGate 概要（おさらい）

データ活用のためのTips

その他Tips

1 2 3

(4)

本日の内容

GoldenGate 概要（おさらい）

データ活用のためのTips

その他Tips

1 2 3

(5)

Oracle GoldenGate - アーキテクチャー概要

GoldenGate

更新ログ

抽出 プロセス (Capture) 転送 プロセス (DataPump)

OS

Trailファイル

GoldenGate

受信 プロセス (Collector) 適用 プロセス (Replicat)

OS

Trailファイル

SQL を生成してトランザクションを適用 (標準方式) 論理変更レコードを DBに直接転送 (Oracle DBのみ)

(6)

停止時間を極小化したデータベース移行

GoldenGate のよくある使い方

1) システム移行前 2) システム切替当日 3) システム移行後

GoldenGate GoldenGate GoldenGate

切り戻しに活用

(7)

GoldenGate のよくある使い方

クエリー・オフロード / データ活用

GoldenGate 現行DB 新環境DB 新規サービス開発・テスト必要な表だけレプリケーション検索処理をオフロード

(8)

Cloudにも対応

GoldenGate Cloud Service (GGCS)

他社クラウドサービスオンプレミス・環境

Database Database

Oracle Cloud 環境 Oracle Cloud 環境

DBCS GGCS GGCS GGCS GGCS DBCS DBCS GoldenGate GoldenGate 単方向 or 双方向単方向 or 双方向単方向 or 双方向 3rd _Party Cloud

DBCS : Database Cloud Service ExaCS : Exadata Cloud Service BDCS : Big Data Cloud Service

DBCS

【注意】 ExaCS/BDCS への接続は 今後提供予定

(9)

Network

Oracle GoldenGate

GoldenGate Cloud Service

GoldenGate Cloud Service アーキテクチャー

抽出プロセス

(Capture) 転送プロセス(DataPump) 受信プロセス(Collector) 適用プロセス(Replicat) 抽出プロセス (Capture) 転送プロセス (DataPump) 受信プロセス (Collector) 適用プロセス (Replicat)

GoldenGate Cloud Service

DBCS DBCS

Operating System GoldenGate Cloud Service DBCS

■ DBCS - DBCS 間の場合 ■ オンプレミスDB - DBCS 間の場合 Trailファイル抽出プロセス (Capture) 転送プロセス (DataPump) 受信プロセス (Collector) 適用プロセス (Replicat) 抽出プロセス

(Capture) 転送プロセス(DataPump) 受信プロセス(Collector) 適用プロセス(Replicat)

(10)

ルールベースの競合解決機能「Conflict Detection and Resolution (略称：CDR)」

双方向同期における競合データ解決に対応

OGG CDRによる競合解決ソース側でのキャプチャ時に、Before Image(変更前イメージ) とAfter Image(変更後イメージ)をTrailに格納し、Replicatでターゲット側に適用する際に競合を解決 Insert処理時の競合(一意制約違反)を検知 Update処理時にBefore Imageとの違いを検知 Update処理時に対象が存在しないことを検知 Delete処理時にBefore Imageとの違いを検知 両方で同じ行/列のデータを更新する場合、 データ連携時に競合が発生してしまう。 更新処理 競合の例 CDRでの解決 事前にルールを設定しておくことで、 上書きやスキップ等の処理を自動化可能 Before Image

After Image Replicat

ターゲットデータルール OVERWRITE(上書き) IGNORE(スキップ) DISCARD(スキップ) USEMAX[EQ](値比較) 検知ルール解決ルール 1)検知と解決のルールを組み合わせて定義設定 2)Trailデータの取り込み 3)ターゲットデータの状態確認 4)競合検知後のルール確認 5)ルールに基づいた適用

(11)

Web公開しているGoldenGate技術情報

• ここにまとめています

– http://www.oracle.com/technetwork/jp/middleware/goldengate/learnmore/index.html

–

「Oracle GoldenGate お役立ち情報」で検索

• 例えばこんな情報

–

アーキテクチャと基本機能

• http://www.slideshare.net/oracle4engineer/oracle-goldengate-55184702

–

導入するときのポイント・注意事項

–

障害発生時にサポートサービスに提供すべき情報の取得方法

–

オラクルコンサル直伝のノウハウ

• https://blogs.oracle.com/oracle4engineer/entry/material_goldengate_ocs • http://www.slideshare.net/oracle4engineer/goldengate4oracle-goldengate2016511

(12)

本日の内容

GoldenGate 概要（おさらい）

データ活用のためのTips

その他Tips

1 2 3

(13)

GoldenGate の柔軟性

• 異機種間のレプリケーション

–

旧バージョンのOracle DBから 12c にデータ移行

–

商用UNIXのデータをLinuxに切り出す

• 異なる表間のレプリケーション

–

表名が異なる

–

列構成が異なる

–

(変換処理により)データが異なる

本日掘り下げる部分

移行・クエリーオフロードで

実績豊富

参考マニュアル http://docs.oracle.com/cd/E74358_01/gg-winux/GWUAD/wu_datainteg.htm GoldenGate • GoldenGateが使いやすい形でデータを供給 • 開発・データ加工のコストを削減

(14)

• やりたいこと

–

複数DBの表データを統合して参照

可能にする

複数のDBの表データを統合

Tokyo_DB Osaka_DB Consolidated_DB

(15)

• 導入方法

–

2つのレプリケーションを構成

• Tokyo to Consolidated

• Osaka to Consolidated

–

2つのReplicatは同一のターゲット

表に対してそのままデータ伝搬する

• キー列値が重複しない前提

パターン1：そのまま統合

Key Col1 Col2

Tokyo_DB Osaka_DB Consolidated_DB Capture Trail Pump Trail Replicat Capture Trail Pump Trail Replicat

Key Col1 Col2

101 AA1 Cool 102 AA2 Hot 203 BB3 Hot 101 AA1 Cool 102 AA2 Hot 203 BB3 Hot

(16)

設定パラメータ

extract ext1a userid ggs, password ggs exttrail ./dirdat/1a table test.t_tab1; extract ext1b userid ggs, password ggs exttrail ./dirdat/1b table test.o_tab1; Tokyo側 Capture Osaka側 Capture extract pump1a rmthost <XX>, mgrport <XX> passthru rmttrail ./dirdat/1a table test.t_tab1; extract pump1b rmthost <XX>, mgrport <XX> passthru rmttrail ./dirdat/1b table test.o_tab1; Tokyo側 Pump Osaka側 Pump replicat rep1a userid ggs, password ggs map test.t_tab1, target test.c_tab_01; replicat rep1b userid ggs, password ggs map test.o_tab1, target test.c_tab_01; Tokyo側 Replicat Osaka側 Replicat ※ データ連携に必要な最低限のパラメータを記載 伝搬対象のテーブルを指定 ソース/ターゲットのマッピングを記載 (test.o_tab1 としてキャプチャした データをtest.c_tab_01 に伝搬)

(17)

• 実現したいこと

–

ターゲット表からデータの生成元を

確認できる

–

キー列値が重複しても制約違反にならない

• 導入方法

–

2つのレプリケーションを構成

• Tokyo to Consolidated • Osaka to Consolidated

–

Replicatパラメータに列マッピングを記述

し、Loc列に固定値を挿入する

パターン2：ターゲット表に列を追加

Consolidated_DB Capture Trail Pump Trail Replicat Capture Trail Pump Trail Replicat

Loc Key Col1 Col2 Key Col1 Col2

Tokyo_DB

Osaka_DB

Key Col1 Col2

101 AA1 Cool 102 AA2 Hot 203 BB3 Hot T 101 AA1 Cool T 102 AA2 Hot O 203 BB3 Hot

(18)

設定パラメータ

extract ext2a userid ggs, password ggs exttrail ./dirdat/2a table test.t_tab1; extract ext2b userid ggs, password ggs exttrail ./dirdat/2b table test.o_tab1; Tokyo側 Capture Osaka側 Capture extract pump2a rmthost <XX>, mgrport <XX> passthru rmttrail ./dirdat/2a table test.t_tab1; extract pump2b rmthost <XX>, mgrport <XX> passthru rmttrail ./dirdat/2b table test.o_tab1; Tokyo側 Pump Osaka側 Pump ※ データ連携に必要な最低限のパラメータを記載 replicat rep2a userid ggs, password ggs map test.t_tab1, target test.c_tab_02, colmap ( usedefaults, LOC = 'T' ); replicat rep2b userid ggs, password ggs map test.t_tab1, target test.c_tab_02, colmap ( usedefaults, LOC = ‘O' ); Tokyo側 Replicat Osaka側 Replicat Colmap句でソースとターゲットの 列の関連を記載。Usedefaultは同一 の列をそのままマッピングする指定。

(19)

• GoldenGate 12.1以前

– ソースDBから定義ファイルを抽出し、Replicat がsourcedefsパラメータで読み込む必要がある

• “同一の構成”と判断される条件

– 同一DB(Oracle と Oracle など) – 同一キャラクタ・セットとロケール – 列数・列名・データ型・列長が同一 – 列長さセマンティクス(バイトか文字か)が同じ – すべての列が同じ順序で定義されている

• GoldenGate 12.2

– Trail ファイルに定義情報が自動的に格納されるため、定義ファイルの作成は不要

参考：構成の異なる(同一ではない)表間のレプリケーション

Capture Trail Pump Trail Replicat defgen Metadata Capture Trail Pump Trail Replicat Metadata Metadata GoldenGate 12.1 まで：定義ファイルを作れば、後はGoldenGateがデータマッピングしてくれる。 GoldenGate 12.2では、定義ファイルの扱いも不要に！ ※ 本資料のサンプルは GoldenGate 12.2を想定

(20)

• 実現したいこと

–

データ統合に合わせて新しいコード体系を

導入

–

キー列値が重複しても制約違反にならない

• 導入方法

–

2つのレプリケーションを構成

–

ターゲットDBにコード変換用のルック

アップ表を作成

–

Replicatにルックアップ表を使用した

変換処理を記載

パターン3：コード体系の変更

Consolidated_DB Capture Trail Pump Trail Replicat

Capture Pump Replicat

C_K Key Col1 Col2

Lookup

Key Col1 Col2

Tokyo_DB

Osaka_DB

Key Col1 Col2

101 AA1 Cool 102 AA2 Hot 203 BB3 Hot C_K Key T01 101 O03 203 T02 102 T01 101 AA1 Cool T02 102 AA2 Hot O03 203 BB3 Hot

(21)

設定パラメータ

extract ext3a userid ggs, password ggs exttrail ./dirdat/3a table test.t_tab1; extract ext3b userid ggs, password ggs exttrail ./dirdat/3b table test.o_tab1; Tokyo側 Capture Osaka側 Capture extract pump3a rmthost <XX>, mgrport <XX> passthru rmttrail ./dirdat/3a table test.t_tab1; extract pump3b rmthost <XX>, mgrport <XX> passthru rmttrail ./dirdat/3b table test.o_tab1; Tokyo側 Pump Osaka側 Pump ※ データ連携に必要な最低限のパラメータを記載

(22)

設定パラメータ -cont

※ データ連携に必要な最低限のパラメータを記載 replicat rep3a userid ggs, password ggs map test.t_tab1, target test.c_tab_03,

SQLEXEC (ID LOOKUP,

QUERY "SELECT C_K FROM TEST.LOOKUP WHERE KEY = :CODE_IN_PARAM“,

PARAMS (CODE_IN_PARAM = KEY )), colmap (usedefaults, C_K = @GETVAL(LOOKUP.C_K) ); replicat rep3b userid ggs, password ggs map test.t_tab1, target test.c_tab_03,

SQLEXEC (ID LOOKUP,

QUERY "SELECT C_K FROM TEST.LOOKUP WHERE KEY = :CODE_IN_PARAM“,

PARAMS (CODE_IN_PARAM = KEY )), colmap (usedefaults,

C_K = @GETVAL(LOOKUP.C_K) );

Tokyo側 Replicat _{Osaka側 Replicat}

SQLEXEC句でReplicatが実行するSQLについて記載 QUERY:実行するSQL文

(23)

• 実現したいこと

–

ソースDBでの処理確定時間を伝搬

–

ターゲット側で時間軸での絞り込みが可能

• 例：2016年第1四半期のデータから集計

• 導入方法

–

2つのレプリケーションを構成

–

Replicatパラメータに列マッピングを記載

し、commit timestamp情報を Time列に

マップする

パターン4：処理時間情報を付与

Consolidated_DB Capture Trail Pump Trail Replicat Capture Trail Pump Trail Replicat

Key Col1 Col2 Time

Key Col1 Col2

Tokyo_DB

Osaka_DB

Key Col1 Col2

101 AA1 Cool 102 AA2 Hot 203 BB3 Hot 101 AA1 Cool Ts 102 AA2 Hot Ts 203 BB3 Hot Ts

(24)

設定パラメータ

extract ext4a userid ggs, password ggs exttrail ./dirdat/2a table test.t_tab1; extract ext4b userid ggs, password ggs exttrail ./dirdat/2b table test.o_tab1; Tokyo側 Capture Osaka側 Capture extract pump4a rmthost <XX>, mgrport <XX> passthru rmttrail ./dirdat/4a table test.t_tab1; extract pump4b rmthost <XX>, mgrport <XX> passthru rmttrail ./dirdat/4b table test.o_tab1; Tokyo側 Pump Osaka側 Pump ※ データ連携に必要な最低限のパラメータを記載 replicat rep4a userid ggs, password ggs map test.t_tab1, target test.c_tab_04, colmap (usedefaults,

TIME = @GETENV ('GGHEADER', 'COMMITTIMESTAMP') ); replicat rep4b userid ggs, password ggs map test.t_tab1, target test.c_tab_04, colmap (usedefaults,

TIME = @GETENV ('GGHEADER',

Tokyo側 Replicat Osaka側 Replicat GETENV関数でTrailファイル に格納されたcommit timestamp Trailファイルには表データ 以外に関連する様々な属性 (scn,commit時間, 処理の種類 など)が格納される

(25)

参考：タイムゾーンを調整

• ソースDBが海外にあり、時刻列に Timestamp with Timezoneを使っていない場合など

..

map test.t_tab1, target test.c_tab_04, colmap ( usedefaults,

time = @DATE ('YYYY-MM-DD HH:MI:SS', 'JTS', @COMPUTE

(@DATE ('JTS', 'YYYY-MM-DD HH:MI:SS', source_col) + 18000000000 ))); (1) DATE関数でース表の時刻列をJTS (ユリウスタイムスタンプ)に変換 Trailファイル内の timestampを時差調整 (3) DATE関数で(2)の結果を フォーマット変換し、ターゲット表の time列にマップ

time = @DATE ('YYYY-MM-DD HH:MI:SS', 'JTS', @COMPUTE

(@DATE ('JTS', 'YYYY-MM-DD HH:MI:SS', @GETENV ('GGHEADER', 'COMMITTIMESTAMP') ) + 18000000000 ))

(2) COMPUTE関数で(1)に

(26)

テスト・開発用データは機密情報をマスクしたい

ID Name Address Card No

Capture

Trail

Pump

Trail

Replicat

ID Name Address Card No

業務AP Card No 参照可 テスト・開発 Card No 参照不可 機密情報をテスト・サー バーに送信しないよう、 ローカルTrailファイル書き 込み時点でマスク 101 Taro Tokyo… 123-123 102 Jiro Osaka… 123-456 103 Goro Nagoya… 123-789 101 Taro Tokyo… XXX-XXX 102 Jiro Osaka… XXX-XXX 103 Goro Nagoya… XXX-XXX

(27)

設定パラメータ

extract ext5a userid ggs, password ggs exttrail ./dirdat/5a table test.cust target test.cust_test, colmap ( usedefaults, card_no = 'XXX-XXX' ); Capture extract pump5a rmthost <XX>, mgrport <XX> passthru rmttrail ./dirdat/5a table test.cust_test; Pump ※ データ連携に必要な最低限のパラメータを記載 replicat rep5a userid ggs, password ggs

map test.cust, target test.cust_test;

Replicat

※本ケースでのマスキングは値を置き換えるだけの簡易的なものです カーディナリティの考慮等、より汎用的なマスキングが必要な場合は Oracle Data Masking and Subsetting をご使用ください

Card_no列に定数’XXX-XXX’をマップ

してTrailファイルに格納、以降のプロセスは Card_no列の元と値を確認できない

(28)

データを貯める

パターン1：削除処理を伝搬しない設定

Order No Cust Prod Date

… … … … ① 新規オーダー追加 ② 2015年の注文情 報を削除 Capture ①新規オーダー、 ②過去の注文情報も 参照可能

Order No Cust Prod Date

00024 CustA Prod Y 2015-XX-XX 00025 CustB Prod Z 2015-XX-XX 00032 Cust Prod R 2015-XX-XX … … … … レプリケーション対象 表へのDELETEを伝搬

②

①

Insertによる新規レコード追加がメインのテーブルのデータ蓄積に有効（注文表など） 00024 CustA Prod Y 2015-XX-XX 00025 CustB Prod Z 2015-XX-XX 00032 Cust Prod R 2015-XX-XX

(29)

設定パラメータ

extract ext6a userid ggs, password ggs exttrail ./dirdat/6a ignoredeletes table test.orders; Capture extract pump6a rmthost <XX>, mgrport <XX> passthru rmttrail ./dirdat/6a table test.orders; Pump ※ データ連携に必要な最低限のパラメータを記載 replicat rep6a userid ggs, password ggs map test.orders, target test.orders_hist; Replicat Delete文により処理は Trailファイルに格納しない

※過去データをdrop partition/truncate partition

等で削除している場合は、ソース表へのDDLレプリケーション (ALTER TABLE)を対象外にする

(30)

データを貯める

パターン2：処理履歴を蓄積

ID Balance Grade ID Balance Grade 123 400 Gold 345 50 Silver 678 210 Gold ③ID=123列を削除 ②ID=345列を更新 ①ID=981列を追加

ID Bal Grade Timestamp Op

Capture Trail Pump Trail Replicat Updateによるデータ更新がメインとなるテーブ ルのデータ蓄積に有効（口座、契約、在庫、その 他マスタ表など） 監査ログとしても活用可能 981 0 Black 450 Gold 123 400 Gold 2014-10-07 19:17:32 I 345 50 Silver 2014-10-07 19:21:00 I 678 210 Gold 2014-10-07 19:25:32 I 981 0 Black 2014-10-08 1:30:19 I 345 450 Gold 2014-10-08 1:33:05 U 123 400 Gold 2014-10-08 1:36:57 D 123 400 Gold 345 50 Silver 678 210 Gold

(31)

設定パラメータ

extract ext7a userid ggs, password ggs exttrail ./dirdat/7a table test.credit; Capture extract pump7a rmthost <XX>, mgrport <XX> passthru rmttrail ./dirdat/7a table test.orders; Pump ※ データ連携に必要な最低限のパラメータを記載 replicat rep7a userid ggs, password ggs insertallrecords map test.credit, target test.credit_hist, colmap ( usedefaulsts, timestamp = @GETENV ('GGHEADER', 'COMMITTIMESTAMP‘) operation = @GETENV ('GGHEADER', 'OPTYPE') ) ; Replicat ソース表は全列サプリメンタル ロギング対象する必要がある 全ての処理レコードをINSERTで ターゲット表に反映する Timestamp列にTrailファイルに 格納されたcommit timestamp値 をマップ Operation列にTrailファイルに格納された 処理の種類(Insert/Update/Delete)をマップ

(32)

データを貯める

処理履歴を蓄積しつつ、データ同期もする

Trail Replicat •同じトランザクション情報を格納した Trailファイルから2表にデータ適用。 •１つは、処理履歴を蓄積 •１つは、レプリカ ID Balance Grade Capture Pump Trail

123 400 Gold 2014-10-07 19:17:32 I 345 50 Silver 2014-10-07 19:21:00 I 678 210 Gold 2014-10-07 19:25:32 I 981 0 Black 2014-10-08 1:30:19 I 345 450 Gold 2014-10-08 1:33:05 U 123 400 Gold 2014-10-08 1:36:57 D 123 400 Gold 345 50 Silver 678 210 Gold 981 0 Black 450 Gold ID Balance Grade 123 400 Gold 345 50 Silver 678 210 Gold 981 0 Black 450 Gold

(33)

設定パラメータ

extract ext8a userid ggs, password ggs exttrail ./dirdat/8a table test.credit; Capture extract pump8a rmthost <XX>, mgrport <XX> passthru rmttrail ./dirdat/8a table test.orders; Pump ※ データ連携に必要な最低限のパラメータを記載 replicat rep8a userid ggs, password ggs insertallrecords map test.credit, target test.credit_hist, colmap ( usedefaulsts, timestamp = @GETENV ('GGHEADER', 'COMMITTIMESTAMP‘) operation = @GETENV ('GGHEADER', 'OPTYPE') ) ;

map test.credit, target test.credit;

Replicat

データ同期用のMAPを 一つ追加するだけ

(34)

データ蓄積に適した基盤にも対応

Oracle GoldenGate for Big Data = Hadoop用データ投入モジュール

①トランザクション抽出 ②転送 ③適用 ③適用 （処理履歴）

抽出・転送までは

RDB to RDBと全く同じ仕組み

Trail Replicat Capture Pump Trail

RDB

Hadoop

Replicat ここだけ

(35)

設定パラメータ

※ データ連携に必要な最低限のパラメータを記載

REPLICAT rep_bd

TARGETDB LIBFILE ./libggjava.so SET property= ./dirprm/hive.props

DDL INCLUDE ALL

MAP test.credit, TARGET demo.credit_hist;

Replicat

ターゲット環境に会わせて プロパティファイルを指定

Hadoopに対する DDL伝搬も可能

(36)

参考：HDFS Handler(For Hive)の例

gg.handlerlist=hive gg.handler. hive.type=hdfs gg.handler.hive.mode=tx gg.handler.hive.includeTokens=false gg.handler.hive.maxFileSize=1g gg.handler.hive.rootFilePath=/ogg 21/txt gg.handler.hive.fileRollInterval=0 gg.handler.hive.inactivityRollInterval=0 gg.handler.hive.fileSuffix=.txt gg.handler.hive.partitionByTable=true gg.handler.hive.rollOnMetadataChange=true gg.handler.hive.authType=none gg.handler.hive.format=delimitedtext gg.handler.hdfs.format.encoding=UTF-8 gg.handler.hdfs.format.fieldDelimiter=| goldengate.userexit.timestamp=utc goldengate.userexit.writers=javawriter javawriter.stats.display=TRUE javawriter.stats.full=TRUE gg.log=log4j gg.log.level=INFO gg.report.time=30sec gg.checkpoint=java gg.classpath=/etc/hadoop:/etc/hadoop/conf :/usr/lib/hadoop/client/*:/usr/lib/hadoop/*: /usr/lib/hadoop/lib/*:/usr/lib/hadoop- hdfs/*:/usr/lib/hadoop- hdfs/lib/*:/etc/hadoop/conf/core- site.xml:/etc/hadoop/conf/hdfs-site.xml:./ggjava/*:./ggjava/resources/lib/* javawriter.bootoptions=-Xmx512m -Xms32m

(37)

GoldenGate for Big Data

様々なテクノロジに対応

• ターゲット・テクノロジ

–

HDFS

–

Hive

–

HBASE

–

Flume

–

Kafka

–

MongoDB(*)

–

Elastic Search(*)

* 2016/10/27時点 java.netでの公開モジュールのみ（サポートサービス提供なし）

• データフォーマット

–

JSON

–

AVRO

–

XML

–

デリミタ区切り

Big Data Lite – GoldenGate for Big Dataを含むOracle DB / Hadoop環境のVM環境を無償で公開しています。

http://www.oracle.com/technetwork/database/bigdata-appliance/oracle-bigdatalite-2104726.html

(38)

GoldenGate for Big Data

Hive Table に蓄積した処理履歴から最新状態のみを表示

123 400 Gold 2014-10-07 19:17:32 I 345 50 Silver 2014-10-07 19:21:00 I 678 210 Gold 2014-06-08 19:17:32 I 981 0 Black 2014-10-08 1:30:19 I 345 450 Gold 2014-10-08 1:33:05 U 123 400 Gold 2014-10-08 1:36:57 D Replicat GoldenGate Hive Table

CREATE VIEW credit_latest AS

SELECT t1.*

FROM credit t1

JOIN (SELECT id,

Max(timestamp) max_modified

FROM credit GROUP BY id) s ON t1.id = s.id

AND t1.timestamp = s.max_modified WHERE t1.op_type != ‘D';

Trail

Hive View作成 _{レコードを抽出}IDごとの最新

削除された レコードは除外

ID Balance Grade

345 450 Gold

(39)

本日の内容

GoldenGate 概要（おさらい）

データ活用のためのTips

その他Tips

1 2 3

(40)

• DBに発生したイベントに応じて、

GoldenGateプロセスが任意の処理を起動

• イベントとは「特定の表に特定のデータが入

る」など、GoldenGateのパラメータ内で指

定可能なもの

– Flag更新のイメージ – Capture/Pump/Replicat で設定可能

• ユースケース

–

日時処理のShellをキック

–

Replicatの停止

• ターゲットを静止断面にする

–

SQL実行

• Event表に挿入されたSQL文をそのまま実行することが可能 • INSSERT SELECT等を高速に伝播できる

–

Mviewのリフレッシュを実行

• 参考マニュアル

– http://docs.oracle.com/cd/E74358_01/gg-winux/GWUAD/wu_customcode.htm#i1047744 – http://docs.oracle.com/cd/E74358_01/gg-winux/GWURF/gg_parameters168.htm#i2016744

イベント・マーカー

Capture Trail Pump Trail Replicat Event表に データ追加 Event表のデー タを認識したら、 ジョブを起動

(41)

• やりたいこと

–

ソース側は処理A、処理Bを順に実行

–

ターゲット側は処理Aの伝搬が完了したら、

バッチ処理を流し、その後処理Bを伝搬

• 処理A終了時の静止断面で日次処理の実行が必要等の要件を想定

• 実現方法

–

ソース側で処理AとBの間にイベントテー

ブルを更新処理を入れる

–

Replicatを2つ構成

• レプリケーション用とバッチ処理起動用

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

Capture Trail Pump Trail Replicat1 (1)処理A (2)イベント更新 (3)処理B •処理Aの伝搬 •イベント更新のレコード を受け取ったら停止 •再起動後処理Bを伝搬 Replicat2 •イベント更新レコードを受 け取ったらシェル実行 •シェルの中でバッチ処理を 実行 •バッチ処理完了後に Replicat2を起動 • 処理Aを伝搬 • イベント更新を伝搬 • 処理Bを伝搬

(42)

設定パラメータ

extract ext9a userid ggs, password ggs exttrail ./dirdat/9a table test.*; table ggs.event; Capture extract pump9a rmthost <XX>, mgrport <XX> passthru rmttrail ./dirdat/9a table test.*; table ggs.event; Pump replicat rep9a userid ggs, password ggs map test.*, target test.*; insertallrecords

map ggs.event, target ggs.event,

where (flag = ‘STOP’), EVENTACTIONS (STOP);

replicat rep9b

userid ggs, password ggs

map ggs.event, target ggs.event,

where (flag = ‘STOP’),

EVENTACTIONS (SHELL “./batch.sh” );

Replicat1 Replicat2 ※ データ連携に必要な最低限のパラメータを記載 イベントテーブルにSTOP フラグを受け取ったら バッチシェルを実行 イベントテーブルにSTOP フラグを受け取ったら Replicat停止

(43)

バッチシェルのサンプル

#!/bin/sh #変数の設定 OGG_HOME=<GoldenGateインストールディレクトリ> INTERVAL=<Replicat停止確認の間隔> REP_MONITOR=<バッチ実行用Replicatの名前> REP_NAME=<レプリケーション用Replicatの名前> # ABENDしているReplicatがいる場合は、ログを出力して処理終了

echo "info all"|$OGG_HOME/ggsci|grep REPLICAT|grep -v $REP_MONITOR|awk '{print $2}'>rep_temp.out

grep -q "ABENDED" rep_temp.out if [ "$?" == 0 ]; then

echo "SUSPENDING BATCH RUN AS ONE OR MORE REPLICATS ARE IN ABENDED STATE">rep_status.out

exit 1

# バッチ実行用Replicat以外のReplicatがすべて終了していることを確認 else

r_counter=`echo "info all"|$OGG_HOME/ggsci|grep "RUNNING"|grep "REPLICAT"|grep -v $REP_MONITOR|awk '{print $2}'|wc -l`

while [ "$r_counter" != 0 ]; do sleep $INTERVAL

r_counter=`echo "info all"|$OGG_HOME/ggsci|grep "RUNNING"|grep "REPLICAT"|grep -v $REP_MONITOR|awk '{print $2}'|wc -l`

# 再度ABENDしているReplicatがいるかを確認

echo "info all"|$OGG_HOME/ggsci|grep REPLICAT|grep -v $REP_MONITOR|awk '{print $2}'>rep_temp.out

grep -q "ABENDED" rep_temp.out if [ "$?" == 0 ]; then rep_state=1 break fi done # バッチ処理を実行 if [ "$rep_state" != 1 ]; then

echo "RUNNING BATCH JOB...." >> rep_temp.out ##################

# ここにバッチ処理を記述。本サンプルはダミー echo "BATCH processing completed !!!" > result.out

# バッチ完了後、レプリケーション用のReplicatを再度起動 echo "start $REP_NAME"|$OGG_HOME/ggsci

################### exit 0

else

echo "SUSPENDING BATCH RUN AS ONE OR MORE REPLICATS ARE IN ABENDED STATE" >rep_status.out exit 1 fi fi ※サンプルはサポート外です。環境に合わせて適宜編集ください

(44)

• やりたいこと

–

ソース側は処理A、処理Bを順に実行

–

ターゲット側は処理Aの伝搬し、処理Bは

ターゲット側で実行する

• 処理Bはラージトランザクションなどを想定

• 実現方法

–

ソース側で処理Bの前後にイベントテーブ

ルを更新処理を入れる

–

Replicatを2つ構成

• レプリケーション用とバッチ処理起動用

–

My Oracle Supportにサンプルを掲載

• Oracle GoldenGate Best Practices: Dual

Apply for GoldenGate (ドキュメントID

イベント・マーカー活用例 – dual apply

-Capture Trail Pump Trail Replicat1 (1)処理A (2)イベント更新 (3)処理B (4)イベント更新 •処理A伝搬 •イベント更新のレコード を受け取ったら停止 •Replicat2より起動され る Replicat2 •イベント更新のレコードを受け 取ったらシェル実行 •シェルの中でバッチ処理を実行 •シェル完了後、イベント更新の レコードを受け取ったら • 処理Aを伝搬 • イベント更新を伝搬 • 処理Bは伝搬しない • イベント更新を伝搬

(45)

GoldenGate 12.1.2.1以降の Globalization機能

• Column Level Character Set Support

– 列レベルで異なるキャラクタセットを認識して

データ変換・レプリケーションを実施可能

– ReplicatのMAPパラメータのオプション

• CHARSET : 表レベル、COLCHARSET : 列レベル

• Character Mapping Override

– キャラクタセット間のマッピングを上書き • マップ先が無い文字に代替のマップ先を設定 • 標準では未対応のマッピングを編集 • Unicodeで複数のコードポイントを持つ文字のマッピングを編集 • 機種依存文字、ユーザー定義文字などを任意にマッピング Source database: WE8ISO8859P1

Table1: JA16EUC

Table2, Col1: WE8MSWIN1252

Table2, Col2: UTF8

Target database: AL32UTF8

例：

全てAL32UTF8に変換

MAP SOURCE.Table1, TARGET TARGET.Table1, CHARSET( JA16EUC ); MAP SOURCE.Table2, TARGET TARGET.Table2,

COLCHARSET( Col1, WE8MSWIN1252 ),

COLCHARSET( Col2, UTF8 );

Replicatのパラメータ _{SOURCECHARSET al32utf8}

TARGETCHARSET ja16euc

¥xef¥xbd¥x9e ¥xa1¥xc1 -- 1 to 1 mapping ¥x61 - ¥x7a ¥x41 - ¥x5a -- range mapping ¥x80 - ¥xff ¥x20 -- range to 1 mapping マップファイル

Replicat のパラメータ

(46)

(47)

柔軟なレプリケーションで可用性の課題にも対応

業務AP （現） Load Balancer 参照処理 GoldenGate 業務AP （現） Load Balancer APアップデート （テーブル変更 等）・動作確認 GoldenGate 業務AP （現） Load Balancer 業務AP （新） Load Balancer 業務AP （新） （テーブル変更 後）参照処理 GoldenGate 1. 通常稼働時 2. AP改修 3. 切り替え 4. 逆同期 ※任意で再度切り替えを実施可能 ※切り替え作業中のみサービス停止 ※開発・検証環境での作業後、本番データを使用した動作確認が可能 2,4 で異なる表構成 間、データ変換を伴 うレプリケーション が発生

(48)

定期的に実施されるシステムメンテナンスで

サービス停止を極小化したい

業務開始 ポイント

AS

-I

S

To

Be

事前作業 _事後作業通常の業務サービス AP プロビジョニングと改修 業務停止 ポイント 新サービス開始 AP 改修(ローリングのため性能縮退) _{データパッチ}DB 構成変更結合テスト_(AP/DB) DBのリストア_{AP リリース}

A面

B面

データパッチDB 構成変更結合テスト(AP/DB) リストアDB 切り戻し対策データ静止断面十数時間に及び、工数も増大

サービス停止の極小化を実現

(49)

(50)

-- ソース表(TOKYO_DB) CREATE TABLE T_TAB1 (

KEY NUMBER NOT NULL , COL1 VARCHAR2(20) , COL2 VARCHAR2(20)

, CONSTRAINT T_TAB1_PK PRIMARY KEY ( KEY ) ENABLE );

-- ソース表(OSAKA_DB) CREATE TABLE O_TAB1 (

, CONSTRAINT O_TAB1_PK PRIMARY KEY ( KEY ) ENABLE );

-- ターゲット表(そのまま統合) CREATE TABLE C_TAB_01 (

, CONSTRAINT C_TAB_01_PK PRIMARY KEY ( KEY ) ENABLE);

-- ソース表へのDML(そのまま統合)

insert into t_tab1 values (101,'AA1','Cool'); commit;

insert into o_tab1 values (203,'BB3','Hot'); commit;

insert into t_tab1 values (102,'AA2','Hot'); Commit;

-- ターゲット表で伝搬を確認(そのまま統合) SQL> select * from c_tab_01;

-- ターゲット表(ターゲット表に列を追加) CREATE TABLE C_TAB_02

(

LOC VARCHAR2(20) NOT NULL , KEY NUMBER NOT NULL

, COL1 VARCHAR2(20) , COL2 VARCHAR2(20)

, CONSTRAINT C_TAB_02_PK PRIMARY KEY ( LOC , KEY ) ENABLE );

-- ターゲット表で伝搬を確認(ターゲット表に列を追加₎

SQL> select * from c_tab_02;

-- ターゲット表(コード体系の変更) CREATE TABLE C_TAB_03

(

C_K VARCHAR2(20) NOT NULL , KEY NUMBER NOT NULL , COL1 VARCHAR2(20) , COL2 VARCHAR2(20)

, CONSTRAINT TABLE1_PK PRIMARY KEY ( C_K , KEY ) ENABLE );

-- ルックアップ表(コード体系の変更) CREATE TABLE LOOKUP

(

C_K VARCHAR2(20) , KEY NUMBER );

-- ターゲット表で伝搬を確認(コード体系の変更) SQL> select * from lookup;

-- ターゲット表(処理時間情報を付与) CREATE TABLE C_TAB_04

(

KEY NUMBER NOT NULL , COL1 VARCHAR2(20) , COL2 VARCHAR2(20) , TIME TIMESTAMP

(51)

-- ソース表(機密情報をマスク) CREATE TABLE CUST

(

ID NUMBER NOT NULL , NAME VARCHAR2(20) , ADDRESS VARCHAR2(20) , CARD_NO VARCHAR2(20)

, CONSTRAINT CUST_PK PRIMARY KEY ( ID ) ENABLE );

-- ターゲット表(機密情報をマスク) CREATE TABLE CUST_TEST

(

ID NUMBER NOT NULL , NAME VARCHAR2(20) , ADDRESS VARCHAR2(20) , CARD_NO VARCHAR2(20)

, CONSTRAINT CUST_TEST_PK PRIMARY KEY

( ID ) ENABLE );

-- ソース表へのDML (機密情報をマスク) insert into cust values

(101,'Taro','Tokyo','123-123'); commit;

insert into cust values (102,'Jiro','Osaka','123-456');

Commit;

insert into cust values (103,'Goro','Nagoya','123-789');

commit;

-- ソース表(データを貯める：削除処理を伝播しない₎

CREATE TABLE ORDERS (

ORDER_NO NUMBER NOT NULL , CUST VARCHAR2(20)

, PROD VARCHAR2(20) , DATA DATE

, CONSTRAINT ORDERS_PK PRIMARY KEY ( ORDER_NO ) ENABLE );

-- ターゲット表(データを貯める：削除処理を伝播しない)

CREATE TABLE ORDERS_TEST (

ORDERS_NO NUMBER NOT NULL , CUST VARCHAR2(20)

, PROD VARCHAR2(20) , DATA DATE

, CONSTRAINT ORDERS_TEST_PK PRIMARY KEY ( ORDERS_NO ) ENABLE );

-- ソース表(データを貯める：処理履歴を蓄積) CREATE TABLE CREDIT

(

ID NUMBER NOT NULL , BALANCE VARCHAR2(20) , GRADE VARCHAR2(20)

, CONSTRAINT CREDIT_PK PRIMARY KEY ( ID ) ENABLE );

-- ターゲット表(データを貯める：処理履歴を蓄積) CREATE TABLE CREDIT_HIST

( ID NUMBER , BALANCE VARCHAR2(20) , GRADE VARCHAR2(20) , TIMESTAMP TIMESTAMP , OPERATION VARCHAR2(20) );

(52)

-- ソース表へのDML(データを貯める：処理履歴を蓄積₎

insert into credit values (123,'400','Gold'); commit;

insert into credit values (345,'50','Silver'); commit;

insert into credit values (678,'210','Gold'); commit;

insert into credit values (981,'0','Black'); commit;

update credit set

balance='450',grade='Gold' where id=345; commit;

delete from credit where id=123; commit;

-- ソース表(イベントマーカー活用例) CREATE TABLE EVENT

(

KEY NUMBER NOT NULL , flag VARCHAR2(20)

, CONSTRAINT EVENT_PK PRIMARY KEY ( KEY ) ENABLE );

-- ターゲット表(イベントマーカー活用例) CREATE TABLE EVENT_LOG

(

key NUMBER NOT NULL , flag VARCHAR2(20) );

-- ターゲット表(イベントマーカー活用例) CREATE TABLE EVENT_TARG

(

key NUMBER NOT NULL , flag VARCHAR2(20) );

-- イベント表更新

insert into event values (1,'Dummy'); commit;

update event set flag='STOP'; commit;

update event set flag='START'; commit;

(53)

Oracle Database 12c 対応研修コースのご案内

Oracle Database 12c: SQL 基礎 I (3日間) Oracle Database 12c: 管理ワークショップ (5日間) Oracle Database 12c: SQL チューニングワークショップ (3日間) Oracle Database 12c: PL/SQL プログラム開発 (3日間) Oracle Database 12c: インストール＆アップグレード (2日間) Oracle Database 12c: バックアップ・リカバリ (5日間) Oracle Database 12c: 新機能 (5日間) Oracle Database 12c: セキュリティ (5日間) Oracle Database 12c: Clusterware 管理 (4日間) Oracle Database 12c: RAC 管理 (4日間) Oracle Database 12c: PL/SQL 基礎 (2日間) データベース設計 (3日間) Oracle Database 12c: パフォーマンス・チューニング (5日間) Bronze Silver Platinum Gold Oracle Database 12c: SQL 基礎 II (2日間) Oracle Database 11g: データ・マイニング手法 (2 日間) Oracle Database 12c: Database Vault (2日間) Oracle ではじめる統計入門 (1 日間) Oracle R Enterprise エッセンシャルズ (2 日間) Oracle Database 12c: マルチテナント・アーキテクチャ (2日間) Oracle Database 12c: ASM 管理 (2日間) Oracle Database 12c: 管理クイック・スタート (2日間) Oracle Database 12c: 管理ネクスト・ステップ (3日間) Ad va nc ed A na lyti cs O pti on 対応コース 基礎から上級スキルまで。Oracle Database 12c の製品機能を学習できる多彩な研修コースでスキルアップを

(54)

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

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

(55)

(56)

(57)