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

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

スイッチオーバーとフェイルオーバーのベスト プラクティス Oracle Data Guard 10g Release 2 概要... 3 所見およびベスト プラクティス 概要... 4 フェイルオーバーのベスト プラクティス... 5 スイッチオーバーのベスト プラクティス... 6 DATA GUARD ロールの推移 概要... 7 フェイルオーバー... 8 手動フェイルオーバー... 8 フィジカル スタンバイ データベースに対する手動フェイルオーバー... 8 ロジカル スタンバイ データベースに対する手動フェイルオーバー... 9 ファスト スタート フェイルオーバー... 10 フィジカルまたはロジカル スタンバイ データベースに対するファスト スタート フェイルオーバー... 11 手動フェイルオーバーとファスト スタート フェイルオーバーのテスト結果... 12 単一インスタンス データベース... 13 複数インスタンス Real Application Clusters... 13 スイッチオーバー... 14 SQL*Plus およびフィジカル スタンバイ データベースの使用... 14 SQL*Plus およびロジカル スタンバイ データベースの使用... 15 スイッチオーバーのテスト結果... 16 単一インスタンス データベース... 16 複数インスタンス Real Application Clusters... 17 アプリケーションとクライアントのフェイルオーバー... 18 まとめ... 18 参考資料... 19 スイッチオーバーとフェイルオーバーのベスト プラクティス :Oracle Data Guard 10g Release 2 2

スイッチオーバーとフェイルオーバーのベスト プラクティス Oracle Data Guard 10g Release 2 概要 Oracle Data Guard [1] は現在提供されている 企業データのデータ保護および障害時リカバリ ソリューションの中で 最も効率的かつ包括的なソリューションの 1 つです Oracle Databaseを保護し 最も重要な資産の 1 つである企業のオンライン情報を保護する機能を提供します Data Guardのフェイルオーバーおよびスイッチオーバー操作により ネットワーク停止や本番データベース障害などの計画外停止後 またはソフトウェアのアップグレードや他の定期メンテナンスなどの計画的停止後も オンライン情報は使用可能です Oracle Database 10g Release 2 では Data Guard のファスト スタート フェイルオーバー機能が導入されました そのため 従来のフェイルオーバーおよびスイッチオーバー機能が大きく改善されて Data Guard のロール推移の実行に必要な時間が短縮されました このホワイト ペーパーでは Oracle Database 10g Release 2 を使用した最速のData Guardスイッチオーバーとフェイルオーバーを実現する Maximum Availability Architecture (MAA) [2] ベスト プラクティスについて説明します また 様々な構成設定でのスイッチオーバーとフェイルオーバーのタイミングの予測も提供します さらに ファスト スタート フェイルオーバー特有の説明は 補足的なホワイト ペーパー Oracle Data Guard 10g Release 2 Fast-Start Failover Best Practices [3] を参照してください この 2 つのホワイト ペーパーを参照すると Oracle Data Guard 環境でロール推移を実行するためのベスト プラクティスについての実用的なアドバイスが得られます これらのホワイト ペーパーの最新版は Oracle Technology Network(OTN)[2] ウェブサイトのMAAのページを参照してください Data Guard 10g Release 2ロール推移を使用した MAA テストにはスイッチオーバー 手動フェイルオーバーおよびファスト スタート フェイルオーバーのテストが含まれていました すべてのテストは Oracle Enterprise Manager と Data Guard Broker のコマンドライン インタフェース (DGMGRL) と SQL*Plus 文を使用して実行されました スイッチオーバーとフェイルオーバーのベスト プラクティス :Oracle Data Guard 10g Release 2 3

所見およびベスト プラクティス 概要 適切に計画し実行した場合 Data Guard のロール推移によりダウンタイムが最小限に抑えられ ビジネスへの影響を最小にしたうえでデータベース環境がリストアされます フィジカル スタンバイ データベースまたはロジカル スタンバイ データベースの使用とは関係なく MAA テストでは Oracle Data Guard 10g Release 2 を使用したスイッチオーバー時間とフェイルオーバー時間が 秒単位に短縮されることが確認されました サイト障害およびデータベース障害に対する秒単位の自動フェイルオーバー データ破損に対する秒単位の自動フェイルオーバー システム ハードウェアまたはサイト変更のための計画的なダウンタイムを短縮する 秒単位の手動スイッチオーバー Data Guard および関連するソリューションを使用して 様々な停止に対して実現できるソリューションとリカバリ時間を表 1 に示します 表 1: 計画外停止と計画的停止に対する Oracle のソリューション 停止のタイプ Oracle のソリューションリカバリ時間 コンピュータ障害 ストレージ障害 データ破損 サイト障害 システムとクラスタのアップグレード すべてのパッチ セットとデータベースのアップグレード 4 ファスト スタート フェイルオーバーと Fast-Application Notification (FAN) [8] ファスト スタート フェイルオーバーと Fast-Application Notification Data Guard と Automatic Storage Management (ASM) [9] REDO ブロックの適用前に それらを自動的に検証し 本番データベースが破損した場合 破損していないスタンバイ データベースへ迅速にフェイルオーバーする Data Guard と Hardware Assisted Resilient Data (HARD) Initiative [10] ファスト スタート フェイルオーバーと Fast-Application Notification (FAN) [8] RAC ローリング アップグレードを使用したアップグレードが不可能なシステム アップグレードの場合 ( 例 : ダウンタイムが必要なシステム制限またはクラスタ ファームウェアのアップグレード ) フィジカルまたはロジカル スタンバイ データベースにスイッチオーバー Data Guard SQL Apply およびロジカル スタンバイ データベースを使用して Oracle データベースをアップグレード 30 秒未満 30 秒未満 ダウンタイムなし 1 30 秒未満 ダウンタイムなし 2 30 秒未満 3 数秒から数分 数秒から数分 1 2 3 4 ミラー化および自動的なバランスの再調整機能を持つAutomatic Storage Management(ASM) を使用すると ストレージ障害を回避できます ストレージ ベンダーが実装したHARD Initiativeによってデータ損失を防止する場合 ダウンタイムはありません リカバリ時間の対象となるのは データベースおよび既存のデータベース接続障害です ネットワーク接続の変更や他のサイト固有のアクティビティによっては リカバリにかかる合計時間が長くなる場合があります Oracle Database Release 10.1.0.3 以降専用にサポートされています また SQL Applyにデータ型の制限があることに注意してください 詳細は Oracle Data Guard Concepts and Administration [5] でリストを参照してください スイッチオーバーとフェイルオーバーのベスト プラクティス :Oracle Data Guard 10g Release 2 4

