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のログなどより障害要因を確認

今回はここまで!!

次回はスナップショット・スタンバイの検証と質問の回答を予定しています。

コールド・ストーン・クリーマリーの商品値上げにショック! 恵比寿にて