ファスト・スタート・フェイルオーバーのベスト・プラクティス：Oracle Data Guard 10g Release 2

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

のベスト・プラクティス：Oracle Data

Guard 10g Release 2

Oracle Maximum Availability Architecture ホワイト・ペーパー

2007 年 1 月

Maximum

Availability

Architecture

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

プラクティス Oracle Data Guard 10g Release 2

概要 ... 3

ファスト・スタート・フェイルオーバー構成の要素... 3

ファスト・スタート・フェイルオーバーの構成... 5

ファスト・スタート・フェイルオーバーをトリガーするイベント... 6

ファスト・スタート・フェイルオーバー後の回復... 6

オラクルのテスト結果 ... 7

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

Oracle ベスト・プラクティス ... 7

本番データベースの構成... 7

ネットワーク転送... 8

スタンバイの構成... 8

オブザーバ... 9

ファスト・スタート・フェイルオーバーのしきい値 ... 11

監視... 11

フラッシュバック・データベースの構成 ... 12

複数スタンバイによる構成... 12

ファスト・スタート・フェイルオーバーに適したアプリケーション... 13

自動クライアント・フェイルオーバー... 13

DB_ROLE_CHANGE イベント ... 14

結論 ... 14

参考資料 ... 15

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

プラクティス Oracle Data Guard 10g Release 2

概要

ファスト・スタート・フェイルオーバーは、Oracle Data Guard 10g Release 2 [1]の 機能です。この機能によって、本番データベースが消失した場合、指定された同 期のスタンバイ・データベースへの迅速で確実なフェイルオーバーが自動的に行 われます。手動操作なしにフェイルオーバーを開始します。 さらに、ファスト・スタート・フェイルオーバーに続いて、構成へ再接続する際 に、元の本番データベースが新しいスタンバイ・データベースとして自動的に再 構成されます。この機能によって、Data Guard は構成内で障害保護を素早く簡単 にリストアできるので、データベースはすばやく保護された状態に復帰します。 このホワイト・ペーパーでは、ファスト・スタート・フェイルオーバーと、Maximum Availability Architecture (MAA) [2]のベスト・プラクティスの使用方法を説明します。 手動フェイルオーバーと計画的なスイッチオーバーのベスト・プラクティスについ て詳しくは、『Oracle Data Guard 10g Release 2, Switchover and Failover Best Practices』

[3]を参照してください。

ファスト・スタート・フェイルオーバー構成の要素

ファスト・スタート・フェイルオーバーは、Oracle Data Guard Broker の管理下にある Data Guard 構成で使用されます。Oracle Data Guard Broker によって、Data Guard 構成が 集中管理されます。また、コマンドライン・インタフェース（DGMGRL）を使用 して、単一のコマンドで複数の SQL*Plus 文と同等の作業を行い、Data Guard 構成 の管理を大幅に簡素化します。Oracle Data Guard Broker は、Oracle Data Guard に含 まれているので、個別にインストールする必要はありません。

ファスト・スタート・フェイルオーバーは、DGMGRL または Oracle Enterprise Manager 10g Grid Control のいずれかによって管理されます。Oracle Enterprise Manager は、監視 と制御のための使いやすいグラフィカル・ユーザー・インタフェースを提供し、1 つ 以上の Data Guard 構成を集中管理できます。

ファスト・スタート・フェイルオーバー構成には、次の 3 つの重要な要素（図 1） が含まれます。 • 本番データベース • ターゲット・スタンバイ・データベース • ファスト・スタート・フェイルオーバー・オブザーバ ターゲット・スタンバイ・データベースは、ファスト・スタート・フェイルオー バーの後、新しい本番データベースになります（注：Data Guard 構成では、複数 のスタンバイ・データベースを構成できますが、ファスト・スタート・フェイル オーバーのターゲットとして指定できるのは、ただ 1 つです。構成内の他のスタ ンバイ・データベースへのフェイルオーバーを実行するには、手動のフェイルオー バーが必要です）。 オブザーバは、DGMGRL クライアントに組み込まれた独立したプロセスであり、 本番データベースとターゲット・スタンバイ・データベースに障害を引き起こす 条件がないかどうかを継続的に監視します。 ルールでは、これら 3 つの要素（本番データベース、スタンバイ・データベース、 オブザーバ）のうち、いずれか 2 つが相互に通信することによって、ファスト・ スタート・フェイルオーバーの発生が決定されます。たとえば、本番データベー スが使用不能になった場合、オブザーバは、本番データベースが使用不能である ことと、ターゲット・スタンバイ・データベースが本番データベースと同期され ていることを、ターゲット・スタンバイ・データベースに確認します。確認が取 れると、ターゲット・スタンバイ・データベースへのファスト・スタート・フェ イルオーバーが開始されます。このような確認が行われない場合、ファスト・ス タート・フェイルオーバーは発生しません。