Oracle の高可用性ソリューションおよび高速化された Data Guard フェイルオー バーとスイッチオーバーのメリットの詳細は Oracle Database High Availability Overview [4] を参照してください フェイルオーバーのベスト プラクティスフェイルオーバー処理を最適化するには 次のベスト プラクティスを実行します ファスト スタート フェイルオーバーの使用 Oracle Database 10g Release 2 を実行するMAAテストでは Data Guard Brokerとファスト スタート フェイルオーバーを使用して実行したフェイルオーバーにより 可用性が大幅に強化されることを示しています オラクル社では MAA Webサイトで入手可能なホワイト ペーパー Oracle Data Guard 10g Release 2 Fast-Start Failover Best Practices [3] に記載された Oracleのベスト プラクティスの包括的な概説を読むことをお薦めします 障害時のリカバリのために ファスト スタート フェイルオーバー オブザーバは 本番およびスタンバイ データ センターから離れた場所にインストールするのが理想的です オブザーバは データ センターから独立している必要があり 可能であれば エンド ユーザーのクライアントと同じネットワークで本番およびスタンバイ データベースに接続している必要もあります 指定されたオブザーバに障害が発生した場合 Enterprise Manager はそれを検出できます そのために 同一のホスト上でオブザーバを自動的に再起動するように Enterprise Manager を設定できます 独立した場所にオブザーバを配置できない場合は スタンバイ データ センターに配置してください ただしホストは できるかぎりスタンバイ データベースの障害から影響を受けないように別に配置してください フェイルオーバー処理の完了後 フラッシュバック データベースを有効にして本番データベースを復元します フラッシュバック データベースは 必要に応じて高速な Point-in-Time リカバリを実現するという 2 番目に重要な機能を提供します Data Guard のリアルタイム適用機能により REDO データ受信後ただちにスタンバイ データベースに適用します Real Application Clusters に関連する手動フェイルオーバーの場合 フェイルオーバーを実行する前に すべての RAC セカンダリ インスタンスで SHUTDOWN ABORT 文を発行します ロジカル スタンバイ データベースの場合 MAAのホワイト ペーパー Oracle 10g SQL Apply Best Practices [6] を参照して 最適なSQL Apply 速度を取得してください スイッチオーバーとフェイルオーバーのベスト プラクティス :Oracle Data Guard 10g Release 2 5

フィジカル スタンバイ データベースの場合 MAAのホワイト ペーパー Oracle Database 10g Best Practices: Data Guard Redo Apply and Media Recovery [7] を参照して REDO Applyに対しメディア リカバリを最適化してください スタンバイ データベースを再起動せずに MOUNT 状態から直接 OPEN 状態に進みます 読取り専用モードから REDO APPLY( リカバリ ) モードに推移するときは データベースを再起動します LOG_FILE_NAME_CONVERT パラメータを設定します フェイルオーバーの一部として 新規の本番データベースとして開く前にスタンバイ データベースのスタンバイ オンライン ログを消去する必要があります この I/O の処理に必要な時間により ファイルオーバーに必要な合計時間が大幅に増えます LOG_FILE_NAME_CONVERT パラメータを設定すると MRP が最初に開始されたときにスタンバイ オンライン REDO ログを事前に消去することができます スイッチオーバーのベスト プラクティス 可能なセッションすべてを切断し ジョブの処理を停止します スイッチオーバーを実行する前に NODELAY キーワードを使用して指定された任意の適用遅延をキャンセルします 例を示します SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY; また スタンバイ データベースの REDO にギャップがないことを確認してください ロジカル スタンバイ データベースの場合 1. ホワイト ペーパー Oracle 10g SQL Apply Best Practices [6] を参照して 最適なSQL Apply 速度を取得してください 2. 実際にスイッチオーバーを実行する前に SQL 文 ALTER DATABASE PREPARE TO SWITCHOVERを発行することにより構築されたLogMiner Multi-versioned Data Dictionaryを実行します 詳細な手順は Oracle Data Guard Concepts and Administration [5] の Switchovers Involving a Logical Standby Database を参照してください フィジカル スタンバイ データベースの場合 ホワイト ペーパー Oracle 10g Redo Apply and Media Recovery Best Practices [7] を参照して 最適なRedo Apply 速度を取得してください 読み取り専用モードからREDO APPLY( リカバリ ) モードに推移するときに データベースを再起動します REDO データが受信直後にスタンバイ データベースに適用されるよう Data Guard のリアルタイム適用を使用します これによってスタンバイ データベースは スイッチオーバー時間を最小限に抑えるため処理前に本番データベースと同期化されます スイッチオーバーとフェイルオーバーのベスト プラクティス :Oracle Data Guard 10g Release 2 6

