oracle goldengate導入tips

Copyright © 2016 Oracle and/or its affiliates. All rights reserved. |

Oracle GoldenGateの導入Tips v1.3

2016年8月日本オラクル株式会社クラウド＆テクノロジー事業統括


免責事項

以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供することをコミットメント（確約）するものではないため、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。 Oracleは、米国オラクル・コーポレーション及びその子会社、関連会社の米国及びその他の国における登録商標または商標です。他社名又は製品名は、それぞれ各社の商標である場合があります。

2


はじめに • 本資料は、Oracle GoldenGate for Oracle Databaseを導入する際の技術Tipsを導入フェーズ毎に紹介しています

• 本資料は、GoldenGateの提案・導入に関わる技術者が、タスクを進めていく上での考慮漏れ等が無いかを確認するための参考資料として使用されることを想定して作成されています

• 製品機能の網羅的な説明や使用手順は、別途製品マニュアル等をご参照ください

• 本資料はGoldenGate 11.2 と GoldenGate 12.1 を前提に説明します – GoldenGate 12.1 は Oracle 11g, Oracle 12.1 に対応 – GoldenGate 複数バージョン間のレプリケーションが構成可能です – 例：ソース Oracle 10.2/OGG 11.2 , ターゲット：Oracle 12.1/OGG 12.1

3


アジェンダ

環境確認

サイジング

設定・設計

初期ロード

監視

トラブルシュート

1

2

3

4

5

4

6


アジェンダ

環境確認

サイジング

設定・設計

初期ロード

監視


1

2

3

4

5

5

6


導入可能な環境か？

• 導入環境のサーバ情報を入手(ソース/ターゲット共に)

– OSの種類・バージョン・updateレベル・ビット数

– CPUアーキテクチャ

– Oracle DBバージョン(PSRレベルまで)・エディション

• Certification Matrixを確認

– GoldenGate 12.1 • http://www.oracle.com/technetwork/middleware/fusion-middleware/documentation/fmw-1212certmatrix-1970069.xls

– GoldenGate 11.2 • http://www.oracle.com/technetwork/middleware/data-integration/goldengate1121-cert-matrix-1522269.xls

• GoldenGateのサポートレベルは一緒に動くOracle DBのサポートレベルと同じ

6

http://www.oracle.com/technetwork/middleware/data-integration/goldengate1121-cert-matrix-1522269.xls










導入検討フェーズにおけるTips Sustaining SupportのDB(DB9i等)を接続対象にする際の注意点

• 製品使用時の注意点 – 接続対象となるデータベースがSustaining Supportの場合、基本的に最新バージョンでビルドは提供されないため、既存のビルドから選択。 MOSから既存ビルドをダウンロードするには、 DB同様SRでパスワード取得が必要

– 当該ビルドについては、基本的に新規パッチは提供されない

• Terminalパッチ未適用のDBを接続対象とする場合(Matrixにない構成) – 導入後に発生した事象(エラーなど)に関するサポートへの問合せは対応

– ケースによって、バージョンアップ以外での対処方法が無い場合、環境のバージョンアップを提案させて頂くケースあり

※補足※ いずれのケースでも、パッチ提供状況やマルチバイト関連制限事項など、十分に御確認頂く事を強く推奨

7


クラスタ構成 (RAC/HA) • RAC構成でも、単一のCaptureが全REDOスレッドを処理

• フェイルオーバー先のノードで処理継続ができるように、OGGのファイル用に共有ファイルシステムが必須

– NAS/DBFS/ACFS を使用

参考資料

・NASを使用する場合のマウントオプション

Oracle GoldenGate Best Practice: NFS Mount options for use with GoldenGate(Doc ID 1232303.1)

・Exadata 環境における DBFSの設定

http://www.oracle.com/au/products/database/maa-wp-gg-oracledbm-128760.pdf

• Captureプロセスが全ノードのアーカイブにアクセス可能にするため、共有ファイルシステムを準備

– 共有ファイルシステムを準備できない場合は、アーカイブを1か所に集める仕組みが必要

Cluster

GoldenGate

DBファイル

GoldenGateファイル

アーカイブ・ログ

共有ファイルシステム

8











Oracle DB環境の確認 • マニュアルベースで「伝播できないデータ/処理」が無いかを確認

• 以降のマトリクスの見方

– ○：問題なし

– *：異なる構成間や変換処理を含む伝播で一部制限あり。マニュアル参照

– Fetch：設定や構成方法により、REDOではなく実データからのキャプチャ。マニュアル参照

– △：一部の設定で伝播不可。マニュアル参照

– ×：未対応

• 伝播対象オブジェクトの精査

– クエリ・オフローディング / データ連携：ターゲット側の処理で必要な表は？

– 移行 / DR ：伝播不要な表は無いか？テスト用スキーマの残骸、バッチ処理の一時表・中間表など

– 事前に精査することで、環境確認の負荷が減り、レプリケーションも軽量化できる可能性があります

9


データ型対応一覧:DML (1)

10

DB10.2 / Classic DB11.1/Classic DB11.2/Classic DB11.2/Integrated DB12.1/Classic DB12.1/Integrated

VARCHAR2 ○* ○* ○* ○* ○* ○*

NVARHCAR ○* ○* ○* ○* ○* ○*

NUMBER ○* ○* ○* ○* ○* ○*

LONG ○ ○ ○ ○ ○ ○

DATE ○ ○ ○ ○ ○ ○

BINARY_FLOAT ○* ○* ○* ○* ○* ○*

BINARY_DOUBLE ○* ○* ○* ○* ○* ○*

TIMESTAMP ○* ○* ○* ○* ○* ○*

TIMESTAMP WITH TIMEZONE

○* ○* ○* ○* ○* ○*

TIMESTAMP WITH LOCAL TIMEZONE

○* ○* ○* ○* ○* ○*

INTERVAL YEAR TO MONTH

○* ○* ○* ○* ○* ○*

INTERVAL YEAR TO SECOND

○* ○* ○* ○* ○* ○*

RAW ○ ○ ○ ○ ○ ○



11


LONG RAW ○ ○ ○ ○ ○ ○

ROWID ○ ○ ○ ○ ○ ○

UROWID × × × ○ × ○

CHAR ○* ○* ○* ○* ○* ○*

NCHAR ○* ○* ○* ○* ○* ○*

CLOB Fetch * Fetch * Fetch * Fetch * (ほぼREDO) Fetch * Fetch * (ほぼREDO)

NCLOB Fetch * Fetch * Fetch * Fetch *(ほぼREDO) Fetch * Fetch * (ほぼREDO)

BLOB Fetch * Fetch * Fetch * Fetch * (ほぼREDO) Fetch * Fetch * (ほぼREDO)

BFILE × × × × × ×

USER DEFINED TYPE Fetch △ Fetch △ Fetch △ Fetch △ Fetch △ Fetch △ (ほぼREDO)

REF × × × × × ×

VARRAY Fetch △ Fetch △ Fetch △ Fetch △ Fetch △ Fetch △ (ほぼREDO)