これによって、ファスト・スタート・フェイルオーバーの 2 つの重要な特性が保 証されます。 • 自動的なフェイルオーバーによって、ファスト・スタート・フェイルオー バー構成内で 1 つ以上のデータベースが同時に本番ロールを担うことは ありません。これによって、ファスト・スタート・フェイルオーバー構 成内で、1 つのデータベースのみがトランザクションの受け入れを保証し、 一般に"スプリット・ブレイン"と呼ばれるシナリオが回避されます。 • ファスト・スタート･フェイルオーバーは、データが消失しないと確定し たときのみ発生します。

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

ファスト・スタート・フェイルオーバーの構成および有効化について詳しくは、 ドキュメント『Data Guard Broker』[4]および『Oracle Data Guard Concepts and Administration』[5]を参照してください。高度な手順を次に示します。 • 本番データベースおよびLGWR SYNC REDO転送サービスの最大可用性保 護モードを使用して構成された、少なくとも 1 つのスタンバイ･データ ベースを含むData Guard構成から開始します。本番データベースとスタン バイ・データベースの両方で、フラッシュバック・データベースとフラッ シュ・リカバリ領域を有効にします。 • 3 番目のシステムをオブザーバ・ホストに指定します。このホストには DGMGRL ユーティリティがインストールされているので、本番データ ベースおよびスタンバイ・データベースの両方で Oracle Net 接続を確立で きる必要があります。オブザーバが、本番データベースおよびスタンバ イ・データベースとは異なるデータセンターに配置されたホスト上で実 行されるのが理想的です。これが不可能な場合、オブザーバをスタンバ イ・データベースとは別のシステム上のスタンバイ・ロケーションに配 置し、スタンバイ・データベースに影響を与える可能性のあるイベント から、可能な限り切り離します。オブザーバ・ホストには、Oracle インス タンスをインストールする必要はありません。 • Data Guard リアルタイム適用を使用して、フェイルオーバー時間を最小限 に抑えることを推奨します。そうすることで、スタンバイ・データベー スは、本番データベースから受信した最新の REDO によって最新の状態 が維持されます。また、スタンバイ・データベースが受信した REDO の 適用を完了するまで待つことで発生するフェイルオーバーの遅延が排除 されます。 • フェイルオーバー・ターゲットであるデータベースのDB_UNIQUE_NAMEを入 力して、ファスト・スタート・フェイルオーバーのターゲットを構成し ます。 • フェイルオーバーのしきい値を設定します。フェイルオーバーのしきい 値は、オブザーバがフェイルオーバーを開始する前に、本番データベー スへの再接続を試行する秒数です。フェイルオーバーのしきい値に最も 適切な値を設定する方法は後述します。

• Oracle Enterprise Manager または DGMGRL を使用して、ファスト・スター ト・フェイルオーバーを有効にし、オブザーバを起動します。

ファスト・スタート・フェイルオーバーをトリガーするイベント

ファスト・スタート・フェイルオーバーは、データベースが次の状態になった場 合に実行されます。

• データベース・インスタンス障害（RAC 構成では最後のインスタンス障害）

• Shutdown Abort（RAC 構成では最後のインスタンスの shutdown abort） • I/O エラーによるデータファイルのオフライン化 ファスト・スタート・フェイルオーバーは、ネットワークが次の状態になった場 合に実行されます。 • オブザーバとスタンバイ・データベースの両方で本番データベースへの ネットワーク接続が切断された場合、スタンバイ・データベースが"同期 化された"状態であることを確認した場合。

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

多くの場合、ファスト・スタート・フェイルオーバー後やフェイルオーバーを引 き起こした問題が解決された後、管理者は元の本番データベースを再起動できま す。このため、オブザーバは、ファスト・スタート・フェイルオーバー後に元の 本番データベースへの再接続を定期的に試行します。元の本番データベースへの ネットワーク・アクセスを回復すると、オブザーバは、自動的に新しい本番デー タベースのスタンバイ・データベースとして復帰するよう、Oracle Data Guard Broker に対して要求を開始します。これによって、障害保護と新しい本番データ ベースの高可用性が早急に回復します。

