Oracle11g DataGuard新機能 その5
<Oracle 11g検証 第4弾 新機能:Oracle11g DataGuard その5>
ペンネーム: オレンジみかん
先週に引き続き「Oracle11g DataGuard新機能」について検証します。
今週はファスト・スタート・フェイルオーバーでの追加された機能について
検証します。
1.検証目的
■検証ポイント
(1)ファスト・スタート・フェイルオーバーの動作変更点
(2)フェイルオーバー後の復旧操作
ファスト・スタート・フェイルオーバーは10gより追加された機能です。
ここではあまり聞きなれない方のためにファスト・スタート・フェイルオー
バーの機能について説明します。
■ファスト・スタート・フェイルオーバーとは
プライマリDBに障害が発生した場合、複雑な手動手順を実行したフェイルオーバー
を起動することなく指定されたスタンバイDBへ自動で素早く確実にフェイル
オーバーを行うことができる機能です。これにより、稼働時間を透過的に
維持し、システム障害、データ障害およびサイト停止に対する高可用性
レベル、ならびに障害時のリカバリ時間を短縮することができます。
以下にファスト・スタート・フェイルオーバーの起動条件を示します。
[ファスト・スタート・フェイルオーバーの起動条件]
(1)[データファイル・オフライン]
書込みエラーのためにデータファイルがオフラインの場合
(2)[破損したディクショナリ]
重要なデータベース・オブジェクトのディクショナリが破損した場合
(3)[破損した制御ファイル]
重要なデータベース・オブジェクトの制御ファイルが破損した場合
(4)[アクセス不可能なログ・ファイル]
I/OエラーのためにLGWRがログ・グループのどのメンバーにも書き込む
ことができない場合
(5)[スタック・アーカイバ]
デバイスに空き容量がないかデバイスを使用できないためにアーカイバが
REDOログをアーカイブ出来ない場合
※出典:Oracle Data Guard Broker 11gリリース1(11.1)E05756-01
ファスト・スタート・フェイルオーバーを実現するには別HOSTに
監視サーバー(オブザーバー)を用意する必要があります。
実際にはDGMGRLコマンドライン・インタフェースを利用して接続し
オブザーバーを起動します。
[構成図]
Archive |~~~~~~~~~~~~~~~~~| log |~~~~~~~~~~~~~~~~~| | プライマリDB | ⇒ | スタンバイDB | |_________________| |_________________| |Data Guard Broker| |Data Guard Broker| ~~~~~~~~~|~~~~~~~~ ~~~~~~~~~|~~~~~~~~ |_______________________| ↑ |~~~~~~~~~~~~~~| | オブザーバー | |(監視サーバー)| ~~~~~~~~~~~~~~
■11gから追加されたファスト・スタート・フェイルオーバー追加パラメータ
ついて紹介します。このパラメータを利用することで自動的なスタンバイDB
再構築を停止させ、障害の原因究明が実施し易くなりました。
尚、原因究明後はREINSTATE DATABASE コマンドを使用してスタンバイDBの
再構築する必要があります。
[11g新機能]
(1)[パラメータ:FastStartFailoverShutdown] [内容] V$DATABASEのFS_FAILOVER_STATUS列がSTALLEDになっていた場合、 FastStartFailoverThresholdプロパティで指定している値(秒数)後に SHUTDOWN ABORTを実行します。 FastStartFailover後に自動的にシャットダウンしない。そのため、 問題発生時には原因究明ができる。問題解決後、手動でSHUTDOWN ABORT を実行し再構成します。 (2)[パラメータ:FastStartFailoverAutoReinstate] [内容] ファイルオーバー後の旧プライマリDBをmount起動後、 再びオブザーバーとの接続を確立すると、オブザーバーは 新スタンバイDBとして自動的に再構成する。 (DGMGRL> REINSTATE DATABASE [DBユニーク名]; と同じ) 再構成しない⇒問題の原因究明時に利用 (3)[パラメータ:FastStartFailoverLagLimit] [内容]最大パフォーマンスモードで動作している際に、REDO適用に 関してプライマリDBからスタンバイDBへ転送が遅れる時間を指定する。
※[補足]
最大パフォーマンスモード:
Data Guardの保護モードの1つでプライマリ・データベースのパフォーマンス
に影響しない範囲で可能な最高レベルのデータ保護を提供します
その他の保護モードには最大可用性モード、最大保護モードがあります。
2.検証開始
[検証の流れ]
・ファスト・スタート・フェイルオーバーのパラメータ設定
・オブザーバーの開始
・障害を発生させる(仮想障害)
・自動フェイルオーバー動作後の状態
[動作準備]
ファスト・スタート・フェイルオーバーを実行するには監視サーバー
(OBSERVER)の動作に必要な設定をおこないます。
(1)[動作モードの設定]
ファスト・スタート・フェイルオーバーの前提条件としてデータベース/
DataGuard構成に対して高可用性モードに変更する必要があります。
SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY; DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;
(2)[ファスト・スタート・フェイルオーバーに関するプロパティの設定]
・フェイルオーバー先をプライマリDB/スタンバイDBの各サーバーに設定
します
DGMGRL> EDIT DATABASE 'ORA111' SET PROPERTY FastStartFailoverTarget = 'ORA111W'; DGMGRL> EDIT DATABASE 'ORA111W' SET PROPERTY FastStartFailoverTarget = 'ORA111';
(3)[ファスト・スタート・フェイルオーバーの有効化]
DGMGRL> ENABLE FAST_START FAILOVER 有効になりました。
(4)[オブザーバーの起動]
プライマリDBの障害を監視するためにオブザーバーを起動します。
(オブザーバー):OBS_SRV
・Data Guard 管理コンソールに接続
DGMGRL> CONNECT /
・オブザーバーの起動
DGMGRL>START OBSERVER オブザーバーが起動しました
(5)[DataGuard構成の状態確認]
DGMGRL> show configuration verbose; Configuration Name: DGSolution Enabled: YES Protection Mode: MaxAvailability Databases: ORA111 - Primary database ORA111W - Physical standby database - Fast-Start Failover target Fast-Start Failover: ENABLED Threshold: 30 seconds Target: ORA111W Observer: OBS_SRV ~(11gより追加項目)~~~~~~~~~~~~~~~~ Lag Limit: 60 seconds (not in use) Shutdown Primary: TRUE Auto-reinstate: TRUE ~~~~~~~~~~~~~~~~~~~~~~~~~~
11gよりLag Limit、Shutdown Primar、Auto-reinstateのパラメータが追加
になりました
SHOW CONFIGURATIONコマンドで設定したパラメータ値が反映されていること
を確認できます。
Lag Limit ⇒FastStartFailoverLagLimit Shutdown Primary ⇒FastStartFailoverShutdown Auto-reinstate ⇒FastStartFailoverAutoReinstate
となります。この例では Lag Limitは最大パフォーマンスモード用の
パラメータなので現在の最大可用性モードではnot in use(未使用)で表示されます。
(6) [ファスト・スタート・フェイルオーバーの詳細情報の確認]
11gよりSHOW FAST_START FAILOVERコマンドで
ファスト・スタート・フェイルオーバーの詳細情報が確認出来ようになりました。
Health Conditions:にてフェイルオーバーの条件がどの様に有効になって
いるかを確認できます。
~(11gより追加項目)~~~~~~~~~~~~~~~~
DGMGRL> SHOW FAST_START FAILOVER; Fast-Start Failover: ENABLED Threshold: 30 seconds Target: ORA111 Observer: OBS_SRV Lag Limit: 120 seconds (not in use) Shutdown Primary: TRUE Auto-reinstate: TRUE Configurable Failover Conditions Health Conditions: Corrupted Controlfile YES Corrupted Dictionary YES Inaccessible Logfile NO Stuck Archiver NO Datafile Offline YES Oracle Error Conditions: (none) ~~~~~~~~~~~~~~~~~~~~~~~~~~
Health Conditionsの条件
・破損した制御ファイル(Corrupted Controlfile)
・破損したディクショナリ(Corrupted Dictionary)
・アクセス不可能なログ・ファイル(Inaccessible Logfile)
・データファイル・オフライン(Datafile Offline )
・スタック・アーカイバ(Stuck Archiver)
フェイルオーバーの起動条件は以下のコマンドで設定できます。
[有効化]
DGMGRL>enable fast_start failover condition ; [無効化] DGMGRL>disable fast_start failover condition ;
3.動作検証
実際に障害を発生させて動作検証をしましょう。
(1)[障害を発生させます]
プライマリDBからスタンバイDBへのREDO転送障害として
プライマリDBをshutdown abortします。
(プライマリDB>
SQL> SHUTDOWN ABORT
(2)ファスト・スタート・フェイルオーバーの開始
障害発生(プライマリDBのREDO通信切断)から
ファスト・スタート・フェイルオーバーのしきい値(Threshold)まで
30 secondsが経過すると指定されたスタンバイDBにフェイルオーバーが
実施されます。
——-
DGMGRL> START OBSERVER オブザーバーが起動しました
~~プライマリDB障害発生 ~~
17:51:07.84 2008年4月22日 火曜日
データベース”ORA111W”へのファスト・スタート・フェイルオーバーを開始し
現在フェイルオーバーを実行しています。お待ちください…
フェイルオーバーに成功しました。新規プライマリは”ORA111W”です
17:51:23.90 2008年4月22日 火曜日
~~フェイルオーバー完了(プライマリDBは”ORA111W”) ~~
~~スタンバイDBを startup mount で起動します ~~
17:59:33.83 2008年4月22日 火曜日
~~自動でスタンバイDB再構築~~
データベース”ORA111″の修復を開始しています…
データベース”ORA111″を修復しています。お待ちください…
操作上、インスタンス”ORA111″ (データベース”ORA111″) を停止する必要があ
インスタンス”ORA111″の停止中…
ORA-01109: データベースがオープンされていません。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
操作上、インスタンス”ORA111″ (データベース”ORA111″) を起動する必要が
インスタンス”ORA111″の起動中…
ORACLEインスタンスが起動しました。
データベースがマウントされました。
データベース”ORA111″の修復を続行します…
データベース”ORA111″の修復に成功しました
18:00:06.80 2008年4月22日 火曜日
———————————————————————
※ORA-01109は旧プライマリDBがシャットダウンしたため、
ORA-01109が表示されてしまっています。
(3)障害原因の調査の追加
11gより追加された障害原因のV$表は以下になります。
[追加されたV$表]
V$FS_FAILOVER_STATS: ファースト・スタート・フェイルオーバーの発生原因、発生時間を参照 LAST_FAILOVER_TIME :発生時間 LAST_FAILOVER_REASON:発生要因 V$FS_FAILOVER_HISTOGRAM プライマリDBとスタンバイDB間の接続統計情報を表示します。 REDO_LATENCY :プライマリDBからの書き込み間隔 FREQUENCY :遅延発生時間 LAST_TIME :最後に遅延が発生した時間
今回のフェイルオーバーの発生要因を確認してみましょう。
SQL> SELECT * FROM V$FS_FAILOVER_STATS; LAST_FAILOVER_TIME LAST_FAILOVER_REASON --------------------- ---------------------------------- 04/22/2008 17:59:33 Primary Disconnected
お!。障害発生原因として、プライマリDBの通信切断が記録されています。
内容は「いつ、どんな障害が発生したか」の情報となってます。
詳細はこのV$表では分かりません。
ではV$FS_FAILOVER_HISTOGRAMの情報はどうでしょうか?
SQL> SELECT * FROM V$FS_FAILOVER_HISTOGRAM; REDO_LATENCY FREQUENCY LAST_TIME ------------ ---------- -------------------- 1 0 2 0 3 0 4 0 (中略) 169 94 04/22/2008 18:00:21
このように遅延時間が参照出来ました。
接続障害による分析に於いてはアラートログを分析するよりは
見やすくなっています。ただし、何が起こったかは分からないので
接続障害がいつ、どれだけの遅延で発生しているのかはわかりますが
詳細は分からない情報です。
以上の動作検証から
4.検証まとめ
(1)[ファスト・スタート・フェイルオーバーの条件の有効/無効化設定]
Health Conditionsの指定が可能になったことにより、各利用ユーザーの
要件に応じて設定変更が可能になりました。この機能により
ディザスタリカバリの運用が柔軟に対応し易くなりました。
(2)[障害に対する原因究明の簡略化]
□スタンバイDBの自動復旧が手動に変更可能
FastStartFailoverShutdown=FALSE
Oracle10gまでは旧プライマリDBをmountした時点で自動的にスタンバイDB
再構築を行ってしまい原因が分からないケースがありました。
この点に於いて、FastStartFailoverShutdown=FALSE にすることにより、
自動再構築を停止し障害が発生した状態で原因復旧を行うこと
が出来るようになりました。
□障害分析の補助情報として活用できそう
障害発生原因の分析には10gではアラートログより読み取るしかない状況で
した。11gからはV$FS_FAILOVER_STATS、V$FS_FAILOVER_HISTOGRAMなどを
参照すれば障害発生の時刻と障害名を参照できるため、原因究明の参考情報
として利用できそうです。
以上から、フェイルオーバーの障害分析では以下の流れが良さそうです。
(1)障害発生の時間を参照する(障害の発生時間、何の障害なのか?)
V$FS_FAILOVER_STATSで障害発生時間を特定して分析の目安を確認
接続障害の場合はV$FS_FAILOVER_HISTOGRAM
(3)プライマリDB、スタンバイDBのアラートログ、Listenerログ、
DataGuardBrokerのログなどより障害要因を確認
今回はここまで!!
次回はスナップショット・スタンバイの検証と質問の回答を予定しています。
コールド・ストーン・クリーマリーの商品値上げにショック! 恵比寿にて