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

Size: px

Start display at page:

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

しょうすけくまじ
5 years ago
Views:

1 ファストスタートフェイルオーバーのベストプラクティス :Oracle Data Guard 10g Release 2 Oracle Maximum Availability Architecture ホワイトペーパー 2007 年 1 月 Maximum Availability Architecture Oracle Best Practices for High Availability

2 ファストスタートフェイルオーバーのベストプラクティス Oracle Data Guard 10g Release 2 概要... 3 ファストスタートフェイルオーバー構成の要素... 3 ファストスタートフェイルオーバーの構成... 5 ファストスタートフェイルオーバーをトリガーするイベント... 6 ファストスタートフェイルオーバー後の回復... 6 オラクルのテスト結果... 7 ファストスタートフェイルオーバーのための Oracle ベストプラクティス... 7 本番データベースの構成... 7 ネットワーク転送... 8 スタンバイの構成... 8 オブザーバ... 9 ファストスタートフェイルオーバーのしきい値監視フラッシュバックデータベースの構成複数スタンバイによる構成ファストスタートフェイルオーバーに適したアプリケーション自動クライアントフェイルオーバー DB_ROLE_CHANGE イベント結論参考資料ファストスタートフェイルオーバーのベストプラクティス :Oracle Data Guard 10g Release 2 2

3 ファストスタートフェイルオーバーのベストプラクティス 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 構成では複数のスタンバイ

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

5 これによってファストスタートフェイルオーバーの 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

6 ファストスタートフェイルオーバーをトリガーするイベントファストスタートフェイルオーバーはデータベースが次の状態になった場合に実行されますデータベースインスタンス障害 (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

7 オラクルのテスト結果オラクルでは本番データベーススタンバイデータベースオブザーバ ( いずれも 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 のネットワーク

8 これは本番データベースが本番サーバーとスタンバイサーバーの両方のディスクに 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

9 これによってフィジカルスタンバイ上の管理リカバリプロセスまたはロジカルスタンバイ上の 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 ではオブザーバの処理に障害が発生したことが検出された場合同じホスト上のオブザーバを自動的に再起動できますファストスタートフェイルオーバーが有効になると自動再起動機能がアクティブになりますこれによって予期せぬプロセスの停止やオブザーバホストの再起動に起因するオブザーバの停止が自動的に処理されますまた Oracle Enterprise Managerエージェントは起動時に自動で開始し観測されていない未解決の状況が残っている場合は続いてオブザーバを起動するのでユーザーはホストの起動時にオブザーバを再起動するカスタムプロシージャを構成する作業が不要になります Oracle Enterprise Manager は最初のホストに障害が発生した場合に異なるホスト上で代替のオブザーバホームを識別する追加機能を提供し第 2 のホストでオブザーバを自動的に再起動します単一ホスト上で複数のファストスタートフェイルオーバーのオブザーバをサポート : 複数の本番データベースの監視に 1 つのホストを使用する必要がありそれぞれがスタンバイデータベースをファストスタートフェイルオーバーファストスタートフェイルオーバーのベストプラクティス :Oracle Data Guard 10g Release 2 9

10 のターゲットにしている場合がありますオブザーバの各プロセスは単一の本番 / スタンバイのペアを監視するので複数のオブザーバを単一のホスト上で構成する必要があります実装の詳細は選択する管理インタフェースによって異なります代表的なユースケースを次に示しますユースケース : 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

11 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

12 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

13 同期のデータ保護をサポートできる待機時間の短い 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

14 このイベントは次の項で説明します自動クライアントフェイルオーバーについて詳しくは 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

15 フェイルオーバー後ファストスタートフェイルオーバーによって元の本番データベースは自動的に復元されますその結果ほとんどの場合元の本番データベースの " 手動による再構築 " に要する時間と労力が排除されますこれによって管理者が本番システムで障害のトラブルシューティングを行う間に停止時間が発生する場合よりも容易かつ高速にフェイルオーバーを実行できます Oracle Data Guard 10g Release 2 のロール移行イベントは中間層でデータベースフェイルオーバーをフェイルオーバープロシージャと統合して Data Guard のフェイルオーバーを迅速に検知しクライアントとアプリケーションをスタンバイロケーションの新しい本番データベースへ自動的にリダイレクトする追加機能を備えビジネスの継続性を達成するエンドツーエンドのソリューションを提供します参考資料 1. Oracle Data Guard 2. Oracle Maximum Availability Architecture 3. Oracle Data Guard 10g Release 2, Switchover and Failover Best Practices( 英語 ) 4. Oracle Data Guard Broker ( 製品マニュアル ) 5. Oracle Data Guard 概要および管理 ( 製品マニュアル ) 6. Oracle Database 10g Release 2 High Availability Best Practices ( 英語 ) 7. Oracle Database 10g Best Practices:Data Guard Redo Apply and Media Recovery ( 英語 ) 8. Data Guard SQL Apply Best Practices in Oracle Database 10g ( 英語 ) 9. Data Guard Primary Site and Network Best Practices ( 英語 ) Oracle Database バックアップおよびリカバリ基礎 ( 製品マニュアル ) Oracle Data Guard 10g Release 2 Best Practices for Client Failover( 英語 ) DB_ROLE_CHANGE - Oracle Database アプリケーション開発者ガイド ( 製品マニュアル ) ファストスタートフェイルオーバーのベストプラクティス :Oracle Data Guard 10g Release 2 15

16 13. Fast-Application Notification (FAN) references: Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide - sthref428 Oracle Database High Availability Overview (Part #B ) Transparent Application Failover (TAF) - i Oracle Database Clusterware and Oracle Real Application Clusters Administration and Deployment Guide 10g Release 2 (10.2) - sthref FILE= option ファストスタートフェイルオーバーのベストプラクティス :Oracle Data Guard 10g Release 2 16

17 ファストスタートフェイルオーバーのベストプラクティス : Oracle Data Guard 10g Release 年 1 月著者 :Joseph Meeks Michael T. Smith Ashish Ray Sadhana Kyathappala Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA U.S.A. 海外からのお問合せ窓口 : 電話 : ファクシミリ : oracle.com Copyright 2007, Oracle.All rights reserved. 本文書は情報提供のみを目的として提供されておりここに記載される内容は予告なく変更されることがあります本文書は一切間違いがないことを保証するものではなくさらに口述による明示または法律による黙示を問わず特定の目的に対する商品性もしくは適合性についての黙示的な保証を含みいかなる他の保証や条件も提供するものではありませんオラクル社は本文書に関するいかなる法的責任も明確に否認し本文書によって直接的または間接的に確立される契約義務はないものとします本文書はオラクル社の書面による許可を前もって得ることなくいかなる目的のためにも電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません Oracle JD Edwards PeopleSoft Retek はオラクル社およびその子会社関連会社の登録商標ですその他の名称はそれぞれの会社の商標です

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

スイッチオーバーとフェイルオーバーのベスト・プラクティス Oracle Data Guard 10g Release 2 スイッチオーバーとフェイルオーバーのベストプラクティス :Oracle Data Guard 10g Release 2 Oracle の最大可用性アーキテクチャのホワイトペーパー 2007 年 1 月 Maximum Availability Architecture Oracle Best Practices For High Availability スイッチオーバーとフェイルオーバーのベスト