スイッチオーバー時に障害が発生した場合 処理を簡単に取り消せるようにフラッシュバック データベースを有効にします スイッチオーバーを実行する前に ローカルおよびリモートのアーカイブに必要な ARCH のプロセス回数を必要最小限にします ARCH のプロセス数が増えると停止までの時間が長くなるため スイッチオーバーに必要な合計時間が増えます スイッチオーバー完了後 ARCH の追加処理が可能です LOG_FILE_NAME_CONVERT パラメータを設定します スイッチオーバーの一部として 新規の本番データベースとして開く前にスタンバイ オンライン ログを消去する必要があります この I/O の処理に必要な時間により スイッチオーバーに必要な合計時間が大幅に増えます LOG_FILE_NAME_CONVERT パラメータを設定すると MRP が最初に開始されたときにスタンバイ オンライン REDO ログを事前に消去することができます DATA GUARD ロールの推移 概要 Data Guard の構成は 本番ロールで機能する 1 つのデータベースとスタンバイ ロールで機能する 1 つ以上のデータベースで構成されています これらのスタンバイ データベースは 本番データベースの同期化されたコピーとして保存されます これらのスタンバイ データベースは 本番データ センターから遠く離れた障害時リカバリ サイトに配置することも 同じ都市 構内またはビルに配置することもできます 計画外または計画的停止が発生した場合 Data Guard は 最小のダウンタイムで迅速にスタンバイ データベースの 1 つを本番ロールに変更できます 1 つのサーバーが使用できない場合でもサイト全体が使用できない場合でも Data Guard は 効果的で迅速なリカバリのためにスイッチオーバーとフェイルオーバーを提供し ビジネスを継続させます スイッチオーバーとは 本番データベースと 1 つのスタンバイ データベース間の計画的なロール リバーサルのことで 本番システムの定期メンテナンス時のシステム停止を防ぐため または今後ロール推移を実施するにあたり準備状況を確認するために行われます スイッチオーバーでは データ消失は発生しません スイッチオーバー時 本番データベースはスタンバイ ロールに切り替わり スタンバイ データベースは本番ロールに切り替わります この切替えでは いずれのデータベースも再起動する必要はありません スイッチオーバーは Enterprise Manager または Data Guard Broker のコマンドライン インタフェースを介して あるいは SQL*Plus コマンドを発行して 管理者が実行します フェイルオーバーは 本番データベース (RAC 本番データベースのすべてのインスタンス ) に障害が発生し スタンバイ データベースの 1 つが本番ロールを引き継ぐために切り替えられた場合に実行され ビジネスを継続させます フェイルオーバーが完了しアプリケーションが再開した後 管理スタッフはシステムの問題解決に戻ることができます フェイルオーバーの結果 データが消失するかどうかは フェイルオーバー時に有効になっている Data Guard 保護モードによります スイッチオーバーとフェイルオーバーのベスト プラクティス :Oracle Data Guard 10g Release 2 7

Oracle Database 10g Release 2 以降 フェイルオーバーには 手動フェイルオーバーとファスト スタート フェイルオーバーの 2 種類あります 手動フェイルオーバーは 本番データベースに障害が発生した場合に管理者が実行します これに対し Data Guard Broker は 本番データベースが一定期間 ( ファスト スタート フェイルオーバーのしきい値 ) 使用不可能になると 自動的にファスト スタート フェイルオーバーを開始します 注意 : 可用性の高いアーキテクチャは 高速なデータベース フェイルオーバーを実行できるだけではなく アプリケーションがビジネスに利用可能なように 高速なクライアント フェイルオーバーを実行できる必要があります クライアント フェイルオーバーに対するData Guard 構成のMAAのベスト プラクティスは MAAのホワイト ペーパー Oracle Data Guard 10g Release 2 Client Failover Best Practices [12] で説明しています フェイルオーバー Data Guard 構成でフェイルオーバーを実行すると スタンバイ データベースが本番データベースに変換されます 後述のセクションでは 手動フェイルオーバーとファスト スタート フェイルオーバーについて詳しく説明します 手動フェイルオーバー手動フェイルオーバーは Enterprise Manager のグラフィカル ユーザー インタフェース Data Guard Broker のコマンドライン インタフェース (DGMGRL) から または SQL*Plus 文を発行して管理者が直接実行します 次のセクションでは 関連する SQL*Plus のコマンドついて説明します フィジカル スタンバイ データベースに対する手動フェイルオーバー次のコマンドを使用して フィジカル スタンバイ データベースの手動フェイルオーバーを実行します 1. Real Application Clusters 環境での手動フェイルオーバーの場合 フェイルオーバーを実行する前に セカンダリ スタンバイ データベースのすべての RAC インスタンスで SHUTDOWN ABORT 文を発行します 2. ターゲット スタンバイ データベースで次の文を発行し フェイルオーバーを開始します SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE; 注意 : FORCE キーワードを組み込んで スタンバイ データベース上の RFS プロセスが 必ずネットワーク接続の停止前に 通常の TCP タイムアウト処理でタイムアウトするのを待たずにフェイルオーバーするようにします 3. フィジカル スタンバイ データベースを本番ロールに変換します ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY; スイッチオーバーとフェイルオーバーのベスト プラクティス :Oracle Data Guard 10g Release 2 8