ファスト・スタート・フェイルオーバー後の元の本番データベースのオープンを 制御する対策が取られています。管理者が STARTUP コマンドを使用して、元の 本番データベースをオープンしようとすると、Oracle Data Guard Broker は、他の ファスト・スタート・フェイルオーバーの少なくとも 1 つがこの遷移に同意しな い限り、元の本番データベースのマウント状態からオープン状態への移行を許可 しません。これは、ファスト・スタート・フェイルオーバーがすでに発生してお り、構成内に新しい本番データベースがあるため、元の本番データベースは、オ ブザーバまたはターゲット・スタンバイ・データベース（現在の新しい本番デー タベース）から確認を得られないからです。こうして、スプリット・ブレインの シナリオが回避されます。 管理者がSTARTUP MOUNTコマンドを使用して元の本番データベースを起動しよ うとしても、エラー・メッセージは生成されません。オブザーバは、自動的に元 の本番データベースをData Guard構成内で新しいスタンバイ・データベースとして 復元します。 管理者がSTARTUP NOMOUNTコマンドを使用して元の本番データベースを起動し ようとしても、元の本番データベースはマウントされません。Oracle Data Guard Brokerは、さらに管理アクションが実行されるまで（元の本番データベースのマ ウントなど）、回復を実行しません。

オラクルのテスト結果

オラクルでは、本番データベース、スタンバイ・データベース、オブザーバ（い ずれも Redhat Linux 3.0 を実行）で構成されるファスト・スタート・フェイルオー バー構成をテストしました。テストの結果を次の図 2 に示します。 テスト・データベースのサイズは、それぞれ 100GB でした（注：フェイルオーバー のタイミングは、データベースのサイズに影響されません）。各ホストは、ギガ ビット・ネットワークで隣のホストに接続されました。本番データベースのワー クロードは、REDO データを 3MB/秒の速度で生成しました。シングル・インスタ ンス・データベースとマルチ・インスタンスの RAC 構成をテストしました。テス トした構成には、フィジカル・スタンバイ・データベース（REDO Apply）および ロジカル・スタンバイ・データベース（SQL Apply）へのフェイルオーバーが含ま れています。すべてのケースで、フェイルオーバーのしきい値（オブザーバが、 障害が発生したと宣言してフェイルオーバーを開始する前に、本番データベース からの応答を待つ時間であり、ユーザーによる設定が可能）は、フェイルオーバー 時間の計算に含まれていません。テストでは、実際のデータベースのフェイルオー バーを完了するために必要な時間のみを測定しました。フェイルオーバーを完了 する合計時間は 10～25 秒で、これは構成によって異なります。

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

Oracle ベスト・プラクティス

本番データベースの構成

ファスト・スタート・フェイルオーバーでは、LGWR SYNC AFFIRM REDO転送を 使用して、Data Guard構成を最大可用性保護モードに設定する必要があります。最 大可用性は、本番データベースをネットワーク障害またはスタンバイ・サーバー の障害から分離します（このような障害は自動的に検出され、本番データベース は処理を続行します）。ただし、REDO送信には同期という性質があるので、本 番データベースのパフォーマンスがネットワークの遅延やスタンバイ・システム のディスクI/Oの影響を受ける可能性があります。

これは、本番データベースが、本番サーバーとスタンバイ・サーバーの両方のディ スクに REDO が書き込まれたという通知を受けるまで、データベース・クライア ントに COMMIT を返さないからです。ファスト・スタート・フェイルオーバーを 使用する場合は、ネットワーク帯域幅と遅延が、同期の REDO 送信に適応してい る必要があります。

ネットワーク転送

Oracle Data Guard のネットワーク・スループットに影響を与えるオペレーティング・ システム・パラメータをチューニングすると、最大可用性構成をサポートするネッ トワークの機能が大幅に向上します。 これらのパラメータには、TCP/受信バッファ、およびカーネル・ネットワーク・ サブシステムとネットワーク・インタフェース・カードのドライバ間のバッファ・ サイズを指定する設定が含まれています。オラクルが行ったテストから、ワーク ロードの大きいアプリケーションをチューニングすることの重要性が明らかにな りました。テストでは、TCP 送信/受信バッファ、デバイス・ネットワークのキュー・ サイズおよび SDU（Oracle Net Services セッション・データ・ユニット）をチュー ニングするだけで、スループットが大幅に向上しました。図 3 にこのチューニング の結果を示します。詳しくは、『Data Guard Primary Site and Network Best Practices』 [9]を参照してください。

スタンバイの構成

フェイルオーバー時間を最短にするには、スタンバイ・データベースにスタンバイ REDO ログ（SRL）とリアルタイム適用の両方を構成する必要があります。

