Oracle Database 10g Release 2のOracle Data Guardエンタープラ …otndnld.oracle.co.jp/deploy/availability/pdf/TWP_DataGuard_10gR2.pdf · Oracle Corporation発行「Oracle Data

Oracle Database 10g Release 2 の Oracle Data Guard エンタープライズ環境での

ビジネスの継続

Oracle ホワイト・ペーパー 2006 年 11 月

Oracle Data Guard エンタープライズ環境でのビジネスの継続

概要 ...................................................................................................................... 3 障害の影響 .......................................................................................................... 3

高可用性の課題............................................................................................. 3 Oracle Data Guard........................................................................................... 4 Oracle Database 高可用性ソリューション.................................................. 4

Oracle Data Guard の概要 ................................................................................... 5 Oracle Data Guard とは.................................................................................. 5 Oracle Data Guard の機能.............................................................................. 6 Oracle Database 10g Release 2 の新機能 ...................................................... 7 Oracle Data Guard の利点.............................................................................. 8

Oracle Data Guard プロセス・アーキテクチャ................................................ 9 主要テクノロジ・コンポーネント................................................................. 10

Oracle Data Guard 構成................................................................................ 10 保護モードと REDO トランスポート ...................................................... 11

大保護モード ..................................................................................... 11 大可用性モード ................................................................................. 11 大パフォーマンス・モード ............................................................. 12

Oracle Database 10g Release 2 の REDO トランスポートの強化 ...... 13 Redo Apply と SQL Apply ........................................................................... 13

フィジカル・スタンバイ・データベース - REDO Apply................ 14 ロジカル・スタンバイ・データベース - SQL Apply ....................... 16

Oracle Enterprise Manager と Oracle Data Guard Broker............................ 19 Oracle Database 10g Release 2 の管理強化........................................... 20

ロール移行 - スイッチオーバーとフェイルオーバー .......................... 21 スイッチオーバー ................................................................................. 21 フェイルオーバーの種類 ..................................................................... 22 手動フェイルオーバー ......................................................................... 22 ファスト・スタート・フェイルオーバー ......................................... 23 新しいスタンバイ・データベースとしての旧プライマリ・データベースのリストア ......................................... 26 ロール移行イベント ............................................................................. 26

通信障害の対応........................................................................................... 27 人的エラーによるデータ破損からの保護 ............................................... 27 ローリング・データベース・アップグレード ....................................... 28 REDO ログ宛先のカスケード ................................................................... 29

Oracle Data Guard と RAC ................................................................................ 29 Maximum Availability Architecture.................................................................... 29 Oracle Data Guard とリモート・ミラー化ソリューション.......................... 30 Oracle Data Guard のカスタマ ......................................................................... 32 結論 .................................................................................................................... 33 参考資料 ............................................................................................................ 34

Oracle Database 10g Release 2 の Oracle Data Guard エンタープライズ環境でのビジネスの継続

2

Oracle Corporation 発行「Oracle Data Guard in Oracle Database 10g Release 2 - Business Continuity for the Enterprise」の翻訳版です。

Oracle Data Guard エンタープライズ環境でのビジネスの継続

概要

多くのグローバル企業の経営者にとっての優先事項は、ビジネスの継続性と障

害時リカバリです。現在のグローバル企業は、経済変動、市場動向の急激な変化、

競争圧力によって、365 日 24 時間態勢の対応が求められており、不測の事業中断

に対して迅速かつ効率的に対処する必要があります。

Oracle Data Guardは、企業の中核資産であるデータを保護することを目的とした、

現在提供されている中でも効果的なソリューションの一つであり、障害やその

他の停止などに対し、24 時間態勢でデータの使用を可能にします。このホワイト・

ペーパーでは、Oracle Database 10g の Oracle Data Guard テクノロジについて説明し、

それがあらゆる企業の事業継続のインフラストラクチャにおいて重要な要素であ

ることを示します。

障害の影響

e ビジネスの普及に伴い、今日の企業は、きわめて複雑で高度にネットワーク化さ

れたグローバル経済の中で事業を展開しており、以前と比べて障害による影響を

受けやすくなっています。障害や停止によるコストは、業界によって異なります

が、1 時間で数百万ドル規模に達することさえあります。数字は膨大ではありま

すが、その理由はいたって明白です。インターネットにより、数百万人のお客様

が電子店舗を直接訪れるようになったからです。顧客関係、競争上の優位性、法

の遵守、業界の評判、株主の信任といった、重要かつ相互依存性の高い事業課題

は、事業の中断や停止時間に対する脆弱性が増加していることから、これまで以

上に重大な意味を持っています。

高可用性の課題

ビジネスに影響を及ぼす停止には計画外停止と計画停止があります。計画外停止

は、ハードウェアやシステムの故障、データやストレージの不具合、人的エラー、

コンピュータ・ウィルス、ソフトウェアの誤作動、自然災害、悪意のある行為な

どが原因で起こります。また、システム・アップグレードなどのための定期的な

メンテナンスなど、計画停止も存在します。

データは企業の最も重要な資産の一つ

です。データへの継続的アクセスは、多

額の損失を招くビジネス・プロセスの中

断を回避する上で欠かすことができま

せん。

ビジネス継続性戦略を策定する場合、企業はこうした課題に効果的に対応するた

めのビジネス継続性計画（BCP）を作成しなければなりません。BCP の重大な要

件の一つに、企業データの保護があります。データは、給与や社員情報、顧客レ

コード、貴重な研究結果、財務レコード、履歴情報など、すべてが企業のも重

要な資産の 1 つであるからです。企業がデータを失い簡単に取り戻せない場合、


3


そのデータを再構築したり、あるいは再生成したりすることは、不可能ではない

にしろ、莫大な費用を要する作業であり、企業が事業を継続する能力に重大な影

響を及ぼします。

Oracle Data Guard

Oracle Data Guard は、データ保護機能と障害時リカバリ（DR）機能の広範なセッ

トを提供し、Oracle データベースに悪影響を及ぼす障害や人的エラー、破損が発

生した場合にビジネス継続性を維持します。

このホワイト・ペーパーでは、Oracle Database 10g Release 2 の Oracle Data Guard

について、アーキテクチャとテクノロジの面から概説します。詳細については、

Oracle Data Guard ドキュメント（参考[1]）を参照してください。

Oracle Database 高可用性ソリューション

Oracle Data Guard は、Oracle データベースの高可用性（HA）ソリューション・ス

タックのコンポーネントです。Oracle データベースは、ビジネスに影響を及ぼす

さまざまな計画停止や計画外停止を小限に抑制することで、ビジネス継続性を

確保するための HA 機能の統合セットを備えています。次の図は、Oracle Database

10g で使用することができるさまざまな HA 機能を示しています。各機能の詳細に

ついては、[2]および[3]を参照してください。

計画外停止

計画停止

システムの故障

データ障害

システム変更

データ変更

グリッド・クラスタ

自動ストレージ管理フラッシュバック

RMAN およびフラッシュ・リカバリ領域H.A.R.D.

Data Guard

オンライン再構成ローリング・アップグレード

オンライン再定義

Oracle Database は、ビジネスに影響を

及ぼすさまざまな計画停止や計画外停止

を最小限に抑制するための HA 機能の統

合セットを備えています。

図 1：Oracle Database 10g の統合された高可用性機能


4


Oracle Data Guard の概要

Oracle Data Guard とは

Oracle Data Guard は、管理、監視、自動化のためのソフトウェア・インフラスト

ラクチャで、企業のデータを、故障、障害、エラー、データ破損から保護するた

めに、1 つまたは複数のスタンバイ・データベースを、作成、保守、および監視

します。

Oracle Data Guard は、スタンバイ・データベースを、トランザクションの整合性

を有する本番データベースのコピーとして保守します。これらのスタンバイ・デー

タベースは、本番データ・センターから数千マイル離れた障害時リカバリ・サイ

トに配置することも、本番データ・センターと同じ都市、同じ構内、あるいは同

じ建物内に設置することもできます。計画停止または計画外停止によって本番

データベースが使用できなくなった場合、Oracle Data Guard によってスタンバイ・

データベースの 1 つを本番ロールに切り替え、その停止による停止時間を小限

に抑え、データ消失を防止します。

Oracle Data Guard は、企業のデータを、

故障、障害、エラー、データ破損から保

護するために、1 つまたは複数のスタン

バイ・データベースを、作成、保守、お

よび監視します。

Oracle Database 10g Enterprise Edition の機能として使用できる Oracle Data Guard は、

Real Application Clusters（RAC）および Recovery Manager（RMAN）など、他の

Oracle 高可用性ソリューションと共に使用することで、これまでになかった高水

準のデータ保護とデータ可用性を実現します。

次の図で、Oracle Data Guard の概要を説明します。

クライアントクライアント

プライマリ・サイト

スタンバイ・サイト

データ変更

Oracle Data Guard Brokerプライマリ・

データベーススタンバイ・データベース

図 2：Oracle Data Guard のアーキテクチャの概要


5


Oracle Data Guard の機能

Oracle Data Guard は、プライマリ・データベースとも呼ばれる本番データベース

と、トランザクションの整合性を備えたプライマリ・データベースのコピーであ

る、大 9 つのスタンバイ・データベースで構成されています。トランザクショ

ンの整合性は、REDO データを使用することで維持されています。プライマリ・

データベースでトランザクションが発生すると、REDO データが生成され、ロー

カル REDO ログ・ファイルに書き込まれます。Oracle Data Guard は、その REDO

データをスタンバイ・サイトに送信し、スタンバイ・データベースに適用して、

プライマリ・データベースと常に同期させます。管理者は、この REDO データを

スタンバイ・サイトに同期で送信するか、もしくは非同期で送信するかを選択で

きます。 "Oracle Data Guard 10gのパフォーマンス

は非常に素晴らしいものです。我が社の

システムとネットワーク環境では、1 時

間に 100 万件のビジネス・トランザク

ションを実行するアプリケーション・

ワークロードに対し、データ損失ゼロ、

障害時リカバリ保護の実現が証明されま

した。"- Fannie Mae 社（連邦住宅抵当公

庫）、Database Systems Management部門マネージャ、Manohar Malayanur

スタンバイ・データベースの基本となっているテクノロジは、Oracle Data Guard

Redo Apply（フィジカル・スタンバイ・データベース）と Oracle Data Guard SQL

Apply（ロジカル・スタンバイ・データベース）です。フィジカル・スタンバイ・

データベースは、ブロック単位でプライマリ・データベースとまったく同一のオ

ンディスク・データベース構造になっており、Oracle メディア・リカバリを使用

して更新します。ロジカル・スタンバイ・データベースは、プライマリ・データ

ベースと同じデータを持つ独立データベースです。SQL 文を使用して更新され、

リカバリと同時に、レポートや問合せといった他のタスクにも使用できる利点が

あります。

Oracle Data Guard によって、プライマリ・データベースと選択したスタンバイ・