NESTED TABLE Fetch △ Fetch △ Fetch △ Fetch △ Fetch △ Fetch △

ANYTYPE × × × × × ×

ANYDATA × × × (OGG 12c は Fetch △ ) × (OGG 12c は Fetch △ ) Fetch △ Fetch △ (ほぼREDO)

ANYDATASET × × × × × ×



12


XML TYPE Fetch △ Fetch △ Fetch △ Fetch △ Fetch △ △

URI TYPE × × × × × ×

SDO_GEOMETRY Fetch △ Fetch △ Fetch △ Fetch △ Fetch △ △

SDO_TOPO_GEOMETRY Fetch △ Fetch △ Fetch △ Fetch △ Fetch △ Fetch △

SDO_GEORASTER Fetch △ Fetch △ Fetch △ Fetch △ Fetch △ Fetch △

ORDDICOM × × × × × ×

TIMEZONE_ABBR × × × × × ×

MLSLABEL × × × × × ×

LARGE VARCHAR2 N/A N/A N/A N/A × ○

IDENTITY COLUMN N/A N/A N/A N/A × ×

VALID TEMPORAL COLUMN

N/A N/A N/A N/A × ×


制限事項（オブジェクト：DML）

13


2MBを超えるレコード (LOB/LONG列は除く)

× × × × × ×

1列で構成される表 △ △ △ △ △ △

未使用列を含む表 △ △ △ △ △ △

仮想列を含む表伝播必要ならFetch 伝播必要ならFetch 伝播必要ならFetch 伝播必要ならFetch 伝播必要ならFetch 伝播必要ならFetch

暗号化表領域上の表 N/A × △ ○ ○ ○

暗号化列を含む表 △ × △ ○ ○ ○

圧縮表 × × × ○ × ○

索引構成表 △ △ △ ○ △ ○

外部表 × × × × × ×

ビュー / シノニム元表から伝播元表から伝播元表から伝播元表から伝播元表から伝播元表から伝播

MView △ （双方でリフレッシュするが基本）

△ （双方でリフレッシュするが基本）





クラスタ表 △ △ △ ○ △ ○

オブジェクト表 Fetch △ Fetch △ Fetch △ Fetch △ Fetch △ △

XMLType表 × × × ○ × ○

シーケンス △（双方向は不可） △（双方向は不可） △（双方向は不可） △（双方向は不可） △（双方向は不可） △（双方向は不可）


制限事項（DML処理）

14


NOLOGGING × × × × × ×

APPEND hint ○ ○ ○ ○ ○ ○

DIRECT LOAD ○ ○ ○ ○ ○ ○

Parallel DML (Non-RAC) ○ ○ ○ ○ ○ ○

Parallel DML (RAC) △（トランザクションが1インスタンス完結すれば可）

△（トランザクションが1インスタンス完結すれば可）


○ △（トランザクションが1

インスタンス完結すれば可）

○

Database Replay × × × × × ×

XA (Non-RAC) ○ ○ ○ ○ ○ ○

XA (RAC) △（トランザクションが1インスタンス完結すれば可）



○ △（トランザクションが1

インスタンス完結すれば可）

○


制限事項（DDL）

• 以下のオブジェクトをサポート – clusters / functions / indexes / packages / procedure / tables / tablespaces / roles /

sequences / synonyms / Triggers / types / views / materialized views / users

• サポートされないDDL – 2MBを超えるDDL文

– Oracleの予約スキーマ/オブジェクト • http://docs.oracle.com/goldengate/1212/gg-winux/GIORA/system_requirements.htm#BABBAEDH

– Nested Table / Invisible column / Idenetidy Column / DB Link / Flashback Data Archive を含むDDL

– ALTER DATABASE / ALTER SYSTEM文

–パスワードベースの列暗号を含むDDL (Classic Captureのみ)

15

http://docs.oracle.com/goldengate/1212/gg-winux/GIORA/system_requirements.htm




制限事項（その他） • オブジェクト名/列名に以下の文字を含むオブジェクトは伝播不可

– { } Begin and end curly brackets (braces)

– [ ] Begin and end brackets

– = Equal symbol

– + Plus sign

– ! Exclamation point

– ~ Tilde

– | Pipe

– & Ampersand

– : Colon

– ; Semi-colon

– , Comma

– ‘ ’ Single quotes

– “ ” Double quotes

– ' Accent mark (Diacritical mark)

– . Period

– < Less-than symbol

– > Greater-than symbol

– ¥ Backward slash (Must be ¥¥ when used in parameter file)

16


環境確認を補助するツール

• My Oracle Support にチェックスクリプトを公開

– Oracle GoldenGate database Complete Database Profile check script for Oracle DB (All Schemas) Classic Extract (Doc ID 1298562.1)

– Oracle GoldenGate database Schema Profile check script for Oracle DB (Doc ID 1296168.1)

• Oracle 11.2.0.4, 12.1 であればDB内のビューを使用可能

– DBA_GOLDENGATE_SUPPORT_MODE

17


アジェンダ

環境確認

サイジング

設定・設計

初期ロード

監視


1

2

3

4

5

18

6


GoldenGate導入におけるサイジング

• 多いケース

– ソース側は既存のDBサーバーにGoldenGateを導入

– ネットワークは既存のものを使用

– ターゲット側はDBサーバーを新規構築

• REDO生成量を使用してラフなサイジングを実施

– 現行のAWRレポートや将来予測値から基準となるREDO生成量を決める

19

•REDO生成量 •要件（性能・可用性・伝播要件） •現環境情報

設定・設定（仮）

POC 設定・設計（再）

構築・検証設定・設計（本）導入・稼働

※業務相当のワークロードでPOCを実施することで、設計精度を上げる


GoldenGate導入による追加のリソース消費

• ソース

– REDO生成量の増加(logging設定/サプリメンタル・ロギング)

– Capture/Pump プロセスによる CPU/メモリリソースの消費

– ローカルTrailファイル用のファイルシステム領域

• ネットワーク

– GoldenGateのデータ転送に使用

• ターゲット

– Replicat プロセス

– リモートTrailファイル用のファイルシステム領域

20


REDO生成量の増加

• Logging 設定

– Nologging 設定の処理をGoldenGateで伝播するにはLogging への変更が必要

– 影響はワークロードに依存するため、環境固有の確認が必要

• まずは Nologging処理の有無を確認

• サプリメンタル・ロギング

– データレプリケーションに必要な情報をREDOログに付加

– キー制約(PK/UK/Unique Index)列または論理キー列値をログに常に付加

– 10%未満の増量になることがほとんどだが、キー列のない表は増分に注意

– アーカイブ保存領域の容量がギリギリの場合は拡張または一時退避先の検討が必要

21

※本スライドの情報は実績に基づく傾向ですが、全ての環境で保証するものではありません


Capture/ Data Pump • スループット

– Classic / Integrated 共に単一CaptureでREDO30-50MB/s程度実現可能 – Data Pump は Capture以上のスループットを実現可能

