Oracle Data Guard / Oracle GoldenGate 高可用性のための実践 Tips 製品戦略統括本部戦略製品ソリューション本部 Principal Sales Consultant 後藤陽介

1

Oracle Data Guard / Oracle GoldenGate 高可用性のための実践 Tips 製品戦略統括本部戦略製品ソリューション本部 Principal Sales Consultant 後藤陽介

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

Oracle Maximum Availability Architecture (MAA) MAA を構成する機能 製品 計画外停止 計画停止 ノード障害データ障害システム変更データ変更アプリ変更 Real Application Clusters Flashback RMAN & Oracle Secure Backup ASM Active Data Guard GoldenGate Online Reconfiguration Rolling Upgrades Online Redefinition Edition-based Redefinition Oracle MAA Best Practices 4

アジェンダ 前半 :Oracle Data Guard の Tips 後半 :Oracle GoldenGate の Tips 5

前半アジェンダ データ破損対策としての Data Guard データロス ゼロのフェイルオーバー RACスタンバイでの適用インスタンスの可用性 スタンバイDBの賢い構築法 Data Guard と GoldenGateの違い 本資料では Data Guard は全てフィジカル スタンバイを想定します 6

データ破損対策としての Data Guard Data Guard のアーキテクチャ プライマリ REDO 転送ログバッファまたはオンライン REDO ログから REDO を転送 スタンバイ側で受信 スタンバイ REDO 適用リカバリの仕組みで REDO を逐次適用 サーバープロセス ログバッファ LGWR NSS/NSA RFS MRP ログバッファ データファイル オンライン REDO ログ アーカイブログ スタンバイ REDO ログ アーカイブログ データファイルはデータブロックレベルで等しいが データファイルをコピーしているわけではない データファイル 7

データ破損対策としての Data Guard プライマリのデータファイル破損をスタンバイから復旧 プライマリ スタンバイ サーバープロセス ログバッファ LGWR NSS/NSA RFS MRP ログバッファ データファイル オンライン REDO ログ アーカイブスタンバイログ REDOログリストア / リカバリ アーカイブログ データファイル プライマリのデータファイルが破損しても スタンバイのデータファイルは破損しない 8