データベースとの間でロール移行を実行することができ、計画停止や計画外障害

時の全体的な停止時間を短縮できます。

プライマリ・データベースとスタンバイ・データベース、およびその間のさまざ

まな通信は、SQL*Plus を使用して管理できます。また、Oracle Data Guard Broker

と呼ばれる、Oracle Data Guard 構成の作成、メンテナンス、監視を自動化して一

元化するための、分散型管理フレームワークも実装されています。管理を容易に

するために、管理者は、Oracle Enterprise Manager あるいは Oracle Data Guard Broker

の特殊コマンドライン・インタフェース（DGMGRL）によって、Oracle Data Guard

Broker の管理機能を活用できます。

次の図に、Oracle Data Guard のコンポーネントを示します。


6


同期または非同期の

REDO 送信

ネットワーク Broker

REDO Apply

バックアップ

REDO からSQL への変換

SQL Apply

追加索引とマテリアライズド・ビュー

レポート用にオープン

フィジカル・スタンバイ・データベース

本番データベース

ロジカル・スタンバイ・データベース

図 3：Oracle Data Guard アーキテクチャのコンポーネント

Oracle Database 10g Release 2 の新機能

次に、Oracle Database 10g Release 2 から新たに採用された Oracle Data Guard の機

能について概略を説明します。詳細については、この後の各項で取り上げます。

• ファスト・スタート・フェイルオーバー – この機能によって、Data Guard

は、プライマリ・データベースが消失した場合に、あらかじめ選択および同

期化されているスタンバイ・データベースに自動的かつ迅速にフェイルオー

バーできます。このとき、フェイルオーバーを手動で起動する必要はなく、

データが消失することはありません。ファスト・スタート・フェイルオーバー

の後、元のプライマリ・データベースが修復されると、Data Guardは、それを

自動的にスタンバイ・データベースに設定します。この処理によって、Data

Guard構成により再度高可用性が実現されます。

• REDO送信の強化 - プライマリ・データベースで生成されたREDOデータが、

可能な限り迅速かつ効率的にスタンバイ・データベースに送られるよう、

REDO送信アーキテクチャでいくつかの点が強化されました。

• フィジカル・スタンバイ・データベースからレポーティング・データベース

への簡単な変換 - フィジカル・スタンバイ・データベースは、プライマリ・

データベースとしてアクティブにし、レポート作成のために読取り/書込み

オープンし、過去の特定の時点にフラッシュバックさせた後にフィジカル・

スタンバイ・データベースに簡単に戻すことができます。ここで、Data Guard

は、スタンバイ・データベースとプライマリ・データベースを自動的に同期

します。その結果、フィジカル・スタンバイ・データベースをレポーティン

グやクローニングの読取り/書込みに使用できます。


7


• ロジカル・スタンバイ・データベースで適用されたアーカイブ済みREDOロ

グ・ファイルの自動削除 - ロジカル・スタンバイ・データベースで適用され

たアーカイブ済みログを自動的に削除することができ、ロジカル・スタンバ

イ・データベースのストレージ消費を低減し、Data Guardの管理性を向上させ

ることができます。フィジカル・スタンバイ・データベースについては、す

でにフラッシュ・リカバリ領域を備えたOracle Database 10g Release 1 で、この

機能を実現していました[4]。

• Data Guard 構成の厳密な監視 - Oracle Enterprise Manager の機能が拡張され、

Data Guard 構成のきめ細かな、新の監視が可能となりました。そのため、

管理者は、この構成の管理に関して、十分な情報に基づき、目的に合った決

定を下すことができます。

Oracle Data Guard の利点

Oracle Data Guard には、次のような利点があります。

• 障害時リカバリと高可用性 - 効率的で包括的な障害時リカバリと高可用性を

実現します。自動フェイルオーバーと管理が容易なスイッチオーバー機能に

よって、プライマリ・データベースとスタンバイ・データベースのロールを

切り替え、計画停止や計画外停止によるプライマリ・データベースの停止時

間を小限に抑えます。

• 完璧なデータ保護 - スタンバイ・データベースは、データ破損やユーザー・

エラーなどに対する効果的な予防策になります。プライマリ・データベース

上で発生したストレージ・レベルの物理データ破損が、スタンバイ・データ

ベースに波及することはありません。同様に、プライマリ・データベースの

恒久的損傷を引き起こすおそれのある論理データ破損やユーザー・エラーも

解消することが可能です。また、REDO データは、スタンバイ・データベー

スで受け取られる時点やスタンバイ・データベースに適用される時点で、検

証が行われます。

"Oracle Data Guard によって障害時リカ

バリ手順を自動化することができ、デー

タ消失の危険性を、これまでの方法に比

べて格段に軽減することができました。

"- Fidelity Investments 社、 Data Architecture & Services 担当副社長、

Jonathan Schapiro

• システム・リソースの効率的使用 - フィジカル・スタンバイ・データベース

は、バックアップや読取り専用レポートに使用できるため、プライマリ・デー

タベースのワークロードを軽減し、貴重な CPU や I/O サイクルを節約できま

す。Oracle Database 10g Release 2 では、フィジカル・スタンバイ・データベー

スを、オープン読取り/書込みデータベースに簡単に切り替えて使用できます。

ロジカル・スタンバイ・データベースの表は、プライマリ・データベースか

ら表を更新する間、読取り専用でこれらの表に同時にアクセスできます。ロ

ジカル・スタンバイ・データベースによって、プライマリ・データベースか

ら更新されていない表で、データを操作することも可能です。また、追加索

引やマテリアライズド・ビューをロジカル・スタンバイ・データベースで作

成し、レポート・パフォーマンスを高めることができます。

• 可用性要件とパフォーマンス要件とのバランスを取るデータ保護の柔軟性 -

Oracle Data Guard には、企業によるデータ保護要件とシステム・パフォーマン

ス要件とのバランス調整を支援する、大保護、大可用性、大パフォー

マンスという 3 種類のモードが設定されています。


8


• 通信障害からの保護 - プライマリ・データベースと 1 つ以上のスタンバイ・

データベースの間でネットワーク接続が失われると、REDO データをプライ

マリ・データベースからスタンバイ・データベースへ送ることができなくな

ります。接続が回復すると、消失した REDO データの検索が Oracle Data Guard

によって自動的に実行され、必要なアーカイブ・ログが自動的にスタンバイ・

データベースに送られます。スタンバイ・データベースは、管理者の手動に

よる介入なしに、プライマリ・データベースに再同期されます。

• 一元化されたシンプルな管理 - Oracle Data Guard Broker は、Data Guard 構成内

にある複数のデータベースの管理および監視を自動化します。管理者は、

Oracle Enterprise Manager あるいは Oracle Data Guard Broker の特殊コマンドラ

イン・インタフェース（DGMGRL）によって、この統合管理フレームワーク

を利用できます。

• Oracle データベースとの統合 - Oracle Data Guard は、追加の費用負担なしに、

Oracle Database Enterprise Edition の機能として利用できます。

Oracle Data Guard プロセス・アーキテクチャ

次の図に示されているように、Oracle Data Guard では Oracle データベース・イン

スタンスの複数のプロセスを使用して、障害時リカバリや高可用性に必要な自動

化を行います。

オンラインREDO ログ

/

同期

プライマリ・データベース

フィジカルロジカル・スタンバイ・データベース

アーカイブ済みREDO ログ

アーカイブ済みREDO ログ

バックアップ/レポート

SQL Apply のためのREDOからSQL への変換スタンバイ

REDO ログ

トランザクショ

非同期

arch

ン

MRP/LSP RFS LNS LGWR

FAL

ARCH

ARCH

Oracle Net

図 4：Oracle Database 10g Release 2 の Oracle Data Guard プロセス・アーキテクチャ

プライマリ・データベースでは、ログ・ライター（LGWR）プロセスまたは複数

のアーカイバ（ARCH）プロセスを使用して、トランザクション REDO データの

収集が行われます。ネットワークの分断から切り離すため、ログ･ライター・プロ

セスでは、LogWriter Network Server（LNS）という特殊なバックグラウンド・プロ

セスを使用して、同期的または非同期的に REDO データをスタンバイ・データベー

スに送信できます。アーカイバ・プロセスは、REDO データをスタンバイ・デー

タベースに直接送信します。プライマリ・データベースでは、フェッチ・アーカ


9


イブ・ログ（FAL）プロセスを備え、プライマリ・データベースとスタンバイ・

データベースとの間の通信が切断された後で、自動ギャップ解消および再同期化

のために、アーカイブ済みログのスタンバイ・データベースへの送信を行うクラ

イアント/サーバー・メカニズムを提供します。

スタンバイ・データベースでは、Oracle Data Guard は 1 つ以上のリモート・ファ

イル・サーバー（RFS）プロセスを使用してプライマリ・データベースから REDO

データを受け取り、管理リカバリ・プロセス（MRP）で REDO データをフィジカ

ル・スタンバイ・データベースに適用します。また、ロジカル・スタンバイ・プ

ロセス（LSP）で SQL 変換された REDO データをロジカル・スタンバイ・データ

ベースに適用します。

Oracle Data Guard Broker が有効化されると、Oracle Data Guard も Oracle Data Guard

Broker モニタ（DMON）プロセスを使用して、プライマリ・データベースとスタ

ンバイ・データベースを統合された 1 つの構成として管理および監視されます。

主要テクノロジ・コンポーネント

Oracle Data Guard 構成

Oracle Data Guard は、1 つのプライマリ・データベースと大 9 つのスタンバイ・

データベースで構成されます。プライマリ・データベースとスタンバイ・データ

ベースは、単一ノードあるいは RAC 環境で動作できます。スタンバイ・データベー

スは、Local Area Network (LAN)、Metropolitan Area network (MAN)、Wide Area

Network (WAN)などの標準的 TCP/IP ベースのネットワークによって、Oracle Net

Services を使用してプライマリ・データベースに接続します。データベース同士の

通信が可能であれば、設置場所に関する制約はありません。ただし、障害時リカ

バリを考慮した場合、スタンバイ・データベースはプライマリ・データベースか

ら地理的に離れた場所へ設置することを推奨します。 Oracle Data Guard には、プライマリ・

データベースに対するスタンバイ・デー

タベースの設置場所に関して、距離の制

限がありません。 Oracle Data Guard では、プライマリ・データベースとスタンバイ・データベース

のオペレーティング・システム・アーキテクチャは同じでなければなりません。

したがって、プライマリ・データベースが Intel アーキテクチャで LINUX のオペ

レーティング・システムを使用している場合、そのスタンバイ・データベースも

すべて Intel と LINUX でなければなりません。この場合、たとえば、Windows シ

ステムは使用できません。また、ロジカル・スタンバイ・データベースを使用し

てのローリング・データベース・アップグレードの場合を除き（詳細については"

ローリング・データベース・アップグレード"の項を参照）、プライマリ・データ