これによって、フィジカル・スタンバイ上の管理リカバリ・プロセス、またはロ ジカル・スタンバイ上の SQL Apply プロセスが有効になり、本番データベースで ログ・スイッチを待たずに、受信した REDO がすぐにスタンバイ・データベース に適用されます。こうして、スタンバイ・データベースに本番データベースの最 新の状態が反映され、フェイルオーバー時に必要な処理が最小限に抑えられます。 ピーク時に大量のREDOが生成されるData Guard構成の場合、受信するREDOに合わせた 適用処理を実行するには、デフォルト設定では不十分です。『Oracle Database 10g Release 2 High Availability Best Practices』[6]に記載されているOracleベスト・プラ クティスのレビューを確認することを推奨します。フィジカル・スタンバイの REDO Applyプロセスをチューニングするためのベスト・プラクティスをさらにド リルダウンする場合は、『Oracle Database 10g Best Practices, Data Guard Redo Apply and Media Recovery』[7]を参照してください。ロジカル・スタンバイ上のSQL Apply プロセスに関する同様の情報は、『Data Guard SQL Apply Best Practices in Oracle Database 10g』[8]を参照してください。

オブザーバ

ロケーション：障害時リカバリ要件として、オブザーバは、本番データセンター とスタンバイ・データセンターとは別の場所にインストールすることが理想的で す。オブザーバは、データセンターから独立している必要があり、可能であれば、 クライアント・アプリケーションと同じネットワークで本番データベースとスタ ンバイ・データベースに接続します。これが不可能な場合、オブザーバをスタン バイ・データベースとは別のシステム上のスタンバイ・ロケーションに配置し、 スタンバイ・データベースに影響を与える可能性のあるイベントから、可能な限 り切り離します。

インストール：Oracle Client Administratorをインストールすると、オブザーバがイ ンストールされます（[Open Universal Installer]から[Administrator]オプションを選 択します）。オブザーバ・システムにはOracleインスタンスが含まれないため、 Oracle Client Administratorをインストールすると、使用するディスク領域が減少し ます。Oracle Enterprise Managerを使用する場合は、オブザーバ・システムにOracle Enterprise Managerエージェントもインストールしてください。

オブザーバの可用性を高める：Oracle Enterprise Manager 10.2.0.1 では、オブザーバ の処理に障害が発生したことが検出された場合、同じホスト上のオブザーバを自 動的に再起動できます。ファスト・スタート・フェイルオーバーが有効になると、 自動再起動機能がアクティブになります。これによって、予期せぬプロセスの停 止やオブザーバ・ホストの再起動に起因するオブザーバの停止が自動的に処理さ れます。また、Oracle Enterprise Managerエージェントは、起動時に自動で開始し、 観測されていない未解決の状況が残っている場合は続いてオブザーバを起動する ので、ユーザーは、ホストの起動時にオブザーバを再起動するカスタム・プロシー ジャを構成する作業が不要になります。

Oracle Enterprise Manager 10.2.0.3 は、最初のホストに障害が発生した場合に、異な るホスト上で代替のオブザーバ・ホームを識別する追加機能を提供し、第 2 のホ ストでオブザーバを自動的に再起動します。

単一ホスト上で複数のファスト・スタート・フェイルオーバーのオブザーバをサ ポート：複数の本番データベースの監視に 1 つのホストを使用する必要があり、 それぞれがスタンバイ・データベースをファスト・スタート・フェイルオーバー

のターゲットにしている場合があります。オブザーバの各プロセスは、単一の本 番/スタンバイのペアを監視するので、複数のオブザーバを単一のホスト上で構成 する必要があります。実装の詳細は、選択する管理インタフェースによって異な ります。代表的なユースケースを次に示します。 ユースケース： • 3 つの異なる（まったく無関係な）本番データベース • 3 つのフィジカル・スタンバイ・データベース、各本番データベースに 1 つ • 単一の Oracle ホームで 3 つの独立したオブザーバが動作する 1 つのサー バー、各本番/スタンバイ・ペアに対して、1 つのオブザーバ

Oracle Data Guard Brokerを使用した複数オブザーバの構成：Oracle Data Guard Broker のコマンドライン・インタフェースDGMGRLは、複数の本番データベース用ファ スト・スタート・フェイルオーバーのオブザーバを作成するために使用されます。 オブザーバのイベントの追跡に使用するdgmgrlログ・ファイルは、DGMGRLの起 動時に（-logfileコマンドライン・パラメータを使用して）指定できます単一のホ スト上の同じOracleホームで複数のオブザーバを実行するには、各オブザーバのロ グ・ファイルに一意の名前を指定します。 また、オブザーバは、ファスト・スタート・フェイルオーバーの本番/スタンバイ・ ペアの構成情報を含むデータファイルを維持します。デフォルトでは、このファ イルは FSFO.DAT と呼ばれます。同一のホームで複数のオブザーバを実行するに は、オブザーバの起動時に、START OBSERVER コマンド[16]に FILE= option を使 用して、オブザーバのデータファイルの場所を指定する必要があります。各デー タファイルの名前が一意であることを確認してください。 たとえば、上記のユースケースに従い、各オブザーバに対してファイルを一意に識 別するために、各本番データベースの DB_UNIQUE_NAME を使用できます。各本 番データベースの DB_UNIQUE_NAME が、Boston、Chicago、Washington である場 合は、次のようにします（必要なディレクトリが作成済みであると仮定します）。 dgmgrl -logfile $ORACLE_HOME/rdbms/log/Boston.log

