DataGuard新機能」について検証します。今週はファスト・スタート・フェイルオーバーでの追加された機能について検証します。■検証ポイント(1)ファスト・スタート・フェイルオーバーの動作変更点(2)フェイルオーバー後の復旧操作ファスト・スタート・フェイルオーバーは10gより追加された機能です。ここではあまり聞きなれない方のためにファスト・スタート・フェイルオーバーの機能について説明します。■ファスト・スタート・フェイルオーバーとはプライマリDBに障害が発生した場合、複雑な手動手順を実行したフェイルオーバーを起動することなく指定されたスタンバイDBへ自動で素早く確実にフェイルオーバーを行うことができる機能です。これにより、稼働時間を透過的に維持し、システム障害、データ障害およびサイト停止に対する高可用性レベル、ならびに障害時のリカバリ時間を短縮することができます。以下にファスト・スタート・フェイルオーバーの起動条件を示します。11gリリース1(11.1)E05756-01ファスト・スタート・フェイルオーバーを実現するには別HOSTに監視サーバー(オブザーバー)を用意する必要があります。実際にはDGMGRLコマンドライン・インタフェースを利用して接続しオブザーバーを起動します。~~~~~~~~~~~~~~■11gから追加されたファスト・スタート・フェイルオーバー追加パラメータついて紹介します。このパラメータを利用することで自動的なスタンバイDB再構築を停止させ、障害の原因究明が実施し易くなりました。コマンドを使用してスタンバイDBの再構築する必要があります。ABORTを実行します。FastStartFailover後に自動的にシャットダウンしない。新スタンバイDBとして自動的に再構成する。関してプライマリDBからスタンバイDBへ転送が遅れる時間を指定する。Guardの保護モードの1つでプライマリ・データベースのパフォーマンスに影響しない範囲で可能な最高レベルのデータ保護を提供しますその他の保護モードには最大可用性モード、最大保護モードがあります。・障害を発生させる(仮想障害)・自動フェイルオーバー動作後の状態[動作準備]ファスト・スタート・フェイルオーバーを実行するには監視サーバー(OBSERVER)の動作に必要な設定をおこないます。(1)[動作モードの設定]ファスト・スタート・フェイルオーバーの前提条件としてデータベース/DataGuard構成に対して高可用性モードに変更する必要があります。(4)[オブザーバーの起動]プライマリDBの障害を監視するためにオブザーバーを起動します。CONFIGURATIONコマンドで設定したパラメータ値が反映されていることを確認できます。⇒FastStartFailoverAutoReinstateとなります。use(未使用)で表示されます。FAILOVERコマンドでファスト・スタート・フェイルオーバーの詳細情報が確認出来ようになりました。Conditions:にてフェイルオーバーの条件がどの様に有効になっているかを確認できます。Archiver)フェイルオーバーの起動条件は以下のコマンドで設定できます。実際に障害を発生させて動作検証をしましょう。secondsが経過すると指定されたスタンバイDBにフェイルオーバーが実施されます。火曜日データベース”ORA111W”へのファスト・スタート・フェイルオーバーを開始し現在フェイルオーバーを実行しています。お待ちください...フェイルオーバーに成功しました。火曜日~~自動でスタンバイDB再構築~~データベース”ORA111′′の修復を開始しています...データベース”ORA111′′を修復しています。データベースがオープンされていません。データベースがディスマウントされました。ORACLEインスタンスがシャットダウンされました。起動する必要がインスタンス”ORA111′′の起動中...ORACLEインスタンスが起動しました。データベースがマウントされました。ORA-01109は旧プライマリDBがシャットダウンしたため、ORA-01109が表示されてしまっています。(3)障害原因の調査の追加11gより追加された障害原因のV$表は以下になります。プライマリDBとスタンバイDB間の接続統計情報を表示します。今回のフェイルオーバーの発生要因を確認してみましょう。Disconnectedお!。障害発生原因として、プライマリDBの通信切断が記録されています。内容は「いつ、どんな障害が発生したか」の情報となってます。詳細はこのV$表では分かりません。18:00:21このように遅延時間が参照出来ました。接続障害による分析に於いてはアラートログを分析するよりは見やすくなっています。何が起こったかは分からないので接続障害がいつ、どれだけの遅延で発生しているのかはわかりますが詳細は分からない情報です。Conditionsの指定が可能になったことにより、各利用ユーザーの要件に応じて設定変更が可能になりました。この機能によりディザスタリカバリの運用が柔軟に対応し易くなりました。(2)[障害に対する原因究明の簡略化]□スタンバイDBの自動復旧が手動に変更可能FastStartFailoverShutdown=FALSEOracle10gまでは旧プライマリDBをmountした時点で自動的にスタンバイDB再構築を行ってしまい原因が分からないケースがありました。自動再構築を停止し障害が発生した状態で原因復旧を行うことが出来るようになりました。□障害分析の補助情報として活用できそう障害発生原因の分析には10gではアラートログより読み取るしかない状況でした。11gからはV$FS_FAILOVER_STATS、V$FS_FAILOVER_HISTOGRAMなどを参照すれば障害発生の時刻と障害名を参照できるため、原因究明の参考情報として利用できそうです。以上から、フェイルオーバーの障害分析では以下の流れが良さそうです。今回はここまで!!次回はスナップショット・スタンバイの検証と質問の回答を予定しています。reserved.トップページ企業概要プライバシーポリシ。