4. スタンバイ データベースが最後に起動されてから一度も読取り専用として開かれていない場合 次の文を発行して新しい本番データベースを開きます ALTER DATABASE OPEN; フィジカル スタンバイ データベースが最後に起動されてから読取り専用として開かれた場合は ターゲット スタンバイ データベースを停止し再起動します SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP; 注意 : まれに フェイルオーバーの実行前に 現在のスタンバイ REDO ログ ファイルの REDO が適用されるまで待機したくない場合があります ( 注意 : Data Guard のリアルタイム適用を使用して スタンバイ データベースを最新の状態に保つことにより遅延を回避できます ) その場合は ALTER DATABASE ACTIVATE STANDBY DATABASE 文を発行し フェイルオーバーをただちに実行します この文は スタンバイ データベースを本番データベースに変換し 新しい resetlogs ブランチを作成しデータベースを開きます ただし この文はスタンバイ REDO ログ ファイルの適用されない REDO のデータ消失の原因になることがあるため オラクル社では 前述の手順で説明したフェイルオーバー手順とコマンドを使用して フェイルオーバーを実行することをお薦めします Oracle Data Guard 概要および管理 [5] で次のセクションを参照してください 順を踏んだフェイルオーバー手順は 物理スタンバイ データベースを必要とするフェイルオーバー で 新しいresetlogsブランチに対するフィジカル スタンバイ データベースの反応は OPEN RESETLOGS 文によるリカバリ方法 で説明しています ロジカル スタンバイ データベースに対する手動フェイルオーバー次のコマンドを使用して ロジカル スタンバイ データベースの手動フェイルオーバーを実行します 1. Real Application Clusters 環境での手動フェイルオーバーの場合 フェイルオーバーを実行する前に 全スタンバイ データベースのすべての RAC インスタンスで SHUTDOWN ABORT 文を発行します 2. ターゲット スタンバイ データベースで次の文を発行し フェイルオーバーを開始します ALTER DATABASE ACTIVATE LOGICAL STANDBY DATABASE FINISH APPLY; この文は RFS 処理の停止 残りの REDO データの適用 SQL Apply の停止 本番ロールのロジカル スタンバイ データベースのアクティブ化を実行します スイッチオーバーとフェイルオーバーのベスト プラクティス :Oracle Data Guard 10g Release 2 9

注意 : フェイルオーバーの実行前に スタンバイ REDO ログ ファイルの REDO が適用されるまで待機しないようにするには この文の FINISH APPLY 句を除外します FINISH APPLY 句の省略により フェイルオーバーは加速しますが スタンバイ REDO ログが適用されていない REDO データは消失します 消失する REDO の量を測定するには V$LOGSTDBY_PROGRESS ビューに対して問合せを実行します LATEST_SCN 列の値は本番データベースから受信した最後の SCN を また APPLIED_SCN 列の値は スタンバイ データベースに適用された最後の SCN を示します 2 つの値の間のすべての SCN は消失します Oracle Data Guard Concepts and Administration [5] で次のセクションを参照してください 順を踏んだフェイルオーバー手順は ロジカル スタンバイ データベースを必要とするフェイルオーバー で 新しいresetlogsブランチに対するフィジカル スタンバイ データベースの反応は OPEN RESETLOGS 文によるリカバリ方法 で説明しています ファスト スタート フェイルオーバーファスト スタート フェイルオーバーは Oracle Data Guard 10g Release 2 の機能の1つです 迅速かつ確実に ターゲット スタンバイ データベースを本番データベース ロールにフェイルオーバーします 管理者は手動でフェイルオーバーを実行する必要がなく データが消失することもありません ファスト スタート フェイルオーバーを実行するには Data Guard 構成と Data Guard Broker を事前に設定する必要があります 設定が有効の場合 オブザーバは Data Guard 構成を年中無休で監視し 本番データベースが一定期間使用不可能になるたびに 指定されたターゲット スタンバイ データベースのファスト スタート フェイルオーバーを自動的に開始します 自動フェイルオーバーが開始されるためには ファスト スタート フェイルオーバーの 3 つのメンバー ( 本番データベース ターゲット スタンバイ データベース オブザーバ ) のうち少なくとも 2 つについて必須条件がすべて満たされている必要があります これにより 1 つの本番データベースのみがトランザクションを受け入れることが保証され 一般に スプリット ブレイン と呼ばれるシナリオが回避されます Broker のクライアントであるオブザーバは Data Guard 構成を監視し Data Guard が本番データベースに確実に接続できるようにします オブザーバとスタンバイ データベースが共に本番データベースから切断されると オブザーバは管理者が定義した一定時間 本番データベースへの再接続を試みますが オブザーバとスタンバイ データベースが本番データベースに接続できない場合は フェイルオーバーが開始されます スイッチオーバーとフェイルオーバーのベスト プラクティス :Oracle Data Guard 10g Release 2 10

またフェイルオーバー後 データベースが再起動されると ( データベースが再起動可能で オブザーバへの接続を確立できると仮定して ) Broker は障害を起こした本番データベースを新しいターゲット スタンバイとして自動的に復元します これにより Data Guard は 古い本番データベースを新しい本番データベースに迅速かつ自動的に再同期化でき 障害を起こした ( 古い本番 ) データベースを新しい本番データベースのバックアップからリストアする必要がなくなります そのため Data Guard 構成に対する高可用性のリストア時間が向上します フィジカルまたはロジカル スタンバイ データベースに対するファスト スタート フェイルオーバーファスト スタート フェイルオーバーは Data Guard Broker のコントロール下の Data Guard 構成内で使用されます Data Guard Broker は Data Guard 構成内ですべてのリソースを集中管理します コマンドライン インタフェース (DGMGRL) またはEnterprise Manager 5 を使用して Data Guard Brokerは 単一のコマンドで複数のSQL*Plus 文と同等の作業を実行しData Guard 構成の管理を大幅に簡素化します ファスト スタート フェイルオーバーを有効にするには 次の前提条件を満たす必要があります 本番データベースとターゲット スタンバイ データベースでフラッシュバック データベースを有効にする 本番データベースとターゲット スタンバイ データベースでフラッシュ リカバリ領域を構成する Data Guard Broker 構成を有効にする LGWR SYNC モードで REDO 転送サービスを構成する 最大可用性モードで Data Guard 構成を実行する オブザーバがスタンバイ データベースと本番データベースにネットワーク接続していることを確認する Broker を使用してファスト スタート フェイルオーバーを構成すると 構成内で重要な次の 3 つの要素が設定されます ( 図 1) 本番データベース ターゲット ( フィジカルまたはロジカル ) スタンバイ データベース ファスト スタート フェイルオーバー オブザーバ 5 Enterprise Manager は ファスト スタート フェイルオーバーに推奨されるインタフェースです その理由は次のとおりです オブザーバは Enterprise Manager を介して起動すると バックグラウンド プロセスとして起動します Enterprise Manager メトリックを使用し DBA はオブザーバを監視でき オブザーバが停止すると通知を受け取ります オブザーバが動作していたホストが再起動されると Enterprise Manager はオブザーバを自動的に再起動します オブザーバに障害が発生した場合 Enterprise Manager はそれを検出できるため 同一のホスト上でオブザーバを自動的に再起動するように Enterprise Manager を設定できます スイッチオーバーとフェイルオーバーのベスト プラクティス :Oracle Data Guard 10g Release 2 11