• CPU – Classic Capture は最大1 CPUコア程度のリソース消費は考慮に入れる – Integrated Capture は Oracleのバックグランドプロセス稼働による+αを考慮 – Data PumpのCPU消費はCaptureに比べ大幅に小さい

• メモリ – Captureのメモリ消費はオープントランザクション量に依存するため見積もりは困難だが、制御は可能

• データローディングや洗い替えなどでラージトランザクションがある場合は、基準とする • CaptureはOSに対して仮想メモリをリクエスト（物理メモリを直接要求しない） • Capture側の設定で仮想メモリリクエストの敷居値を設け、内部ページングさせることも可能

– Integrated Capture はOracleインスタンスに streams_pool_size の確保が必要 – Data Pumpのメモリ消費はCaptureに比べ大幅に小さい

22



参考：Captureプロセスのメモリ消費

23

CACHESIZEMAX （環境によるが、

CACHESIZEの2倍弱程度）

•CACHESIZE/CACHESIZEMAXを超えると、ディスクに書き出す（ページング）

•ページング動作は、各閾値を利用して2段階で行われる

未コミットのトランザクションサイズ

Tx 1

Tx 2

Tx 3

Tx 4

Tx n

キャッシュ（管理仮想メモリー・プール）

CACHEDIRECTORY （デフォルトはインストールディレクトリ配下のdirtmp）

オンデマンドで割り当てられる

DIMM SWAP

OS仮想メモリ空間

CACHESIZE


Trailファイルの領域 • Trailファイルは以下のタイミングで新規ファイルを生成しながら蓄積される

– 上限サイズ100MB(デフォルト/変更可)

– プロセス再起動

• 製品機能により、送信が完了したTrailファイルは自動削除可能 – 正常稼働時は大量データは蓄積されない

• サイジングは想定障害復旧時間からの見積もりが基本 – ローカルTrail : ネットワーク障害の想定復旧時間

– リモートTrail : ターゲットDBの想定復旧時間

– さらに小さくすることも可能だが、手作業が増える

• サイズ試算例 – 全テーブル伝播想定REDO生成量 × 1.1(サプリメンタル・ロギング増分) × 0.4 × 想定復旧時間

• 必要に応じて余裕率かける

– 現環境のアーカイブからTrailを生成する方法 • (参考)How to Setup extract in-house to Process Customer's Archived Logs (Doc ID 1205843.1)

24



ネットワーク

• Trailファイルの生成量をベースに帯域におさまるか確認

– 試算例：REDO生成量 × 1.1(サプリメンタル・ロギング増分) × 0.4

• 帯域に収まらない場合は転送圧縮機能の使用を検討

– ラフな見積もり： Trailファイルをgzipで圧縮

– 圧縮機能を使用するとData PumpのCPU消費が向上

25


Replicat

• スループット

– 単一のNormal Replicat でREDO 5MB/s前後 - 10MB/s 程度を実現可能

– 複数のNormal Replicat または Coordinated Replicat を使用してワークロードを分割することでスループット向上が可能

• サーバー/DB側のボトルネックになるまでスケールする

• 分割方法は手動設計が必要

– Integrated Replicat を使用する場合は単一Replicat から自動計算による並列化が可能

• CPU/メモリ

– ターゲットDBは新規構築となるケースが多いため、細かい見積もりは行わない傾向

26



多重化の考え方 • Replicatのみ

– Replicatのみスループットが追いつかない状況

– DataPumpの転送までは DB全体のトランザクション順序を保証

• Captureから多重化

– 同一DB上で優先度の異なる複数業務が動いている場合

– 業務単位でCaptureから分ける

27

Capture

Trail file

Replicat

DataPump Replicat

Replicat

Trail file

Capture

Trail file

DataPump Replicat

Trail file

Capture

Trail file

DataPump Replicat

Trail file

Capture

Trail file

DataPump Replicat

Trail file


アジェンダ

環境確認

サイジング

設定・設計

初期ロード

監視


1

2

3

4

5

28

6


Oracle DB (ソース/ターゲット)への設定変更 • サプリメンタル・ロギング（ソースのみ）

• GoldenGate用Oracleユーザー

• アーカイブ・ログ・モード（ソースのみ）

• 初期化パラメータ enable_goldengate_replication

– Oracle 11.2.0.4 / Oracle 12.1.0.2 以降の場合

• Oracle DBへの必須/推奨パッチの確認と適用

– Integrated Capture / Integrated Replicatを使用する場合

– Oracle GoldenGate -- Oracle RDBMS Server Recommended Patches (Doc ID 1557031.1)

• クラスタウェアへの組み込み

– クラスタ構成(RAC/HA)上のGoldenGateで自動フェイルオーバーを組む場合

– 参考情報

• Oracle Clusterware による作り込みサンプル：http://www.oracle.com/technetwork/jp/middleware/goldengate/overview/ha-goldengate-whitepaper-128197-ja.pdf

• Exadata上での構成：http://www.oracle.com/technetwork/jp/database/maa-wp-gg-oracledbm-1708092-ja.pdf

• 事前定義済みのテンプレートから作成 Grid Infrastructure 11.2.0.3 以降：Oracle GoldenGate Best Practices: Configuring Oracle GoldenGate with Oracle Grid Infrastructure Bundled Agents (XAG) (Doc ID 1527310.1)

• DDLレプリケーションを実行する場合は、ソースDBに対してDBA権限を持ったユーザーでの作業が必要

29

DB停止が必要なのはアーカイブ・ログ・モードへ

の変更のみ

http://www.oracle.com/technetwork/jp/middleware/goldengate/overview/ha-goldengate-whitepaper-128197-ja.pdf









http://www.oracle.com/technetwork/jp/database/maa-wp-gg-oracledbm-1708092-ja.pdf












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

• 最小サプリメンタル・ロギング

– Oracle DB側で alter databaseコマンドで設定

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

– GoldenGateのコマンドツール(ggsci) より設定

• ADD TRANDATA

–表単位での指定 (ワイルドカード指定による一括設定は可能)

–主キーの存在しない表は論理的なキー列を指定（colsオプション）

• ADD SCHEMATRANDATA

–スキーマ単位で表レベルのサプリメンタル・ロギングを一括指定

– DDL(CREATE / ALTER)でキー列設定が変わった場合も自動追従

– ソースDBが11.2.0.2より古い場合はPatch 10423000の適用が必要

30

設定可能な環境で、伝播対象表にDDLが発行される場合お勧め


GoldenGateのパラメータ設定

• Manager / Capture / Data Pump / Replicat のパラメータを指定します

• サンプルパラメータを使用して、代表的な設定例を紹介します

– Oracle GoldenGate Best Practices: sample parameter files (Doc ID 1321696.1)

31


Managerプロセスのパラメータ

32