ベースとすべてのスタンバイ・データベースに、同じリリースの Oracle Database

Enterprise Edition をインストールする必要があります。


10


保護モードと REDO トランスポート

Oracle Data Guard には、コスト、可用性、パフォーマンス、トランザクション保

護のバランスを取る、高水準のデータ保護モードが 3 種類用意されています。こ

れらのモードは、使用可能な管理インタフェースによって簡単に設定できます。

たとえば、プライマリ・データベース上で次のような単純な SQL文を実行します。

ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY | PERFORMANCE};

適切なデータ保護モードを決定するには、企業はデータ保護に関する自社のビジ

ネス要件と、システム応答時間に対するユーザー・ニーズとを十分に検討する必

要があります。次の表は、データ消失リスクの観点から見た、各モードの適合性

をまとめたものです。

保護モード障害発生時のデータ消失リスク REDO トランスポート・メカニズム

大保護データ損失ゼロ同期（LGWR SYNC）

大可用性データ損失ゼロ同期（LGWR SYNC）

大パフォーマンス

小限度のデータ消失 - 通常は数秒非同期（LGWR ASYNC）または

ARCH

以下のセクションでは、これら 3 種類の保護モードについて詳しく説明します。

最大保護モード

大保護モードはプライマリ・データベースに対する高レベルのデータ保護で

あり、データ損失ゼロの包括的な障害時リカバリ・ソリューションとなります。

大保護モードで動作している場合、REDO レコードは LGWR プロセスによって

（LNS プロセス経由で）、プライマリ・データベースからスタンバイ・データベー

スに同期転送され、トランザクション・データが少なくとも 1 台のスタンバイ・

サーバーのディスクで使用可能であることが確認されるまで、プライマリ・デー

タベース上のトランザクションはコミットされません。このモードは、スタンバ

イ・データベースが 2 つ以上の場合に構成することを強く推奨します。後に参

加したスタンバイ・データベースが使用不能となった場合、処理はプライマリ・

データベース上で停止します。これによって、すべてのスタンバイ・データベー

スとの接続が消失した後にプライマリ・データベースで障害が発生した場合でも、

トランザクションが失われることはありません。

REDO 送信が同期的に実行されることから、この大保護モードはプライマリ・

データベースの応答時間に影響を及ぼす可能性があります。こうした影響は、ト

ランザクションのピーク負荷に対して十分な帯域幅を備えた、待機時間の短い

ネットワークを構築することで小限に抑えることができます。大保護モード

を必要とするビジネスの例としては、証券取引所、外国為替取扱業者、金融機関

などがあります。

最大可用性モード

大可用性モードは、プライマリ・データベースのデータ可用性に関して、2 番


11


目に高いレベルです。大保護モードの場合と同様に、REDO データは、LGWRプロセスによってプライマリ・データベースからスタンバイ・データベースに同

期転送され、トランザクション・データが少なくとも 1 台のスタンバイ・サーバー

のディスクで使用可能であることが確認されるまで、プライマリ・データベース

上のトランザクションがコミットされることはありません。ただし、大保護モー

ドと異なり、後に参加したスタンバイ・データベースがネットワーク接続の問

題などで使用不能となった場合、処理はプライマリ・データベース上で続けられ

ます。スタンバイ・データベースは一時的にプライマリ・データベースよりも遅

れることになりますが、再び使用可能になったときにはプライマリ・データベー

スに蓄積されたアーカイブ・ログを使用して、自動的にプライマリ・データベー

スと同期化され、データ消失は生じません。

REDO が同期転送されるため、この保護モードは応答時間とスループットに影響

する可能性があります。こうした影響は、トランザクションのピーク負荷に対し

て十分な帯域幅を備えた、待機時間の短いネットワークを構築することで小限

に抑えることができます。

大可用性モードは、データ損失ゼロを確実にする保護を必要とするものの、本

番データベースがネットワークやスタンバイ・サーバーの障害によって影響を受

けることを望まないビジネスに適しています。初のネットワーク/スタンバイ・

サーバーの障害が解決する前に、別の障害によって本番データベースが大きな影

響を受ける場合は、データ損失が発生する可能性があります。

最大パフォーマンス・モード

大パフォーマンス・モードはデフォルトの保護モードです。大可用性モード

に比べ、プライマリ・データベースに対する保護レベルは若干低くなりますが、

パフォーマンスは高度に維持できます。このモードでは、トランザクションはプ

ライマリ・データベースで処理され、REDO データは LGWR プロセスによって非

同期的にスタンバイ・データベースに送られます。あるいは、プライマリ・デー

タベースのアーカイバ・プロセス（ARCH）を設定して、このモードで REDO デー

タを送信できます。どちらの場合も、プライマリ・データベースのコミット操作

は、スタンバイ・データベースが受信を確認するのを待たずに、書込み動作を完

了させます。いずれかのスタンバイ宛先が使用不能になった場合も、処理はプラ

イマリ・データベースで続行されるので、パフォーマンスへの影響はほとんどあ

るいはまったくありません。

プライマリ・データベースに障害が発生した場合、まだスタンバイ・データベー

スに送られていなかった REDO データは失われます。ただし、ネットワークのス

ループットが十分大きく、REDO トラフィックのピークに対応でき、スタンバイ・

サーバーへの送信に LGWR プロセスが使用されている場合、トランザクション消

失の件数はごくわずかかゼロになります。

大パフォーマンス・モードは、プライマリ・データベースの可用性やパフォー

マンスが、多少のデータを失うリスクよりも重要な場合に使用します。また、ネッ

トワーク固有の待機時間が、同期 REDO 送信の適合性を制限するような WAN 上

の Oracle Data Guard の配置にも適しています。


12


Oracle Database 10g Release 2 の REDO トランスポートの強化

Oracle Database 10g Release 2 では、REDO トランスポート・アーキテクチャにいく

つかの重要な拡張機能が追加されました。ログ･ライター・プロセス（LGWR ASYNC）

を使用した非同期 REDO 送信の間、各スタンバイ・データベースのネットワーク・

サーバー（LNSn）プロセスによって、Oracle Database 10g Release 1 以前のように

ASYNC バッファを使用する代わりに、プライマリ・データベース上のオンライン

REDO ログ・ファイルから REDO データが送信されます。そのため、LGWR を使

用した非同期 REDO 送信は、ASYNC バッファのサイズに制限されません。また、

大ネットワーク送信サイズも 1MB から 10MB に増え、大きな負荷がかかった状

態でのネットワーク利用が大きく改善されます。

ARCH ベースの転送では、複数のアーカイバ・プロセスによって、REDO データ

を 1 つのアーカイブ済み REDO ログ・ファイルからスタンバイ・データベースへ

パラレルに転送できます。この操作は、LOG_ARCHIVE_DEST_nパラメータの新

しい属性 MAX_CONNECTIONSから指定します。使用できる ARCH プロセスの

大数（LOG_ARCHIVE_MAX_PROCESSES初期化パラメータで指定する）も 10 か

ら 30 に増えました。これらの機能拡張によって、バッチ・アップロードなどのピー

ク・アクティビティ中でも、アーカイブ済み REDO データからスタンバイ・デー

タベースへ適切に転送できます。

Redo Apply と SQL Apply

スタンバイ・データベースは、初にプライマリ・データベースのバックアップ・

コピーから作成されます。一度作成された後は、Oracle Data Guard によってプラ

イマリ・データベースからスタンバイ・データベースに REDO データが送信され、

スタンバイ・システムに適用されることで、スタンバイ・データベースは、プラ

イマリ・データベースとトランザクションの整合性があるコピーとして自動的に

保守されます。

Oracle Data Guard には、この REDO データをスタンバイ・データベースに適用し

た、プライマリ・データベースとのトランザクションの整合性を維持する方法が

2 つ用意されており、それぞれ Oracle Data Guard がサポートする 2 種類のスタン

バイ・データベースに対応しています。

• REDO Apply は、フィジカル・スタンバイ・データベースに使用されます。

• SQL Apply は、ロジカル・スタンバイ・データベースに使用されます。

図 4 に示されているように、プライマリ・データベースからの REDO データ送信

という点に関しては、この 2 種類のスタンバイ・データベースに違いはありませ

ん。一度 REDO データがスタンバイ・サーバーに送信されると、この 2 種類のス

タンバイ・データベースでは、REDO データがスタンバイ・データベースに適用

される方法が異なります。


13


フィジカル・スタンバイ・データベース - REDO Apply

フィジカル・スタンバイ・データベースは、Oracle メディア・リカバリを使用し

てプライマリ・データベースから受け取った REDO データを適用することで、プ

ライマリ・データベースとの同期が維持されます。ブロック単位で見た場合、ス

タンバイ・データベースはプライマリ・データベースと同一であり、インデック

スを含むデータベース・スキーマも同じになります。

REDO Apply の動作

Oracle Data Guard の REDO Apply では、管理リカバリ・プロセス（MRP）と呼ば

れる特殊なプロセスが使用されます。MRP は、RFS プロセスで書き込まれたスタ

ンバイ REDO ログ（SRL)から REDO データを直接読み取り、それをフィジカル・

スタンバイ・データベースに適用します。MRP は、データベースをマウントして、

以下のコマンドを実行することで、フィジカル・スタンバイ・データベース上で

起動されます。

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

また、MRP が SRL の読取りを完了する前に SRL がアーカイブされた場合、MRP は

アーカイブ済みのスタンバイ・ログの読取りに透過的に切り替わります（この状況は、

プライマリ・データベースの REDO 生成率がきわめて高い場合に生じます）。

MRP はパラレルで実行され、Data Guard REDO Apply のベスト・パフォーマンス

を達成できます。Oracle Database 10g 以前のリリースでは、上記の RECOVER

MANAGED STANDBY DATABASEコマンドで PARALLEL句を使用する必要があり

ました。Oracle Database 10g では、MRP の起動時に、パラレル・リカバリ処理の

適な数が（PARALLEL句のリクエストなしで）自動的に決定され、その数は、

スタンバイ・サーバーの使用可能な CPU 数に基づいています[5]。

フィジカル・スタンバイ・データベース

は読取り専用としてオープンでき、その

時、フィジカル・スタンバイ・データベー

スに対して問合せを実行できます。

フィジカル・スタンバイ・データベースは読取り専用としてオープンでき、フィ

ジカル・スタンバイ・データベースに対して問合せを実行できます。読取り専用

として開かれたフィジカル・スタンバイ・データベースでは、同時にリカバリを

実行できません。読取り専用でオープンしているとき、スタンバイ・データベー

スに送信された REDO データはスタンバイ・サイトに蓄積されますが、適用はさ

れません。ただし、リカバリ操作はいつでもフィジカル・スタンバイ・データベー

ス上で再開することができ、蓄積された REDO データは自動的に適用されます。

そのため、フィジカル・スタンバイ・データベースは、まず短時間のリカバリを

実行し、次に読取り専用でオープンしてレポートを実行でき、リカバリに戻って、

