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

(1)

(2)

Oracle Data Guard / Oracle

GoldenGate 高可用性のための

実践Tips

製品戦略統括本部戦略製品ソリューション本部

Principal Sales Consultant

(3)

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

また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことは

できません。以下の事項は、マテリアルやコード、機能を提供することをコミットメン

ト（確約）するものではないため、購買決定を行う際の判断材料になさらないで下さ

い。オラクル製品に関して記載されている機能の開発、リリースおよび時期につい

ては、弊社の裁量により決定されます。

OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。

文中の社名、商品名等は各社の商標または登録商標である場合があります。

(4)

Oracle Maximum Availability Architecture (MAA)

ノード障害

データ障害

システム変更

アプリ変更

Real Application Clusters

Flashback

RMAN & Oracle Secure Backup

ASM

Active Data Guard

GoldenGate

Online Reconfiguration

Rolling Upgrades

Edition-based Redefinition

Ora

cle

M

A

Be

st Pr

ac

tice

s

Online Redefinition

データ変更

MAA を構成する機能・製品

計画外停止

計画停止

(5)

アジェンダ



前半：Oracle Data Guard のTips

(6)

前半アジェンダ



データ破損対策としての Data Guard



データロス・ゼロのフェイルオーバー



RACスタンバイでの適用インスタンスの可用性



スタンバイDBの賢い構築法



Data Guard と GoldenGateの違い

(7)

データ破損対策としての Data Guard

Data Guard のアーキテクチャ

データファイル

オンライン

REDOログ

REDO転送

ログバッファまたはオンラインREDOログ

からREDOを転送、スタンバイ側で受信

ログ

バッファ

ログ

バッファ

LGWR

NSS/NSA

RFS

アーカイブ

ログ

データファイル

スタンバイ

REDOログ

REDO適用

リカバリの仕組みでREDO

を逐次適用

MRP

サーバー

プロセス

アーカイブ

ログ

プライマリ

スタンバイ

データファイルはデータブロックレベルで等しいが、

データファイルをコピーしているわけではない

(8)

データ破損対策としての Data Guard

プライマリのデータファイル破損をスタンバイから復旧

データファイル

オンライン

REDOログ

ログ

バッファ

ログ

バッファ

LGWR

NSS/NSA

RFS

アーカイブ

ログ

データファイル

スタンバイ

REDOログ

MRP

サーバー

プロセス

アーカイブ

ログ

プライマリ

スタンバイ

リストア / リカバリ

プライマリのデータファイルが破損しても、スタンバイのデータファイルは破損しない

(9)

データ破損対策としての Data Guard

Active Data Guard による、自動ブロック修復(Oracle 11gR2)

MAX(C1)

---

5000

②ブロック破損

の検知

④スタンバイ側の正常な

ブロックを自動的に転送

③スタンバイに正常

ブロックを要求

⑤自動的に

修復

①SQL発行

⑥エラーなく

結果が返る

Waiting Auto BMR response