ファスト スタート フェイルオーバーの詳細な構成情報は OTN MAA [2] Web サイトにあるホワイト ペーパー Oracle Data Guard 10g Release 2 Fast-Start Failover Best Practices [3] および Oracle Data Guard Broker [14] を参照してください また フラッシュバック データベースおよびフラッシュ リカバリ領域の設定に関する情報は Oracle Database Backup and Recovery Basics [13] の Setup and Maintenance for Oracle Flashback Database と Oracle Data Guard Concepts and Administration [5] の Setting Up Flash Recovery Areas を参照してください オブザーバ プライマリ サイト スタンバイ サイト 図 1 ファスト スタート フェイルオーバー構成 手動フェイルオーバーとファスト スタート フェイルオーバーのテスト結果 このホワイト ペーパーと Oracle Data Guard Release 2 で説明するベスト プラクティスを使用して フェイルオーバー時間を測定するために多くのテストが実行されました テスト データベースはそれぞれ 100GB で Gigabit Network に接続しました 異なるネットワーク待機時間をシミュレートしましたが 待機時間は フェイルオーバーおよびスイッチオーバー時間の最適化の要因ではありませんでした 本番データベースのワークロードは REDO を 3MB/ 秒の速度で生成しました シングル インスタンス データベースと RAC 構成のテストでは フィジカル スタンバイ データベース (Redo Apply) およびロジカル スタンバイ データベース (SQL Apply) へのフェイルオーバーをテストしました テスト中にフェイルオーバーを起動するために 本番データベースで SHUTDOWN ABORT を発行して障害をシミュレートし フェイルオーバーの主要な各セクションに要する時間は Data Guard Broker とデータベース アラート ログを使用して測定しました すべてのケースで ユーザーが構成できるフェイルオーバーしきい値 ( 障害を検出する時間 ) は フェイルオーバー時間の計算に含まれていません テストでは 実際のデータベース フェイルオーバーを完了するために必要な時間のみが測定されました フェイルオーバーを完了する合計時間は構成により異なり 10~25 秒でした スイッチオーバーとフェイルオーバーのベスト プラクティス :Oracle Data Guard 10g Release 2 12

単一インスタンス データベースこのホワイト ペーパーのセクション フェイルオーバーのベスト プラクティス で説明したベスト プラクティスを使用した場合 単一インスタンス データベースの平均フェイルオーバー時間は次のようになりました 手動フェイルオーバー SQL*Plus 文 DGMGRL または Enterprise Manager フィジカル スタンバイ 17 秒 18 秒 17 秒 ロジカル スタンバイ 10 秒 12 秒 14 秒 複数インスタンス Real Application Clusters このホワイト ペーパーのセクション フェイルオーバーのベスト プラクティス で説明したベスト プラクティスを使用した場合 複数インスタンス データベースの平均フェイルオーバー時間は次のようになりました 手動フェイルオーバー ファスト スタート フェイルオーバー ファスト スタート フェイルオーバー SQL*Plus 文 DGMGRL または Enterprise Manager フィジカル スタンバイ 22 秒 25 秒 25 秒 ロジカル スタンバイ 14 秒 17 秒 16 秒 表示された RAC のフェイルオーバーの結果を得るには バージョン 10.2.0.2.0 以降の Oracle Database が必要です このリリースでは すべてのセカンダリ インスタンスでの SHUTDOWN ABORT が最適化されているため フェイルオーバー合計時間が大幅に短縮されます バージョン 10.2.0.1 でこれらの時間を実現するには フェイルオーバー前に 各セカンダリ スタンバイ インスタンスで SHUTDOWN ABORT を発行します 注意 : テスト中 すべてのインスタンスは 最悪の事態をシミュレートするよう起動されました ただし ベスト プラクティスとして フェイルオーバーに必要な合計時間を更に短縮するため フェイルオーバーの実行前にすべてのセカンダリ スタンバイ インスタンスを (SHUTDOWN ABORT を使用して ) 閉じる必要があります ファスト スタート フェイルオーバーの詳細な構成情報は OTN MAA [2] Web サイトにあるホワイト ペーパー Fast-Start Failover: Oracle Database 10g Release 2 [3] および Oracle Data Guard Broker [14] を参照してください 手動フェイルオーバー情報は Oracle Data Guard 概要および管理 [5] の ロール推移 の章で提供されています スイッチオーバーとフェイルオーバーのベスト プラクティス :Oracle Data Guard 10g Release 2 13