PORT <port number> -- プロセスが使用するポート番号 -- Trailファイルの自動削除ルール -- USECHECKPOINTS : チェックポイント情報（処理済みかどうか）を元に削除ファイルを決定 -- MINKEEPHOURS : 保持時間の設定 -- MINKEEPFILES : 保持ファイル数の設定 PURGEOLDEXTRACTS <path to the trail file>, USECHECKPOINTS, MINKEEPHOURS <"x" hours> MINKEEPFILES <"y" number of files> -- プロセスの自動再起動設定 -- 下記設定は全てのExtract/Replicat を自動再起動、y分待機して x回のリトライ、z分後にリトライ回数をリセットする AUTORESTART ER *, RETRIES <x>, WAITMINUTES <y>, RESETMINUTES <z> LAGREPORTMINUTES <x> -- Extract/Replicatチェックポイント・ラグを確認する間隔 LAGCRITICALSECONDS <y> -- クリティカルとみなし、エラーログにメッセージを出力するチェックポイント・ラグの敷居値（秒）


Captureプロセスのパラメータ

33

EXTRACT <Extract name> -- プロセス名 SETENV (ORACLE_HOME = “<Oracle home path>” ) – 環境変数の指定 SETENV (ORACLE_SID="<Oracle sid>") USERID <username>, password <password> -- Oracleにログインするユーザー名 EXTTRAIL <extract trail path/two character trail id> -- Trailファイルのロケーション TRANLOGOPTIONS EXCLUDEUSER <Replicat username> -- Replicatによる TRANLOGOPTIONS DBLOGREADER – ASM環境への接続(Classic Captureの場合、かつ Oracle 10.2.0.5 または Oracle 11.2.0.2 以降) DDL INCLUDE ALL, EXCLUDE OBJNAME “<schema name>.<object name> ” -- DDLキャプチャ設定. ワイルドカード使用可能 DDLOPTIONS ADDTRANDATA -- Create Tableやキー列変更処理を検知したタイミングでサプリメンタル・ロギング設定を実施 REPORTROLLOVER AT <hh:mi> on <day of the week> -- レポートファイルの切り替え処理 REPORTCOUNT EVERY <n> HOURS, RATE – プロセスの処理レコード数をレポートファイルに定期的に出力 FETCHOPTIONS, USESNAPSHOT, NOUSELATESTVERSION, MISSINGROW REPORT – フェッチによるキャプチャに関する設定 STATOPTIONS REPORTFETCH – フェッチ処理の統計をレポート追記 Table <source schema name>.<table name>; -- キャプチャ対象テーブル. ワイルドカード指定可能


Classic Capture or Integrated Capture? • Integrated Capture が適するケース

– 圧縮表、Oracle Multitenant, RAC構成へのXA, Parallel DMLなど Classic では伝播できないデータがある

– RAC / ASM / 暗号化 • Integrated Captureの方が容易に構成可能

– LOB更新が多い • Integrated CaptureはほとんどのLOB更新をREDOから取得可能

– GoldenGateを常時連携・連携基盤として使用（移行などの使い切りではない） • GoldenGate for Oracle では、主要なCapture機能拡張はIntegrated Capture に実装予定

• 注意点 – streams_pool_sizeの設定が必要

– 関連バックグランドプロセスの性能分析など、+α のナレッジが必要

• ソースDBの前提条件 – 必須パッチの適用された Oracle 11.2.0.3

– Oracle 11.2.0.4 以降

34


外部サーバー構成 • ソースDBとは異なるサーバーでGoldenGateの

Captureを稼働させることが可能

• ソースDBへのGoldenGate導入が不要になる

• デメリットも多い

– 外部サーバーのコスト

– 設定工数の増加

– 性能劣化（リアルタイム性・スループット）

• ソースDBへのGoldenGate導入を基本に考え、どうしても許容されない場合のみ外部サーバー構成を検討する

35

Capture

Trail file

• 外部サーバーからキャプチャ

– Archive Log Only (ALO / Classic Capture)

– Downstream (Integrated Capture)

– 外部サーバーからオンラインREDOをキャプチャ(Classic )

– Active Data Guardスタンバイからキャプチャ(Classic/GoldenGate12.1)

– 外部サーバーからオンラインREDOをキャプチャ(Integrated)

• それぞれの手法に外部サーバーの前提条件あり（マニュアル参照）

• ソースDBへのサプリメンタル・ロギング設定は必須

• ソースDBがIBM AIX HACMPのIP切り替え方式で構成されている場合は、外部サーバー構成が必須


Data Pumpプロセスのパラメータ

36

EXTRACT <Pump name> -- プロセス名 SETENV (ORACLE_HOME = “<Oracle home path>” ) – 環境変数 SETENV (ORACLE_SID="<Oracle sid>") Passthru – パススルーモード（Trailファイルの情報をそのまま送信） RMTHOST <Remote hostname>, MGRPORT <Target manager port number> -- 送信先ホストの RMTTRAIL <extract trail path/two character trail id> -- ターゲットサーバー上のTrailファイルのパス REPORTROLLOVER AT <hh:mi> on <day of the week> -- レポートファイルのロールオーバー間隔 REPORTCOUNT EVERY <n> HOURS, RATE – 処理レコード件数の推移をレポートファイルに記録 Table <source schema name>.<table name>; -- 伝播対象テーブル。ワイルドカード指定可能


Replicatプロセスのパラメータ

37

REPLICAT <Replicat name> -- プロセス名 SETENV (ORACLE_HOME = “<Oracle home path>” ) --環境変数 SETENV (ORACLE_SID= "<Oracle sid>") SETENV (NLS_LANG = ="<Target db charecterset>") USERID <username>, password <password> -- オラクルユーザーとパスワード DISCARDFILE <diacard file path/<discard file name.dsc>, APPEND Megabytes <n> -- Discardファイルの出力設定(12c はデフォルトで出力) DISCARDROLLOVER AT <hh:mi> on <day of the week> -- Discardファイルのロールオーバー DDL INCLUDE ALL, EXCLUDE OBJNAME “<schema name>.<object name>“ -- DDLレプリケーション設計 DDLOPTIONS REPORT --DDLレプリケーション情報をレポートファイルに記述 BATCHSQL -- 配列処理によるSQL適用で高速化 REPORTROLLOVER AT <hh:mi> on <day of the week> -- レポートファイルのロールオーバー設定 REPORTCOUNT EVERY <n> HOURS, RATE -- 処理件数の推移をレポートファイルに出力 DBOPTIONS SUPPRESSTRIGGERS -- SQL適用時のターゲット表でのトリガー発動を抑止し、2重実行を回避 DBOPTIONS DEFERREFCONST -- SQL適用時の delete cascade 制約のチェックを遅延させ、適用エラーを回避 MAP <source schema name>.<table name>, TARGET <target schema name>.<tablename>;


Replicat ? Integrated Replicat ? Coordinated Replicat ?

• Non-Integrated Replicat（従来のReplicat）

– 多重化不要であれば、最もシンプルに導入可能

• Coordinated Replicat

– GoldenGate 12.1 以降であれば、ターゲットDBのバージョンは問わない

– 従来のReplicatの設計ノウハウを応用しやすく、管理性能向上が可能

• Integrated Replicat