DGMGRL> START OBSERVER FILE=$ORACLE_HOME/dbs/Boston.dat'; dgmgrl -logfile $ORACLE_HOME/rdbms/log/Chicago.log

DGMGRL> START OBSERVER FILE=$ORACLE_HOME/dbs/Chicago.dat'; dgmgrl -logfile $ORACLE_HOME/rdbms/log/Washington.log

DGMGRL> START OBSERVER FILE=$ORACLE_HOME/dbs/Washington.dat';

Data Guard 構成に接続されるまで、DGMGRL 自体にはコンテキストがありません。 DGMGRL が構成に接続され、START OBSERVER コマンドが発行されると、その 構成のみが観測されます。

Oracle Data Guard Broker は同一の構成に対する複数のオブザーバを許可しないの で、一意のファイル名が必要になります。

DGMGRLコマンドおよびオプションについて詳しくは、『Oracle Data Guard Broker Manual』[4]の第 8 章である、Data Guard Command-Line Interface Referenceを参照し

てください。

Oracle Enterprise Managerを使用した複数のオブザーバの構成：Oracle Enterprise ManagerのEnable Fast-Start Failoverウィザードを使用する場合は、ファスト・スター ト・フェイルオーバーを構成するときに、オブザーバのホストとOracleホームを指 定するだけです。Oracle Enterprise Managerは、指定される各オブザーバが、一意 の名前を付けられたオブザーバ・データおよびdgmgrlログ・ファイルを持ってい ることを自動的に確認します。オブザーバのデータファイルは、$ORACLE_ HOME/dbsディレクトリ（afoXXXXX.dat）にあります。dgmgrlログ・ファイルは、 $ORACLE_HOME/rdbms/logディレクトリ（dgmgrlXXXXX.log）にあります。XXXXX は、Oracle Enterprise Managerが生成する一意の番号で、一定の本番/スタンバイ・ データベース構成では、オブザーバ・データファイルおよびdgmgrlログ・ファイ ルも同じです。オブザーバが再起動されるたびに、XXXXXの値は変わります。

ファスト・スタート・フェイルオーバーのしきい値

オブザーバとスタンバイ・データベースの両方で、FastStartFailoverThreshold プ ロパティの値を超過して本番データベースとの接続が中断され、構成の状態が同 期化されていることを双方が認めた場合、ファスト・スタート・フェイルオーバー が発生します。FastStartFailoverThreshold プロパティの最適値は、最も高速なフェ イルオーバー（つまり停止時間の最短化）と、ネットワークの一瞬の不規則性ま たは可用性に大きな影響を与えない一時的なイベントによって引き起こされる、 不必要なフェイルオーバーの間でのトレードオフに重点をおきます。ファスト・ スタート・フェイルオーバーを有効にする際に設定されるデフォルト値は 30 秒で す。FastStartFailoverThreshold プロパティに推奨する設定は、次のとおりです。 • 単一インスタンスの本番データベース、待機時間が短い、信頼性の高い ネットワーク = 10～15 秒 • 単一インスタンスの本番データベース、待機時間が長い WAN 上のネット ワーク = 30～45 秒 • RAC 本番データベース = 障害が発生したノードを除外するために必要 な時間 + 20 秒この方法を使用して、RAC 構成でしきい値を設定すると、 ノードが排除された後で影響を受けていないノードが処理を再開する場 合、ファスト・スタート・フェイルオーバーは発生しません。

監視

ファスト・スタート・フェイルオーバーは、本番データベースとスタンバイ・デー タベースが同期した状態でなければ発生しないため、ネットワークの停止やスタ ンバイ・サーバーのクラッシュに迅速に対応し、Oracle Data Guard が、発生した REDO ギャップを素早く解決して、スタンバイ構成を同期の状態に戻せるように することが重要です。