スイッチオーバー Data Guard のスイッチオーバー機能は 高レベルの可用性を維持しながらシステムのダウンタイムを短縮する必要がある場合 重要なソリューションです スイッチオーバーは 本番データベースをスタンバイ ロールに切り替え スタンバイ データベースと本番ロールに切り替える手段を管理者に提供することによって これを実現します ロール推移では データ消失は発生しません 本番ロールが切り替えられると オペレーティング システムやハードウェアのアップグレードなどのメンテナンス作業をアプリケーション処理に影響を与えることなく実行できます メンテナンス作業が完了すると 管理者は本番ロールを元のサイトに簡単に切り替えることができます 同様に スイッチオーバーは Oracle データベース ソフトウェアのローリング アップグレードおよび障害時リカバリ対策のテストに使用できます スイッチオーバーは Oracle Enterprise Manager Data Guard Broker コマンドライン インタフェース または SQL*Plus 文を使用して実行できます スイッチオーバーの一部として すべてのユーザー セッションが本番データベースから切断されます すべてのセッションが切断されると 本番データベースはスタンバイ ロールに変換され その後スタンバイ データベースが本番ロールに切り替えられます 元の本番データベースにまだアクセスできる状態で ロール推移を実行するには フェイルオーバーではなく Data Guard スイッチオーバーを使用してください Data Guard スイッチオーバー機能は 高レベルの可用性を維持しながらシステムのダウンタイムを短縮する必要がある場合 最適のソリューションです SQL*Plus およびフィジカル スタンバイ データベースの使用このセクションで示す手順では フィジカル スタンバイ データベースの最適なスイッチオーバー処理を説明します フィジカル スタンバイ データベースが最後に起動されてから一度も読取り専用として開かれたことがなく (Oracle Database 10g Release 2 では スイッチオーバー後データベースを再起動する必要がないため ) 管理者が SQL*Plus 文を使用してスイッチオーバーを実行する場合に スイッチオーバーの実行に必要な合計時間を短縮できます フィジカル スタンバイ データベースが必要な手動スイッチオーバーを実行する場合 次の手順を実行して処理を最適化します 1. 可能な場合 ユーザー セッションを切断し アプリケーション処理を無効にするか停止します 2. 本番およびスタンバイ データベースが RAC 構成の場合 1つの本番インスタンスを除くすべてのインスタンスを完全に停止し 適用インスタンスを除くすべてのスタンバイ インスタンスを停止します ( これは 各クラスタで単一インスタンスが実行している状態です ) この操作を加速するには セカンダリ RAC インスタンスで SHUTDOWN ABORT を発行します スイッチオーバーとフェイルオーバーのベスト プラクティス :Oracle Data Guard 10g Release 2 14

3. 本番データベースで次の文を発行して 本番データベースをスタンバイ データベースに変換します ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY WITH SESSION SHUTDOWN; 4. 手順 3 の文が完了したら a. 古いスタンバイ データベースで次の文を発行します ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY; b. 前述の COMMIT TO SWITCHOVER TO PRIMARY 文の発行直後に 古い本番データベースを新しいスタンバイ データベースとして起動し MOUNT 状態にします SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT; 5. 手順 4 のスイッチオーバー コマンドが完了すると 新しい本番データベースで ALTER DATABASE OPEN 文を発行して OPEN 状態にします 注意 : Oracle Database 10g Release 2 以降 本番データベースが最後に起動されてから読取り専用として開かれなかった場合 新しい本番データベースを MOUNT 状態から直接開くことができます データベースが読取り専用として開かれた場合は 再起動する必要があります 6. 本番およびスタンバイ データベースが RAC で構成されている場合は すべてのインスタンスを起動します 7. ユーザー セッションとアプリケーション処理を再起動します SQL*Plus およびロジカル スタンバイ データベースの使用 SQL*Plus 文を使用してスイッチオーバーを実行する場合は 実際のスイッチオ- バーの前に 新しい本番データベースになるスタンバイ データベースが LogMiner ディクショナリを構築して 現在の本番データベース ( 新しいスタンバイ データベース ) に転送することが可能です これにより スイッチオーバーの実行に必要な合計時間が短縮されます 次の手順で この最適化された方法の実行の仕方を説明します 1. 本番データベースで次の文を発行して 現在のスタンバイ データベースから REDO を受信できるようにします ALTER DATABASE PREPARE TO SWITCHOVER TO LOGICAL STANDBY; 2. 現在のロジカル スタンバイ データベースで LogMiner ディクショナリを構築して このディクショナリを現在の本番データベースに転送します ALTER DATABASE PREPARE TO SWITCHOVER TO PRIMARY; 実行する作業とデータベースのサイズにより 文の実行に時間がかかる場合があります 3. 本番データベースの V$DATABASE 固定ビューの SWITCHOVER_STATUS 列に対して問合せを実行し LogMiner Multiversioned Data Dictionary が本番データベースに受信されたことを確認します スイッチオーバーとフェイルオーバーのベスト プラクティス :Oracle Data Guard 10g Release 2 15