– GoldenGate 12.1以降 / ターゲットDBがOracle 11.2.0.4以降で使用可能

– 自動的に多重化されるため、設計不要

– Streams_pool_size の設定が必要

– 関連バックグランドプロセスなど、従来のReplicat +αのナレッジが必要

38


GLOBALSのパラメータ

39

-- 全プロセスに共通の設定を記載するファイル MGRSERVNAME <mgr service name> -- Managerプロセスのサービス名（Windows環境） CHECKPOINTTABLE <owner.tablename> -- チェックポイント表の名前 GGSCHEMA <schema name> -- GoldenGateスキーマ(DDLレプリケーション用)


Trailファイルの暗号化

• GoldenGate 11.2 はファイルベースで暗号化鍵を管理

• GoldenGate 12.1は Oracle Wallet 暗号化鍵を管理

40

OGG12c

暗号化された

Trailファイル

ウォレット

マスターキー

・・・

Trailファイルキー（一時的に生成）

• マスターキー＆ウォレット方式で利用する鍵

Trailファイルキー

• Trailファイルを暗号化するための鍵。

• １つのTrailファイルにつき、1つのTrailファイルキーが作成される。

マスターキー

• Trailファイルキーを暗号化するための鍵。ウォレットに格納される。

• セキュリティを保つため定期的に更新することを推奨。

• 256ビットで作成される（変更不可）。


アジェンダ

環境確認

サイジング

設定・設計

初期ロード

監視


1

2

3

4

5

41

6


初期ロード • GoldenGateによるレプリケーションを開始する前にデータベースの

データを同期させる作業

• GoldenGateの機能 – Direct Load – File to Replicat – Direct Bulk Load – File to Database Utility ※主に異機種DB間を想定

• Oracle DB の機能 – expdp/impdp – TTS – Restore＆Recovery etc

42

ターゲットDB ソースDB

ソースDB ターゲットDB

ソースDB ターゲットDB

empno ename

1 Smith

2 Jones

empno ename

1 Smith

2 Jones

empno ename

1 Smith

2 Jones

3 Scott

empno ename

1 Smith

2 Jones

3 Scott

empno ename

1 Smith

2 Jones

Network （TCP/IP)

Network （TCP/IP)

Network （TCP/IP)

ソース側のデータがターゲット側に格納されている

1. 初期ロード前

2. 初期ロード後

3. GoldenGateによる同期

•Oracle to Oracle のレプリケーションでは、プラットフォーム・バージョン間の柔軟性を考えると expdp/impdp が最も汎用的 •ほとんどのケースで expdp/impdp をベースに初期ロード方式が検討される


初期ロード方式で最初に確認すること

• 業務処理が停止している時間に Export 処理を行えるか？

– Export のみ, dmpファイル転送と Import の考慮は不要

• 停止時間中に Export 可能なら、全スライドのシンプルな手順で初期ロード可能

1. 業務処理停止

2. Export

3. GoldenGateのCapture/Data Pump構成起動

4. 業務処理再開

5. dmp転送/ Import

6. GoldenGateのReplicat開始

• Export中の業務停止が不可なら無停止前提の方式を検討

43


業務稼働中の初期ロード方式

• 以下の2つの方法から検討

– SCNレベルの断面を取得

• Replicat起動時に適用開始SCNを指定

GGSCI> start replicat <Replicat名> aftercsn <SCN番号>

– キー制約の使用

• ReplicatのパラメータにHANDLECOLLOSIONSオプションを使用

44


SCNレベルの断面を取得する初期ロード方式

• expdpのFlashback_SCNオプション

– Flashback Query により SCNレベルの一貫性のあるdmpを取得

– ソースDBのUndo表領域に影響

• オンラインバックアップ/リストア/リカバリでクローンDBを作成しクローンDBから Export

45

Capture

Expdp + flashback_scn dmp

Expdp

Online backup Restore recovery

①Capture開始（SCN1111）

DataPump Replicat

②dmp取得（SCN2222）

③Import

④Replicat起動 (SCN2222から適用)


キー制約を使用した無停止初期ロード

• exp/imp or expdp/impdpを使用 (flashback_scnなし)

– ソース側でExport前にGoldenGateのキャプチャ開始

– Replicatで重複更新を無視しながら追い付き処理を行う(handlecollisionsパラメータ)

46

データ同期状態

ソースDB

ターゲットDB 005 003 004 005

①適用

②適用

③適用

ソース側更新発生タイミングターゲット側適用タイミング

ターゲット適用済みの更新が発生する

002 003 004 005 006 007 008

①更新

②更新

③更新

④更新

⑤更新

⑥更新

Extract(Capture) 開始

exp実行 imp実行 Replicatの追い付き処理


キー制約を使用した無停止初期ロード

• 競合エラーを無視する設定 (HANDLECOLLISIONS)

– 概要

• ターゲットDBへのSQL適用時、以下のエラーを無視する

– INSERT時にデータがある(ORA-00001)

– DELETE時にデータがない(ORA-01403)

–主キーへのUPDATE時にUPDATE対象行が存在しない場合、INSERTに変換

• （重要）ターゲット側に主キー / 一意キー / 一意制約が存在することが前提

– 用途

• 移行時

– Captureプロセスの差分同期開始からExport開始までの更新はターゲットDBへのImportにより更新済みの状態であり、ターゲットDBへのSQL適用時に競合発生の可能性あり

47


初期ロード応用編 • 業務稼働中の初期ロードが必要

• クローンDBを構築するリソースがない

• 検証の結果、Flashback_SCNで全テーブルをexportするundo負荷が許容できない

• 全てのテーブルに主キーが付いていない。主キーが無い表がオンライン

• テーブル毎に初期ロード方式を変えることが可能

– 主キーがある表は通常の expdp と handlecollosionsで初期ロード

– 主キーがない表のみ expdp + flashback_scn オプションで初期ロード

（参考）テーブル単位でSCN断面を指定する方法 • How to add new tables for OGG replication in the current running extract and replicat ? (DocID 1332674.1)

• OGG How to Resync Tables / Schemas on Different SCN s in a Single Replicat (Doc ID 1339317.1)

48


アジェンダ

環境確認

サイジング

設定・設計

初期ロード

監視


1

2

3

4

5

49

6


GoldenGateの監視

• 死活監視

• エラー監視

• 性能監視

• 整合性確認

50


死活監視

• GoldenGateはManagerプロセスがExtract/Replicatを監視する

– 各サーバーのManagerを監視することで全体を監視可能

• DBサーバ自体に監視のポリシーがある場合は、継承されるケースもある

– GoldenGateの各プロセスをps コマンドで監視など

51

DataPump Replicat Capture

Manager

Collector

Manager


エラー監視

• ggserr.log

– GoldenGate操作やメッセージが出力されるログ

– Oracle DB の alert.log に近いイメージ

52

2014-11-05 17:38:39 INFO OGG-00992 Oracle GoldenGate Capture for Oracle, cap01.prm: EXTRACT

CAP01 starting.