未処理の REDO データを適用するといったシーケンスを実行できます。

フィジカル・スタンバイを読取り専用でオープンするには、以下のコマンドを使

用してリカバリをスタンバイで取り消す必要があります。

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

次に、データベースを読取り専用でオープンします。

ALTER DATABASE OPEN;


14


スタンバイ・データベースを、REDO Apply を実行するフィジカル・スタンバイ・

データベースに戻すには、アクティブなユーザー・セッションを終了し、ALTER

DATABASE RECOVER MANAGED STANDBY DATABASEコマンドで MRP を再スター

トさせます。

Oracle Database 10g Release 2 の REDO Apply の強化

Oracle Database 10g Release 2 で、Oracle Data Guard とフラッシュバック・データ

ベースを組み合わせて使用することで、フィジカル・スタンバイ・データベース

を一時的に読取り/書込みモードでオープンし、開発、レポートあるいはテスト目

的に使用できます。その後、過去のある時点までフラッシュバックさせて、フィ

ジカル・スタンバイ・データベースに戻すことができます。データベースのフラッ

シュバック後、Oracle Data Guard は、スタンバイ・データベースとプライマリ・

データベースを自動的に同期します。プライマリ・データベースのバックアップ・

コピーから、再度フィジカル・スタンバイ・データベースを作成する必要はあり

ません。

この操作を行うコマンドは、SQL*Plus を通じて次のように簡単に指定できます。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; SQL>

CREATE RESTORE POINT t1 GUARANTEE FLASHBACK DATABASE;

SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;

<ここでレポートの読取り/書込みを行います。> SQL> FLASHBACK DATABASE TO RESTORE POINT t1;

SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

フィジカル・スタンバイ・データベースは、読取り/書込みモードでオープンして

いる間、プライマリ・データベースからの REDO データの受け取りや適用を行い

ません。また、障害に対する保護機能も使用できない点に注意してください。こ

のような場合に、障害に対する保護機能を引き続き使用するには、別のスタンバ

イ・データベースが必要になります。

フィジカル・スタンバイ・データベースの利点

フィジカル・スタンバイ・データベースには次の利点があります。

"Oracle Data Guard に関してもすばら

しい点は、管理性と信頼性、それに使い

やすさです。サポートする担当者を増や

すことなく、障害時リカバリおよび高可

用性ソリューションを簡単に実装できる

というのは驚きでした。 "- Sun Microsystems 社、Sun Services Global Engineering 部門、Database Services 担

当スタッフ・エンジニア、Darl Kuhn

• 障害時リカバリと高可用性 - フィジカル・スタンバイ・データベースは、堅

牢で効率的な障害時リカバリおよび高可用性ソリューションを可能にします。

管理が容易なスイッチオーバー機能とフェイルオーバー機能によって、プラ

イマリ・データベースとフィジカル・スタンバイ・データベースとの間での

ロール切替えが簡単に実行でき、計画停止や計画外停止によるプライマリ・

データベースの停止時間を小限に抑えることができます。

• データ保護 - フィジカル・スタンバイ・データベースを使用することで、

Oracle Data Guard は、予想外の障害に遭遇した場合でも、データ消失がないこ

とを保証します。フィジカル・スタンバイ・データベースは、あらゆるデー

タ型のほか、プライマリ・データベースがサポート可能な DDL オペレーショ

ンや DML オペレーションをサポートします。また、データ破損やユーザー・

エラーに対する予防策も用意しています。プライマリ・データベース上で発


15


生した、ストレージ・レベルの物理データ破損がスタンバイ・データベース

に波及することはありません。同様に、プライマリ・データベースの恒久的

損傷を引き起こすおそれのある論理データ破損やユーザー・エラーも解消で

きます。また、REDO データは、スタンバイ・データベースでの受け取りと

適用が終了した時点で検証が行われます。

• プライマリ・データベース・ワークロードの軽減 - フィジカル・スタンバイ・

データベースは、レポートや問合せのために読み取り専用でオープンでき、読

取り/書込みのアクティブ・データベースに簡単に切り替えられます。さらに、

Oracle Recovery Manager（RMAN)を使用すれば、フィジカル・スタンバイ・デー

タベースを使用して本番データベースのバックアップを作成し、それによって

本番システムの貴重なCPUおよび I/Oサイクルを節約できます。RMANは、フィ

ジカル・スタンバイ・データベースがリカバリを実行しているか、読取り専用

でオープンしている間に、このバックアップを実行できます。

• パフォーマンス - フィジカル・スタンバイ・データベースで使用している

REDO Apply テクノロジは、低レベル・リカバリ・メカニズムを使用して変更

を適用します。これは、すべての SQL レベル・コード階層をバイパスするた

め、変更の適用にも効率的なメカニズムです。その結果、REDO Apply テク

ノロジは、トランザクション上の整合性を有した、プライマリ・データベー

スのコピーを保守するきわめて効率的なメカニズムになります。

ロジカル・スタンバイ・データベース - SQL Apply

ロジカル・スタンバイ・データベースは、プライマリ・データベースとデータの

物理編成と物理構造は異なりますが、同じ論理情報を持っています。SQL Apply

テクノロジは、プライマリ・データベースから受け取った REDO データを SQL 文

に変換し、それをスタンバイ・データベースで実行することによって、ロジカル・

スタンバイ・データベースとプライマリ・データベースとの同期を維持します。

その結果、SQL を適用すると同時に、問合せやレポートのためにロジカル・スタ

ンバイ・データベースにアクセスできます。

ロジカル・スタンバイ・データベースは SQL 文を使用して更新されるため、読取

り/書込みモードでオープンの状態です。また、プライマリ・データベースから更

新中の表は、同時にレポート、総和、問合せなど、他のタスクに使用できます。

これらのタスクは、保守されている表に追加索引およびマテリアライズド・ビュー

を作成することで適化できます。ロジカル・スタンバイ・データベースは、複

数のデータベース・スキーマをホストでき、ユーザーは、プライマリ・データベー

スから更新されていないスキーマで、表に通常のデータ操作を実行できます。

ロジカル・スタンバイ・データベースの場合、データ型、表のタイプ、DDL オペ

レーションと DML オペレーションのタイプに制約があります。サポートされて

いないデータ型やストレージ属性については、[1]を参照してください。

SQL Apply の動作

SQL Apply では、プライマリ・データベースからロジカル・スタンバイ・データ

ベースに変更を適用したタスクを実行するパラレル実行サーバーとバックグラウ

ンド・プロセスのコレクションが使用されます。次の図に、情報の流れと各プロ

セスが実行するロールを示します。


16


トランザクションにグループ化されていない論理変更レコード

プライマリ・データベースからの REDO

データ

Reader

REDO レコード

Preparer

共有プール

Builder

ログ検索

適用プロセス

トランザクション・グループ

データファイル Applier適用される

トランザクション依存性の順にソート

されたトランザクション

Coordinator Analyzer

図 5：Oracle Data Guard SQL Apply プロセス・アーキテクチャ

以下に各プロセスの機能を説明します。

• Reader プロセスでは、スタンバイ REDO ログまたはスタンバイ・アーカ

イブ・ログから送られてくる REDO レコードを読み取ります。

• Preparer プロセスでは、ブロック変更を表変更つまり論理変更レコード

（LCR）に変換します。この時点で、LCR は具体的なトランザクションを

表しているわけではありません。

• Builder プロセスは、個々の LCR から完了したトランザクションをまとめ

ます。

• Analyzer プロセスでは、完了したトランザクションを検査し、異なるトラ

ンザクション間の依存関係を識別します。

• Coordinator プロセス（ロジカル・スタンバイ・プロセスまたは LSP とも

呼ばれます）では、トランザクションを適用プロセスに割り当て、トラ

ンザクション間の依存関係を監視し、ロジカル・スタンバイ・データベー

スへの変更のコミットを許可します。

• Applier プロセスでは、割り当てられたトランザクションの LCR をデータ

ベースに適用し、Coordinator からの指示でトランザクションをコミット

します。

これらのさまざまな SQL Apply プロセスは、次のシンプルな SQL コマンドをロジ

カル・スタンバイ・データベースに入力して、開始できます。

ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

SQL Apply を実行する一方で、ロジカル・スタンバイ・データベースを読取り/書

込みモードでオープンできるため、SRL から直接 REDO データをロジカル・スタ

ンバイ・データベースへ同期転送および適用し、ロジカル・スタンバイ・データ

ベースをリアルタイムのレポート作成ソリューションとして使用できます。これ

は、障害に対する保護以外のビジネス用途における Oracle Data Guard 活用方法を

示すものです。


17


Oracle Database 10g Release 2 のアーカイブ済みログの自動削除

Oracle Database 10g Release 2 のロジカル・スタンバイ・データベースでは、SQL

Apply によって適用されるアーカイブ済み REDO ログ・ファイルは自動的に削除

されます。その結果、ロジカル・スタンバイ・データベースでのスペース管理が

強化できます。

DBA_LOGMNR_PURGED_LOGビューは、必要のなくなった削除候補のアーカイブ

済み REDO ログ・ファイルを表示します。管理者がこの削除プロセスを制御しよ

うとする場合、ロジカル・スタンバイ・パラメータ LOG_AUTO_DELETEを FALSE

に設定することで、デフォルトの自動削除動作を変更できます。ロジカル・スタンバイ・データベースは、

表がプライマリ・データベースから更新

されると同時にオープンでき、それらの

表は同時に読取りアクセスに使用でき

ます。

ロジカル・スタンバイ・データベースの利点

ロジカル・スタンバイ・データベースは、障害時リカバリ、高可用性、データ保

護の点で、フィジカル・スタンバイ・データベースと同じような利点を備えてい

ます。さらに、次の特別な利点があります。

• スタンバイ・ハードウェア・リソースの効率的使用 - ロジカル・スタンバイ・

データベースは、障害時リカバリ要件以外のビジネス目的にも使用できます。

Oracle Data Guard 構成で保護されるデータベース・スキーマに加え、その他の

データベース・スキーマをホストでき、ユーザーはそうしたスキーマで、い

つでも DDL オペレーションや DML オペレーションを実行できます。Oracle

Data Guard によって保護されているロジカル・スタンバイ表は、プライマリ・

データベース以外の物理レイアウトに保存することができるため、追加索引

やマテリアライズド・ビューを作成して、問合せパフォーマンスを向上させ、

具体的なビジネス要件に適合させることができます。

• プライマリ・データベース・ワークロードの軽減 - ロジカル・スタンバイ・

データベースは、その表がプライマリ・データベースから更新される間、同

時にオープンでき、それらの表は同時に読取りアクセスに使用できます。そ

のため、ロジカル・スタンバイ・データベースをデータ保護とレポートの両

方に同時に使用でき、プライマリ・データベースをレポート作成や問合せタ

スクから解放し、貴重な CPU および I/O サイクルを節約できます。


18