最初は SWITCHOVER_STATUS 列に PREPARING DICTIONARY が表 示され LogMiner Multiversioned Data Dictionary は REDO ストリームに 記録されます これが正常に終了すると 列に PREPARING SWITCHOVER が表示されます 問合せによって TO LOGICAL STANDBY 値が戻されたら 次の手順に進みます 4. 可能な場合 ユーザー セッションを切断し アプリケーション処理を無効にするか停止します 5. 本番およびスタンバイ データベースが RAC 構成の場合 1つの本番インスタンスを除くすべてのインスタンスを完全に停止し 適用インスタンスを除くすべてのスタンバイ インスタンスを停止します ( これは 各クラスタで単一インスタンスが実行している状態です ) 停止操作を最適化するには SHUTDOWN ABORT を使用します 停止したすべての本番インスタンスおよびスタンバイ インスタンスのスレッドを無効にします スイッチオーバー完了後 スレッドを再度有効化しインスタンスを開始できます 6. V$DATABASE ビューの SWITCHOVER_STATUS 列によって TO LOGICAL STANDBY が返されたら 次の文を発行して本番データベースをスタンバイ データベースに変換します ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY WITH SESSION SHUTDOWN; 7. 古いスタンバイ データベースで次の文を発行します ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY; 8. 本番およびスタンバイ データベースが RAC で構成されている場合は すべてのインスタンスを起動します 9. ユーザー セッションとアプリケーション処理を再起動します スイッチオーバーのテスト結果 シングル インスタンス データベースと RAC 構成のテストでは フィジカル スタンバイ データベース (Redo Apply) およびロジカル スタンバイ データベース (SQL Apply) へのスイッチオーバーをテストしました SQL*Plus を使用したスイッチオーバーの完了にかかった合計時間は構成によって異なり 50~55 秒でした 単一インスタンス データベースこのホワイト ペーパーのセクション スイッチオーバーのベスト プラクティス で説明したベスト プラクティスを使用したテストの結果 単一インスタンス データベースのスイッチオーバー時間は 50 秒 ~2 分 49 秒でした 次の表に 単一インスタンスの本番データベースおよびロジカル スタンバイ データベースでスイッチオーバーの実行に必要な合計時間を示します スイッチオーバーとフェイルオーバーのベスト プラクティス :Oracle Data Guard 10g Release 2 16

SQL*Plus を使用した スイッチオーバー DGMGRL または Enterprise Manager を 使用したスイッチオーバー フィジカル スタンバイ 0:52 2:49 ロジカル スタンバイ 0:50 1:48 これらのスイッチオーバー時間は SQL*Plus 文を使用して 前述した最適なスイッチオーバーの方法により達成されました この方法では 古いスタンバイ ( 新しい本番 ) データベースの変換と同時に新しいスタンバイ ( 古い本番 ) データベースが再起動されました また 新しい本番データベースは MOUNT 状態から OPEN 状態に直接切り替えられるため データベースを再起動する必要はありません Enterprise Manager を使用してスイッチオーバーを実行すると SQL*Plus の場合より時間がかかります それは スイッチオーバー時にインスタンスが再起動される順序のため また新しい本番データベースが再起動されるためです さらに Data Guard Broker 処理時間により スイッチオーバーに必要な合計時間が長くなりました 複数インスタンス Real Application Clusters このホワイト ペーパーのセクション スイッチオーバーのベスト プラクティス で説明したベスト プラクティスを使用したテストの結果 RACデータベースのスイッチオーバー時間は 53 秒 ~2 分 56 秒でした SQL*Plus を使用したスイッチオーバー DGMGRL または Enterprise Manager を使用したスイッチオーバー フィジカル スタンバイ 0:55 2:56 ロジカル スタンバイ 0:53 1:54 RAC スイッチオーバーのテストは すべての本番およびスタンバイ インスタンスを起動して実行されました 表に示した時間は スタンバイ データベースから本番データベースへのロール推移 および新しいスタンバイ データベースの起動に必要な時間です セカンダリ 本番およびスタンバイ データベース インスタンスの再起動に必要な時間は示していません Broker ベースのロジカル スタンバイ スイッチオーバーには さらに時間がかかります それは SQL*Plus を使用したスイッチオーバーは スイッチオーバー前に完全に準備されているにもかかわらず (ALTER DATABASE PREPARE TO SWITCHOVER 文を使用して ) Broker が管理するスイッチオーバーではこの機能が使用されないためです スイッチオーバーとフェイルオーバーのベスト プラクティス :Oracle Data Guard 10g Release 2 17

アプリケーションとクライアントのフェイルオーバー ユーザーの可用性要件に最適なアーキテクチャを選択し実装するのは 困難な作業になる場合があります 可用性の高いアーキテクチャは 高速なデータベース フェイルオーバーを実行できるだけではなく あらゆるタイプの障害に対するクライアント フェイルオーバーに対応できる必要があります 新しい Data Guard 10g Release 2 では 自動データベース フェイルオーバーをフェイルオーバー プロシージャと中間層で統合して クライアントとアプリケーションをスタンバイ ロケーションの新しい本番データベースに自動的にリダイレクトする追加機能を提供します これにより ビジネスの継続性を達成するエンドツーエンドなソリューションが提供されます クライアント フェイルオーバーに対するData Guard 構成のベスト プラクティスは MAAのホワイト ペーパー Oracle Data Guard 10g Release 2 Client Failover Best Practices [12] で説明しています まとめ Data Guard 10g Release 2 の拡張機能 およびこのホワイト ペーパーで説明したベスト プラクティスにより 次のような一般的な問題を克服してロール推移の高速化を実現できます フェイルオーバーの検出と対応は遅いため 時間がかかります 障害発生場所の特定 管理者への通知に時間がかかる場合もあります Data Guard のファスト スタート フェイルオーバーは自動で障害を検出し 必要に応じてフェイルオーバーを実行します 問題の評価には時間がかかります 障害にフェイルオーバーを実行する正当な理由があるかを判定するためには さらに時間がかかります Data Guard のファスト スタート フェイルオーバーは 確立された基準を基に判断を行い 基準を満たす場合にフェイルオーバーを自動で実行します データ消失の量を抑えるには フェイルオーバーの正確なプロシージャを実行する必要があります Data Guard のファスト スタート フェイルオーバーは フェイルオーバーのプロシージャに影響をあたえる人的エラー発生の可能性を排除します フェイルオーバー後 古い本番データベースを再構築するには 時間とリソースが必要で ビジネスはプロセスが完了するまで二次的な障害の危険にさらされます ファスト スタート フェイルオーバー後 オブザーバは 古い本番データベースへの接続を定期的に試行します 古い本番データベースに再接続されると オブザーバは古い本番データベースを復元します これによって古い本番データベースは 新しい本番データベースに対するスタンバイ データベースになります これらの機能により Data Guard 構成の高可用性が迅速に回復されます スイッチオーバーとフェイルオーバーのベスト プラクティス :Oracle Data Guard 10g Release 2 18