2014-11-05 17:38:39 INFO OGG-03035 Oracle GoldenGate Capture for Oracle, cap01.prm:

Operating system character set identified as US-ASCII. Locale: en_US_POSIX, LC_ALL:.

2014-11-05 17:38:39 ERROR OGG-00664 Oracle GoldenGate Capture for Oracle, cap01.prm: OCI

Error beginning session (status = 28001-ORA-28001: ).

2014-11-05 17:38:39 ERROR OGG-01668 Oracle GoldenGate Capture for Oracle, cap01.prm: PROCESS

ABENDING.

2014-11-05 17:39:34 INFO OGG-00987 Oracle GoldenGate Command Interpreter for Oracle: GGSCI

command (oracle): start cap01.

2014-11-05 17:39:34 INFO OGG-00963 Oracle GoldenGate Manager for Oracle, mgr.prm: Command

received from GGSCI on host red.jp.oracle.com (START EXTRACT CAP01 ).

•INFO / WARNING / ERROR でメッセージが区分される •エラー監視で使用可能


エラー監視

• レポートファイル

– プロセスごとに出力されるログファイル

– プロセスごとのより詳細な挙動やエラー情報を表示

– GoldenGateインストールディレクトリ下の dirrpt ディレクトリに出力

– プロセス障害発生時にはまず参照するファイル

– 下記コマンドからも参照可能

GGSCI> view report <プロセス名>

53

ggserr.log だけでなく、レポートファイルも確認する


性能監視

• プロセス毎のラグ

• Heartbeat Table

• 処理量

54


ラグ（lagコマンドで取得）

55

• 最後に処理したトランザクションのコミット時間と処理完了時までの時間の差

• どのプロセスの処理が遅れているか？

• 各プロセスが自分の処理を完了した時間

– Extract(Capture/DataPump)であればTrailファイルの出力まで

– Replicatであればターゲット側でのデータの適用まで

Trail

ターゲットDB ソースDB

Network （TCP/IP)

Captureラグ Data Pumpラグ

DataPump Capture Collector Replicat Trail

Replicat ラグ


ラグ情報の蓄積 • Management Pack for Oracle GoldenGateの使用

– オリジナルのWeb UI よりラグの履歴をグラフで確認可能 • Oracle GoldenGate Monitor

– Enterprise Manager Cloud Control の画面よりグラフで確認可能 • Enterprise Manager Oracle GoldenGate System Monitoring Plug-In

• 定期的な lagコマンド実行をファイルに出力 – Shell スクリプトへの組み込み

• Managerパラメータ設定より、レポート/ggserr.log に出力 – LAGREPORT{MINUTS | HOURS} – LAGINFO{SECONDS | MINUTS | HOURS} – LAGCRITICAL{SECONDS | MINUTES | HOURS}

56


lagコマンドの注意点

• lagコマンドは各プロセス内で計算可能なラグ情報を算出

– (プロセスが最新トランザクションを処理した時間) – (最新トランザクションがソースDBでコミットされた時間)

– 新しいレコードを読みこまなければラグは更新されない

• 前段のプロセスが停止

• 業務処理が停止

• ソースDBとターゲットDBの時間差は常に測定できない

– Heartbeat Table の使用を検討

57

参考：[GG] LAG コマンドを使用した LAG 情報の取得方法(KROWN:149705) (Doc ID 1753561.1)


Heartbeat Table

• 原理

– ダミー表を作り、定期的にsysdateをupdate

– ダミー表をGoldenGateでレプリケーション

– ターゲット側でダミー表を参照し「いつ時点までのデータが届いているか」を確認

• GoldenGateの管理情報を含むHeartbeat Table の作成・管理も可能

– 参考：Oracle GoldenGate Best Practices: Heartbeat Table for Monitoring Lag times (Doc ID 1299679.1)

58

Capture DataPump Replicat

sysdateを毎秒update

sysdate

2015-02-18 15:30:00

15:29:50までの更新は届いている

現在時刻とのラグは？

sysdate

2015-02-18 15:29:50


処理量

• statsコマンドによる取得

– 各プロセスに対して実行し、表毎のSQL処理量を取得

59

Extracting from SCOTT.TEST to SCOTT.TEST: *** Total statistics since 2011-08-16 16:02:56 *** Total inserts 100.00 Total updates 20.00 Total deletes 17.00 Total discards 0.00 Total operations 137.00

出力結果例（抜粋）

1029260 records processed as of 2011-09-19 17:22:02 (rate 102053,delta 102053) 1946631 records processed as of 2011-09-19 17:22:12 (rate 96917,delta 91737) 3089452 records processed as of 2011-09-19 17:22:22 (rate 102688,delta 114281) 4000338 records processed as of 2011-09-19 17:22:35 (rate 92206,delta 68493)

REPORTCOUNT EVERY 10 SECONDS, RATE

設定例

GGSCI> stats {extract | replicat} <プロセス名>

コマンド

出力結果例（抜粋）

• REPORTCOUNTパラメータに取得

– 各プロセスのパラメータとして指定し、指定の間隔で、全体のSQL処理量をレポートファイルに記録


処理量の蓄積

• Management Pack for Oracle GoldenGateの使用

– オリジナルのWeb UI より処理量の推移をグラフで確認可能

• Oracle GoldenGate Monitor

– Enterprise Manager Cloud Control の画面よりグラフで確認可能

• Enterprise Manager Oracle GoldenGate System Monitoring Plug-In

• 定期的な statsコマンド実行をファイルに出力

– Shell スクリプトへの組み込み

• 各プロセスで REPORTCOUNTパラメータを指定

60


(参考) Oracle GoldenGate Monitor

61

ラグの推移

処理量の推移


（参考）スクリプトの作成

• OBEYスクリプト – GGSCIコマンドをスクリプトファイル化

– GGSCIより OBEYコマンドで呼び出す

– SQL*Plusの@のようなイメージ

GGSCI> obey lag_extract.oby GGSCI> lag extract cap01 Sending GETLAG request to EXTRACT CAP01 ... Last record lag: 2 seconds. At EOF, no more records to process.

$ cat lag_extract.oby lag extract cap01

作成例

実行例

$ cat lag_extract.sh #!/bin/sh OGG_DIR=/goldengate cd ${OGG_DIR} ( SHELL_DIR=/home/oracle/shell SLEEP_COUNT=10 LOOP_COUNT=0 LOOP_MAX=10 while [ $LOOP_COUNT -lt $LOOP_MAX ] do echo "OBEY ${SHELL_DIR}/lag_extract.oby" sleep ${SLEEP_COUNT} LOOP_COUNT=`expr $LOOP_COUNT + 1` done ) | ./ggsci

作成例（定期的にOBEYスクリプトを実行）

• シェルスクリプト – OSシェルスクリプトからGGSCIコマンドを呼び出す

62


整合性確認

• GoldenGateによるレプリケーション時、ソースDB/ターゲットDBは常にOpen状態

• オペミス/接続ミスなどによる意図しない更新によるデータ不整合GoldenGateではハンドリング不可能