Oracle Enterprise Managerは、継続的に構成の状態を監視し、注意が必要なイベントを 管理者に通知します。また、構成の状態は、V$DATABASEビューのFS_FAILOVER_ STATUS列でも監視できます。SYNCHRONIZED状態とは、本番データベースとス タンバイ・データベースが同期しており、ファスト・スタート・フェイルオーバー が可能な状態のことです。UNSYNCHRONIZED状態とは、本番データベースによっ て生成されたすべてのREDOをスタンバイ・データベースが受信していないため に、ファスト・スタート・フェイルオーバーが発生できない状態です。 ファスト・スタート・フェイルオーバーの発生には、構成内の 3 つの要素うち 2 つ の同意が必要であるため、オブザーバの状態も監視する必要があります。オブザー バの状態は、Oracle Enterprise Manager GUIを介して、またはV$DATABASEビュー のFS_FAILOVER_OBSERVER_PRESENT列で監視します。

フラッシュバック・データベースの構成

本番データベースとスタンバイ・データベースの両方で、フラッシュバック・デー タベースを構成します。Oracle Data Guard Broker は、フラッシュバック・データ ベースを使用して、フェイルオーバーが発生した場合に、障害が発生した本番デー タベースを新しい本番データベースのスタンバイ・データベースとして自動的に 復元します。これは、元の本番データベースが再起動可能で、フェイルオーバー 操作がファスト・スタート・フェイルオーバーによって実行されている場合にの み行われます。 ファスト・スタート・フェイルオーバーのコンテキストでDB_FLASHBACK_RETENTION_ TARGETを単独で使用する場合、その値を60 分など、低い値に設定することを推 奨します。この保存ターゲットは、ファスト・スタート・フェイルオーバーを目 的とした安全な値です。ただし、フラッシュバック・データベースが、ユーザー・ エラーや破損に対して早期にリカバリを行う追加機能に対応する場合は、フラッ シュバック保存期間をこれらの目的の達成に必要と思われる時間に設定する必要 があります。たとえば、Oracle MAAのベスト・プラクティスでは、この目的に最 低 6 時間の保存期間を推奨しています（これらの目標はユーザーによって異なり、 保護を強化するとストレージ要件も拡大します）。 フラッシュバック・データベースとフラッシュ・リカバリ領域について詳しくは、 『Oracle Database Backup and Recovery Basics』[10]の"Oracle Flashback Databaseの設 定とメンテナンス"および『Oracle Data Guard Concepts and Administration』[5]の "フラッシュ・リカバリ領域の設定"を参照してください。

複数スタンバイによる構成

Data Guard 構成には、1 つの本番データベースに対して 1 つ以上のスタンバイ・デー タベースが含まれていることがあります。多くの場合、"ローカル"のスタンバイ を使用して、データ消失ゼロの目標を達成します。

同期のデータ保護をサポートできる、待機時間の短い LAN を使用することで、待 機時間の長い WAN のパフォーマンス・オーバーヘッドを発生させません。第 2 のスタンバイは本番サイトから地理的に 100～1000 マイル離れた構成で、非同期 のデータ保護を使用して待機時間の長い WAN のパフォーマンス・オーバーヘッ ドを回避します。このような構成でファスト・スタート・フェイルオーバーを使 用すると、ローカル・スタンバイはフェイルオーバー・ターゲットまたはシステ ムに指定され、本番データベースとともに、オブザーバに監視されます。フェイ ルオーバー時に、ファスト・スタート・フェイルオーバーは、ローカル・スタン バイを本番ロールに移行し、リモート・スタンバイは、新しい本番データベース のスタンバイ・データベースにシームレスに移行します。そのため、元の本番デー タベースが復旧される間、データ保護および障害時リカバリ保護を継続できます。

ファスト・スタート・フェイルオーバーに適したアプリケーション

通常、Oracle Data Guard は、データ保護と障害時リカバリを目的として、本番サ イトから離れたデータセンターで同期のスタンバイ・システムを管理するために 使用されます。Oracle9i 以降、Oracle Data Guard は、必要に応じて管理者が即座に フェイルオーバーを実行できることを前提として、データ消失ゼロと迅速なデー タベース・フェイルオーバーを可能にしてきました。Oracle Data Guard 10g の拡張 機能は、手動でフェイルオーバーを実行する所要時間を大幅に短縮しました。 ただし、停止時間について細心の注意を必要とするアプリケーションがあります。 たとえば、製造業の重要なアプリケーションでは、いかなる停止時間も生産低下 につながり、取引システムでは、ビジネス上の損失が生じ、オンラインの Web 小 売業では、停止時間は売上と顧客満足に直接影響を与えます。このようなアプリ ケーションを使用するビジネスでは、フェイルオーバーの手動による起動処理が もたらす遅延時間の増大を容認できません。管理者が必要なときに直ちにフェイ ルオーバーを実行できない場合、この遅延時間はさらに増加します。 ファスト・スタート・フェイルオーバーは、このような種類のアプリケーション に非常に適しています。ファスト・スタート・フェイルオーバーは、手動操作を 必要とする処理の不確実性を排除し、停止を検出した後、数秒以内にデータ消失 ゼロのフェイルオーバーを自動的に実行します。

