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

スイッチオーバーとフェイルオーバー

のベスト・プラクティス：Oracle Data

Guard 10g Release 2

Oracle の最大可用性アーキテクチャのホワイト・ペーパー

2007 年 1 月

Maximum

Availability

Architecture

スイッチオーバーとフェイルオーバーの

ベスト・プラクティス

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

スイッチオーバーとフェイルオーバーの

ベスト・プラクティス

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 文を使用し て実行されました。

所見およびベスト・プラクティス

− 概要

適切に計画し実行した場合、Data Guard のロール推移によりダウンタイムが最小 限に抑えられ、ビジネスへの影響を最小にしたうえでデータベース環境がリスト アされます。フィジカル・スタンバイ・データベースまたはロジカル・スタンバ イ・データベースの使用とは関係なく、MAA テストでは Oracle Data Guard 10g Release 2 を使用したスイッチオーバー時間とフェイルオーバー時間が、秒単位に 短縮されることが確認されました。 • サイト障害およびデータベース障害に対する秒単位の自動フェイルオー バー • データ破損に対する秒単位の自動フェイルオーバー • システム、ハードウェアまたはサイト変更のための計画的なダウンタイ ムを短縮する、秒単位の手動スイッチオーバー Data Guard および関連するソリューションを使用して、様々な停止に対して実現 できるソリューションとリカバリ時間を表 1 に示します。 表 1: 計画外停止と計画的停止に対する Oracle のソリューション 停止のタイプ Oracle のソリューション リカバリ時間 コンピュータ障害 • ファスト・スタート・フェイルオーバーと Fast-Application Notification (FAN) [8] 30 秒未満 ストレージ障害 • ファスト・スタート・フェイルオーバーと Fast-Application Notification

• Data Guard と Automatic Storage Management (ASM) [9]

30 秒未満

ダウンタイムなし 1

データ破損 • REDO ブロックの適用前に、それらを自動的に検証し、本番

データベースが破損した場合、破損していないスタンバイ・ データベースへ迅速にフェイルオーバーする

• Data Guard と Hardware Assisted Resilient Data (HARD) Initiative [10] 30 秒未満 ダウンタイムなし 2 サイト障害 • ファスト・スタート・フェイルオーバーと Fast-Application Notification (FAN) [8] 30 秒未満 3 システムとクラスタ のアップグレード • RAC ローリング・アップグレードを使用したアップグレー ドが不可能なシステム・アップグレードの場合（例: ダウン タイムが必要なシステム制限またはクラスタ・ファームウェ アのアップグレード）、フィジカルまたはロジカル・スタン バイ・データベースにスイッチオーバー 数秒から数分 すべてのパッチ・セッ トとデータベースの アップグレード 4

• Data Guard SQL Apply およびロジカル・スタンバイ・データ ベースを使用して Oracle データベースをアップグレード

数秒から数分

1 _{ミラー化および自動的なバランスの再調整機能を持つAutomatic Storage Management（ASM）を使用す}

ると、ストレージ障害を回避できます。 2 _{ストレージ・ベンダーが実装したHARD Initiativeによってデータ損失を防止する場合、ダウンタイム} はありません。 3 _{リカバリ時間の対象となるのは、データベースおよび既存のデータベース接続障害です。ネットワー} ク接続の変更や他のサイト固有のアクティビティによっては、リカバリにかかる合計時間が長くなる 場合があります。

4 _{Oracle Database Release 10.1.0.3 以降専用にサポートされています。また、SQL Applyにデータ型の制限}

があることに注意してください。詳細は、『Oracle Data Guard Concepts and Administration』[5]でリス トを参照してください。

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速

• フィジカル・スタンバイ・データベースの場合

° 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 のリアルタイム適用を使用します。これによってスタンバイ・データ ベースは、スイッチオーバー時間を最小限に抑えるため処理前に本番データ ベースと同期化されます。

• スイッチオーバー時に障害が発生した場合、処理を簡単に取り消せるように フラッシュバック・データベースを有効にします。 • スイッチオーバーを実行する前に、ローカルおよびリモートのアーカイブに 必要な 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 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. フィジカル・スタンバイ・データベースを本番ロールに変換します。

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 の停止、 本番ロールのロジカル・スタンバイ・データベースのアクティブ化を実行し ます。