Oracle Enterprise Manager と Oracle Data Guard Broker

Oracle Data Guard Broker は、Oracle Data Guard 構成の作成、メンテナンス、監視を

自動化および一元化する、分散型管理フレームワークです。すべての管理操作は、

Oracle Data Guard Broker を使用する Oracle Enterprise Manager か、Oracle Data Guard

Broker の特殊コマンドライン・インタフェース（DGMGRL）を介して実行できま

す。次のスクリーンショットは、Oracle Enterprise Manager の Oracle Data Guard ホー

ムページです。

図 6：Oracle Enterprise Manager による Oracle Data Guard 構成

次のリストに、Oracle Data Guard Broker によって自動化および簡略化される操作

の例を示します。

• 1 つのプライマリ・データベースと大 9 つのスタンバイ（フィジカルまたは

ロジカル）データベースを含む Oracle Data Guard 構成を作成および有効化し

ます。これらのデータベースの全部または一部を組み合わせて、RAC クラス

タを構成できます。

• Oracle Data Guard 構成にある任意のサイトからの Data Guard 構成全体を管理

します。

• Oracle Data Guard 構成の全システムで、複雑なロール変更を含むスイッチオー

バーまたはフェイルオーバー（ファスト・スタート・フェイルオーバーを含

む）を実装します。

• 一元的監視およびイベント通知によって、適用率を監視し、診断情報を取得

し、問題を迅速に検出します。


19


Oracle Data Guard Broker の使いやすいインタフェースと Data Guard 構成の一元化

された管理および監視によって、Oracle Data Guard は、企業の高可用性およびデー

タ保護に関する強化されたソリューションとなります。

Oracle Database 10g Release 2 の管理強化

Oracle Database 10g Release 2 では、Oracle Data Guard はさまざまな拡張ビューを提

供し、Data Guard 構成のランタイム・パフォーマンスを詳細に監視します。これ

らのビューには、SQL*Plus、DGMGRL、または Oracle Enterprise Manager からア

クセスできます。

Oracle Enterprise Manager は、監視する Data Guard メトリックに関する傾向分析の

履歴、たとえば、過去 24 時間あるいは過去 5 日間のメトリック・パフォーマンス

の推移など、新しい機能が用意されています。また、Oracle Enterprise Manager を

介して通知アラームの設定もできるため、メトリックが設定されたしきい値に達

した場合、管理者は通知を受けられます。

Oracle Enterprise Manager の監視対象となる Data Guard のメトリックには次のよう

なものがあります。

• 推定フェイルオーバー時間 - このスタンバイ・データベースへフェイルオー

バーするために必要なおおよその秒数。

• 適用ラグ - スタンバイ・データベースがプライマリ・データベースからどれ

くらい遅れているかが示されます。

• REDO 適用率 - スタンバイで REDO が適用される率。

• REDO 生成率 - スタンバイ・データベースで REDO が生成される率。

• 転送ラグ - このスタンバイ・データベースでまだ使用できない REDO のおお

よその秒数。これは、REDO がまだ送信されていないか、ギャップがあるた

めです。

• Oracle Data Guard ステータス - Oracle Data Guard 構成にある各データベース

のステータスが示されます。

• ファスト・スタート・フェイルオーバー発生 - ファスト・スタート・フェイ

ルオーバーが有効に設定されている場合、ファスト・スタート・フェイルオー

バーが発生すると、このメトリックによって新しいプライマリ・データベー

ス（旧スタンバイ・データベース）に重要なアラートが発信されます（ファ

スト・スタート・フェイルオーバーの詳細については、"ファスト・スタート・

フェイルオーバー"の項を参照してください）。

• ファスト・スタート・フェイルオーバー時間 - ファスト・スタート・フェイ

ルオーバーが有効に設定されている場合、ファスト・スタート・フェイルオー

バーが発生すると、このメトリックによって新しいプライマリ・データベー

ス（旧スタンバイ・データベース）に重要なアラートが発信され、発生のタ

イム・スタンプが表示されます。


20


ロール移行 - スイッチオーバーとフェイルオーバー

Oracle Data Guard には、本番サイトにおける計画停止と計画外停止に対処するた

めの、使いやすい方法が 2 種類用意されています。どちらの手段も、指定された

スタンバイ・データベースを可能な限り迅速に本番ロールに移行することを目的

としています。この 2 つの手段は、スイッチオーバーおよびフェイルオーバーと

呼ばれ、それぞれ計画停止と計画外停止にどのように対処するかを示します。 Oracle Data Guard には、本番サイトにお

ける計画停止と計画外停止に対処するた

めの、使いやすい方法が 2 種類用意され

ています。スイッチオーバー

通常、スイッチオーバーは、オペレーティング・システムやハードウェア・アッ

プグレード、Oracle データベース・ソフトウェア、およびパッチ・セットのロー

リング・アップグレードなどの計画停止で、プライマリ・データベースの停止時

間を短縮するために使用します。また、障害時リカバリの準備をテストする際に

使用する場合もあります。

スイッチオーバーを実行するには、プライマリ・データベースからすべてのユー

ザー・セッションを切断する必要があります。その後、プライマリ・データベー

スはスタンバイ・ロールに移行し、スタンバイ・データベースがプライマリ・ロー

ルに移行します。

スイッチオーバーは、Oracle Enterprise Manager GUI インタフェースあるいは

Oracle Data Guard Broker のコマンドライン・インタフェースを使用するか、SQL

を直接介して、管理者が開始します。

たとえば、下記の Oracle Data Guard Broker CLI（DGMGRL）コマンドによって、

スタンバイ・データベース"StandbyChicago"へのスイッチオーバーを開始し、完了

します。

DGMGRL> SWITCHOVER TO StandbyChicago;

上述したように、管理者はスイッチオーバーの際、ターゲット・スタンバイ・デー

タベースを指定しなければなりません。スイッチオーバーが開始されると、実際

のロール移行プロセスは自動的に実行されます。プロセスの間にデータが失われ

ることはありません。

ターゲットがロジカル・スタンバイ・データベースの場合、スイッチオーバーの

後に新旧のプライマリ・データベースの再起動は不要です。また、Oracle Data Guard

構成内にある他のロジカル・スタンバイ・データベースをシャットダウンして再

起動する必要もありません。スイッチオーバー完了後も、そうした他のロジカル・

スタンバイ・データベースは正常に機能し続けます。ただし、既存のフィジカル・

スタンバイ・データベースは、スイッチオーバー後に Oracle Data Guard 構成に参

加できないことが示され、フィジカル・スタンバイとしてのロールを継続するに

は、新しいプライマリ・データベースのバックアップからあらためて作成する必

要があります。

ターゲットがフィジカル・スタンバイ・データベースの場合、古いプライマリ・

データベースはスイッチオーバー後に再起動し、（新しいスタンバイ・データベー

スとして）マウントする必要があります。Oracle Database 10g Release 2 では、フィ

ジカル・スタンバイ・データベースであったときに読取り専用でオープンされた

ことがない旧スタンバイ・データベースであれば、再起動する必要はありません。


21


読取り専用でオープンされたことがある場合は、いったん停止し、新しいプライ

マリ・データベースとして読取り/書込み用としてオープンできるように再起動す

る必要があります。構成内にあるその他のスタンバイ・データベースは、フィジ

カル・データベースでもロジカル・データベースでも、いったん停止し再起動を

行う必要はありません。

また、スイッチバックという用語は、Oracle Data Guard のロール管理の領域でも

使用されることがあります。スイッチバック操作とは、スイッチオーバー後にデー

タベースを元のロールに戻すための操作です。

スイッチバック操作とは、スイッチオー

バー後にデータベースを元のロールに戻

すための操作です。フェイルオーバーの種類

フェイルオーバーとは、プライマリ・データベースで予想外の壊滅的障害が発生

し、プライマリ・データベースを迅速にリカバリできる可能性がない場合に、1

つのスタンバイ・データベースを新しいプライマリ・データベースとして作動さ

せる操作です。

Oracle Database 10g Release 2 の Data Guard に関しては、手動フェイルオーバーと

ファスト・スタート・フェイルオーバーという 2 種類のフェイルオーバー操作が

あります。手動フェイルオーバーは、Oracle Enterprise Manager GUI インタフェー

スあるいは Data Guard Broker のコマンドライン・インタフェースを使用するか、

SQL*Plus を直接介して、管理者が開始します。ファスト・スタート・フェイルオー

バーでは、プライマリ・データベースが使用できなくなり、データ消失の危険が

ない場合、あらかじめ指定してあったスタンバイ・データベースへ自動的にフェ

イルオーバーします。ファスト・スタート・フェイルオーバーによって、管理者

は手動で操作せずに可用性を高めることができるため、管理コストの削減や停止

時間の短縮が可能になります。手動フェイルオーバーでは、管理者はフェイルオー

バー・プロセスをより細かく制御できます。たとえば、データ消失の可能性があ

る場合であっても、手動フェイルオーバーを実行できます。

手動フェイルオーバー

手動フェイルオーバーの処理は、新たにプライマリ・データベースになるスタン

バイ・データベースから開始されます。たとえば、下記の Data Guard Broker CLI

（DGMGRL）コマンドによって、スタンバイ・データベース"StandbyChicago"への

フェイルオーバーを開始し、完了できます。

DGMGRL> FAILOVER TO StandbyChicago;

ターゲットがロジカル・スタンバイ・データベースの場合、フェイルオーバー後

に新しいプライマリ・データベースを再起動する必要はありません。Data Guard

構成内の他のロジカル・スタンバイ・データベースは、フラッシュバックして同

期化するか、新しいプライマリ・データベースのバックアップから新たに作成す

ることが必要になります。構成内の他のフィジカル・スタンバイ・データベース

は互換性を失うので、新しいプライマリ・データベースのバックアップから新た

に作成することが必要になります。

ターゲットがフィジカル・スタンバイ・データベースの場合、そのスタンバイ・

データベース（つまり、新しいプライマリ・データベース）は、後に起動した


22


後で読取り専用でオープンされていなければ、再起動する必要はありません。読

取り専用でオープンされたことがある場合は、いったん停止し、新しいプライマ

リ・データベースとして読取り/書込み用としてオープンして、再起動する必要が

あります。構成内にあるその他のスタンバイ・データベースは、フィジカル・デー

タベースでもロジカル・データベースでも、フェイルオーバー時点でターゲット

のスタンバイ・データベースよりも"トランザクション"が進んでいない限り、いっ

たん停止して再起動を行う必要はありません。トランザクションが進んでいる場

合は、フラッシュバックして同期化する、または新しいプライマリ・データベー

スのバックアップから新たに作成することが必要になります。

Oracle Data Guardが大保護モードまたは大可用性モードで動作していて、フェ

イルオーバーの時点でターゲット・スタンバイ・データベースが同期化されてい

る場合、手動フェイルオーバーによって、データ損失ゼロが保証されます。大

パフォーマンス・モードでは、フェイルオーバーの時点で、まだスタンバイに送