• Oracle GoldenGate Veridataを使用して、データ伝播対象表の中身のレベルで確認

– どの表のどのデータが不一致かをレポーティング可能

63


(参考)Oracle GoldenGate Veridata

64

① 終了したジョブ

の情報を表示

②不一致データの存在を確認

③不一致データの詳細を確認


(参考)Veridataによる不一致データの修復

65

① クリックして展開

② 不一致レコード

の詳細を確認

③ 修復を実行


アジェンダ

環境確認

サイジング

設定・設計

初期ロード

監視


1

2

3

4

5

66

6 •遅延 •異常停止 •その他


遅延

• どのプロセスが遅延しているのかを特定する

• 確認ステップ例

1. 業務テーブルまたはHeartbeat Tableからレプリケーションの遅れを確認

• ターゲットDBに最新データが届いていない

2. 各プロセスのラグを確認

• どのプロセスが遅れているのか？

3. 処理量の推移を確認

• 処理量が増えている？

67


遅延ケース(1)： Replicatスループットの限界

• 傾向

– Replicatのラグが大きい

– ReplicatプロセスのCPU使用率が高い（100%とは限らない）

– AWRなど見てもターゲットDBのボトルネックは見られない(ほとんどDB CPU待ちなど)

• 対処方法

– BATCHSQLが未設定であれば試す

– Replicatの多重化検討

• Replicatごとの担当テーブルを割り振り

– Trailファイルからテーブル毎の更新を分析し、分割方法を検討

Oracle GoldenGate - Using the GoldenGate Logdump Utility to Manually Load Balance across Multiple Processes (Doc ID 1301300.1)

• RANGE関数の使用して、Replicatごとの担当をレコードで分割

• Integrated Replicat への構成変更

68


遅延ケース(2) : ターゲット表でFull Scan 多発 • 傾向

– Replicatのラグが大きい – 特定の表への update / delete 処理負荷・時間がかかっている

• 原因 – 主キーの無いソース表への一括 update または delete 分

• 例： UPDATE TAB1 SET COL3=‘Finished’;

• 対策 – ターゲット表に（一時的でも）索引を作成し論理キー(KEYCOL)として指定

69

COL1 COl2 COL3

1 A On going ⇒ Finished

2 B On going ⇒ Finished

3 C On going ⇒ Finished

Extract Replicat

COL1 COl2 COL3

1 A On going ⇒ Finished

2 B On going ⇒ Finished

3 C On going ⇒ Finished

ターゲットは1件ずつ更新索引が効かないため都度Full Scan


遅延ケース(3) : ネットワーク転送が遅い

• 傾向

– Data Pumpのラグが大きい

• 原因

– 帯域不足

– Round Trip Time(RTT)が大きい（遠隔地転送など）ことによるスループット低下

• 対処方法

– 帯域不足に対しては、圧縮転送機能の使用を検討

• RMTHOST <hostname>, MGRPORT <port number>, COMPRESS

– RTTの大きい環境に対してはTCPソケットバッファサイズを大きくする

• 例：平均RTT 80ms (0.08 sec) 帯域幅 100Mbpsの場合

0.08 × 100 ÷ 8 (バイト換算) =1MB = 1000000

RMTHOST <hostname>, MGRPORT <port number>, TCPBUFSIZE 1000000

70


遅延ケース(4):NASへのTrailファイルの書き込みが遅い • 傾向

– Data Pump または Capture のラグが大きい

• 原因

– NFSマウントオプション（共通） • Oracle GoldenGate Best Practice: NFS Mount options for use with GoldenGate (Doc ID 1232303.1)

• Linuxの場合: rw,bg,hard,nointr,rsize=32768,wsize=32768,tcp,actimeo=0,noac,vers=3,timeo=600 (actimeo=0, noac が低速化の原因になりやすい傾向)

– I/Oサイズ（Data Pumpのみ） • TCPバッファサイズに依存してCollectorからのI/Oサイズが小さくなり、NFSマウントオプションの影響を受けやすい

• 対処方法 – 出力先の変更

– TCPバッファサイズ増加によってI/Oサイズを大きくする

• 前スライドと同様の設定方法

– actimeo=0, noac を外す対応は、性能向上に有効な可能性があるが、障害リスクが高まるため推奨されない方法。問題が発生した場合、マウントオプションを元に戻すガイドをすることを検討。

71

Collector DataPump

TCPバッファサイズの調整で、ここのI/Oサイズを大きくする


遅延ケース(5):ラージトランザクションのキャプチャ

72

• CaptureがラージトランザクションをTrailファイルに書き出すまでに時間がかかる

CACHESIZEMAX （環境によるが、

CACHESIZEの2倍弱程度）

未コミットのトランザクション

サイズ

Tx 1

Tx 2

Tx 3

Tx 4

Tx n

キャッシュ（管理仮想メモリー・プール）

オンデマンドで割り当てられる

DIMM SWAP

OS仮想メモリ空間

CACHESIZE

キャッシュサイズの増加 • ページング発生を抑止

トランザクションサイズの監視 • “send extract CACHEMGR

CACHESTATS”コマンドの “vm used max”（利用仮想メモリの最大値）

CACHEDIRECTORY （デフォルトはインストールディレクトリ配下のdirtmp）

• CACHESIZE/CACHESIZEMAXを超えると、ディスクに書き出す（ページング）

•ページング動作は、各閾値を利用して2段階で行われる

ディスクI/O性能の改善 • CACHEDIRECTORYを「IO性能が高いディスク」に配置


遅延ケース(6): ラグの極小化

• 各プロセスの処理間隔を最小にする

• Trailファイルを高速なディスクに配置

• その他のボトルネックが無いか確認

73

DataPump Replicat Capture

EOFDELAYCSECS 1に設定 (10ms)

高速なディスク(SSDなど)に配置

高速なディスク(SSDなど)に配置

EOFDELAYCSECS 1 FLUCHCSECS 1 に設定(10ms)

EOFDELAYCSECS 1に設定 (10ms)


異常停止

74

障害の種類関連コンポーネント復旧方法

プロセス障害 Extract (Capture) Managerによる自動再起動

Extract (Data Pump) / Collector Managerによる自動再起動

Replicat Managerによる自動再起動

Manager 手動再起動（Oracle Clusterwareにより自動化）

ファイル障害（オペミス / OS,Disk障害

による破損等）

Trail ファイル / Checkpointファイル

過去時点からのTrailファイル再生成し、再同期

または、初期ロードから再構成

ネットワーク障害 Extract (Data Pump) / Collector ネットワーク復旧後にプロセスを再起動

サーバー障害 Extract (Capture), Extract (Data

Pump) / Collector, Replicat , Manager

サーバー復旧後にプロセスを再起動 (Extract / ReplicatはManager起動時に自動起動可能)

データ同期障害（オペミスによるターゲッ

ト表への誤った更新等）

Extract (Capture) 過去時点からのTrailファイル再生成し、再同期

または、初期ロードから再構成

手動での修復