for (file# 7, block# 261)

Auto BMR successful

Requesting Auto BMR for

(file# 7, block# 261)

alert

SQL> SELECT max(c1)

FROM tab1;

破損を自動的に修復。アプリケーションは障害に気づかない

※ Active Data Guard オプション

があれば使用可能

(10)

データ破損対策としての Data Guard



REDO転送は同期でも非同期でも良い



タイムアウト（60秒）に達するまでに、

正常ブロックがスタンバイに適用されていれば

自動ブロック修復は動作する

自動ブロック修復の動き

(11)

データ破損対策としての Data Guard



ストレージ層の障害により書き込みに失敗しているにも関わらず、

OSに対して正常完了の通知を返す



更新（update）のトランザクションでLost Writeが起こると？

–

次のトランザクションがLost Writeのブロックにアクセスしてもエラーにならない

–

ディスク上のデータは更新前のままだが、アプリケーションは更新後

のデータとして扱う

–

正しくないデータをユーザー/顧客に提供するリスク

–

Oracleが障害を検知するまでに時間がかかるケースがある

Lost Write

(12)

データ破損対策としての 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

(13)

（参考）計画外停止の主な要因(過去3年)

2012 IOUG Database Availability Survey アンケート結果より

(14)



データ破損は 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/maa-datacorruption-bestpractices-396464.pdf

ビルトインされた Data Validation

Disk

FC / TCP/IP

Disk Firmware

HBA / NIC

SAN/NAS

Device Driver

OS

CPU/Memory

I/

O

P

A

T

H

（参考）Oracle DBによるデータ破損対策

(15)

前半アジェンダ



データ破損対策としての Data Guard



データロス・ゼロのフェイルオーバー



RACスタンバイでの適用インスタンスの可用性



スタンバイDBの賢い構築法



Data Guard と GoldenGateの違い

(16)

データロス・ゼロのフェイルオーバー



スイッチオーバー

–

計画停止用途

–

データロスなしを保証

Data Guard の切り替え操作

昇

格

降

格



フェイルオーバー

–

計画外停止用途

–

同期転送ならデータロスなし

–

非同期転送ならデータロストあり

（未転送データ分）

昇

格

(17)

データロス・ゼロのフェイルオーバー



システム表領域破損でデータベースをオープンできない



スタンバイへのフェイルオーバーは可能、但しデータロスは？

障害の例

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

(18)

データロス・ゼロのフェイルオーバー



以下の条件で、未転送データをスタンバイに強制転送（Oracle 11.2以降）

–

プライマリDBがマウント可能（データファイルは不要）

–

制御ファイル、オンライン/アーカイブREDOログにアクセス可能

※条件を満たせばデータ・ロス・ゼロのフェイルオーバーが可能



実行コマンド

SQL> alter system flush redo to ‘boston’;

(スタンバイに適用されるまでコマンドレスポンスを待つ)

SQL> alter system flush redo to ‘boston‘ no confirm apply;

(スタンバイに転送されるまでコマンドレスポンスを待つ)

(19)

データロス・ゼロのフェイルオーバー



アラート・ログ出力

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.



データロス・ゼロのフェイルオーバーを実行可能

(20)

前半アジェンダ



データ破損対策としての Data Guard



データロス・ゼロのフェイルオーバー



RACスタンバイでの適用インスタンスの可用性



スタンバイDBの賢い構築法



Data Guard と GoldenGateの違い

(21)

RACスタンバイでの適用インスタンスの可用性

overview



スタンバイがRACの場合、

REDO適用は1インスタンスの

みで行われる



適用インスタンスがダウンした

時の対応は？



Solution: Data Guard Broker

REDO転送

Active Standby Instances

Apply Instance

N1

N2

N3

(22)

RACスタンバイでの適用インスタンスの可用性



PreferredApplyInstance: 優先する適用インスタンス



ApplyInstanceTimeout: 適用インスタンスの障害を検知して、他のインスタンスへのフェ

イルオーバー時間（デフォルト0秒）



フェイルオーバー時の挙動

–

PreferredApplyInstance が使用可能であれば、使う

–

PreferredApplyInstance が使用できない場合はランダムに選択される



Active Data Guardの場合

–

障害前にオープンしていたインスタンスは、Brokerにより自動的にオープンされる

(23)

前半アジェンダ



データ破損対策としての Data Guard



データロス・ゼロのフェイルオーバー



RACスタンバイでの適用インスタンスの可用性



スタンバイDBの賢い構築法



Data Guard と GoldenGateの違い

(24)

スタンバイDBの賢い構築方法

1. プライマリDBを設定（

Force logging / アーカイブ・ログ・モード）

2. 初期化パラメータの設定

3. データベースファイルをスタンバイにコピー（

バックアップ / リストア or ネットワーク転送）

4. REDOログの作成

5. 管理リカバリプロセスの開始



懸念

–

バックアップ / リストアの領域が必要。取得に時間がかかる



データファイルを直接コピーし、バックアップ / リストアを不要にする

–

ネットワーク帯域が狭いと、転送に時間がかかる



バックアップを圧縮して、転送量を抑える

一般的なスタンバイの構築方法

(25)

スタンバイDBの賢い構築方法

RMANでスタンバイ構築を最適化

パターン

手法

使用ポイント

使用可能バージョン

（１）

プライマリDBから直接コ

ピーして作成

(Duplicate from Active

Database)

•ネットワーク帯域が広い場合に有効

•バックアップ用領域が確保できない場合に有効

•DBサイズ / 帯域で試算可能

•本番DBファイルに長時間のアクセスが発生する

11gR1以降

（２）

プライマリDBの高速圧縮

バックアップから作成

(Advanced Compression)

• 圧縮率が高く、ネットワーク帯域が狭い場合に有効

•（３）より高速

•マルチセクション・バックアップによる高速化が可能

•試算にはバックアップ/リストアの性能と圧縮率が必要

11gR1以降

（３）

プライマリDBの標準圧縮

バックアップから作成

• 圧縮率が高く、ネットワーク帯域が狭い場合に有効

•（２）より低速

•試算にはバックアップ/リストアの性能と圧縮率が必要

10gR1以降

(26)

スタンバイDBの賢い構築方法

検証結果

処理内容

（１）

（２）

（３）

Backup

プライマリDBのバック

_{アップを取得}

N/A

0:18:24

0:32:28

SCP

バックアップをスタンバイ

DBサーバーに転送

N/A

0:29:11

0:26:23

Nomount

スタンバイDBインスタン

_スを起動

0:00:04

0:00:06

Duplicate

DBリストアとREDOログ

_{ファイルの作成}

3:39:01

0:24:40

0:41:33

StartMRP

スタンバイDBのリカバリ

_{プロセスを起動}

0:00:06

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)

(27)

スタンバイDBの賢い構築方法



ファイル転送性能

–

ネットワーク帯域に依存



本検証は実効4.6MB/s



バックアップ/リストア性能

–

ストレージI/O 性能と圧縮率に依存

–

本検証では高い圧縮効果



高速圧縮(2) : バックアップサイズ 7.9GB



標準圧縮(3) : バックアップサイズ 7.1GB

ポイントとなる性能値

（参考）RMANの圧縮機能

未使用ブロック圧縮 : 未使用のデータブロックは

スキップされる

バイナリ圧縮 : バックアップ出力時に圧縮アルゴリ

ズムを適用

データファイルサイズ 57.2GB

52.8GB

7.9GB

未使用ブロック圧縮

バイナリ圧縮

（例）パターン（2）の場合

- 4.4GB

6.7倍

(28)

参考：検証で使用したスクリプト抜粋：パターン(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 "Duplicate,`date +%y%m%d,%H%M%S`" >> ${LOGDIR}/time.log

(

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

(29)

参考：検証で使用したスクリプト抜粋：パターン(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}

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

(30)

参考：検証で使用したスクリプト抜粋：パターン(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

(31)

前半アジェンダ



データ破損対策としての Data Guard



データロス・ゼロのフェイルオーバー



RACスタンバイでの適用インスタンスの可用性



スタンバイDBの賢い構築法



Data Guard と GoldenGateの違い

(32)

Data Guard と GoldenGate の違い



DBの完全なコピーに特化し

て、性能・管理性・データ保護

考慮されたアーキテクチャ



REDO適用によるデータ同期

アーキテクチャ

ログ

バッファ

ログ

バッファ

NSS

/ NSA

RFS

データファイル

オンライン

REDOログ

Data Guard

LGWR

REDOログ

Capture

_Trail

Files

Pump

_Trail

_Delivery

Files

GoldenGate



DBとの分離性、プロセス毎

の分離性、構成の柔軟性が

考慮されたアーキテクチャ



SQL適用によるデータ同期

MRP

スタンバイ

REDOログ

(33)

Data Guard と GoldenGate の違い

データレプリケーションと切り替えの考え方

Data Guard

 DBレベルで正（プライマリ）、副（スタンバ

イ）の概念を持つ

 実運用を想定した切り替え機能（スイッチ

オーバー / フェイルオーバー）を持つ

GoldenGate

 正 / 副の考え方はない。Read / Write 可能

なDB間のデータレプリケーション

 GoldenGate は、DB間の更新トランザク

ションのレプリケーションをするのみ。実運

用での切り替え手順は管理者が考える必

要がある

(34)

Data Guard と GoldenGate の違い

出来ること、出来ないこと

Data Guardだけが出来ること

 同期転送

 データ破損検知・修復

- 自動ブロック修復（Active Data Guard）

- DB_LOST_WRITE_PROTECT

 スタンバイのバックアップをプライマリにリス

トア

 自動フェイルオーバー

（Data Guard Broker）

 全てのデータ型・オブジェクトに対応

GoldenGateだけが出来ること

 Active-Active構成（両DBで書き込み可能）

 異OSかつ異バージョン間の

レプリケーション

 表単位のレプリケーション

 複数DBから単一DBへ集約

 フィルタ / 変換処理をかませたレプリケー

ション

 Standard Editionのレプリケーション

(35)

前半アジェンダ



データ破壊対策としての Data Guard



データロス・ゼロのフェイルオーバー



RACスタンバイでの適用インスタンスの可用性



スタンバイDBの賢い構築法



Data Guard と GoldenGateの違い

(36)

(37)

(38)

(39)