データ破損対策としての Data Guard Active Data Guard による 自動ブロック修復 (Oracle 11gR2) SQL> SELECT max(c1) FROM tab1; 1SQL 発行 alert 2 ブロック破損の検知 Requesting Auto BMR for (file# 7, block# 261) 3 スタンバイに正常ブロックを要求 alert Active Data Guard オプションがあれば使用可能 Waiting Auto BMR response for (file# 7, block# 261) Auto BMR successful MAX(C1) ----------------- 5000 6 エラーなく結果が返る 5 自動的に修復 4 スタンバイ側の正常なブロックを自動的に転送 破損を自動的に修復 アプリケーションは障害に気づかない 9

データ破損対策としての Data Guard 自動ブロック修復の動き REDO 転送は同期でも非同期でも良い タイムアウト (60 秒 ) に達するまでに 正常ブロックがスタンバイに適用されていれば自動ブロック修復は動作する 10

データ破損対策としての Data Guard Lost Write ストレージ層の障害により書き込みに失敗しているにも関わらず OS に対して正常完了の通知を返す 更新 (update) のトランザクションで Lost Write が起こると? 次のトランザクションが Lost Write のブロックにアクセスしてもエラーにならない ディスク上のデータは更新前のままだが アプリケーションは更新後のデータとして扱う 正しくないデータをユーザー / 顧客に提供するリスク Oracle が障害を検知するまでに時間がかかるケースがある 11

データ破損対策としての Data Guard Lost Write の検知に対応する Data Guard 初期化パラメータ (Oracle 11.1 以降 ) DB_LOST_WRITE_PROTECT TYPICAL: read / write の表領域について バッファキャッシュ読み取りをREDOに記録 FULL: read / write, read-onlyの表領域について バッファキャッシュ読み取りをREDOに記録 プライマリから受信したREDOブロックのSCNとフィジカル スタンバイ上のSCNを比較する プライマリのSCNがスタンバイのSCNより低い場合 スタンバイはLost Write を検知 ORA-00752: recovery detected a lost write of a data block ORA-10567: Redo is inconsistent with data block (file# 7, block# 26) ORA-10564: tablespace TBS_2 ORA-01110: data file 7: '/oracle/dbs/btbs_21.f' ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 57503 スタンバイにフェイルオーバーすることで復旧 SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE; 参考 :MOS Note 1265884.1 - Resolving ORA-752 or ORA-600 [3020] During Standby Recovery 12

( 参考 ) 計画外停止の主な要因 ( 過去 3 年 ) 2012 IOUG Database Availability Survey アンケート結果より 出典 :ENTERPRISE DATA AND THE COST OF DOWNTIME, 2012 IOUG Database Availability Survey was produced by Unisphere Research and sponsored by Oracle. 13

I/O PATH ( 参考 )Oracle DB によるデータ破損対策 ビルトインされた Data Validation データ破損は I/O のあらゆる層で起こり得る障害 Oracle は ブロック構造を理解したデータ検証 破損検知 修復が可能 DB_BLOCK_CHECKSUM DB_BLOCK_CHECKING DB_LOST_WRITE_PROTECT ASM Flashback Technology Active Data Guard 自動ブロック修復 Oracle DB によるデータ破損対策の全体像 Preventing, Detecting, and Repairing Block Corruption: Oracle Database 11g http://www.oracle.com/technetwork/database/availability/maadatacorruption-bestpractices-396464.pdf CPU/Memory OS Device Driver HBA / NIC FC / TCP/IP SAN/NAS Disk Firmware Disk 14

前半アジェンダ データ破損対策としての Data Guard データロス ゼロのフェイルオーバー RACスタンバイでの適用インスタンスの可用性 スタンバイDBの賢い構築法 Data Guard と GoldenGateの違い 本資料では Data Guard は全てフィジカル スタンバイを想定します 15

データロス ゼロのフェイルオーバー Data Guard の切り替え操作 スイッチオーバー 計画停止用途 データロスなしを保証 フェイルオーバー 計画外停止用途 同期転送ならデータロスなし 非同期転送ならデータロストあり ( 未転送データ分 ) 降格 昇格 昇格 16

データロス ゼロのフェイルオーバー 障害の例 システム表領域破損でデータベースをオープンできない SQL> alter database open; --- primary cannot be opened alter database open * ERROR at line 1: ORA-01122: database file 1 failed verification check ORA-01110: data file 1: '/home/oracle/dbs/t_db1.f' ORA-01210: data file header is media corrupt スタンバイへのフェイルオーバーは可能 但しデータロスは? 17

データロス ゼロのフェイルオーバー Flush Redo 以下の条件で 未転送データをスタンバイに強制転送 (Oracle 11.2 以降 ) プライマリDBがマウント可能 ( データファイルは不要 ) 制御ファイル オンライン / アーカイブREDOログにアクセス可能 条件を満たせばデータ ロス ゼロのフェイルオーバーが可能 実行コマンド SQL> alter system flush redo to boston ; ( スタンバイに適用されるまでコマンドレスポンスを待つ ) SQL> alter system flush redo to boston no confirm apply; ( スタンバイに転送されるまでコマンドレスポンスを待つ ) 18

データロス ゼロのフェイルオーバー スタンバイ側の挙動 アラート ログ出力 Media Recovery: FLUSH REDO EOR logs encountered. Media Recovery recovers through FLUSH REDO EOR logs. Tue Aug 30 21:45:36 2011 Standby switchover readiness check: Checking whether recovery applied all redo.. Physical Standby applied all the redo from the primary. データロス ゼロのフェイルオーバーを実行可能 19

前半アジェンダ データ破損対策としての Data Guard データロス ゼロのフェイルオーバー RACスタンバイでの適用インスタンスの可用性 スタンバイDBの賢い構築法 Data Guard と GoldenGateの違い 本資料では Data Guard は全てフィジカル スタンバイを想定します 20

RAC スタンバイでの適用インスタンスの可用性 overview スタンバイが RAC の場合 REDO 適用は 1 インスタンスのみで行われる 適用インスタンスがダウンした時の対応は? REDO 転送 適用インスタンスアクティブなスタンバイインスタンス Apply Instance Active Standby Instances N1 N2 N3 Solution: Data Guard Broker 21

RAC スタンバイでの適用インスタンスの可用性 2 つのプロパティ設定 (Data Guard Broker) PreferredApplyInstance: 優先する適用インスタンス ApplyInstanceTimeout: 適用インスタンスの障害を検知して 他のインスタンスへのフェイルオーバー時間 ( デフォルト 0 秒 ) フェイルオーバー時の挙動 PreferredApplyInstance が使用可能であれば 使う PreferredApplyInstance が使用できない場合はランダムに選択される Active Data Guard の場合 障害前にオープンしていたインスタンスは Broker により自動的にオープンされる 22

前半アジェンダ データ破損対策としての Data Guard データロス ゼロのフェイルオーバー RACスタンバイでの適用インスタンスの可用性 スタンバイDBの賢い構築法 Data Guard と GoldenGateの違い 本資料では Data Guard は全てフィジカル スタンバイを想定します 23

スタンバイ DB の賢い構築方法 一般的なスタンバイの構築方法 1. プライマリDBを設定 (Force logging / アーカイブ ログ モード ) 2. 初期化パラメータの設定 3. データベースファイルをスタンバイにコピー ( バックアップ / リストア or ネットワーク転送 ) 4. REDOログの作成 5. 管理リカバリプロセスの開始 懸念 バックアップ / リストアの領域が必要 取得に時間がかかる データファイルを直接コピーし バックアップ / リストアを不要にする ネットワーク帯域が狭いと 転送に時間がかかる バックアップを圧縮して 転送量を抑える 24

スタンバイ DB の賢い構築方法 RMAN でスタンバイ構築を最適化 パターン手法使用ポイント使用可能バージョン (1) プライマリ DB から直接コピーして作成 (Duplicate from Active Database) ネットワーク帯域が広い場合に有効 バックアップ用領域が確保できない場合に有効 DB サイズ / 帯域で試算可能 本番 DB ファイルに長時間のアクセスが発生する 11gR1 以降 (2) プライマリ DB の高速圧縮バックアップから作成 (Advanced Compression) (3) プライマリ DB の標準圧縮バックアップから作成 圧縮率が高く ネットワーク帯域が狭い場合に有効 (3) より高速 マルチセクション バックアップによる高速化が可能 試算にはバックアップ / リストアの性能と圧縮率が必要 圧縮率が高く ネットワーク帯域が狭い場合に有効 (2) より低速 試算にはバックアップ / リストアの性能と圧縮率が必要 11gR1 以降 10gR1 以降 25

スタンバイ DB の賢い構築方法検証結果 処理内容 (1) (2) (3) Backup SCP Nomount Duplicate StartMRP プライマリ DB のバックアップを取得 バックアップをスタンバイ DB サーバーに転送 スタンバイ DB インスタンスを起動 DB リストアと REDO ログファイルの作成 スタンバイ DB のリカバリプロセスを起動 N/A 0:18:24 0:32:28 N/A 0:29:11 0:26:23 0:00:04 0:00:04 0:00:06 3:39:01 0:24:40 0:41:33 0:00:06 0:00:07 0:00:07 合計 3:39:11 1:12:26 1:40:37 検証環境 4 core のIAサーバー メモリ8GB Oracle Linux 5.3 (64bit) Oracle 11.2.0.2 (single) ネットワーク帯域 40Mbps ( 実効 4.6MB/s 程度 ) テストデータ データファイル 57GB ( データサイズ 52GB) スタンバイ作成中にトランザクションは発生しない 26

スタンバイ DB の賢い構築方法 ポイントとなる性能値 ファイル転送性能 ネットワーク帯域に依存 本検証は実効 4.6MB/s バックアップ / リストア性能 ストレージI/O 性能と圧縮率に依存 本検証では高い圧縮効果 高速圧縮 (2) : バックアップサイズ 7.9GB 標準圧縮 (3) : バックアップサイズ 7.1GB ( 参考 )RMAN の圧縮機能未使用ブロック圧縮 : 未使用のデータブロックはスキップされるバイナリ圧縮 : バックアップ出力時に圧縮アルゴリズムを適用 ( 例 ) パターン (2) の場合 データファイルサイズ 57.2GB - 4.4GB 6.7 倍 未使用ブロック圧縮 52.8GB バイナリ圧縮 7.9GB 27

参考 : 検証で使用したスクリプト抜粋 : パターン (1) #!/bin/sh # 本スクリプトは 以下の作業後にスタンバイで実行します # 1. スタンバイには listener.ora で静的サービスを登録し Nomout でも接続可能な状態 # 2. パスワード ファイルはプライマリのコピーをスタンバイの SID に合わせて rename し $ORACLE_HOME/dbs に配置済み # 3. スタンバイ用の初期化パラメータファイルを作成済み LOGDIR=< ログディレクトリ > PRIMARYDB=< プライマリの接続記述子 > STANDBYDB=< スタンバイの接続記述子 > PASSWORD=< パスワード > mkdir -p ${LOGDIR} echo "Nomount,`date +%y%m%d,%h%m%s`" >> ${LOGDIR}/time.log sqlplus / as sysdba <<EOF startup nomount exit EOF ( echo "run{ CONFIGURE DEVICE TYPE DISK PARALLELISM 1; duplicate target database for standby from active database; }" echo "exit" ) rman target sys/${password}@${primarydb} auxiliary sys/oracle@{standbydb} > ${LOGDIR}/duplicate.log echo "StartMRP,`date +%y%m%d,%h%m%s`" >> ${LOGDIR}/time.log sqlplus / as sysdba <<EOF alter database recover managed standby database using current logfile disconnect; exit EOF echo "END,`date +%y%m%d,%h%m%s`" >> ${LOGDIR}/time.log echo "Duplicate,`date +%y%m%d,%h%m%s`" >> ${LOGDIR}/time.log 28

参考 : 検証で使用したスクリプト抜粋 : パターン (2) #!/bin/sh # 本スクリプトは 以下の作業後にスタンバイで実行します # 1. スタンバイには listener.ora で静的サービスを登録し Nomout でも接続可能な状態 # 2. パスワード ファイルはプライマリのコピーをスタンバイの SID に合わせて rename し $ORACLE_HOME/dbs に配置済み # 3. スタンバイ用の初期化パラメータファイルを作成済み LOGDIR=< ログディレクトリ > BACKUPDIR=< バックアップ出力先のディレクトリ > PRIMARYHOST=< プライマリのホスト名 > PRIMARYDB=< プライマリの接続記述子 > STANDBYDB=< スタンバイの接続記述子 > PASSWORD=< パスワード > mkdir -p ${LOGDIR} echo "Backup,`date +%y%m%d,%h%m%s`" >> ${LOGDIR}/time.log # 圧縮アルゴリズムの設定方法は Oracle バージョンにより異なります 本スクリプトは 11.2 のものです ( echo "run { CONFIGURE DEVICE TYPE DISK PARALLELISM 4; configure compression ALGORITHM 'medium'; backup as compressed backupset section size 500M DEVICE TYPE DISK FORMAT '${BACKUPDIR}/%U' database plus archivelog; BACKUP DEVICE TYPE DISK FORMAT ''${BACKUPDIR}/%U' CURRENT CONTROLFILE FOR STANDBY; }" echo "exit" ) rman target sys/${password}@$<primarydb> > ${LOGDIR}/backup.log echo "SCP,`date +%y%m%d,%h%m%s`" >> ${LOGDIR}/time.log scp -rp ${PRIMARYHOST}:${BACKUPDIR}/* ${BACKUPDIR} echo "Normount,`date +%y%m%d,%h%m%s`" >> ${LOGDIR}/time.log sqlplus / as sysdba <<EOF startup nomount exit EOF echo "Duplicate,`date +%y%m%d,%h%m%s`" >> ${LOGDIR}/time.log ( echo "run{ CONFIGURE DEVICE TYPE DISK PARALLELISM 4; DUPLICATE TARGET DATABASE FOR STANDBY; }" echo "exit" ) rman target sys/${password}@${primarydb} auxiliary sys/oracle@${standbydb} > ${LOGDIR}/duplicate.log echo "StartMRP,`date +%y%m%d,%h%m%s`" >> ${LOGDIR}/time.log sqlplus / as sysdba <<EOF alter database recover managed standby database using current logfile disconnect; exit EOF echo "END,`date +%y%m%d,%h%m%s`" >> ${LOGDIR}/time.log du -h ${BACKUPDIR} > ${LOGDIR}/size_of_backup.log 29

参考 : 検証で使用したスクリプト抜粋 : パターン (3) #!/bin/sh # 本スクリプトは 以下の作業後にスタンバイで実行します # 1. スタンバイには listener.ora で静的サービスを登録し Nomout でも接続可能な状態 # 2. パスワード ファイルはプライマリのコピーをスタンバイの SID に合わせて rename し $ORACLE_HOME/dbs に配置済み # 3. スタンバイ用の初期化パラメータファイルを作成済み # 10g の場合 スタンバイ制御のバックアップが個別に必要です 詳細はマニュアルをご参照ください LOGDIR=< ログディレクトリ > BACKUPDIR=< バックアップ出力先のディレクトリ > PRIMARYHOST=< プライマリのホスト名 > PRIMARYDB=< プライマリの接続記述子 > STANDBYDB=< スタンバイの接続記述子 > PASSWORD=< パスワード > mkdir -p ${LOGDIR} echo "Backup,`date +%y%m%d,%h%m%s`" >> ${LOGDIR}/time.log # 圧縮アルゴリズムの設定方法は Oracle バージョンにより異なります 本スクリプトは 11.2 のものです ( echo "run { CONFIGURE DEVICE TYPE DISK PARALLELISM 4; configure compression ALGORITHM 'basic'; backup as compressed backupset DEVICE TYPE DISK FORMAT '${BACKUPDIR}/%U' database plus archivelog; BACKUP DEVICE TYPE DISK FORMAT '${BACKUPDIR}/%U' CURRENT CONTROLFILE FOR STANDBY; }" echo "exit" ) rman target sys/${password}@${primarydb} > ${LOGDIR}/backup.log echo "SCP,`date +%y%m%d,%h%m%s`" >> ${LOGDIR}/time.log scp -rp ${PRIMARYHOST}:${BACKUPDIR}/* ${BACKUPDIR} du -h ${BACKUPDIR} > ${LOGDIR}/size_of_backup.log echo "Normount,`date +%y%m%d,%h%m%s`" >> ${LOGDIR}/time.log sqlplus / as sysdba <<EOF startup nomount exit EOF echo "Duplicate,`date +%y%m%d,%h%m%s`" >> ${LOGDIR}/time.log ( echo "run{ CONFIGURE DEVICE TYPE DISK PARALLELISM 4; DUPLICATE TARGET DATABASE FOR STANDBY; }" echo "exit" ) rman target sys/${password}@${primarydb} auxiliary sys/oracle@${standbydb} > ${LOGDIR}/duplicate.log echo "StartMRP,`date +%y%m%d,%h%m%s`" >> ${LOGDIR}/time.log sqlplus / as sysdba <<EOF alter database recover managed standby database using current logfile disconnect; exit EOF echo "END,`date +%y%m%d,%h%m%s`" >> ${LOGDIR}/time.log 30

前半アジェンダ データ破損対策としての Data Guard データロス ゼロのフェイルオーバー RACスタンバイでの適用インスタンスの可用性 スタンバイDBの賢い構築法 Data Guard と GoldenGateの違い 本資料では Data Guard は全てフィジカル スタンバイを想定します 31

Data Guard と GoldenGate の違い アーキテクチャ ログバッファ NSS / NSA RFS LGWR Data Guard ログバッファ MRP DB の完全なコピーに特化して 性能 管理性 データ保護考慮されたアーキテクチャ REDO 適用によるデータ同期 データファイル オンライン REDO ログ スタンバイ REDO ログ データファイル Capture Trail Files GoldenGate Pump Trail Files Delivery DB との分離性 プロセス毎の分離性 構成の柔軟性が考慮されたアーキテクチャ SQL 適用によるデータ同期 REDO ログ 32

Data Guard と GoldenGate の違いデータレプリケーションと切り替えの考え方 Data Guard DB レベルで正 ( プライマリ ) 副 ( スタンバイ ) の概念を持つ 実運用を想定した切り替え機能 ( スイッチオーバー / フェイルオーバー ) を持つ GoldenGate 正 / 副の考え方はない Read / Write 可能な DB 間のデータレプリケーション GoldenGate は DB 間の更新トランザクションのレプリケーションをするのみ 実運用での切り替え手順は管理者が考える必要がある 33

Data Guard と GoldenGate の違い出来ること 出来ないこと Data Guard だけが出来ること 同期転送 データ破損検知 修復 - 自動ブロック修復 (Active Data Guard) - DB_LOST_WRITE_PROTECT スタンバイのバックアップをプライマリにリストア 自動フェイルオーバー (Data Guard Broker) 全てのデータ型 オブジェクトに対応 GoldenGate だけが出来ること Active-Active 構成 ( 両 DB で書き込み可能 ) 異 OS かつ異バージョン間のレプリケーション 表単位のレプリケーション 複数 DB から単一 DB へ集約 フィルタ / 変換処理をかませたレプリケーション Standard Edition のレプリケーション 34

前半アジェンダ データ破壊対策としての Data Guard データロス ゼロのフェイルオーバー RACスタンバイでの適用インスタンスの可用性 スタンバイDBの賢い構築法 Data Guard と GoldenGateの違い 本資料では Data Guard は全てフィジカル スタンバイを想定します 35

36

37

1

Oracle Data Guard / Oracle GoldenGate 高可用性のための実践 Tips 日本オラクル株式会社テクノロシ ーソリューションコンサルティンク 統括本部テクニカルアーキテクト本部テ ータヘ ースアーキテクト部シニアコンサルタント浅井純

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

アジェンダ 前半 :Oracle Data Guard の Tips 後半 :Oracle GoldenGate の Tips 4

後半アジェンダ Oracle GoldenGate 基本アーキテクチャ GoldenGate 自動フェイル オーバー設計 自動フェイル オーバー設計以外の高可用性検討事項 前提条件 Real Application Clusters 環境 ( ソース / ターゲットともに ) Classic Capture ( GoldenGate 11.1 以前から提供されているキャプチャ機能 ) 5

Oracle GoldenGate 基本アーキテクチャ ソース ターゲット ソースデータベース Oracle GoldenGate 管理プロセス Manager Oracle GoldenGate 管理プロセス Manager ターゲットデータベース 抽出プロセス Extract (Capture) 転送プロセス Extract (Data Pump) 受信プロセス Collector 適用プロセス Replicat 差分ログ チェックポイントファイル Trail ファイル チェックポイントファイル Trail ファイル チェックポイントファイル チェックポイント表 OS OS データベースの差分ログを Trail ファイルという汎用的なフォーマットに変換して転送 各プロセスの進行状況はチェックポイントファイル ( バイナリファイルまたはデータベース上の表 ) に保存 上記の構成の他に データベース サーバとは別のサーバに GoldenGate を切り出す構成などが可能 6

後半アジェンダ Oracle GoldenGate 基本アーキテクチャ GoldenGate 自動フェイル オーバー設計 自動フェイル オーバー設計以外の高可用性検討事項 前提条件 Real Application Clusters 環境 ( ソース / ターゲットともに ) Classic Capture ( GoldenGate 11.1 以前から提供されているキャプチャ機能 ) 7

GoldenGate の自動フェイル オーバー設計 自動フェイル オーバーを実現するための考慮事項 GoldenGate の各プロセスは 1 ノードのみで稼働 接続先ノードを意識させないためのアプリケーション VIP の作成 フェイル オーバー後の伝播再開のために必要なファイルを共有領域に配置 参考 NOTE:1313703.1 Oracle GoldenGate Best Practices: Oracle GoldenGate high availability using Oracle Clusterware 8

GoldenGate の自動フェイル オーバー設計 各 GoldenGate プロセスの稼働ノード ソース ターゲット Capture Data Pump Capture Data Pump Collector Replicat Collector Replicat 起動 Manager フェイル オーバー Manager Manager フェイル オーバー Manager 停止 Oracle Grid Infrastracture Oracle Grid Infrastracture ソース / ターゲット別に GoldenGate を稼働させるノードは 1 つ ソース / ターゲットとも複数の GoldenGate プロセスを 1 ノードで稼働させる Managerプロセス : Oracle Clusterware による管理 Managerプロセス以外 : < 起動 > Manager プロセスによる管理 < 停止 > Oracle Clusterware による管理 9

GoldenGate の自動フェイル オーバー設計 GoldenGate 用アプリケーション VIP の作成 ソース ターゲット Manager Collector Data Pump APP VIP Oracle Grid Infrastracture Oracle Grid Infrastracture 接続先を意識させないためのアプリケーション VIP ターゲット側フェイル オーバーを意識させない為の設定 Data Pump プロセスの接続先としてアプリケーション VIP を用意 10

GoldenGate の自動フェイル オーバー設計 GoldenGate 用アプリケーション VIP の作成 ソース Manager ターゲット Collector Data Pump APP VIP Oracle Grid Infrastracture Oracle Grid Infrastracture 接続先を意識させないためのアプリケーション VIP ターゲット側フェイル オーバーを意識させない為の設定 Data Pump プロセスの接続先としてアプリケーション VIP を用意 11

GoldenGate の自動フェイル オーバー設計 Oracle Clusterware に登録するリソース ソース ターゲット GGAPP(Manager) GGAPP(Manager) GGAPP(Manager) GGAPP(Manager) APP VIP フェイル オーバー APP VIP APP VIP フェイル オーバー APP VIP Oracle Grid Infrastracture Oracle Grid Infrastracture 以下の 2 つのリソースを Oracle Clusterware に登録して 同一ノードで稼働するように設計 GoldenGate 用アプリケーション VIP Manager プロセス管理用 GoldenGate リソース 12

GoldenGate の自動フェイル オーバー設計 自動フェイル オーバーのための Oracle Clusterware へのリソース登録 開始の依存関係 停止の依存関係 Collector Replicat Collector Replicat Capture Data Pump Capture Data Pump 強い依存性 GGAPP(Manager) 強い依存性 GGAPP(Manager) プルアップ依存性 GoldenGate 設定による依存関係 APP Vip APP Vip DBLOGREADER の場合 DB Instance Network ASM Instance ASMUSER / ASMPASSWORD の場合 DB Instance Network ASM Instance 13

GoldenGate の自動フェイル オーバー設計 共有領域への配置が必要な GoldenGate 関連ファイル ソース Capture Replicat Data Pump Collector ターゲット チェックポイントファイル Trail ファイル チェックポイントファイル フェイル オーバーを考慮して必要なファイルを共有領域に配置 上記以外にも以下の関連ファイルの配置が必要 Trail ファイル チェックポイントファイル アーカイブ REDO ログ ファイル / パラメータ ファイル / プロセス状態ファイル / レポート ファイル / Discard ファイル / Bounded Recovery ファイル ( ソースのみ ) 14

GoldenGate の自動フェイル オーバー設計共有領域への配置が必要な GoldenGate 関連ファイル ソース Capture Data Pump Capture Data Pump Collector Replicat ターゲット チェックポイントファイル Trail ファイル チェックポイントファイル Trail ファイル フェイル オーバーを考慮して必要なファイルを共有領域に配置 上記以外にも以下の関連ファイルの配置が必要 チェックポイントファイル アーカイブ REDO ログ ファイル / パラメータ ファイル / プロセス状態ファイル / レポート ファイル / Discard ファイル / Bounded Recovery ファイル ( ソースのみ ) 15

GoldenGate の自動フェイル オーバー設計 GoldenGate バイナリの配置先 共有領域に配置 共有領域の耐障害性の検討が必要 各ノードのローカルに配置 共有領域に配置が必要なファイルのうち 出力先設定変更ができないファイルはシンボリック リンク等で共有領域に配置させる 16

後半アジェンダ Oracle GoldenGate 基本アーキテクチャ GoldenGate 自動フェイル オーバー設計 自動フェイル オーバー設計以外の高可用性検討事項 前提条件 Real Application Clusters 環境 ( ソース / ターゲットともに ) Classic Capture ( GoldenGate 11.1 以前から提供されているキャプチャ機能 ) 17

自動フェイル オーバー設計以外の高可用性検討事項 共有領域が準備できないケース ACFS / DBFS を活用する場合の考慮事項 Trail ファイルのデータ欠落の防止 共有領域マウント設定の考慮事項 フェイル オーバーを伴わない障害発生時のデータ伝播の継続 接続先インスタンス設定の考慮事項 Collector プロセスの TIMEOUT 設定 18

自動フェイル オーバー設計以外の高可用性検討事項 共有領域が準備できないケース ACFS ( Automatic Storage Management (ASM) Cluster File System ) GoldenGate バイナリは配置制限あり ACFS は複数ノードでマウント可能 但し GoldenGate 稼働ノード以外でプロセスのステータスを確認すると正しくないステータスが表示される 参考 NOTE:1350133.1 OGG displaying incorrect status from inactive node ACFS を使用する場合は以下のどちらかで対応 ACFS を 1 ノードでのみマウント GoldenGate 稼働ノードでのみで操作 ( GoldenGate バイナリはローカルに配置 ) 19

自動フェイル オーバー設計以外の高可用性検討事項 共有領域が準備できないケース DBFS ( DataBase File System ) Exadata 環境では ACFS が利用できないため DBFS を利用 Bounded Recovery ファイルのみ配置制限あり GoldenGate 11.2 以降 かつ Oracle Database 11.2 以降 DBFS は複数ノードでマウントすることは可能 但し 複数ノードでマウントされた状態ではファイル ロッキング機能がサポートされない DBFS を使用する場合は 1 ノードのみマウントさせる 20

自動フェイル オーバー設計以外の高可用性検討事項 Trail ファイルのデータ欠落の防止 共有領域への Trail ファイル書き込み時にデータ欠落する可能性 Trail ファイルへの書き込み内容がディスクにフラッシュされる前に障害が発生するケース 共有領域のマウント設定で書き込み時のディスクへのフラッシュを強制させることで防止可能 参考 NOTE:1232303.1 Oracle GoldenGate Best Practice: NFS Mount options for use with GoldenGate 21

自動フェイル オーバー設計以外の高可用性検討事項 Trail ファイルのデータ欠落の防止 Trail ファイル nnn Trail ファイル nnn+1 ディスク書き込み済みデータ ディスク書き込み未済データ 障害復旧後に次の Trail に書き出される 実際の Trail ファイルの EOF の位置 ディスク書き込み未済データ 障害時にファイルから消失する範囲 障害発生前の書き込み完了位置 障害復旧後 欠落したデータが再伝播されて補完される可能性がある 障害時に Trail ファイルに書き込みを行うプロセスも停止する 障害復旧後のプロセス再起動で 書き込み先 Trail ファイルが切り替えられる Trail ファイル読み込み側プロセスのチェックポイント情報と Trail ファイルの不整合が発生した場合 プロセスが停止する 参考 NOTE:1138409.1 OGG EXTRACT / REPLICAT CHECKPOINT RBA IS LARGER THAN LOCAL TRAIL SIZE 22

自動フェイル オーバー設計以外の高可用性検討事項 接続先インスタンス設定の考慮事項 ソース Capture フェイル オーバー Capture Replicat Replicat ターゲット tnsnames.ora tnsnames.ora tnsnames.ora DB Instance DB Instance DB Instance DB Instance Classic Capture / Replicat からデータベースへの接続方法 データベース インスタンス障害を考慮して 接続時フェイル オーバーを設定 複数プロセス構成で 接続先インスタンスを分散させる 23

自動フェイル オーバー設計以外の高可用性検討事項 インスタンス障害を考慮した接続時フェイル オーバーの設定 cap01.prm (Capture のパラメータ ) 共有領域に配置 Extract CAP01 USERID gguser@ggcap, PASSWORD oracle tnsnames.ora 1 号機側 GGCAP = (DESCRIPTION = (ADDRESS=(PROTOCOL=TCP)(HOST=racsrc1-vip)(PORT=1521)) (ADDRESS=(PROTOCOL=TCP)(HOST=racsrc2-vip)(PORT=1521)) tnsnames.ora 2 号機側 GGCAP = (DESCRIPTION = (ADDRESS=(PROTOCOL=TCP)(HOST=racsrc2-vip)(PORT=1521)) (ADDRESS=(PROTOCOL=TCP)(HOST=racsrc1-vip)(PORT=1521)) #1 #2 フェイル オーバー Capture Capture tnsnames.ora DB Instance tnsnames.ora DB Instance GoldenGate パラメータは共通 各ノードの tnsnames.ora は異なる 自ノードのインスタンスに優先的に接続するように設定 24

自動フェイル オーバー設計以外の高可用性検討事項 複数プロセス構成で接続先インスタンスの分散 rep01.prm (Replicat のパラメータ ) 共有領域に配置 Replicat REP01 USERID gguser@ggrep1, PASSWORD oracle rep02.prm (Replicat のパラメータ ) 共有領域に配置 Replicat REP01 USERID gguser@ggrep2, PASSWORD oracle tnsnames.ora 1 号機側 GGREP1 = (ADDRESS=(PROTOCOL=TCP)(HOST=ractrg1-vip)(PORT=1521)) (ADDRESS=(PROTOCOL=TCP)(HOST=ractrg2-vip)(PORT=1521)) GGREP2 = (ADDRESS=(PROTOCOL=TCP)(HOST=ractrg2-vip)(PORT=1521)) (ADDRESS=(PROTOCOL=TCP)(HOST=ractrg1-vip)(PORT=1521)) #1 #2 Replicat Replicat tnsnames.ora DB Instance DB Instance GoldenGate パラメータで Replicat 毎に接続先を変更 tnsnames.ora でそれぞれの接続先設定を定義 25

自動フェイル オーバー設計以外の高可用性検討事項 Collector プロセスの TIMEOUT 設定 ソース 1 障害発生 Data Pump 3 フェイル オーバー Oracle Grid Infrastracture 2 伝播停止 Data Pump 4 Collector 起動依頼 Collector 独立して起動中 Manager Data Pump プロセスのフェイル オーバー発生のケース Collector プロセスは障害発生時に停止しない 6 伝播再開 Collector 5 Collector 起動 Oracle Grid Infrastracture 7 Collector 同士で競合 フェイル オーバー発生前の Collector プロセスが起動したままの場合 新たに起動された Collector プロセスと競合してデータ伝播が再開できない フェイル オーバー時間を考慮して Collector の TIMEOUT を設定 ターゲット 26

関連 Note のご紹介 Note:1313703.1 Oracle GoldenGate Best Practices: Oracle GoldenGate high availability using Oracle Clusterware Note:1232303.1 Oracle GoldenGate Best Practice: NFS Mount options for use with GoldenGate Note:1303611.1 Does Oracle GoldenGate support Oracle ACFS? Note:1350133.1 OGG displaying incorrect status from inactive node Note:1371489.1 Configure Oracle GoldenGate on Oracle Exadata Database Machine Note:1138409.1 OGG EXTRACT / REPLICAT CHECKPOINT RBA IS LARGER THAN LOCAL TRAIL SIZE 27

Database Oracle Database 11g R2: Data Guard 管理 ~BCP 策定の要となる 11g R2 DBA のための必修コース ~ Oracle Data Guard を使用して Oracle Database を計画停止および計画外停止から保護する方法を学習します また Data Guard スタンバイ データベースを使用してレポート 問合せ テストなどの本番機能をサポートする方法についても学習します 別のシステムへのビジネス処理要求のオフロード 別のシステムへのバックアップ要求のオフロード 高可用性システムの構築 コース内容 フィジカル スタンバイ データベースおよびロジカル スタンバイ データベースの作成および管理 レポート 問合せ テスト バックアップ実行などの本番機能をサポートするための Data Guard スタンバイ データベースの使用 高可用性 Oracle Database を実現するための Data Guard の使用 Data Guard 構成をメンテナンスするための Enterprise Manager Grid Control および Data Guard コマンドライン インタフェース (DGMGRL) の使用 対象者 データベース管理者 テクニカルコンサルタント 前提条件 コース日程 4 日間 受講料 (2012 年 11 月現在 ) Oracle Database 11g: 管理ワークショップ I / II ご受講済みもしくは相当の知識をお持ちの方 会場 : トレーニングキャンパス青山 2013 年 3 月 11 日 ( 月 )~14 日 ( 木 ) 定価 291,060( 税込 ) Oracle PartnerNetwork 会員様は パートナー割引価格で受講いただけます お申込み お問合せ http://www.oracle.com/jp/education オラクルユニバーシティ Tel: 0120-155-092 28

29

30