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

導入検討フェーズにおける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

制限事項（その他）
• オブジェクト名/列名に以下の文字を含むオブジェクトは伝播不可
– { } 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）
オンデマンドで
割り当てられる
DIMMSWAP
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停止が必要なのは
アーカイブ・ログ・モードへ
の変更のみ

サプリメンタル・ロギングの設定
• 最小サプリメンタル・ロギング
– 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 ReplicatCapture
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ラグ
DataPumpCapture 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)
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
CollectorDataPump
TCPバッファサイズの調整で、
ここのI/Oサイズを大きくする

遅延ケース(5):ラージトランザクションのキャプチャ
72
• CaptureがラージトランザクションをTrailファイルに書き出すまでに時間がかかる
CACHESIZEMAX
（環境によるが、
CACHESIZEの2倍弱程度）
未コミットの
トランザクション
サイズ
Tx 1
Tx 2
Tx 3
Tx 4
Tx n
キャッシュ
（管理仮想メモリー・プール）
オンデマンドで
割り当てられる
DIMMSWAP
OS仮想メモリ空間
CACHESIZE
キャッシュサイズの増加
• ページング発生を抑止
トランザクションサイズの監視
• “send extract CACHEMGR
CACHESTATS”コマンドの “vm used
max”（利用仮想メモリの最大値）
CACHEDIRECTORY
（デフォルトはインス
トールディレクトリ配
下のdirtmp）
• CACHESIZE/CACHESIZEMA
Xを超えると、ディスクに
書き出す（ページング）
• ページング動作は、各閾
値を利用して2段階で行
われる
ディスクI/O性能の改善
• CACHEDIRECTORYを「IO性能が高
いディスク」に配置

遅延ケース(6): ラグの極小化
• 各プロセスの処理間隔を最小にする
• Trailファイルを高速なディスクに配置
• その他のボトルネックが無いか確認
73
DataPump ReplicatCapture
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 ...
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

More Related Content

What's hot

Viewers also liked

Similar to Oracle GoldenGate導入Tips

More from オラクルエンジニア通信

Oracle GoldenGate導入Tips