自動クライアント・フェイルオーバー

クライアント・フェイルオーバーは、複数の方法で構成できます。いずれの場合 にも、ファスト・スタート・フェイルオーバーに先立って、データベースのフェ イルオーバーを実行するための手動の設定が必要です。ファスト・スタート・フェ イルオーバーは、データベースのフェイルオーバーを自動化することで、処理を 効率的にします。さらに、Oracle Data Guard 10g Release 2 には、新しいDB_ROLE_ CHANGEシステム・イベントが含まれており、それをFAN OCIイベント（後述）と 併用すると、フェイルオーバーが発生した場合に、新しい本番データベースに自 動的にリダイレクトされることをクライアントに迅速に通知できます。

このイベントは、次の項で説明します。自動クライアント・フェイルオーバーに ついて詳しくは、『Oracle Data Guard 10g Release 2 Best Practices for Client Failover』 [11]を参照してください。

DB_ROLE_CHANGE イベント

データベースが 1 つのロールから別のロールへ移行するたびに、DB_ROLE_CHANGE システム・イベントが起動します。これは、ロールの変更後に起動する点を除け ば、STARTUPシステム・イベントに酷似しています。ロール変更後のタスクを管 理する方法として、管理者はこのイベントが発生した場合に実行されるトリガー を作成できます。このイベントは、新しいロールとは無関係に、ロールの移行後、 データベースがオープンになったときに起動します（すなわち、ロール変更によっ てデータベースが読み取り専用モードで最初にオープンされたとき、そのロール が、本番データベースか、ロジカル・スタンバイ、あるいはフィジカル・スタン バイであるかどうかは関係ありません）。 DB_ROLE_CHANGEシステム・イベントは、ロール変更後のタスクの管理と自動化に 使用できます。一般的なタスクには、新しい本番データベースでのサービス開始、 ネーミング・サービスの変更、または接続記述子の変更が含まれるため、クライ アントは新しい本番データベースに再接続し、サード・パーティのアプリケーショ ンの起動や一時表領域の追加などを行います。DB_ROLE_CHANGEは、柔軟なメカ ニズムであるため、管理者はデータベース・トリガーを使用して、実行できる任 意のアクションを自動化できます。DB_ROLE_CHANGEイベントについて詳しく は、『Oracle Database Application Developer's Guide - Fundamentals 10g Release 2』[12] を参照してください。

また、Oracle Data Guard Broker を使用してフェイルオーバー操作を調整すると、 障害が発生した本番データベースの代理として、Fast-Application Notification(FAN) [13]イベントがポストされ、OCI クライアントに障害を通知します。さらに、クラ イアント接続が TAF 対応（Transparent Application Failover [14]）である場合、アプ リケーションは新しい本番データベースに自動的にフェイルオーバーできます。

結論

Oracle Data Guard は、いくつかの主要な Oracle リリースを通じて進化してきまし た。この製品は、本番システムに影響を与えるイベントの性質や規模とは無関係 に、Oracle データ、およびそのデータへのアクセスを必要とするアプリケーショ ンの高可用性を保護する、最も機能的な障害時リカバリ・ソリューションです。 ファスト・スタート・フェイルオーバーは、Oracle Data Guard の機能をさらに拡 張して、ビジネスを継続するための要件に対応します。ファスト・スタート・フェ イルオーバーは、Data Guard 構成を年中無休で監視し、特定の条件が存在する場 合、フェイルオーバーを自動的に実行します。ファスト・スタート・フェイルオー バーの自動処理で、手動作業によって生じる遅延を回避できます。また、自動フェ イルオーバーは注意深く制御されるので、データ消失やトランザクションの"スプ リット・ブレイン"状態を完全に回避できます。

フェイルオーバー後、ファスト・スタート・フェイルオーバーによって、元の本 番データベースは自動的に復元されます。その結果、ほとんどの場合、元の本番 データベースの"手動による再構築"に要する時間と労力が排除されます。これに よって、管理者が本番システムで障害のトラブルシューティングを行う間に停止 時間が発生する場合よりも、容易かつ高速にフェイルオーバーを実行できます。 Oracle Data Guard 10g Release 2 のロール移行イベントは、中間層でデータベース・ フェイルオーバーをフェイルオーバー・プロシージャと統合して、Data Guard のフェ イルオーバーを迅速に検知し、クライアントとアプリケーションをスタンバイ・ロ ケーションの新しい本番データベースへ自動的にリダイレクトする追加機能を備え、 ビジネスの継続性を達成するエンドツーエンドのソリューションを提供します。