Extract (Data Pump) / Collector

Replicat

主な障害は自動復旧が可能


データ再同期による復旧

• プロセス再起動だけでは、レプリケーション再開できないケース

– Trailファイルの破損 : 伝播するデータがなくなる

– チェックポイントファイルの破損：処理開始ポイントが分からない

– ターゲットDBのPoint-in-time Recovery : GoldenGateのチェックポイント情報とずれる

• ターゲットDBのチェックポイント・テーブルを使用

– LOG_CSN列に伝播済みのソースDBのSCNが格納されている

• 復旧パターン

75

DataPump Replicat

① LOG_CSN列の値を参照し、伝播完了済みSCNを確認

Capture

② 伝播完了済みSCNの前時点からデータを再伝播 ③ aftercsnオプションで伝

播完了済みSCNを指定し、Replicatを再起動


データ再同期による復旧

• GLOBALSファイルに以下のパラメータを入れることで、 Replicatは常にチェックポイントテーブルを参照しながら起動

• Replicat起動時にチェックポイントテーブルを参照するよう明示的に指定することも可能

• これらの機能を使用することで、チェックポイントテーブルの参照が不要になる

• Integrated Replicatはチェックポイントテーブルは持たずに、内部的に適用状況を管理

76

_csnfiltering on

GGSCI> start replicat <name> filterduptransactions


データ障害ケース(1):Not Nullのない一意キー / 一意索引 • GoldenGateのadd trandataコマンドは、表にUKのみが存在する場合、UK列のみをサプリメンタル・ロギング対象に指定

• UK列にNot Nullがない場合、UK=null列が複数可能

• ソースのUK=nullの行が更新されると、ターゲットはUK=nullの行全てを更新

• 回避策：Null含め一意となる列の組み合わせで、ソース側のサプリメンタル・ロギングを指定

77

ID(UK列) NAME TYPE

1 A JP

B JP ⇒ US

3 C JP

D JP

UPDATE TEST01 SET TYPE=‘US’ WHERE NAME=‘B’ ;

Extract Replicat

ID(UK列) NAME TYPE

1 A JP

B JP ⇒ US

3 C JP

D JP ⇒ US

UPDATE “TEST01 SET TYPE = ‘JP’ WHERE "ID" is NULL


データ障害ケース(2):主キー一括更新 • ソース側が単一のSQLに更新でも、ターゲット側は1レコードずつ処理

• PK = PK + 1 のように1レコード単位で実行するとエラーになる一括更新は注意が必要

• 対応策

– ターゲットDBが11.2.0.2未満：ターゲット表の設定変更が必要。ターゲット表の主キー制約設定 deferrable initially immediate の設定が必要。この設定はデフォルトではなく、設定変更には対象列の制約および索引の再作成が必要。これによりindexがuniqueでなくなるため、業務処理への影響確認が必要。また、ReplicatにHANDLETPKUPDATEパラメータの設定が必要。

– ターゲットDBが11.2.0.2以降：ターゲット表の設定変更は基本的に不要。主キー制約設定 not deferrable initially immediate (デフォルト設定)であれば追加設定不要

78

ID(PK列) NAME

1 => 2 A

2 => 3 B

3 => 4 C

4 => 5 D

UPDATE TEST01 SET ID=ID + 1; Extract Replicat

ID(PK列) NAME

1 A

2 B

3 C

4 D

UPDATE TEST01 SET ID = 2 WHERE "ID" = 1


データ障害ケース(3):初期ロード時のロングトランザクション • 初期ロード後にcommitしたはずのトランザクションが伝播できていない？

– Captureは構成後に開始したトランザクションのみをキャプチャ

• 対処方法

– Trailファイル / アーカイブ・ログから分析

• 対策 – Capture構成前にv$transaction(gv$transaction)等でオープントランザクションを確認

79

時間

Capture 構成

Tx1 begin

Tx1 commit

Tx2 begin

Tx2 commit

初期ロード

Tx3 begin

Tx3 commit

Tx 1 : GoldenGateで伝搬

Tx 2 : 初期ロードで伝搬

Tx 3 : GoldenGateでも初期ロードでも伝搬されない


データ障害ケース(4) : 未対応の処理

• 伝播漏れが発覚した場合は、GoldenGateが対応していない処理によるデータではないかを確認

– Classic Captureで RAC環境へのXA

– Classic CaptureでRAC環境へのパラレルDML

– Nologging のオペレーション

80


その他Tips (1) : 移行先/DRサイトへの切り替え

81

Capture DataPump Collector

REDO log

Oracle Instance

Oracle Instance

Replicat

① アプリケーション停止

②CaptureがREDOログを最後まで処理したことの確認して、停止する

確認コマンド

GGSCI > lag extract cap01

Sending GETLAG request to

EXTRACT CAP01 ...

Last record lag: 1 seconds.

At EOF, no more records to

process.

③DataPumpがTrailファイルを最後まで処理したことの確認して、停止する

確認コマンド

GGSCI > lag extract dp01


EXTRACT DP01 ...



process.

④ReplicatがTrailファイルを最後まで処理したことの確認して、停止する

確認コマンド

GGSCI > lag replicat rep01


REPLICAT REP01 ...



process.

現行側でアプリケーション停止後、Capture, DataPump, Replicat の順に全てのレコードの処理が完了したことを確認してから停止する。Replicat停止時点で、全てのデータ伝搬が完了している。

注意：アプリケーションが停止しても、内部処理によりREDOが生成されEOFに到達しない場合がある。 infoコマンドよりCaptureプロセスのチェックポイント情報を合わせて参照して、処理の完了を確認する。参考：[GG] LAG コマンドを使用した LAG 情報の取得方法(KROWN:149705) (Doc ID 1753561.1)


その他Tips (2) : Integrated Capture / Replicat

• パフォーマンス・チューニング・障害解析に別途情報が必要

– 独自のヘルスチェックレポート

– Oracle DBにGoldenGate用のビューを実装(V$GOLDENGATE_XXX, V$GG_XXX など

– Oracle 12c では、AWRレポート内にGoldenGateの情報も表示

– 参考ドキュメント

• GoldenGate Integrated Capture and Integrated Replicat Healthcheck Script (Doc ID 1448324.1)

• Best Practices and Performance Tuning Recommendations for Oracle GoldenGate Integrated Replicat (Doc ID 1953623.1)

• Oracle GoldenGate Performance Data Gathering (Doc ID 1488668.1)

• GoldenGate Integration with AWR (Doc ID 1596493.1)

82


Document Control

Author

日本オラクル株式会社 • 後藤陽介

Reviewer

日本オラクル株式会社 • 谷川信朗

• 南野英梨子

• 浅井純

• 小西亮輔

• 別府真由美

• 植田智広

• 正木能長

• 舟橋直美

変更履歴

Date Version

2015/4 1.0 Created.

2015/9 1.1 テンプレート変更

2016/2 1.2 先頭スライド削除

2016/8 1.3 UROWID型の記載を変更(P.11)

83

oracle goldengate導入tips

Technology