スイッチオーバーまたはフェイルオーバー後 データベースをリストアするには時間がかかります Oracle Database 10g Release 2 以降では 以前はフィジカル スタンバイ データベースであったデータベースが 最後に起動されてから読取り専用として開かれなかった場合 新しい本番データベースを MOUNT 状態から開くことができます 手動のデータベース フェイルオーバーは 本質的にストレスの多い作業であるため エラーが発生しやすく様々な問題を抱えています ファスト スタート フェイルオーバーを有効にすると 本番データベースが消失した場合 Data Guard は事前に選択され同期化されたスタンバイ データベースにフェイルオーバーします データ消失は発生せず 手動の介入も必要ありません このため 手動管理のフェイルオーバーで発生する可能性があるエラーを最小限に抑えることができます 参考資料 1. Oracle Data Guard http://otndnld.oracle.co.jp/products/database/oracle10g/availability/htdocs/availabilit y/dataguardoverview.html 2. Oracle Maximum Availability Architecture http://otn.oracle.co.jp/products/availability/htdocs/maa.html 3. Oracle Data Guard 10g Release 2 Fast-Start Failover Best Practices( 英語 ): http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm 4. Oracle Database 高可用性概要 http://otndnld.oracle.co.jp/document/products/oracle10g/102/doc_cd/nav/portal_4.ht m 5. Oracle Data Guard 概要および管理 http://otndnld.oracle.co.jp/document/products/oracle10g/102/doc_cd/nav/portal_4.ht m 6. Oracle 10g SQL Apply Best Practices (for logical standby databases)( 英語 ) http://www.oracle.com/technology/deploy/availability/pdf/maa_wp_10gr2_sqla pplybestpractices.pdf 7. Oracle 10g Redo Apply and Media Recovery Best Practices (for physical standby databases)( 英語 ) http://www.oracle.com/technology/deploy/availability/pdf/maa_wp_10grecovery BestPractices.pdf 8. Fast-Application Notification(FAN) 参考資料 Oracle Clusterware および Oracle Real Application Clusters 管理およびデプロイメント ガイド http://otndnld.oracle.co.jp/document/products/oracle10g/102/doc_cd/nav/portal_ 4.htm スイッチオーバーとフェイルオーバーのベスト プラクティス :Oracle Data Guard 10g Release 2 19

Oracle Database High Availability Overview (Part #B14210-01) http://download-west.oracle.com/docs/cd/b19306_01/server.102/b14210/hafeatu res.htm#sthref54 9. Automatic Storage Management(ASM) 参考資料 Oracle Database Administrator s Guide (Part #B14231-01) http://download-west.oracle.com/docs/cd/b19306_01/server.102/b14231/storem an.htm#i1021337 Oracle Database High Availability Overview (Part #B14210-01) http://download-west.oracle.com/docs/cd/b19306_01/server.102/b14210/hafeatu res.htm#sthref43 10. Hardware Assisted Resilient Data (HARD) Initiative: Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide http://download-west.oracle.com/docs/cd/b19306_01/rac.102/b14197/hafeats.ht m#sthref428 Oracle Database High Availability Overview http://download-west.oracle.com/docs/cd/b19306_01/server.102/b14210/hafeatu res.htm#sthref54 11. Transparent Application Failover(TAF) 参考資料 Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide http://download-west.oracle.com/docs/cd/b19306_01/rac.102/b14197/hafeats.ht m#sthref428 12. Oracle Data Guard 10g Release 2 Client Failover Best Practices http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm 10gR2 バージョンのホワイト ペーパーはまもなく発行されます 13. Oracle Database Backup and Recovery Basics (Part # B14192-02) http://download-west.oracle.com/docs/cd/b19306_01/backup.102/b14192/toc.htm 14. Oracle Data Guard Broker (Part #B14230-01) http://download-west.oracle.com/docs/cd/b19306_01/server.102/b14230/toc.htm スイッチオーバーとフェイルオーバーのベスト プラクティス :Oracle Data Guard 10g Release 2 20

スイッチオーバーとフェイルオーバーのベスト プラクティス Oracle Data Guard 10g Release 2 2007 年 1 月著者 : Mike Smith, Lawrence To, and Viv Schupmann 寄稿者 : Joseph Meeks and Ashish Ray Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問合せ窓口 : 電話 : +1.650.506.7000 ファックス : +1.650.506.7200 www.oracle.com Copyright 2007, Oracle. 無断転載を禁ず この文書はあくまで参考資料であり 掲載されている情報は予告なしに変更されることがあります オラクル社は 本ドキュメントの無謬性を保証しません また 本ドキュメントは 法律で明示的または暗黙的に記載されているかどうかに関係なく 商品性または特定の目的に対する適合性に関する暗黙の保証や条件を含む一切の保証または条件に制約されません オラクル社は 本書の内容に関していかなる保証もいたしません また 本書により 契約上の直接的および間接的義務も発生しません 本書は 事前の書面による承諾を得ることなく 電子的または物理的に いかなる形式や方法によっても再生または伝送することはできません Oracle JD Edwards PeopleSoft は Oracle Corporation および関連会社の登録商標です 他の製品名は それぞれの所有者の商標です