参考資料

1. Oracle Data Guard

http://otndnld.oracle.co.jp/products/database/oracle10g/availability/htdocs/availability/DataGuardOverview.html

2. Oracle Maximum Availability Architecture

http://otn.oracle.co.jp/products/availability/htdocs/maa.html

3. Oracle Data Guard 10g Release 2, Switchover and Failover Best Practices（英語）

http://www.oracle.com/technology/deploy/availability/pdf/MAA_WP_10gR2_SwitchoverFailoverBestPractices.pdf

4. Oracle Data Guard Broker （製品マニュアル）

http://otndnld.oracle.co.jp/document/products/oracle10g/102/doc_cd/nav/portal_4.htm

5. Oracle Data Guard 概要および管理（製品マニュアル）

http://otndnld.oracle.co.jp/document/products/oracle10g/102/doc_cd/nav/portal_4.htm

6. Oracle Database 10g Release 2 High Availability Best Practices （英語）

http://download.oracle.com/docs/cd/B19306_01/server.102/b25159/toc.htm

7. Oracle Database 10g Best Practices:Data Guard Redo Apply and Media Recovery （英語）

http://www.oracle.com/technology/deploy/availability/pdf/MAA_WP_10gRecoveryBestPractices.pdf

8. Data Guard SQL Apply Best Practices in Oracle Database 10g （英語）

http://www.oracle.com/technology/deploy/availability/pdf/MAA_WP_10gR2_SQLApplyBestPractices.pdf 9. Data Guard Primary Site and Network Best Practices （英語）

http://www.oracle.com/technology/deploy/availability/pdf/MAA_WP_10gR2_DataGuardNetworkBestPractices.pdf

10. Oracle Database バックアップおよびリカバリ基礎（製品マニュアル）

http://otndnld.oracle.co.jp/document/products/oracle10g/102/doc_cd/nav/portal_4.htm

11. Oracle Data Guard 10g Release 2 Best Practices for Client Failover（英語）

http://www.oracle.com/technology/deploy/availability/pdf/MAA_WP_10gR2_ClientFailoverBestPractices.pdf

12. DB_ROLE_CHANGE - Oracle Database アプリケーション開発者ガイド（製品 マニュアル）

13. Fast-Application Notification (FAN) references:

• Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide

http://download-west.oracle.com/docs/cd/B19306_01/rac.102/b14197/hafeats.htm - sthref428

• Oracle Database High Availability Overview (Part #B14210-01)

http://download-west.oracle.com/docs/cd/B19306_01/server.102/b14210/hafeatures.htm#sthref54

14. Transparent Application Failover (TAF)

http://download-west.oracle.com/docs/cd/B19306_01/server.102/b14220/high_av.htm - i36759

15. Oracle Database Clusterware and Oracle Real Application Clusters Administration and Deployment Guide 10g Release 2 (10.2)

http://download-west.oracle.com/docs/cd/B19306_01/rac.102/b14197/admcon.htm - sthref29

16. FILE= option

ファスト・スタート・フェイルオーバーのベスト・プラクティス： Oracle Data Guard 10g Release 2

2007 年 1 月

著者：Joseph Meeks、Michael T. Smith、Ashish Ray、Sadhana Kyathappala Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問合せ窓口: 電話: +1.650.506.7000 ファクシミリ: +1.650.506.7200 oracle.com

Copyright © 2007, Oracle.All rights reserved.

本文書は情報提供のみを目的として提供されており、ここに記載される内容は予告なく変 更されることがあります。 本文書は一切間違いがないことを保証するものではなく、さらに、口述による明示または 法律による黙示を問わず、特定の目的に対する商品性もしくは適合性についての黙示的な 保証を含み、いかなる他の保証や条件も提供するものではありません。オラクル社は本文 書に関するいかなる法的責任も明確に否認し、本文書によって直接的または間接的に確立 される契約義務はないものとします。本文書はオラクル社の書面による許可を前もって得 ることなく、いかなる目的のためにも、電子または印刷を含むいかなる形式や手段によっ ても再作成または送信することはできません。 Oracle、JD Edwards、PeopleSoft、Retek は、オラクル社およびその子会社、関連会社の登録 商標です。その他の名称はそれぞれの会社の商標です。