られず、プライマリ・データベースに残っている REDO データがあった場合、そ

のデータは消失する場合があります。

次の図に、サンフランシスコにあるプライマリ・データベースからボストンにあ

るフィジカル・スタンバイ・データベースにフェイルオーバーを行った結果を示

します。

プライマリ・データベース

オンライン

REDO ログ

ローカル・アーカイブ

アーカイブ済み

REDO ログ

アプリケーションアプリケーション

サンフランシスコ

ボストン

読取り/書込み

トランザクション

スタンバイ・データ

ベースがプライマリ・

データベースにオンライン

REDO ログ

ローカル・アーカイブ

アーカイブ済み

REDO ログ読取り

専用レポート

図 7：スタンバイ・データベースへのフェイルオーバー

ファスト・スタート・フェイルオーバー

ファスト・スタート・フェイルオーバーは、プライマリ・データベースが消失し

た場合に、フェイルオーバーを手動で起動することなく、あらかじめ選択および

同期化されたスタンバイ・データベースへ自動的にフェイルオーバーする機能で

す。プライマリ・データベースが障害から回復した場合、新しいプライマリ・デー

タベースのスタンバイとして自動的に構成に復帰します。ファスト・スタート・

ファスト・スタート・フェイルオーバー

では、手動による介入なしに、指定され

たスタンバイ・データベースへのフェイ

ルオーバーが自動的に実行されます。


23


フェイルオーバーは、Oracle Data Guard Broker 構成内でのみ使用でき、DGMGRL

または Oracle Enterprise Manager からのみ構成できます。

ファスト・スタート・フェイルオーバー構成は、別のオブザーバ・プロセスによっ

て監視されます。このオブザーバ・プロセスは、DGMGRL クライアント側コンポー

ネントに統合された軽量プロセスです。プライマリ・データベースやスタンバイ・

データベースとは異なるコンピュータで実行する必要があります。ファスト・ス

タート・フェイルオーバー環境を継続的に監視し、プライマリ・データベースが

使用可能であることを確認します。オブザーバおよびスタンバイ・データベース

の両方がプライマリ・データベースとの接続を失うと、オブザーバはファスト・

スタート・フェイルオーバーを開始する前に、設定可能な時間の範囲でプライマ

リ・データベースとの再接続を試みます。

前提条件と管理

ファスト・スタート・フェイルオーバーを使用するには、Oracle Data Guard Broker

が構成に対して有効化されていることが必要です。また、フラッシュバック・デー

タベースが有効で、プライマリ・データベースと指定されたスタンバイ・データ

ベースで、フラッシュ・リカバリ領域が構成されていることが必要です。構成内

にある他のスタンバイ・データベースについても、フラッシュバック・データベー

スとフラッシュ・リカバリ領域を構成することを推奨します。また、フェイルオー

バーによってデータ損失が発生しないようにするため、データ保護モードは大

可用性に設定してください。オブザーバ・プロセスでは、構成を監視できるよう

に、オブザーバ・マシンとプライマリおよびスタンバイ・サーバーとの間にネッ

トワーク接続が必要です。

ファスト・スタート・フェイルオーバーを有効にするには、1 つのスタンバイ・

データベースをターゲットとして指定する必要があります。この指定には、Oracle

Data Guard Broker のプロパティ、FastStartFailoverTarget、または Oracle

Enterprise Manager を使用します。次に、管理者は、ファスト・スタート・フェイ

ルオーバーを開始する前に、オブザーバが元のプライマリ・データベースへの再

接続をどの程度の時間試みるかを設定する必要があります。これは、Oracle Data

Guard Broker のプロパティ、FastStartFailoverThreshold、または Oracle

Enterprise Manager によって、時間（秒単位）を指定することで実行します。後

に、構成に対してファスト・スタート・フェイルオーバーを有効化します。この

操作は、Oracle Enterprise Manager または以下の DGMGRL によって実行します。

DGMGRL> ENABLE FAST_START FAILOVER;

これで、Oracle Enterprise Manager またはシンプルな DGMGRL コマンドを使用し

て、オブザーバ・プロセスが開始でき、ファスト・スタート・フェイルオーバー

構成の監視が開始されます。

DGMGRL> START OBSERVER;

次の図は、ファスト・スタート・フェイルオーバー中のプライマリ・データベー

ス、ターゲット・スタンバイ・データベース、オブザーバの関係を示しています。


24


ファスト・スタート・フェイルオーバー前

ファスト・スタート・フェイルオーバー作動

ファスト・スタート・フェイルオーバー後

オブザーバオブザーバオブザーバ

Oracle インスタンス・プライマリ・データベース

Oracle インスタンス・スタンバイ・データベース

Oracle インスタンス・プライマリ・データベース

Oracle インスタンス・スタンバイ・データベース

データベースデータベースデータベースデータベースデータベースデータベース

図 8：オブザーバ、プライマリ・データベース、スタンバイ・データベース間の相互作用

• ファスト・スタート・フェイルオーバーの前：Oracle Data Guard は安定した状

態で作動し、プライマリ・データベースは REDO データをターゲット・スタ

ンバイ・データベースに送信して、オブザーバは構成全体の状態を監視して

います。

• ファスト・スタート・フェイルオーバー作動：障害が発生し、プライマリ・

データベースとネットワーク接続が影響を受け、オブザーバとターゲット・

スタンバイ・データベースが切断されます。通信の中断を検出すると、オブ

ザーバはファスト・スタート・フェイルオーバーを開始する前に、

FastStartFailoverThreshold プロパティで定義された時間、プライマリ・データ

ベースとの接続回復を試みます。オブザーバが所定の時間内にプライマリ・

データベースとの接続が回復できず、ターゲット・スタンバイ・データベー

スの準備が整っている場合、ファスト・スタート・フェイルオーバーが開始

されます。

• ファスト・スタート・フェイルオーバーの後：ファスト・スタート・フェイ

ルオーバーが完了し、ターゲット・スタンバイ・データベースがプライマリ・

データベースとして作動しています。元のプライマリ・データベースが修復

されると、オブザーバが接続を確立し、そのデータベースを新しいスタンバ

イ・データベースとして構成に戻します。新しいプライマリ・データベース

から新しいスタンバイ・データベースに REDO データの送信が開始されます。その洗練されたアーキテクチャによっ

て、ファスト・スタート・フェイルオー

バーは、データ保護が重要な意味を持つ、

完全自動の高可用性状況で使用される有

力な候補となります。

ファスト・スタート・フェイルオーバー構成のステータスは、Oracle Enterprise

ManagerまたはV$DATABASEビューのFS_FAILOVER_STATUS列から常に監視で

きます。たとえば、大可用性モードにあるプライマリ・データベースがスタン

バイ・データベースから切断され、オブザーバとの接続は保持されている場合、

スタンバイ・データベースはプライマリ・データベースと同期化していません。

このことは、FS_FAILOVER_STATUS列の"UNSYNCHRONIZED"という値によって

確認できます。ファスト・スタート・フェイルオーバーでは、常にデータ損失ゼ

ロが保証されるため、このケースではファスト・スタート・フェイルオーバーは

実行不可能であり、手動フェイルオーバーが必要になります。

ファスト・スタート・フェイルオーバーは、プライマリ・データベース、スタン

バイ・データベース、オブザーバという 3 つの構成メンバー中少なくとも 2 つが


25


主要な状態移行に同意する場合に実行されるよう設計されており、異なる 2 つの

プライマリ・データベースが本番ワークロードを処理するスプリット・ブレイン・

シナリオのような状況を回避しています。そのシンプルで洗練されたアーキテク

チャによって、ファスト・スタート・フェイルオーバーは、データ保護が重要な

意味を持つ、完全自動の高可用性状況で使用される有力な候補となります。

新しいスタンバイ・データベースとしての旧プライマリ・データベースの

リストア

フェイルオーバーの後、古いプライマリ・データベースを新しいスタンバイ・デー

タベースとしてリストアし、構成のデータ保護機能を再開することが必要な場合

があります。

Oracle9i のこの再生作業は、新しいプライマリ・データベースのバックアップから

古いプライマリ・データベースを新しいスタンバイ・データベースとして作成し

なおす以外に方法がありませんでした。Oracle Database 10g Release 1 では、フェイ

ルオーバー以前に、Oracle Database 10g のフラッシュバック・データベース機能が

古いプライマリ・データベースで有効化されていて、プライマリ・データベース

が RAC データベースでない場合、この時間のかかるプロセスを回避できます。実

際の操作は、古いプライマリ・データベースを（V$DATABASEビューの

STANDBY_BECAME_PRIMARY_SCN列に記録された）フェイルオーバーが実行さ

れた時点までフラッシュバックし、スタンバイ・データベースとして起動し、さ

らに Oracle Data Guard によって、この新しいスタンバイ・データベースを新しい

プライマリ・データベースと同期させます。

Oracle Database 10g Release 2 では、RAC を含む Data Guard 構成に対する上記プロ

セスのサポートが追加され、自動化が一段と強化されました。ファスト・スター

ト・フェイルオーバーが有効な場合、古いプライマリ・データベースが修復され

て再起動し、オブザーバとのネットワーク接続が回復すると、オブザーバは直ち

にフラッシュバック・データベースを透過的に使用して、マニュアル介入なしに

構成内の新しいスタンバイ・データベースとして自動的に回復します。ファスト・

スタート・フェイルオーバーが有効でない場合、古いプライマリ・データベース

を新しいスタンバイ・データベースとして回復する作業は、Oracle Enterprise

Manager または以下の DGMGRL コマンドを使用して実行できます。

DGMGRL> REINSTATE DATABASE boston_old_primary;

ロール移行イベント

Oracle Database 10g Release 2 では、接続されていたデータベースがプライマリ・

ロールでも本番ロールでも機能しなくなった場合、Oracle Data Guard のロール変

更によってイベントをポストし、管理者によるロール変更タスクのポストを自動

化して、アプリケーションに通知するのを支援します。具体的には、システム・

イベント DB_ROLE_CHANGEと、FAN（Fast Application Notification、[6]参照）の

イベントの DB_DOWNがポストされます。この 2 つの新しいイベントが、クライア

ント・アプリケーションの指定されたスタンバイ・データベースへのフェイルオー

バーを支援します。


26


システム・イベント DB_ROLE_CHANGEは、新しいロールに関係なく、ロール移

行後にデータベースが初にオープンしたとき起動されます。ロール変更によっ

て読取り専用モードで初にオープンしたときのロールが、プライマリ・データ

ベースかロジカル・スタンバイ・データベースかフィジカル・スタンバイ・デー

タベースかどうかは関係ありません。管理者は、このイベントを実行するトリガー

を記述して、ロール変更後のタスク（新しいプライマリ・データベースでのサー

ビス開始や一時的表領域の追加など）を管理します。

DB_DOWNイベントは、Oracle Data Guard Broker を介してフェイルオーバー処理が