注意: フェイルオーバーの実行前に、スタンバイ 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 の機能 の１つです。迅速かつ確実に、ターゲット・スタンバイ・データベースを本番デー タベース・ロールにフェイルオーバーします。管理者は手動でフェイルオーバー を実行する必要がなく、データが消失することもありません。

ファスト・スタート・フェイルオーバーを実行するには、Data Guard 構成と Data

Guard Broker を事前に設定する必要があります。設定が有効の場合、オブザーバ は Data Guard 構成を年中無休で監視し、本番データベースが一定期間使用不可能 になるたびに、指定されたターゲット・スタンバイ・データベースのファスト・ スタート・フェイルオーバーを自動的に開始します。 自動フェイルオーバーが開始されるためには、ファスト・スタート・フェイルオー バーの 3 つのメンバー（本番データベース、ターゲット・スタンバイ・データベー ス、オブザーバ）のうち少なくとも 2 つについて必須条件がすべて満たされてい る必要があります。これにより、1 つの本番データベースのみがトランザクショ ンを受け入れることが保証され、一般に「スプリット・ブレイン」と呼ばれるシ ナリオが回避されます。

Broker のクライアントであるオブザーバは、Data Guard 構成を監視し、Data Guard が本番データベースに確実に接続できるようにします。オブザーバとスタンバ イ・データベースが共に本番データベースから切断されると、オブザーバは管理 者が定義した一定時間、本番データベースへの再接続を試みますが、オブザーバ とスタンバイ・データベースが本番データベースに接続できない場合は、フェイ ルオーバーが開始されます。

またフェイルオーバー後、データベースが再起動されると（データベースが再起 動可能で、オブザーバへの接続を確立できると仮定して）、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 を設定できます。

ファスト・スタート・フェイルオーバーの詳細な構成情報は、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 秒でした。

単一インスタンス・データベース

このホワイト・ペーパーのセクション、「フェイルオーバーのベスト・プラクティ ス」で説明したベスト・プラクティスを使用した場合、単一インスタンス・デー タベースの平均フェイルオーバー時間は次のようになりました。 手動フェイルオーバー ファスト・スタート・ フェイルオーバー 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]の「ロール推移」の章 で提供されています。

スイッチオーバー

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 構成の場合、１つの本番インス タンスを除くすべてのインスタンスを完全に停止し、適用インスタンスを除 くすべてのスタンバイ・インスタンスを停止します（これは、各クラスタで 単一インスタンスが実行している状態です）。この操作を加速するには、セ カンダリ RAC インスタンスで SHUTDOWN ABORT を発行します。

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 が本 番データベースに受信されたことを確認します。

最初は、SWITCHOVER_STATUS 列に「PREPARING DICTIONARY」が表 示され、LogMiner Multiversioned Data Dictionary は、REDO ストリームに 記録されます。これが正常に終了すると、列に「PREPARING

SWITCHOVER」が表示されます。問合せによって TO LOGICAL STANDBY 値が戻されたら、次の手順に進みます。 4. 可能な場合、ユーザー・セッションを切断し、アプリケーション処理を 無効にするか停止します。 5. 本番およびスタンバイ・データベースが RAC 構成の場合、１つの本番イ ンスタンスを除くすべてのインスタンスを完全に停止し、適用インスタ ンスを除くすべてのスタンバイ・インスタンスを停止します（これは、 各クラスタで単一インスタンスが実行している状態です）。停止操作を 最適化するには 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 秒でした。 次の表に、単一インスタンスの本番データベースおよびロジカル・スタンバイ・ データベースでスイッチオーバーの実行に必要な合計時間を示します。

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 が管理するスイッチオーバーではこの 機能が使用されないためです。

アプリケーションとクライアントのフェイルオーバー

ユーザーの可用性要件に最適なアーキテクチャを選択し実装するのは、困難な作 業になる場合があります。可用性の高いアーキテクチャは、高速なデータベース・ フェイルオーバーを実行できるだけではなく、あらゆるタイプの障害に対するク ライアント・フェイルオーバーに対応できる必要があります。

新しい 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 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 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)

スイッチオーバーとフェイルオーバーのベスト・プラクティス 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 および関連会社の登録商標です。他の製品名は、それぞれの 所有者の商標です。