ファスト スタート フェイルオーバーのベスト プラクティス :Oracle Data Guard 10g Release 2 Oracle Maximum Availability Architecture ホワイト ペーパー 2007 年 1 月 Maximum Availability Architecture Oracle Best Practices for High Availability
ファスト スタート フェイルオーバーのベスト プラクティス 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 2
ファスト スタート フェイルオーバーのベスト プラクティス 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 構成を集中管理できます ファスト スタート フェイルオーバーのベスト プラクティス :Oracle Data Guard 10g Release 2 3
ファスト スタート フェイルオーバー構成には 次の 3 つの重要な要素 ( 図 1) が含まれます 本番データベース ターゲット スタンバイ データベース ファスト スタート フェイルオーバー オブザーバターゲット スタンバイ データベースは ファスト スタート フェイルオーバーの後 新しい本番データベースになります ( 注 :Data Guard 構成では 複数のスタンバイ データベースを構成できますが ファスト スタート フェイルオーバーのターゲットとして指定できるのは ただ 1 つです 構成内の他のスタンバイ データベースへのフェイルオーバーを実行するには 手動のフェイルオーバーが必要です ) オブザーバは DGMGRL クライアントに組み込まれた独立したプロセスであり 本番データベースとターゲット スタンバイ データベースに障害を引き起こす条件がないかどうかを継続的に監視します ルールでは これら 3 つの要素 ( 本番データベース スタンバイ データベース オブザーバ ) のうち いずれか 2 つが相互に通信することによって ファスト スタート フェイルオーバーの発生が決定されます たとえば 本番データベースが使用不能になった場合 オブザーバは 本番データベースが使用不能であることと ターゲット スタンバイ データベースが本番データベースと同期されていることを ターゲット スタンバイ データベースに確認します 確認が取れると ターゲット スタンバイ データベースへのファスト スタート フェイルオーバーが開始されます このような確認が行われない場合 ファスト スタート フェイルオーバーは発生しません ファスト スタート フェイルオーバーのベスト プラクティス :Oracle Data Guard 10g Release 2 4
これによって ファスト スタート フェイルオーバーの 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 を使用して ファスト スタート フェイルオーバーを有効にし オブザーバを起動します ファスト スタート フェイルオーバーのベスト プラクティス :Oracle Data Guard 10g Release 2 5
ファスト スタート フェイルオーバーをトリガーするイベント ファスト スタート フェイルオーバーは データベースが次の状態になった場合に実行されます データベース インスタンス障害 (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は さらに管理アクションが実行されるまで ( 元の本番データベースのマウントなど ) 回復を実行しません ファスト スタート フェイルオーバーのベスト プラクティス :Oracle Data Guard 10g Release 2 6
オラクルのテスト結果 オラクルでは 本番データベース スタンバイ データベース オブザーバ ( いずれも 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の影響を受ける可能性があります ファスト スタート フェイルオーバーのベスト プラクティス :Oracle Data Guard 10g Release 2 7
これは 本番データベースが 本番サーバーとスタンバイ サーバーの両方のディスクに REDO が書き込まれたという通知を受けるまで データベース クライアントに COMMIT を返さないからです ファスト スタート フェイルオーバーを使用する場合は ネットワーク帯域幅と遅延が 同期の REDO 送信に適応している必要があります ネットワーク転送 Oracle Data Guard のネットワーク スループットに影響を与えるオペレーティング システム パラメータをチューニングすると 最大可用性構成をサポートするネットワークの機能が大幅に向上します これらのパラメータには TCP/ 受信バッファ およびカーネル ネットワーク サブシステムとネットワーク インタフェース カードのドライバ間のバッファ サイズを指定する設定が含まれています オラクルが行ったテストから ワークロードの大きいアプリケーションをチューニングすることの重要性が明らかになりました テストでは TCP 送信 / 受信バッファ デバイス ネットワークのキュー サイズおよび SDU(Oracle Net Services セッション データ ユニット ) をチューニングするだけで スループットが大幅に向上しました 図 3 にこのチューニングの結果を示します 詳しくは Data Guard Primary Site and Network Best Practices [9] を参照してください スタンバイの構成 フェイルオーバー時間を最短にするには スタンバイ データベースにスタンバイ REDO ログ (SRL) とリアルタイム適用の両方を構成する必要があります ファスト スタート フェイルオーバーのベスト プラクティス :Oracle Data Guard 10g Release 2 8
これによって フィジカル スタンバイ上の管理リカバリ プロセス またはロジカル スタンバイ上の 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 つのホストを使用する必要があり それぞれがスタンバイ データベースをファスト スタート フェイルオーバー ファスト スタート フェイルオーバーのベスト プラクティス :Oracle Data Guard 10g Release 2 9
のターゲットにしている場合があります オブザーバの各プロセスは 単一の本番 / スタンバイのペアを監視するので 複数のオブザーバを単一のホスト上で構成する必要があります 実装の詳細は 選択する管理インタフェースによって異なります 代表的なユースケースを次に示します ユースケース : 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 10g Release 2 10
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 Data Guard 10g Release 2 11
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 つ以上のスタンバイ データベースが含まれていることがあります 多くの場合 " ローカル " のスタンバイを使用して データ消失ゼロの目標を達成します ファスト スタート フェイルオーバーのベスト プラクティス :Oracle Data Guard 10g Release 2 12
同期のデータ保護をサポートできる 待機時間の短い 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 13
このイベントは 次の項で説明します 自動クライアント フェイルオーバーについて詳しくは 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 14
フェイルオーバー後 ファスト スタート フェイルオーバーによって 元の本番データベースは自動的に復元されます その結果 ほとんどの場合 元の本番データベースの " 手動による再構築 " に要する時間と労力が排除されます これによって 管理者が本番システムで障害のトラブルシューティングを行う間に停止時間が発生する場合よりも 容易かつ高速にフェイルオーバーを実行できます 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 アプリケーション開発者ガイド ( 製品マニュアル ) http://otndnld.oracle.co.jp/document/products/oracle10g/102/doc_cd/nav/portal_5.htm ファスト スタート フェイルオーバーのベスト プラクティス :Oracle Data Guard 10g Release 2 15
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 http://download-west.oracle.com/docs/cd/b19306_01/server.102/b14230/dgmgrl.htm#babjecga ファスト スタート フェイルオーバーのベスト プラクティス :Oracle Data Guard 10g Release 2 16
ファスト スタート フェイルオーバーのベスト プラクティス : 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 は オラクル社およびその子会社 関連会社の登録商標です その他の名称はそれぞれの会社の商標です