行われる場合にポストされます。ポストを実行するのは、古いプライマリ・デー

タベースに代わってプライマリ・ロールを実行しているデータベースです。これ

は、OCI クライアントに通知する FAN イベントで、プライマリ・ロールのデータ

ベースが停止または使用不能となった場合に、このイベントをサブスクライブし

ます。そのため、サイト障害の場合と同様、アプリケーションは、TCP タイムア

ウト期間が経過するまで待つことなく、通知を受け取った後ただちに新しいプラ

イマリ・データベースに接続できます。

通信障害の対応

Oracle Data Guard では、プライマリ・データベースから（フィジカルまたはロジ

カル）スタンバイ・データベースへの接続が一時的に切断されるといったネット

ワーク接続問題にスムーズに対処できます。動作は Oracle Data Guard の保護モー

ドで決定されます。

大保護モードでは、後のスタンバイ・データベースが使用できなくなると、

プライマリ・データベースは停止されます。その他の場合、トランザクションは

プライマリ・データベースでローカルに取得されます。スタンバイ・データベー

スへの接続が回復すると、プライマリ・データベースとの同期が確立されるまで、

蓄積されたアーカイブ・ログが自動的にスタンバイ・データベースに送られ、適

用されます。このプロセスは、管理者による介入は必要ありません。プライマリ・

データベースの周辺でネットワーク障害が頻繁に起こる場合は、こうした再同期

化に十分なネットワーク容量の確保を推奨します。

人的エラーによるデータ破損からの保護

プライマリ・データベースがオープンでアクティブであり、トランザクションが

進行中の場合、REDO データが生成され、スタンバイ・データベースに送られま

す。人的エラーがシステム停止の主要原因であることを考慮すると、この REDO

データに、重要な表の欠損やその他の論理データの破損といった深刻な論理ユー

ザー・エラーが含まれている可能性があり、すでにプライマリ・データベースで

論理的に破損している可能性があります。

Oracle Data Guard では、このようなユーザー・エラーを防止するための簡単な手

段をいくつか用意しています。管理者は、Oracle Database 10g のフラッシュバッ

ク・データベース機能をプライマリとスタンバイの両データベースに使用して、

データベースを以前の状態に戻し、ユーザー・エラーを取り消すことができます。

あるいは、管理者がスタンバイ・データベースへのフェイルオーバーを決定した

ものの、ユーザー・エラーがすでにスタンバイ・データベースにも適用されてい


27


る場合、管理者はスタンバイ・データベースを過去の安全な時点までフラッシュ

バックできます（スタンバイ・データベースでフラッシュバック機能がすでに有

効化されていることが前提です）。さらに、管理者は、設定可能な時間の範囲で、

REDO データのスタンバイ・データベースへの適用を遅らせることができるため、

ユーザー・エラーやデータ破損に対する予防措置として利用できます。

どの手段を選択しても、スタンバイ・データベースへの適用プロセスは、常にロ

グ・レコードの再検証を実行して、破損した物理 REDO データのスタンバイ・デー

タベースへの適用を防止します。

ローリング・データベース・アップグレード

Oracle Database 10g では、主要リリースやパッチセット・アップグレードについて、

Data Guard SQL Apply を使用したデータベース停止時間のほとんどないローリン

グ方式によるデータベース・ソフトウェア・アップグレードをサポートしていま

す（Oracle Database 10g 以降）。これには、ロジカル・スタンバイ・データベース

の新リリースへのアップグレード、混合モードでのアップグレードのテストと検

証、アップグレード済みデータベースへのスイッチオーバーによるロール切替え、

旧プライマリ・データベースのアップグレードという手順が含まれます。テスト

のために混合モードで作動している間、データを消失することなく、アップグレー

ドを中止し、ソフトウェアをダウングレードできます。上記の手順中、さらにデー

タ保護を強化するには、第 2 のスタンバイ・データベースを使用する方法があり

ます。

次の図は、ローリング・アップグレード・プロセスにおけるイベントの順序を示

したものです。

クライアント REDO

バージョン X バージョン X

初期 SQL Apply 構成ノード B の X+1 へのアップグレード

アップグレード

ログ・キュー

REDOアップグレード

テストのため混合モードで実行

REDO

B へのスイッチオーバー、A のアップグレード

パッチセット・アップグレード

主要リリース・アップグレード

クラスタ、ソフトウェア、ハードウェアのアップグレード

Oracle Data Guard は、主要リリースや

パッチセット・アップグレードについて、

データベース停止がほとんどないローリ

ング方式によるデータベース・ソフト

ウェア・アップグレードをサポートして

います。

図 9：SQL Apply を使用したローリング・データベース・アップグレード

停止時間を小限度に抑えたローリング・アップグレードによって、多くの管理

タスクに必然的に伴う大きなメンテナンス時間枠を短縮し、365 日 24 時間の業務

態勢を可能にします。


28


REDO ログ宛先のカスケード

Oracle Data Guardには柔軟性に優れた多くの構成オプションが用意されています。

REDO ログ宛先のカスケードを使用することで、スタンバイ・データベースは、

元のプライマリ・データベースではなく、他のスタンバイ・データベースから

REDO データを受け取ります。プライマリ・データベースは、スタンバイ・デー

タベースのサブセットに対してのみ REDO データを送るため、この機能はプライ

マリ・システムの負荷やネットワーク・トラフィックを軽減し、プライマリ・サ

イトでの貴重なネットワーク・リソースの使用を減少させます。これは、複数の

スタンバイ・データベースが配置されている場合、さまざまな障害時リカバリお

よびレポート作成要件に対応する上でも有効です。

Oracle Data Guard と RAC

Oracle Data Guard と RAC は相互補完の関係にあります。RAC はシステムやインス

タンスの障害に対応します。ノード障害やインスタンス・クラッシュなど、デー

タに影響しない障害からの迅速な自動リカバリです。また、アプリケーションの

スケーラビリティ強化にも役立ちます。一方、Oracle Data Guard は、トランザク

ションの整合性のあるプライマリ・データベースとスタンバイ・データベースを

使用することでデータを保護するものであり、ディスクの共有やロック手順での

実行は必要ありません。そのため、サイト障害やデータ破損からのリカバリが可

能になります。

また Oracle Data Guard には初から RAC が統合されています。つまり、プライマ

リ/スタンバイ・データベース（フィジカルまたはロジカル）の一部またはすべて

を RAC データベースにでき、Oracle Enterprise Manager か Oracle Data Guard Broker

のコマンドライン・インタフェースを使用するか、SQL から直接管理できます。

高可用性と障害時リカバリの利点を大限にするには、Oracle Data Guard と RAC

を組み合わせて使用することが必要です。オラクルの最大可用性アーキテクチャ

は、実績のあるオラクルの高可用性テク

ノロジと実際の顧客への配布実績に基づ

くものであり、最適な高可用性テクノロ

ジの設計に伴う複雑さを排除し、システ

ム可用性を最大限にすることを目的とし

ています。

Maximum Availability Architecture

使用できるシステム機能が増えるにつれ、IT 管理者、アーキテクト、管理者にとっ

て、一連の適切な機能を統合してビジネス要件のすべてを満たす統一された高可

用性（HA）ソリューションの構築は困難になります。Oracle Maximum Availability

Architecture（MAA）は、オラクルの実証済み高可用性テクノロジと推奨事項に基

づいたオラクルのベスト・プラクティス構想です。MAA の目標は、適な高可用

性アーキテクチャの設計から複雑さを排除し、システム可用性を大限にするこ

とです。

MAA には、次のような利点があります。

• MAA は、詳細な構成ガイドラインを提供して、可用性の高い Oracle システム

の実装コストを削減します。さまざまな構成におけるパフォーマンス・イン

パクトの調査結果では、選択された高可用性アーキテクチャが企業のニーズ

に応じて機能し、拡張できることが明らかになりました。


29


• MAA は、人的エラー、システム障害、クラッシュ、保守、データ障害、破損、

災害などの計画停止および計画外停止による停止時間を排除または小限に

抑えるためのベスト・プラクティスとリカバリ手順を提供します。

• MAA は、障害発生時に、停止からの復旧時間の長さと、容認できるデータ損

失量を管理する機能を備えており、特定のビジネス要件に合わせて平均リカ

バリ時間（MTTR）をカスタマイズできます。

Oracle Data Guard は MAA の重要コンポーネントであり、MAA ガイドラインには、

Data Guard 構成に関するベスト・プラクティス推奨事項（[7]参照）が記載され、

RAC と Data Guard の両方を含む構成や、REDO データ送信メカニズム、スイッチ

オーバー/フェイルオーバー、メディア・リカバリ、SQL Apply 構成、ネットワー

ク構成などが説明されています。Oracle Data Guard の実装に関しては、この MAA

ベスト・プラクティス・ガイドラインの参照を強く推奨します。

Oracle Data Guard とリモート・ミラー化ソリューション

リモート・ミラー化ソリューションは、一般的にシンプルで完全なデータ保護を

実現する手段として認識されています。リモート・ミラー化ソリューションには

次の 2 種類があります。

(a)ホスト・ベース・レプリケーション、(b)ストレージ・アレイ・ベースのミラー化

ホスト・ベース・レプリケーションのソリューションでは、プライマリ・サーバー

の特殊ファイル・システム・ドライバやボリューム・マネージャ・コンポーネン

トが、ローカルの書込みを阻止し、論理メッセージにパッケージ化し、IP を通じ

てリモート（セカンダリ）ホストへ同期または非同期で送信します。このような

ソリューションでは、書込み順序を追跡するための特殊なログを保守する必要が

あります。セカンダリ・サーバーのデータ・ボリュームは、レプリケーションの

実行中では、読取り専用アクセスであっても使用できません。

ストレージ・アレイ・ベースのミラー化ソリューションでは、プライマリ・サイ

トのストレージ・アレイ・コントローラが、変更されたディスク I/O ブロックを、

セカンダリ・サイトの類似のストレージ・アレイにミラー化します。近のバー

ジョンでは iSCSI や IP ベース送信もサポートされていますが、こうした変更は、

ESCON、FICON、Fibre Channel などのプロトコルを使用して送信されます。適切

な通信リンクによるミラー化は、適切なファームウェアがロードされている特殊

なリンク・アダプタによって管理されています。I/O がプライマリ・サーバーで発

生すると、データはソース・アレイのキャッシュに書き込まれ、キューに配置さ

れます。リンク・アダプタがキューの初のエントリを受け取り、リンクを介し

てミラー化されたアレイにそのエントリを移動させます。

こうしたソリューションはデータ・センターで使用されていますが、Oracle データ

ベースの保護という点に関しては、Oracle Data Guard の方がリモート・ミラー化ソ

リューションよりも本質的に効率がよく、費用もそれほどかからないので、データ

保護に適しています。Oracle データベースを保護するために、リモート・ミラー化

ソリューションを購入したり、Oracle Data Guard と統合したりする必要はありませ

ん。次に、リモート・ミラー化ソリューションと比較した Oracle Data Guard の利点

を説明します。さらに詳細な分析については、[8]を参照してください。


30


• 優れたネットワーク効率

Oracle Data Guard では、REDO データのみをリモート・サイトに送信する必要

があります。ただし、データ保護にリモート・ミラー化ソリューションを使

用している場合、データベース・ファイル、オンライン・ログ、アーカイブ・

ログ、制御ファイルをミラー化する必要があります。つまり、リモート・ミ

ラー化では、各変更事項は少なくとも 3 回リモート・サイトに送られること

になります。さらに、通常、ログの書込みには多数の変更（グループ・コミッ

ト）を伴うため、ログの書込みよりもデータベースへの書込みの方がはるか

に多くなります。したがって、データベース REDO 送信ベース・ソリューショ

ンに必要なネットワーク帯域幅は、リモート・ミラー化ソリューションの帯

域幅に比べるとかなり小さくなります。さらに重要なことは、これがネット

ワーク・ラウンド・トリップの回数が大幅に少なくなることを意味している

という点です。

リモート・ミラー化はデータベース・ファイル以外のファイルには非常に便

利です。しかし、データベースのデータについては、より優れた保護機能と

より低コストを兼ね備えている点で、Oracle Data Guard の方が有効です。次の

図に示すように、オラクルの社内 E メール・システムの内部分析では、Oracle

Data Guard を使用した場合に比べ、リモート・ミラー化ソリューションを使

用した場合、7 倍のデータがネットワークを介して送信され、27 倍の I/O 操

作が実行されたことが判明しました。

Oracle Data Guard

リモート・ミラー化

ネットワーク帯域幅

ネットワーク I/O

図 10：ネットワーク・パフォーマンス/Oracle Data Guard 対リモート・ミラー化

• WAN に対する適性

ストレージ・システムをベースとするリモート・ミラー化ソリューションは、

ストレージ・システムで使用されている基本的通信技術（Fibre、ESCON）の

ため、距離的制約を受ける場合が頻繁にあります。この距離は、サード・パー

ティ・ベンダーの特殊装置を用いることで延ばすことができます。そうした

装置によって、ESCON/Fibre を適切な IP、ATM、あるいは SONET ネットワー

クに変換します。問題は、そのような装置によってシステムに待機時間が生

じ、本番データベースのパフォーマンスが影響を受け、データ損失ゼロを達

成するために必要な同期転送に不適切な構成になってしまう点です。この問


31


題は、通信パスに中間ストレージ・ボックスを設置することで軽減できます

が、総コストが上昇します。もう 1 つの解決策は、同期転送の使用がありま

すが、リモート・ミラー化ソリューションに依存する場合、データの同期転

送以外は、データベースが保存されているミラー化されたボリュームすべて

の書込み順序を保持できません。つまり、そのような構成では、常にデータ

整合性を保証することができず、OLTP データのデータ保護/障害時リカバ

リ・ソリューションとしては不向きです。

Oracle Data Guard では、標準的 IP ネットワークを使用して、REDO データだ

けをスタンバイ・サイトに送信し、すべての保護モード（同期または非同期

の転送モードのいずれでも）に関してトランザクションの整合性を維持し、

高額の中間ストレージ・ボックスを必要としないため、WAN のための障害時

リカバリおよびデータ保護ソリューションとしてはるかに優れています。

• 優れた回復力とデータ保護

Oracle Data Guard プロセスでは、プライマリ・データベースから情報を読み取

り、書き込むための、データ・フォーマットが認識されます。さらに、Oracle

Data Guard は、フラッシュバック・データベース機能と統合されており、変

更の適用を遅らせることもできます。こうした機能は、多くの人的エラーや

データ破損が、他に波及したりスタンバイ・データベースに影響したりする

のを防ぎます。リモート・ミラー化にはこうした利点はありません。重要な

表を不注意に削除しても、すぐにデータベース・ファイルのリモート・コピー

に波及して悪影響を及ぼします。

• ROI の向上

Oracle Data Guard を使用して変更内容を伝播する一方で、スタンバイ・データ

ベースをレポート作成用にオープンできます。これは、リモート・ミラー化

ソリューションで必ずしも実行できるわけではありません。Oracle Data Guard

は、Oracle データベースの機能として標準装備されており、すぐに使用でき

ます。しかし、リモート・ミラー化ソリューションは別途購入する必要があ

り、データベースとの統合という複雑な作業が必要です。また、リモート・

ミラー化ソリューションの多くは独自仕様であるため、（プライマリ・サイ

トとセカンダリ・サイトの両方において）リモート・ミラー化ソリューショ

ンと同じベンダーのストレージ・システムでしか使用できません。一方、Oracle

Data Guard は、プライマリ・サイトとセカンダリ・サイトの両方において、

特定のストレージ・ソリューションの使用を強制しません。

Oracle Data Guard の顧客

Oracle Version 7 から導入された Oracle Data Guard は、世界各国の主要な顧客の

ミッション・クリティカルなアプリケーションに使用されています。Oracle Data

Guard を高可用性ソリューションおよび障害時リカバリ・ソリューションとして

実装した顧客一覧と、詳細な実装の事例を[9]に示します。顧客の成功例として、

次のようなものがあります。


32


顧客事例

Ohio Savings Bank Oracle Database 10g – Maximum Availability Architectureおよび

データ損失ゼロ

Oracle Global IT WAN上でOracle Data Guardを使用したOracle E-Business Suite

ADT Security Services

WANを介したOracle Data Guard SQL Applyの使用

Amadeus Oracle Data Guardを使用した障害時リカバリおよびローリング・

データベース・アップグレード

Fannie Mae Oracle Data Guard POC：Oracle Database 10gで、1 秒間に 835 トラ

ンザクションとデータ損失ゼロ保護をサポート

First American Real Estate Solutions

Oracle9i Data Guardの使用およびOracle Database 10gのData Guard新機能に対する計画

Kemira GrowHow Ltd, UK

アウトソーシングしていた障害時リカバリ・サービスをOracle Data Guardに切替え

NeuStar 300 マイル離れた本番データベースとスタンバイ・データベースに

同期データ損失ゼロ保護を導入

Swedish Post Oracle Data Guard SQL Applyのレポート機能を使用した障害時リ

カバリ・システムの拡張

VP Bank Oracle Data Guard SQL Applyを使用した企業のファイアウォール

外へのコンテンツ配置

世界中のさまざまな産業界を代表する組織で使用されている Oracle Data Guard に

関するこれらの成功例は、ビジネス継続性における Oracle Data Guard の包括的な

機能を実証します。

結論

Oracle Data Guard は、企業にデータ保護、障害時リカバリ、高可用性を提供する

包括的ソリューションです。計画停止と計画外停止の両方に対処する、柔軟性に

優れた管理しやすいフレームワークを提供します。フィジカル・スタンバイ・デー

タベースとロジカル・スタンバイ・データベースは相互に補完し合う関係にあり、

同時にメンテナンスを実行できます。プライマリ・データベースのオーバーヘッ

ドを軽減する一方で、高付加価値のデータ保護機能を提供します。各種データ保

護モードによって、保護、パフォーマンス、インフラストラクチャに関するさま

ざまな要件に適合した柔軟性を備えています。Oracle Data Guard Broker と Oracle

Enterprise Manager を組み合わせることで、構成と管理のための使いやすいフレー

ムワークが提供されます。

"データの安全な保管を検討しなければ

なりませんでしたが、同時にコストにも

注意する必要がありました。Oracle Data Guard は、他社製品よりも低コストで、

高度な可用性ソリューションに必要なす

べてがそろっていました。" – First American Real Estate Solutions社、Technical Director、Ann Collins

現代の企業は、このホワイト・ペーパーで取り上げたようなテクノロジなく、ミッ

ション・クリティカルなサービスをお客様に提供することはできません。完全で、

統合され、容易な管理で、多目的に対応できる、あらゆる企業データを保護する

ものでなければなりません。同時に、データ保護テクノロジや障害時リカバリ・

テクノロジは高価であってはならず、パフォーマンスにひどく影響を及ぼすもの

であってもなりません。さらに、企業に障害時リカバリ投資からの付加価値を提

供できることが必要です。Oracle Data Guard は、こうしたニーズのすべてに応え

ることができる、現在利用可能な唯一のソリューションです。


33


参考資料

1. 『Oracle Data Guard 概要および管理』

http://otndnld.oracle.co.jp/document/products/oracle10g/102/doc_cd/nav/portal_4.ht

m

2. 『Oracle 高可用性ベスト・プラクティス』


m

3. 概要：Oracle Database High Availability –

http://otn.oracle.co.jp/products/availability/index.html

4. 『Oracle Database バックアップおよびリカバリ基礎』


m

5. Oracle Database 10g Best Practices: Data Guard Redo Apply and Media Recovery,

http://otn.oracle.co.jp/products/availability/htdocs/maa.html

6. 『Oracle Database Oracle Clusterware および Oracle Real Application Clusters 管

理およびデプロイメント・ガイド』


m

7. Oracle Maximum Availability Architecture,

http://otn.oracle.co.jp/products/availability/htdocs/maa.html

8. The Right Choice for Disaster Recovery: Data Guard, Stretch Clusters or Remote

Mirroring,

http://otn.oracle.co.jp/products/availability/techlisting.html

9. Oracle High Availability Case Studies （英語）,

http://www.oracle.com/technology/deploy/availability/htdocs/HA_CaseStudies.html


34


Oracle Database 10g Release 2 の Oracle Data Guard エンタープライズ環境でのビジネスの継続 2006 年 11 月著者：Ashish Ray 共著者：Joseph Meeks Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問合せ窓口：電話：+1.650.506.7000 ファクシミリ：+1.650.506.7200 www.oracle.com Copyright © 2005, Oracle.All rights reserved. 本文書は情報提供のみを目的として提供されており、ここに記載される内容は

予告なく変更されることがあります。本文書は一切間違いがないことを保証す

るものではなく、さらに、口述による明示または法律による黙示を問わず、特

定の目的に対する商品性もしくは適合性についての黙示的な保証を含み、いか

なる他の保証や条件も提供するものではありません。オラクル社は本文書に関

するいかなる法的責任も明確に否認し、本文書によって直接的または間接的に

確立される契約義務はないものとします。本文書はオラクル社の書面による許

可を前もって得ることなく、いかなる目的のためにも、電子または印刷を含む

いかなる形式や手段によっても再作成または送信することはできません。

Oracle、JD Edwards、および PeopleSoft は、オラクル社およびその子会社、関

連会社の登録商標です。その他の名称はそれぞれの会社の商標です。

Documents

Oracle Database 10g Release 2のOracle Data Guardエンタープラ …otndnld.oracle.co.jp/deploy/availability/pdf/TWP_DataGuard_10gR2.pdf · Oracle Corporation発行「Oracle Data