1. Broker
  2. スイッチオーバー操作とフェイルオーバー操作

5 スイッチオーバー操作とフェイルオーバー操作

Oracle Data Guard Brokerを使用して、スイッチオーバーおよびフェイルオーバー中にデータベースを管理する方法を学習します。

5.1 ブローカ環境でのスイッチオーバーおよびフェイルオーバーの概要

Oracle Data Guardにより、スイッチオーバー操作またはフェイルオーバー操作のいずれかを使用して、プライマリとスタンバイ間でデータベースのロールを変更できます。

  • スイッチオーバーとは、プライマリ・データベースとそのスタンバイ・データベースの1つとの間でロールを可逆的に推移させる操作です。スイッチオーバーでは、データの消失がないことが保証され、通常は予定されたプライマリ・システムのメンテナンスの際に実行されます。スイッチオーバー中は、プライマリ・データベースがスタンバイ・ロールに遷移し、スタンバイ・データベースがプライマリ・ロールに遷移します。

  • フェイルオーバーは、プライマリ・データベース(Oracle RACデータベースの場合はすべてのインスタンス)に障害が発生するか、アクセス不能になった場合に、スタンバイ・データベースの1つがプライマリ・ロールに移行されるロール・トランジションです。フェイルオーバーでは、フェイルオーバー時に有効な保護モードによって、データが消失する場合としない場合があります。

ブローカでは、Oracle Enterprise Manager Cloud Control (Cloud Control)でキーを1回クリックするか、DGMGRLコマンドライン・インタフェースで単一のコマンドを使用してスイッチオーバーおよびフェイルオーバーを起動できるため(このドキュメントでは手動フェイルオーバーと呼びます)、これらの操作が簡素化されます。スイッチオーバーの管理の一環として、ブローカでは次の作業を自動的に実行します。

  • 新しいプライマリから構成内の別のメンバーへのREDO転送の設定

  • 新しいスタンバイでのREDO Applyサービスの開始

  • ブローカ構成内の別のスタンバイが新しいプライマリに対して実行可能であることの確認

  • Oracle ClusterwareおよびOracle Global Data Services (GDS)と統合し、ロール変更後に適切なサービスが開始されていることの確認

ファスト・スタート・フェイルオーバーが有効化されている場合、ブローカによってフェイルオーバーの必要性が判断され、現在のターゲット・スタンバイ・データベースへのフェイルオーバーが自動的に開始されます。手動による操作は不要です。手動操作の必要性が減少したことで、管理コストを上げずに可用性を向上できます。手動フェイルオーバーでは、フェイルオーバーを実行する正確なタイミングおよび対象となるターゲット・スタンバイ・データベースを管理できます。選択する方法に関係なく、ブローカによって構成内のすべてのデータベースのロール遷移が調整されます。

5.2 ターゲット・スタンバイ・データベースの選択

スイッチオーバーまたはフェイルオーバー後に次のプライマリ・データベースにするスタンバイ・データベースを選択する際には、いくつかの考慮事項があります。

Oracle Data Guard構成を構築する際には、フィジカル・スタンバイ、ロジカル・スタンバイおよびスナップショット・スタンバイの各特性、スタンバイ・データベース・サイトに対するネットワーク待機時間、将来のプライマリ・データベース・サイトにおけるコンピューティング機能などの要素を含む、すべてのオプションを考慮する必要があります。

ノート:

スナップショット・スタンバイを、スイッチオーバーまたはファスト・スタート・フェイルオーバー操作のターゲットにすることはできません。ただし、スナップショット・スタンバイへの手動フェイルオーバーは実行できます。

遠隔同期インスタンスまたはZero Data Loss Recovery Applianceはデータベースではないため、ロール遷移のターゲットにはできません。

スイッチオーバーについては、すべての要素を理解することで、新規プライマリ・データベースとみなすスタンバイ・データベースを簡単に選択できます。フェイルオーバーが必要な障害が発生した場合、障害のあるプライマリ・データベースのアクティビティを再開するのに最適なスタンバイ・データベースは、スイッチオーバーの場合よりも絞られる可能性があります。「スイッチオーバーでのターゲット・スタンバイ・データベースの選択」と「フェイルオーバーでのターゲット・スタンバイ・データベースの選択」に、ターゲット・スタンバイ・データベースの選択に役立つガイドラインを示します。

ノート:

ファスト・スタート・フェイルオーバーの場合、1つ以上のターゲット・スタンバイ・データベースを事前に選択する必要があります。必要に応じて、複数のターゲットを事前に選択することもできますが、相互に指定しあうようにする必要はありません。

データベースのロール変更可能状況の判定

適切なスイッチオーバーまたはフェイルオーバーのターゲットを選択するには、次のようなDGMGRLコマンドを使用してデータベースでチェックを実行し、ロールの変更を完了するための準備状況を確認します。

関連項目:

5.2.1 スイッチオーバーでのターゲット・スタンバイ・データベースの選択

スタンバイ・データベースがすべて同じタイプである(すべてフィジカルまたはすべてロジカル・スタンバイ・データベース)構成内でスイッチオーバーを実行する場合、未適用のREDOの数が最も少ないスタンバイ・データベースを選択します。

未適用のREDOの数が最も少ないスタンバイ・データベースを選択することで、スイッチオーバー操作が完了するまでの全体の所要時間を最小限にできます。次に例を示します。

  • DGMGRLを使用し、SHOW CONFIGURATION LAGの出力を調べることによって、これを行うことができます。

  • Cloud Controlを使用する場合は、Oracle Data Guardの概要ページの「スタンバイ・データベース」セクションで、各スタンバイ・データベースのApplyLag列の値を表示できます。

構成にフィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データベースの両方が含まれる場合、ターゲット・スタンバイ・データベースとして(未適用REDOの数が最も少ない)フィジカル・スタンバイ・データベースを選択することを考慮します。スイッチオーバー操作の完了後は、構成内のすべてのデータベースが新規プライマリ・データベースに対するスタンバイ・データベースとして使用可能になるため、フィジカル・スタンバイ・データベースへのスイッチオーバーをお薦めします。一方、ロジカル・スタンバイ・データベースにスイッチオーバーすると、構成内のフィジカルおよびスナップショット・スタンバイ・データベースがすべて無効化されます。そのため、フィジカル・スタンバイ・データベースを再有効化するには、新規プライマリ・データベースのコピーからフィジカル・スタンバイ・データベースを再作成する必要があります。または、比較的すぐに元のプライマリにスイッチバックする場合は、無効化されたスタンバイ・データベースをスイッチバック後に再有効化できることがあります。

スナップショット・スタンバイ・データベースへのスイッチオーバーを実行するには、最初にフィジカル・スタンバイ・データベースに戻す必要があります。

ノート:

Oracle Data Guard構成が最大保護モードで動作している場合、ブローカではロジカル・スタンバイ・データベースへのスイッチオーバーが許可されません。ロジカル・スタンバイ・データベースへのスイッチオーバーを実行するには、構成が最大可用性モードまたは最大パフォーマンス・モードのいずれかで動作している必要があります。

5.2.2 フェイルオーバーでのターゲット・スタンバイ・データベースの選択

フェイルオーバーを実行するとき、構成内のスタンバイがすべて同じタイプである場合は、最も転送ラグの小さいスタンバイ・データベースを選択します。

最も転送ラグの小さいスタンバイ・データベースを選択することにより、データの消失量を最小限に抑え、場合によってはデータの消失をゼロにすることができます。

構成にフィジカル・スタンバイ・データベース、スナップショット・スタンバイ・データベースおよびロジカル・スタンバイ・データベースが含まれる場合、ターゲット・スタンバイ・データベースとしてフィジカル・スタンバイ・データベースを選択することを考慮します。フェイルオーバー操作の完了後は、構成内のすべてのスタンバイ・データベースが新規プライマリ・データベースに対するスタンバイ・データベースとして使用可能になる可能性が高いため、フィジカル・スタンバイ・データベースへのフェイルオーバーをお薦めします。

スナップショット・スタンバイ・データベースにフェイルオーバーすることもできます。ただし、スナップショット・スタンバイ・データベースにフェイルオーバーするには、ブローカがこのデータベースを最初にフィジカル・スタンバイ・データベースに戻す必要があるため、時間がかかります。変換した後、ブローカは、プライマリ・ロールへのデータベースのフェイルオーバーを実行する前に、REDO Applyを起動して累積REDOデータを適用します。スナップショット・スタンバイ・データベースをフィジカル・スタンバイ・データベースに変換してからフェイルオーバーが実行されるため、フェイルオーバー操作の完了後、構成内のすべてのスタンバイ・データベースを新しいプライマリ・データベースへのスタンバイ・データベースとして使用することが可能になります。

ロジカル・スタンバイ・データベースにフェイルオーバーするには、フェイルオーバーの完了後に、新しいプライマリ・データベースのコピーからすべてのフィジカルおよびスナップショット・スタンバイ・データベースを再作成する必要があります。さらに、ロジカル・スタンバイ・データベースには、プライマリ・データベースに存在するデータのサブセットのみが含まれる可能性があります。(たとえば、プライマリ・データベース上で実行されるデータベース操作のうちロジカル・スタンバイ・データベースに適用しない操作を指定する際に、DBMS_LOGSTDBY.SKIPプロシージャが使用された場合など。)

ただし、例外として、ターゲット・スタンバイ・データベースとしてフィジカル・スタンバイ・データベースを選択することをお薦めできない場合があります。たとえば、フィジカル・スタンバイ・データベースもすべて利用できない場合は、ロジカル・スタンバイ・データベースへのフェイルオーバーが唯一の選択肢となります。

5.3 スイッチオーバー

スイッチオーバーとは、プライマリ・データベースといずれかのスタンバイ・データベースとの間のロール・リバーサルです。

スイッチオーバーでは、データの消失がないことが保証され、通常は予定されたプライマリ・システムのメンテナンスの際に実行されます。スイッチオーバー中は、プライマリ・データベースがスタンバイ・ロールに遷移し、スタンバイ・データベースがプライマリ・ロールに遷移します。

可能な場合は必ず、フィジカル・スタンバイ・データベースに対してスイッチオーバーしてください。

  • スイッチオーバーによりフィジカル・スタンバイ・データベースをプライマリ・ロールに遷移する場合、次のようになります。

    • 元のプライマリ・データベースはフィジカル・スタンバイ・ロールに切り替えられます。

    • 構成の他のメンバーは、新しいプライマリに基づいて指定されたREDOソースからREDOを受信します。

    • スイッチオーバー操作の一部として、元のプライマリ・データベースが再起動されます。新しいプライマリ・データベースを再起動する必要がないことに注意してください。

      スイッチオーバーに関係しないスタンバイ・データベース(その他のスタンバイ・データベース)は、スイッチオーバーが発生する前の状態で引き続き動作し、新しいプライマリ・データベースから受け取ったREDOデータの適用を自動的に開始します。

  • スイッチオーバーによりロジカル・スタンバイ・データベースをプライマリ・ロールに遷移する場合、次のようになります。

    • 元のプライマリ・データベースはロジカル・スタンバイ・ロールに切り替えられます。

    • スイッチオーバーの完了後、プライマリ・データベースおよびロジカル・スタンバイ・データベースのどちらも再起動の必要はありません。

      ブローカ構成内の他のロジカル・スタンバイ・データベースは、スイッチオーバー後も実行可能です。ロジカル・スタンバイ・データベースへのスイッチオーバーの後、すべてのフィジカルおよびスナップショット・スタンバイ・データベースは無効化されるため、新しいプライマリ・データベースのコピーから再作成する必要があります。

    構成が最大保護モードで動作している場合、ロジカル・スタンバイ・データベースへのスイッチオーバーは許可されません。

    警告:

    ロジカル・スタンバイ・データベースにスイッチオーバーすると、ブローカ構成内のスナップショット・スタンバイ・データベースとフィジカル・スタンバイ・データベースはブローカにより無効化され、これらのデータベースはスタンバイ・データベースとして実行できなくなります。スタンバイ・データベースとして実行可能な状態にリストアする方法は、「ロール変更後の無効化されたデータベースの再有効化」を参照してください。

    比較的すぐに元のプライマリ・データベースにスイッチバックする場合は、フィジカルおよびスナップショット・スタンバイ・データベースを無効なままにしておくことができます。フィジカルおよびスナップショット・スタンバイ・データベースはまだ元のプライマリ・データベースの実行可能なスタンバイ・データベースであるため、元のプライマリ・データベースへのスイッチバックの完了後、これらを再有効化できます。

5.3.1 スイッチオーバー操作実行前の考慮事項

次に、スイッチオーバーを開始する前の考慮点を示します。

  • スイッチオーバーを開始すると、ブローカは、スイッチオーバーの完了後に少なくとも1つのスタンバイ・データベース(スタンバイ・ロールに遷移する予定のプライマリ・データベースも含む)が、全体の保護モード(最大保護、最大可用性または最大パフォーマンス)をサポートするように構成されているかどうかを検証します。

  • 全体の保護モードとの関連で、将来考えられるスタンバイ・データベースとしてのロールに備えて、あらかじめプライマリ・データベースを準備しておきます(「データ保護モードの管理」を参照してください)。こうした準備には、次の操作が含まれます。

    • プライマリ・データベースでスタンバイREDOログ・ファイルが構成されていることを確認します。

    • LogXptMode、NetTimeout、StandbyArchiveLocation、StandbyAlternateLocationおよびRedoRoutesなど、REDO転送サービス関連のデータベース・プロパティをあらかじめ設定します。データベース・プロパティを使用したREDO転送サービスの管理の詳細は、「REDO転送サービスの管理」を参照してください。

    • DelayMinsなど、REDO Applyサービス関連のデータベース・プロパティをリセットします。遅延の適用がある場合は、スイッチオーバーを開始する前にすべて削除する必要があります。ブローカでは、遅延の適用が構成されている(DelayMinsプロパティがゼロ(0)以外の値に設定されている)スタンバイへのスイッチオーバーはできません。プロパティを使用したREDO Applyサービスの管理の詳細は、「ログ適用サービスの管理」を参照してください。

    • 一時表ごとに、プライマリ・データベース上の一時表に関連付けられた一時ファイルがスタンバイ・データベースにも存在することを確認します。

    これらのプロパティは、実際にプライマリ・データベースをスタンバイ・ロールに切り替えるまで、ブローカによってREDO転送サービスとREDO Applyサービスの設定に使用されないことに注意してください。そのため、これらのプロパティの値の妥当性は、スイッチオーバー後まで検証されません。これらのプロパティを設定すると、その値はスイッチオーバーおよびフェイルオーバー時のロール変更を通じて存続します。

  • ファスト・スタート・フェイルオーバーが有効化されている場合、スイッチオーバーを実行できるのは、事前に指定されたターゲット・スタンバイ・データベースに対してのみであり、スタンバイ・データベースがプライマリ・データベースと同期化されているか(最大可用性モード)、構成されている制限範囲内にラグが収まっている(最大パフォーマンス・モード)場合に限られます。ファスト・スタート・フェイルオーバーの有効化の詳細は、「ファスト・スタート・フェイルオーバーの有効化」を参照してください。

  • SHOW CONFIGURATION WHEN PRIMARY ISコマンドを使用すると、指定したデータベースがプライマリ・データベースであった場合に有効になるREDO転送構成(RedoRoutesプロパティの各メンバーの設定に基づく)が表示されます。この情報を使用して、ロール変更の後に不適切になるREDO転送構成があれば事前に特定できます(たとえば、RedoRoutesプロパティが正しく構成されなかったためにREDOを受け取れないスタンバイなど)。

スイッチオーバーの完了後、ブローカにより、保護モードがスイッチオーバー前と同じ保護レベル(最大保護、最大可用性または最大パフォーマンス)に維持され、スイッチオーバー・プロセスの一部として全体のOracle Data Guard保護モードが保持されます。他のすべてのその他のスタンバイ・データベースに対する適用サービスは、新しいプライマリ・データベースから受け取ったREDOデータの適用を自動的に開始します。

構成内にフィジカルまたはスナップショット・スタンバイ・データベースが存在するとき、ロジカル・スタンバイ・データベースへのスイッチオーバーが発生した場合は、「ロール変更後の無効化されたデータベースの再有効化」に示すように、新しいプライマリ・データベースのコピーからこれらのデータベースを再作成し、データベースを再び有効化する必要があります。

ノート:

Oracle Data Guard構成では、SRVCTL -startoptionおよび-roleはスイッチオーバー後に更新され、現在のオープン・モードおよびデータベース・ロールが新しいプライマリ・データベースとスタンバイ・データベースに反映されます。ブローカとOracle Restartの対話に関する追加情報は、「データベース・サービスの構成要件」を参照してください。

5.3.2 スイッチオーバーの開始

スイッチオーバーを開始する場合、関係するプライマリ・データベースとスタンバイ・データベースのREDOラグは、できるかぎり低くする必要があります。

ロールの切替えは、慎重に計画して実行する必要があります。スイッチオーバーに備えたデータベースの設定方法の詳細は、『Oracle Data Guard概要および管理』を参照してください。

Cloud Controlを使用してスイッチオーバーを開始するには、プライマリ・ロールに変更するスタンバイ・データベースを選択して「スイッチオーバー」をクリックします。DGMGRLを使用する場合は、SWITCHOVERコマンドを発行し、プライマリ・ロールに変更するスタンバイ・データベースの名前を指定する必要があります。

ブローカは残りのスイッチオーバーを制御します。

5.3.3 ブローカによるスイッチオーバーの実行方法

スイッチオーバーの開始後にブローカが実行するアクションは、次のとおりです。

  1. プライマリ・データベースとターゲットのスタンバイ・データベースが次の状態であることを検証します。

    1. プライマリ・データベースが有効化されてTRANSPORT-ON状態であること。

    2. ターゲット・スタンバイ・データベースが有効化されてAPPLY-ON状態であること。

    ブローカは、スイッチオーバー操作に関連して選択したプライマリ・データベースとスタンバイ・データベースにエラーがないかぎり、スイッチオーバーを続行します。エラーが他の構成メンバーに発生していても、スイッチオーバーは妨げられません。

  2. プライマリ・データベースおよびスタンバイ・データベースのロールを切り替えます。

    ブローカは最初に、元のプライマリ・データベースを変換してスタンバイ・ロールで実行するようにします。いずれかの変換時にエラーが発生すると、ブローカはスイッチオーバーを停止します。詳細は、「スイッチオーバー操作時の問題のトラブルシューティング」を参照してください。

  3. ブローカ構成ファイルを更新し、ロールの変更を記録します。

    これにより、なんらかの理由でデータベースが後で再起動される際に、REDO転送やREDO Applyなどの適切なData Guardサービスを開始できます。

  4. フィジカル・スタンバイ・データベースへのスイッチオーバーを行った場合は新しいスタンバイ・データベース(元のプライマリ・データベース)を再起動すると、REDO Applyが新しいプライマリ・データベースからのREDOデータの適用を開始します。Oracle Clusterwareが管理するOracle RACのフィジカル・スタンバイ・データベースの場合は、ブローカの指示により、Oracle Clusterwareが新しいスタンバイ・データベースを再起動します。

  5. 新しいプライマリ・データベースが読取り/書込みモードでオープンし、REDO転送サービスが開始します。

    リアルタイム問合せが有効な状態で元のフィジカル・スタンバイ・データベースが実行されていた場合、新しいフィジカル・スタンバイ・データベースはリアルタイム問合せが有効な状態で実行されます。

ブローカは各データベースの状態とステータスを検証し、スイッチオーバーによって、各データベースが新しいロールにそれぞれ正常に遷移していることを確認します。スイッチオーバー後にブローカにより無効化されていないその他のスタンバイ・データベースは、スイッチオーバー前の状態で引き続き動作します。他のすべてのその他のスタンバイ・データベースに対するSQL Applyは、新しいプライマリ・データベースから受け取ったREDOデータの適用を自動的に開始します。

万一スイッチオーバー操作が失敗し、プライマリ・データベースがなくなった場合は、スイッチオーバー・コマンドを再試行します。元のプライマリにスイッチ・バックでき、その後、元のターゲット・スタンバイへのスイッチオーバーを再試行するか、スイッチオーバー先として構成内の別のスタンバイを選択できます。

5.4 手動フェイルオーバー

手動フェイルオーバーでは、元のプライマリ・データベースで障害が発生し、プライマリ・データベースを適時にリカバリできる可能性がない場合に、スタンバイ・データベースをプライマリ・データベースに変換します。

プライマリ・データベースに障害が発生した時点でプライマリ・データベースとターゲット・スタンバイ・データベースが同期化されていたかどうかによって、データが消失する場合があります。手動という用語は、このタイプのフェイルオーバーとファスト・スタート・フェイルオーバー(「ファスト・スタート・フェイルオーバー」を参照)を比較する目的で使用します。

ノート:

ファスト・スタート・フェイルオーバーが有効化されている場合でも、手動フェイルオーバーを実行できます。詳細は、「ファスト・スタート・フェイルオーバーが有効化されている場合の手動によるロール変更の実行」を参照してください。

次の各項では、手動フェイルオーバーの実行方法について説明します。

5.4.1 完全手動フェイルオーバーおよび即時手動フェイルオーバー

Cloud ControlまたはDGMGRLを使用して、完全フェイルオーバー(推奨)または即時フェイルオーバーを実行できます。

  • 完全フェイルオーバーは、推奨方法でありデフォルトのフェイルオーバー・オプションです。完全フェイルオーバーでは、構成が動作している保護モードに応じて最大量のREDOデータが自動的にリカバリされます。また、フェイルオーバーのターゲットではないスタンバイ・データベースの無効化をできるかぎり回避して、新しいプライマリ・データベースに対するスタンバイ・データベースとして機能し続けられるようにします。

    フェイルオーバーのターゲットではないスタンバイ・データベース(その他のスタンバイ・データベース)を無効にするか否かは、フェイルオーバーのターゲットと比較して、ターゲットでないスタンバイに適用されたREDOデータの量、およびフェイルオーバー・ターゲットのスタンバイ・タイプに応じて異なります。

    • フェイルオーバーのターゲットがフィジカルまたはスナップショット・スタンバイ・データベースの場合、新しいプライマリ・データベースのスタンバイ・データベースにするには、元のプライマリ・データベースを回復または再作成する必要があります。また、一部のスタンバイ・データベースで新規プライマリ・データベースによる適用を超えてREDOを適用したことが検出された場合、ブローカはそれらのデータベースをフェイルオーバー中に無効化する場合があります。ブローカにより無効化されたデータベースは、新しいプライマリ・データベースのスタンバイ・データベースにする前に、「ロール変更後の無効化されたデータベースの再有効化」で説明する手順に従って回復または再作成する必要があります。

      スナップショット・スタンバイ・データベースでフェイルオーバーを実行した場合は、元のプライマリをフィジカル・スタンバイ・データベースとして回復または再作成する必要があることに注意してください。

    • フェイルオーバーのターゲットがロジカル・スタンバイ・データベースである場合、元のプライマリ・データベースおよび構成内のすべてのフィジカルおよびスナップショット・スタンバイ・データベースが無効化されます。フラッシュバック・データベースが有効化されている場合、プライマリ・データベースを回復できます。フィジカルおよびスナップショット・スタンバイ・データベースは、新規プライマリ・データベースのコピーから再作成する必要があります。詳細は、「ロール変更後の無効化されたデータベースの再有効化」を参照してください。

    プライマリ・データベースをマウントできる場合は、ALTER SYSTEM FLUSH REDO SQL文を使用して、プライマリ・データベースからターゲット・スタンバイ・データベースへの未送信REDOデータをすべてフラッシュできます。この操作が正常に完了すると、プライマリ・データベースがデータ消失ゼロの保護モードでなくても、データ消失がゼロのフェイルオーバーが可能になります。ALTER SYSTEM FLUSH REDO文の使用の詳細は、『Oracle Data Guard概要および管理』を参照してください。

    完全フェイルオーバー中は、「ブローカによる完全フェイルオーバー操作の実行方法」に示すフェイルオーバー・ステップがブローカによって実行されます。

  • 即時フェイルオーバーは、最も高速なタイプのフェイルオーバーです。ただし、フェイルオーバーの起動後は、スタンバイ・データベースに追加データが適用されません。即時フェイルオーバーを実行した場合は、構成内の他のすべてのデータベースが無効化されます。新規プライマリ・データベースのスタンバイ・データベースとして機能させるには、これらのデータベースを回復または再作成する必要があります。この方法は、「ロール変更後の無効化されたデータベースの再有効化」を参照してください。即時フェイルオーバー中は、「ブローカによる即時フェイルオーバー操作の実行方法」に示すフェイルオーバー・ステップがブローカによって実行されます。

    ノート:

    ORA-752またはORA-600 [3020]エラーにより、フェイルオーバー・ターゲットでREDO Applyが停止されていないかぎり、常に完全フェイルオーバーを最初に実行するようにします。これらのエラーのいずれかが発生した場合は、先に進む前に、My Oracle Supportノート1265884.1のスタンバイ・リカバリ時のORA-752またはORA-600 [3020]の解決のガイドラインに従います。このサポート・ノートは、http://support.oracle.comにあります。

    即時フェイルオーバーは、完全フェイルオーバーが失敗するか、前述のエラーの場合にのみ実行してください。完全フェイルオーバーは、REDO転送サービスの宛先属性に応じて、データ損失なしで実行できますが、即時フェイルオーバーでは、通常データ損失が発生します。

5.4.2 手動フェイルオーバー操作の実行

まずプライマリ・データベースを適時にリカバリできる可能性がないと判断し、プライマリ・データベースが停止していることを確認してから、フェイルオーバーを開始します。

この項の各ステップでは、手動フェイルオーバーの実行に関連するタスクについて説明します。フェイルオーバーおよび関係するスタンバイ・データベースのタイプによって、一部のデータベースの回復または再作成が必要となる場合があります。

5.4.2.1 手動フェイルオーバーの実行(タスク1): 使用可能なスタンバイ・データベースのうち、フェイルオーバーのターゲットとして最適なデータベースの決定

次に、ターゲット・スタンバイ・データベースを選択するためのガイドラインを示します。

ターゲット・スタンバイ・データベースの選択を参照してください。

5.4.2.2 手動フェイルオーバーの実行(タスク2): フェイルオーバーの開始

Cloud ControlまたはDGMGRLを使用して、完全フェイルオーバー(推奨)または即時フェイルオーバーを実行します。

Cloud Controlを使用した手動フェイルオーバー:

Cloud ControlのOracle Data Guardの概要ページで、プライマリ・ロールに変更するスタンバイ・データベースを選択して「フェイルオーバー」をクリックします。その後、フェイルオーバーの確認ページで「はい」をクリックし、デフォルトの「完全」フェイルオーバー・オプションを起動します。

DGMGRLを使用した手動フェイルオーバー

ターゲット・スタンバイ・データベースに接続し、FAILOVERコマンドを発行してフェイルオーバーを実行し、プライマリ・データベースにするスタンバイ・データベースの名前を指定します。 

DGMGRL> FAILOVER TO database-name;

次のいずれかの条件に当てはまる場合は、オプションのIMMEDIATE句を指定して、即時フェイルオーバーを実行します。

  • ORA-752エラーがスタンバイ・データベースで発生した場合

  • ORA-600 [3020]エラーがスタンバイ・データベースで発生し、その原因がプライマリ・データベースでの書込み欠落であるとOracleサポートが判断した場合

  • 完全フェイルオーバーが不可能な場合

DGMGRL> FAILOVER TO database-name IMMEDIATE;

関連項目:

完全フェイルオーバーを実行する場合、データベース・ロールがプライマリに変更される前に、すべての累積REDOデータが適用されます。即時フェイルオーバーを実行する場合、累積REDOデータは適用されずに、データベース・ロールがプライマリに変更されます。

ターゲットがスナップショット・スタンバイ・データベースの場合、ブローカは、最初にデータベースをフィジカル・スタンバイ・データベースに変換します。

ターゲット・スタンバイ・データベースがフィジカル・スタンバイまたはロジカル・スタンバイの場合、フェイルオーバーの実行時にインスタンスは停止されません。ターゲット・スタンバイ・データベースがスナップショット・スタンバイ・データベースの場合は、フェイルオーバーを実行する前に、そのすべてのインスタンスを再起動してマウント・モードにする必要があります。Cloud ControlおよびDGMGRL CLIは、フェイルオーバーの一部としてこれを自動的に実行します。

5.4.2.3 手動フェイルオーバーの実行(タスク3): 保護モードのリセット

このリストでは、手動(完全または即時)フェイルオーバー後の全体的なOracle Data Guard保護モードの処理方法について説明します。

  • 保護モードが最大保護だった場合は、最大パフォーマンスにリセットされます。必要に応じて、保護モードを後でアップグレードできます(「構成に対する保護モードの設定」を参照)。

  • 保護モードが最大可用性または最大パフォーマンスだった場合は、変更されません。

ノート:

ファスト・スタート・フェイルオーバーが有効化されている場合に手動フェイルオーバーを実行すると、次のようになります。

  • フェイルオーバーは、現在のターゲット・スタンバイ・データベースに対してのみ実行できます。

  • ブローカにより、フェイルオーバー前に有効になっていた保護モードが維持されます。

5.4.2.4 手動フェイルオーバーの実行(タスク4): 障害時リカバリ構成の再確立

他の障害が発生した場合に実行可能な障害時リカバリ・ソリューションを維持するには、追加ステップを実行する必要があります。

ロール変更後の無効化されたデータベースの再有効化を参照してください

  • 元のプライマリ・データベースを回復し、新規構成のスタンバイ・データベースとして機能させます。

    注意:

    ORA-752またはORA-600 [3020]エラーがフェイルオーバー・ターゲットで発生した場合、古いプライマリ・データベースの回復操作は行わないでください。かわりに、「無効化されたデータベースの再作成および再有効化の方法」で説明されている手順に従い、古いプライマリ・データベースを新しいプライマリのバックアップからスタンバイとして再作成する必要があります。

  • ブローカによって無効化された構成内のスタンバイ・データベースを回復または再作成します。

    完全フェイルオーバーが完了すると、新しいプライマリ・データベースのスタンバイとして実行可能でないその他のスタンバイ・データベースは、ブローカにより無効化されます。これは次のいずれかの理由で実行されます。

    • その他のスタンバイ・データベースに、新しいプライマリ・データベースがスタンバイ・データベースであったときに適用されたよりも多くのREDOデータが適用された場合。新しいプライマリ・データベースのスタンバイとして機能させるには、このスタンバイ・データベースを再作成または回復する必要があります。

    • ロジカル・スタンバイ・データベースにフェイルオーバーした場合。構成内のすべてのフィジカルおよびスナップショット・スタンバイ・データベースがブローカにより無効化されます。新しいプライマリ・データベースのスタンバイとして機能させるには、これらを再作成する必要があります。

5.4.2.5 ブローカによる完全フェイルオーバー操作の実行方法

次に、完全フェイルオーバーを開始した後のブローカによる処理を示します。

  1. ターゲット・スタンバイ・データベースが有効化されていることを確認します。データベースが有効化されていない場合、このデータベースに対するフェイルオーバーは実行できません。

  2. ターゲットのスタンバイ・データベースで未適用のREDOデータの適用が完了するまで待機し、適用が完了した後でREDO Apply(ターゲットがフィジカル・スタンバイ・データベースの場合)またはSQL Apply(ターゲットがロジカル・スタンバイ・データベースの場合)を停止します。

    ターゲットがスナップショット・スタンバイ・データベースの場合、ブローカは、最初にデータベースをフィジカル・スタンバイに戻し、次にREDO Applyを起動してすべての累積REDOを適用してから、フェイルオーバーを完了してデータベースをプライマリ・データベースとしてオープンします。

  3. ターゲット・スタンバイ・データベースを、次のように、プライマリ・データベース・ロールに遷移させます。

    1. データベースのロールをスタンバイからプライマリに変更します。

    2. 新しいプライマリ・データベースを読取り/書込みモードでオープンします。

    3. フェイルオーバー操作に関係しなかったスタンバイ・データベースを、新しいプライマリ・データベースより多くのREDOデータが適用されたために無効化する必要があるかどうかを判断します。

      このフェイルオーバー中に、その他のスタンバイ・データベースがブローカにより無効化されない場合は、フェイルオーバー前と同じ状態のままになります。たとえば、APPLY-OFF状態であったフィジカル・スタンバイ・データベースは、APPLY-OFF状態のままになります。

      デフォルトでは、ブローカは、完全フェイルオーバーを実行するたびにその他のスタンバイ・データベースが新しいプライマリに対する実行可能なスタンバイ・データベースであるかどうかを判別します。完全フェイルオーバーの実行時に、その他のスタンバイ・データベースの実行可能性のチェックをスキップして、全フェイルオーバー時間を短縮するには、BystandersFollowRoleChange構成プロパティをNONEに設定してください。

      このプロパティをNONEに設定すると、ブローカは、新しいプライマリ・データベースよりも多くのREDOデータが適用されているかどうかのチェックを実行せずに、その他のすべてのスタンバイ・データベースを無効にします。フェイルオーバーの完了後にスタンバイ・データベースを回復または再作成(「ロール変更後の無効化されたデータベースの再有効化」項を参照)する必要があります。SHOW CONFIGURATIONコマンドを使用して、回復可能なデータベースと再作成する必要のあるデータベースを表示します。このプロパティの値を表示するには、SHOW CONFIGURATION BystandersFollowRoleChangeコマンドを使用します。デフォルト値はALLです。

      このプロパティは、ファスト・スタート・フェイルオーバーの発生時にその他のスタンバイ・データベースの実行可能性チェックをスキップするかどうかにも影響を与えます。

    4. REDO転送サービスを起動して、無効化されていないすべてのその他のスタンバイ・データベースへのREDOデータの転送を開始します。

      ノート:

      フェイルオーバー中には、その他のスタンバイ・データベースがブローカにより無効化される場合があります。新しいプライマリ・データベースのスタンバイ・データベースとして機能させるには、これらのデータベースを回復または再作成する必要があります。すべてのデータベースでフラッシュバック・データベースを構成し、フィジカル・スタンバイ・データベースにフェイルオーバーを実行した場合に、無効化されたスタンバイ・データベースをより簡単に回復できるようにすることをお薦めします。ロジカル・スタンバイ・データベースにフェイルオーバーを実行した場合、すべてのフィジカルおよびスナップショット・スタンバイ・データベースがブローカにより無効化されます。この場合、データベースの回復にフラッシュバック・データベースは使用できません。新しいプライマリ・データベースのコピーから再作成する必要があります。フェイルオーバー中に無効化されたロジカル・スタンバイ・データベースは回復できます。

  4. Oracle RACのフィジカルまたはスナップショット・スタンバイ・データベースがフェイルオーバー・ターゲット・データベースである場合は、ブローカの指示により、Oracle Clusterwareがフェイルオーバーの前に停止されたインスタンスをすべて再起動します。

ブローカは、フェイルオーバーに関連して選択したスタンバイ・データベースにエラーがないかぎり、フェイルオーバーを続行します。エラーが他の構成メンバーに発生していても、スイッチオーバーは妨げられません。完全フェイルオーバーを開始して失敗した場合は、即時フェイルオーバーを使用する必要があります。

遠隔同期インスタンスを使用した構成内での完全フェイルオーバー

遠隔同期インスタンスからREDOデータを受け取るスタンバイ・データベースに、より完全なフェイルオーバーを手動で実行できます。フェイルオーバーするには、スタンバイ・データベースに接続し、DGMGRLのFAILOVER TO db-unique-nameコマンドを使用します。フィジカル・スタンバイをプライマリ・データベースに変換する前に、遠隔同期インスタンス上に存在して未送信のREDOデータがすべて、ターゲットのフィジカル・スタンバイに送信されます。

カスケーデッド・スタンバイを使用した構成内での完全フェイルオーバー

完全フェイルオーバーでは、別のスタンバイ・データベース(カスケーダ)からREDOを取得するスタンバイ・データベース(ターミナル・スタンバイ)にフェイルオーバーすることも可能です。この場合、未送信のREDOをカスケーダからターミナル・スタンバイに送信する試行は行われません。

5.4.2.6 ブローカによる即時フェイルオーバー操作の実行方法

即時フェイルオーバーを開始するには、DGMGRLのFAILOVER TO database-name IMMEDIATEコマンドを使用します。

即時フェイルオーバーが開始されると、ブローカは次のことを行います。

  1. ターゲット・スタンバイ・データベースが有効化されていることを確認します。スタンバイ・データベースがブローカによる管理に対応していない場合、フェイルオーバーは実行できません。

  2. 使用可能なREDOデータがすべて適用されるまで待機せずに、スタンバイ・データベースのREDO ApplyまたはSQL Applyを即時停止します。この作業によってデータが失われる可能性があります。

  3. ターゲットのスタンバイ・データベースをプライマリ・ロールに遷移させ、新しいプライマリ・データベースを読取り/書込みモードでオープンし、REDO転送サービスを起動します。

    即時フェイルオーバーが完了すると、構成内のすべてのスタンバイ・データベースはタイプに関係なく無効化されます。それらのデータベースでフラッシュバック・データベースが有効化されている場合、データベースは回復されます。それ以外の場合は、新しいプライマリ・データベースのコピーから再作成する必要があります。

ブローカは、フェイルオーバーに関係するように選択したスタンバイ・データベースにエラーがないかぎり、完全フェイルオーバーを続行します。

ブローカは、フェイルオーバーに関係するように選択したスタンバイ・データベースにエラーがあっても、即時フェイルオーバーを続行します。

遠隔同期インスタンスを使用した構成内での即時フェイルオーバー

遠隔同期インスタンスからREDOデータを受け取るスタンバイ・データベースに、即時フェイルオーバーを手動で実行できます。この場合、フィジカル・スタンバイをプライマリ・データベースに変換する前に、遠隔同期インスタンスからターゲットのフィジカル・スタンバイに未送信のREDOを送信する試行は行われません。

カスケーデッド・スタンバイを使用した構成内での即時フェイルオーバー

即時フェイルオーバーでは、別のスタンバイ・データベース(カスケーダ)からREDOを取得するスタンバイ・データベース(ターミナル・スタンバイ)にフェイルオーバーすることも可能です。この場合、未送信のREDOをカスケーダからターミナル・スタンバイに送信する試行は行われません。

5.4.3 ロール変更後の無効化されたデータベースの再有効化

ロジカル・スタンバイ・データベースへのスイッチオーバー後またはいずれかのスタンバイ・データベースへのフェイルオーバー後に元の障害時リカバリ・ソリューションをリストアするには、追加ステップを実行する必要があります。

ロール遷移後に無効化されたデータベースは、ブローカ構成から削除されませんが、ブローカによって管理されなくなります。

これらのデータベースのブローカによる管理を再び有効化するには、次のいずれかの手順でデータベースを回復または再作成する必要があります。

  • データベースが回復可能な場合は、データベースで次のステータスが示されます。

    ORA-16661: the standby database needs to be reinstated

    「データベースの回復方法」の説明に従って、DGMGRLのREINSTATE DATABASEコマンドまたはCloud Controlの回復オプションを使用してデータベースを回復します。ブローカにより、データベースは回復処理の一部として再有効化されます。

  • 新規プライマリ・データベースのコピーからデータベースを再作成する必要がある場合、データベースのステータスが次のようになります。

    ORA-16795: the standby database needs to be re-created

    無効化されたデータベースの再作成および再有効化の方法の説明に従って、プライマリ・データベースのコピーからスタンバイ・データベースを再作成し、再有効化します。

ノート:

複数のロール変更が実行されたときに無効化されたデータベースは、回復できません。現在のプライマリ・データベースのコピーからデータベースを手動で再作成し、ブローカ構成でデータベースを再有効化する必要があります。

データベースを回復するか再作成するかは、スイッチオーバーとフェイルオーバーのどちらを実行したか、操作のターゲットとなったスタンバイ・データベースのタイプ、および十分なフラッシュバック・ログがあるかどうかに応じて決まります。ロジカル・スタンバイ・データベースにロール変更すると、常にその他のフィジカル・スタンバイ・データベースは無効化されることに注意してください。これらのデータベースは回復できません。新しいプライマリ・データベースのコピーから再作成する必要があります。

次の各項では、データベースの回復または再有効化方法を説明します。

5.4.3.1 データベースの回復方法

ブローカの回復機能を使用して、障害が発生したプライマリ・データベースを新しいプライマリ・データベースの実行可能なスタンバイ・データベースにすることができます。

この処理は、フェイルオーバーがフィジカル、ロジカルまたはスナップショット・スタンバイ・データベースのいずれに実行されたかに関係なく行うことができます。

フェイルオーバー操作中に無効化されたその他のスタンバイ・データベースも回復できます。

回復可能なデータベースは、ステータス値が次のようになります。

ORA-16661: the standby database needs to be reinstated

REINSTATEコマンドを正常に実行するには、フェイルオーバー前にデータベース上でフラッシュバック・データベースが有効化されており、そのデータベースに十分なフラッシュバック・ログが存在する必要があります。さらに、回復するデータベースおよび新規プライマリ・データベースにネットワーク接続が必要です。

データベースを回復するには:

  1. データベースを再起動してマウント済状態にします。

  2. 新規プライマリ・データベースに接続します。

  3. Cloud ControlまたはDGMGRLを使用して、データベースを回復します。

ブローカは、障害が発生したプライマリ・データベースを元のスタンバイ・データベースと同じタイプのスタンバイ・データベース(フィジカルまたはロジカル・スタンバイ・データベース)として回復します。唯一の例外は、スナップショット・スタンバイ・データベースへのフェイルオーバーです。そのような場合は、障害が発生したプライマリ・データベースがフィジカル・スタンバイ・データベースとして回復されます。

ブローカは、フェイルオーバー中に無効化されたその他のスタンバイ・データベースを、新しいプライマリ・データベースのスタンバイ・データベースとして回復します。

Cloud Controlを使用した回復

Oracle Data Guardの概要ページで、「データベースを回復する必要があります」をクリックします。これにより、「回復」ボタンが表示された「一般プロパティ」ページが開きます。「回復」ボタンをクリックすると、Cloud Controlでデータベースの回復が開始されます。

プロセスが完了すると、データベースが新規プライマリ・データベースのスタンバイ・データベースとして有効化され、Cloud ControlでOracle Data Guardの概要ページが表示されます。

DGMGRLを使用した回復

ブローカ構成内のデータベース(回復するデータベースを除く)に接続しているときに、次のコマンドを発行します。

DGMGRL> REINSTATE DATABASE db_unique_name;

新しく回復したスタンバイ・データベースは、新規プライマリ・データベースのスタンバイ・データベースとして機能し始めます。データベースの回復に失敗した場合、ステータスは「ORA-16795: スタンバイ・データベースを再作成する必要があります」に変更されます。この場合、「無効化されたデータベースの再作成および再有効化の方法」の説明に従って、新しいプライマリ・データベースのコピーから再作成して再有効化する必要があります。

5.4.3.2 無効化されたデータベースの再作成および再有効化の方法

元のプライマリ・データベースを再作成する場合、元のスタンバイ・データベースのスタンバイ・タイプで作成する必要があります。

たとえば、元のスタンバイがフィジカルまたはスナップショット・スタンバイだった場合は、元のプライマリをフィジカル・スタンバイとして再作成する必要があります。

データベースが再作成された後、DGMGRLのENABLE DATABASEコマンドを使用して、再作成されたスタンバイ・データベースのブローカ管理を有効化します。

障害が発生したプライマリ・データベースまたはロール遷移時に無効化されたスタンバイ・データベースの再作成が必要なフェイルオーバーまたはスイッチオーバーを実行した場合、『Oracle Data Guard概要および管理』の「フィジカル・スタンバイ・データベースの作成」、「ロジカル・スタンバイ・データベースの作成」および「Oracle Data Guard概要および管理」の手順を実行します。

5.5 ファスト・スタート・フェイルオーバー

ファスト・スタート・フェイルオーバーでは、プライマリ・データベースが消失した場合、ブローカにより、事前に選択されたスタンバイ・データベースに自動的にフェイルオーバーできます。

ファスト・スタート・フェイルオーバーでは、ターゲット・スタンバイ・データベースがプライマリ・データベース・ロールに迅速かつ確実にフェイルオーバーされます。このとき、手動ステップを実行してフェイルオーバーを起動する必要はありません。ファスト・スタート・フェイルオーバーはブローカ構成でのみ使用でき、DGMGRLまたはCloud Controlによってのみ構成できます。

プライマリ・データベースに複数のスタンバイ・データベースがある場合、FastStartFailoverTargetプロパティを使用して複数のファスト・スタート・フェイルオーバー・ターゲットを指定できます。このようなターゲットはターゲット候補と呼びます。ブローカは、FaststartFailoverTargetプロパティでの指定順に基づいて、ターゲットを選択します。指定されたファスト・スタート・フェイルオーバー・ターゲットに問題が発生し、フェイルオーバーのターゲットにできない場合、ブローカはファスト・スタート・フェイルオーバー・ターゲットを別のターゲット候補のいずれかに自動的に変更します。

ファスト・スタート・フェイルオーバーでは、任意の保護モードを使用できます。最大保護モードおよび最大可用性モードは、データが消失しないことを保証する自動フェイルオーバー環境を提供します。最大パフォーマンス・モードによる自動フェイルオーバー環境では、消失データがFastStartFailoverLagLimit構成プロパティで指定したデータ量(秒単位)以下であることが保証されます。このプロパティは、自動フェイルオーバーの実行に許容される最大消失データ量を示します。このプロパティは、ファスト・スタート・フェイルオーバーが有効化され、構成が最大パフォーマンス・モードで動作している場合にのみ使用されます。

ファスト・スタート・フェイルオーバーが有効化されると、ブローカでは、構成されている消失データ量が保証される場合にのみファスト・スタート・フェイルオーバーの実行が可能となります。構成されている消失データ量を保証できない場合、プライマリ・データベースのREDO生成が停止します。最大可用性モードおよび最大パフォーマンス・モードでは、長期にわたる停止を回避するため、ファスト・スタート・フェイルオーバーを実行できないと記録された後、オブザーバまたはターゲット・スタンバイ・データベースにより、プライマリ・データベースでのREDO生成の続行が可能になる場合があります。

最大可用性モードでは、ターゲット・スタンバイ・データベースが失われたREDOデータをすべて受信し終わると、自動的なフェイルオーバー機能がリストアされます。最大パフォーマンス・モードおよび最大可用性モードでは、プライマリ・データベースのREDO生成時点とターゲット・スタンバイ・データベースのREDO適用時点の間に、FastStartFailoverLagLimit構成プロパティに指定された値を超過する遅れがなくなると、自動的なフェイルオーバー機能がリストアされます。最大保護モードでは、プライマリ・データベースがターゲット・スタンバイとの接続を回復するまで、ブローカはプライマリ・データベースによるトランザクションのコミットを許可しないため、自動的なフェイルオーバー機能は常に使用可能です。したがって、ターゲット・スタンバイがプライマリより遅れることはありません(最大可用性モードや最大パフォーマンス・モードではその可能性があります)。

次の表に、ファスト・スタート・フェイルオーバーが有効化されている場合、どの保護モードでどのスタンバイ・タイプがサポートされているか概要を示します。(スナップショット・スタンバイは、ファスト・スタート・フェイルオーバー・ターゲットとしてサポートされていないため、この表には含まれていません。)

保護モード フィジカル・スタンバイのサポート ロジカル・スタンバイのサポート 遠隔同期インスタンスのREDO送信のサポート
最大保護 はい いいえ いいえ
最大可用性 はい はい はい
最大パフォーマンス はい はい いいえ

この表に示したように、ファスト・スタート・フェイルオーバー・ターゲットが遠隔同期インスタンスからREDOデータを受け取るロジカルまたはフィジカル・スタンバイ・データベースの場合、ファスト・スタート・フェイルオーバーを最大可用性モードで有効化できます。これにより、距離に関係なくデータ損失がゼロになる保護が設定された構成で、ブローカの自動フェイルオーバー機能の利点を活用できます。この設定方法の例は、「使用例7: 遠隔同期インスタンスが使用中の場合のファスト・スタート・フェイルオーバーの有効化」を参照してください。

次の各項のトピックでは、ファスト・スタート・フェイルオーバーおよびファスト・スタート・フェイルオーバー環境を監視するオブザーバ・サイトを有効化する方法を説明します。オブザーバは、プライマリ・データベースおよびスタンバイ・データベースとは異なるコンピュータ上で動作する、独立したOCIクライアント側コンポーネントであり、プライマリ・データベースの可用性を監視します。オブザーバについては、「オブザーバの管理」で詳しく説明されています。

オブザーバの起動が完了したら、ユーザーによる操作は必要ありません。オブザーバおよび指定されたスタンバイ・データベースの両方で、FastStartFailoverThreshold構成プロパティに指定された秒数を超えてプライマリ・データベースとの接続が失われた場合、オブザーバはスタンバイ・データベースへのファスト・スタート・フェイルオーバーを開始します。また、FastStartFailoverPmyShutdown構成プロパティがTRUEに設定されている場合、FastStartFailoverThresholdの秒数よりも長い期間に及ぶ接続の消失を検出すると、プライマリ・データベースは停止します。FastStartFailoverAutoReinstate構成プロパティがTRUEに設定されている場合、フェイルオーバーの完了後、元のプライマリ・データベースへの接続が再度確立されたときに、元のプライマリ・データベースがスタンバイ・データベースとして自動的に回復されます。

ノート:

ユーザーが構成可能なファスト・スタート・フェイルオーバー条件が検出されてファスト・スタート・フェイルオーバーが発生した場合、またはアプリケーションからDBMS_DG.INITIATE_FS_FAILOVER関数をコールしてファスト・スタート・フェイルオーバーを開始した場合、元のプライマリ・データベースは必ず停止し、自動的に回復されることはありません。これは、FastStartFailoverPmyShutdownおよびFastStartFailoverAutoReinstate構成プロパティの設定には関係ありません。詳細は、「ファスト・スタート・フェイルオーバーの有効化」を参照してください。

図5-1に、ファスト・スタート・フェイルオーバー時のプライマリ・データベース、ターゲット・スタンバイ・データベースおよびオブザーバの関係を示しています。

  • ファスト・スタート・フェイルオーバー前: Oracle Data Guardは安定した状態で動作しており、プライマリ・データベースがターゲット・スタンバイ・データベースにREDOデータを転送し、オブザーバが全体の構成の状態を監視しています。

  • ファスト・スタート・フェイルオーバーの実行: プライマリ・データベースに障害が発生し、オブザーバおよびターゲット・スタンバイ・データベースへのネットワーク接続がどちらも失われます。オブザーバは、通信の切断を検出すると、ファスト・スタート・フェイルオーバーの開始前にFastStartFailoverThresholdプロパティによって定義された時間内において、プライマリ・データベースとの接続の再確立を試行します。オブザーバが指定時間内にプライマリ・データベースへの接続を回復できず、ターゲット・スタンバイ・データベースがファスト・スタート・フェイルオーバー可能な状態である場合、ファスト・スタート・フェイルオーバーが実行されます。

  • ファスト・スタート・フェイルオーバー後: ファスト・スタート・フェイルオーバーが完了し、ターゲット・スタンバイ・データベースがプライマリ・データベース・ロールで動作しています。元のプライマリ・データベースが修復された後、オブザーバはそのデータベースとの接続を再確立し、新規スタンバイ・データベースとして回復します。新規プライマリ・データベースが新規スタンバイ・データベースへのREDOデータの転送を開始します。

図5-1 プライマリ・データベースおよびスタンバイ・データベースとオブザーバの関係

図5-1の説明が続きます
「図5-1 プライマリ・データベースおよびスタンバイ・データベースとオブザーバの関係」の説明

以降の各項の内容は、次のとおりです。

5.5.1 ファスト・スタート・フェイルオーバーを有効化するための前提条件

ブローカでファスト・スタート・フェイルオーバーを有効化するには、前提条件を満たしている必要があります。

前提条件を次に示します。

  • 保護モードを構成します。「構成に対する保護モードの設定」を参照してください。

  • ファスト・スタート・フェイルオーバー・ターゲットになる選択したスタンバイ・データベースは、プライマリ・データベースから直接REDOを受け取る必要があります。

  • ファスト・スタート・フェイルオーバーのターゲットに選択するスタンバイ・データベースのLogXptModeプロパティが、保護モードに応じて次のように設定されていることを確認します。

    • 最大保護 — SYNC

    • 最大可用性 — SYNCまたはFASTSYNC

    • 最大パフォーマンス — ASYNC

    現在のプライマリ・データベースは、LogXptModeプロパティが適切に設定され、スタンバイREDOログが構成されている必要があります。あるいは、RedoRoutesプロパティを使用して、ターゲット・スタンバイと、現在プライマリ・ロールになっているデータベースのためにREDO転送モードを構成します。

  • ファスト・スタート・フェイルオーバーで遠隔同期インスタンスを使用するには、遠隔同期インスタンスの転送モードはSYNCまたはFASTSYNCに、ターゲット・スタンバイ・データベースの転送モードはASYNCに設定される必要があります。遠隔同期インスタンスは、最大保護モードまた最大パフォーマンス・モードでは使用できません。

  • 「Oracle Data Guardのインストール」の説明に従って、オブザーバ・コンピュータにDGMGRLコマンドライン・インタフェースをインストールします。

  • オブザーバ・システムでTNSNAMES.ORAファイルを構成し、オブザーバがプライマリ・データベースおよび事前に選択されたターゲット・スタンバイ・データベースに接続できるようにします。

  • Oracle ClusterwareもOracle Restartも使用していない場合、オブザーバが回復の一部として自動的にデータベースを再起動できるように、静的サービス名を作成する必要があります。VALIDATE STATIC CONNECT IDENTIFIERコマンドを使用して、静的サービスが正しく構成されていることを確認します。詳細は、「前提条件」を参照してください。

5.5.2 ファスト・スタート・フェイルオーバーの有効化

ブローカ構成のデータベースに接続されている間は、任意のサイトからファスト・スタート・フェイルオーバーを有効化できます。

ファスト・スタート・フェイルオーバーを有効化しても、フェイルオーバーは起動されません。かわりに、フェイルオーバーのデータベース条件が満たされた場合に、構成を監視しているオブザーバがファスト・スタート・フェイルオーバーを起動できるようになります。(ファスト・スタート・フェイルオーバーの条件を満たす、アプリケーションに固有の条件が他にある場合、これらの条件のいずれかが発生した場合に即時にDBMS_DG.INITIATE_FS_FAILOVER機能をコールしてファスト・スタート・フェイルオーバーを開始するように、アプリケーションを設定できます。「アプリケーションによるファスト・スタート・フェイルオーバーの指示」を参照してください)

ファスト・スタート・フェイルオーバーの有効化およびオブザーバ・プロセスの起動には、次のタスクがあります。これらのタスクでは、SYSまたはSYSDGとして接続しており、ブローカ構成でプライマリ・データベースおよびスタンバイ・データベースがすでに設定されていることを前提としています。

5.5.2.1 ファスト・スタート・フェイルオーバーの有効化(タスク1): 使用可能なスタンバイ・データベースのうち、フェイルオーバーのターゲットとして最適なデータベースの決定

フェイルオーバーのターゲットとなる使用可能なスタンバイ・データベースを決定する必要があります。

「ターゲット・スタンバイ・データベースの選択」に示したガイドラインに従います。

5.5.2.2 ファスト・スタート・フェイルオーバーの有効化(タスク2): FastStartFailoverTarget構成プロパティを使用したターゲット・スタンバイの指定

現在のプライマリ・データベースのFastStartFailoverTarget構成プロパティを使用して、1つ以上のファスト・スタート・フェイルオーバー・ターゲットを指定します。

ブローカは、このプロパティでの指定順に基づいて、ターゲット・スタンバイを選択します。

  • 構成内のスタンバイ・データベースが1つのみである場合、このステップをスキップしてタスク3に進みます。

  • 構成内に複数のスタンバイ・データベースがある場合、プライマリ・データベースでFastStartFailoverTargetプロパティを明示的に設定して、1つ以上のターゲット・スタンバイ・データベース候補を指定する必要があります。ファスト・スタート・フェイルオーバーを有効化する際、ブローカは、このプロパティが既存のスタンバイを示していることを確認します。(ターゲット・スタンバイは遠隔同期インスタンスになれないことに注意してください。ただし、ターゲットは遠隔同期インスタンスからREDOを受け取ることができます。)

    ノート:

    FastStartFailoverTargetプロパティを変更して別のスタンバイ・データベースを指すようにするには、ファスト・スタート・フェイルオーバーを無効化し、FastStartFailoverTargetプロパティを設定し、さらにファスト・スタート・フェイルオーバーを再有効化してください。

このプロパティの詳細は、「FastStartFailoverTarget」を参照してください。

5.5.2.3 ファスト・スタート・フェイルオーバーの有効化(タスク3): 使用する保護モードの決定

いかなるデータの消失も許容できない場合は、構成の保護モードが最大可用性または最大保護に設定されていることを確認してください。最大可用性モードでデータ損失がゼロの場合、FastStartFailoverLagLimitプロパティをゼロに設定する必要があります。

最大可用性モードでは、プライマリ・データベースとターゲット・スタンバイ・データベースの両方のLogXptModeデータベース・プロパティをSYNCまたはFASTSYNCに設定します。最大保護モードでは、LogXptModeデータベース・プロパティをSYNCに設定します(最大保護モードでは、遠隔同期インスタンスを使用してREDOをスタンバイに送信することはできません)。次に、LogXptModeプロパティを設定する例を示します。 

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY LogXptMode=SYNC;
DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY LogXptMode=SYNC;
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MaxAvailability;

あるいは、RedoRoutesプロパティを使用して、ターゲット・スタンバイと、現在プライマリ・ロールになっているデータベースのためにREDO転送モードを設定します。その後、構成保護モードを最大可用性に設定してください。

わずかなデータの消失よりもプライマリ・データベースのパフォーマンスを重視する場合は、構成の保護モードを最大パフォーマンスに設定してファスト・スタート・フェイルオーバーを有効化することを検討してください。このモードでは、どれだけのデータ消失を許容できるかを秒単位で検討し、それに従ってFastStartFailoverLagLimit構成プロパティを設定する必要があります。このプロパティは、REDO適用に関してターゲット・スタンバイ・データベースがプライマリ・データベースから遅れることができるデータ量を秒単位で指定します。スタンバイ・データベースでREDOが適用された時点がプライマリ・データベースのREDO生成時点からその秒数以内であれば、ファスト・スタート・フェイルオーバーが許可されます。FastStartFailoverLagLimit構成プロパティは、最大パフォーマンス・モードで動作している構成のファスト・スタート・フェイルオーバーが有効化されている場合にのみブローカによって使用されます。デフォルト値は30秒で、設定できる最小値は5秒です。

構成の保護モードを最大パフォーマンスに設定することに加えて、プライマリ・データベースとターゲットスタンバイ・データベースの両方でデータベース・プロパティLogXptModeがASYNCに設定されていることを確認する必要もあります。次に例を示します。 

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY LogXptMode=ASYNC;
DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY LogXptMode=ASYNC;
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MaxPerformance;
DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverLagLimit=45;
5.5.2.4 ファスト・スタート・フェイルオーバーの有効化(タスク4): FastStartFailoverThreshold構成プロパティの設定

オブザーバおよびターゲット・スタンバイ・データベースの両方で、FastStartFailoverThreshold構成プロパティで指定された時間中にプライマリ・データベースへの接続が失われた場合、ファスト・スタート・フェイルオーバーが実行されます。

FastStartFailoverThresholdプロパティを設定し、(プライマリ・データベースが使用できないことが検出されてから)フェイルオーバーを開始するまでにオブザーバおよびターゲット・スタンバイ・データベースを待機させる秒数を指定します。次に例を示します。 

DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverThreshold = 45;

FastStartFailoverThresholdプロパティのデフォルト値は30秒で、設定できる最小値は6秒です。Oracle RACプライマリ・データベースが存在する場合、インスタンス障害が発生したときに誤ってフェイルオーバーが実行される可能性を最小限にするには、これより大きい値を指定することを考慮します。

この時間間隔は、オブザーバでプライマリ・データベースへの接続が最初に失われたときに開始されます。オブザーバが指定時間内にプライマリ・データベースへの接続を回復できない場合、スタンバイ・データベースがフェイルオーバー可能な状態であれば、オブザーバによりファスト・スタート・フェイルオーバーが開始されます。デフォルト値の30秒は、通常はほとんどの構成で停止および障害を検出できる値ですが、このプロパティでフェイルオーバーの感度を調整することで、一時的に不安定になった環境でフェイルオーバーが誤って実行される可能性を低くすることができます。

REDOの生成が停止し、プライマリ・データベースがオブザーバまたはターゲット・スタンバイ・データベースとの接続を再確立できない場合、FastStartFailoverPmyShutdown構成プロパティがTRUEに設定されていると、FastStartFailoverThresholdの秒数が経過した後にプライマリ・データベースが停止します。

ファスト・スタート・フェイルオーバーが有効化されている場合でもFastStartFailoverThresholdプロパティを変更できることに注意してください。

関連項目:

FastStartFailoverThresholdプロパティの詳細は、「FastStartFailoverThreshold」を参照してください

5.5.2.5 ファスト・スタート・フェイルオーバーの有効化(タスク5): ファスト・スタート・フェイルオーバー関連の他のプロパティの設定(省略可能)

この表は、設定できるオプションのデータベース・プロパティを示します。

プロパティ名 説明 デフォルト値

FastStartFailoverPmyShutdown

この構成プロパティにより、ファスト・スタート・フェイルオーバーが有効化されていてプライマリがFastStartFailoverThresholdの秒数よりも長くSTALLEDになったことをV$DATABASE.FS_FAILOVER_STATUSが示すと、プライマリ・データベースが停止します。TRUEの値は、分離されたプライマリ・データベースがユーザーの問合せに対応できないことを確認するのに役立ちます。

ユーザーの構成条件が検出されたためにファスト・スタート・フェイルオーバーが発生した場合、またはDBMS_DG.INITIATE_FS_FAILOVER関数をコールしてアプリケーションでファスト・スタート・フェイルオーバーを要求した場合、このプロパティを使用してプライマリ・データベースの停止を防止することはできません。

TRUE

FastStartFailoverLagLimit

構成プロパティは、REDOの適用に関して、プライマリよりスタンバイが遅れることができる許容範囲を秒単位で確立します。この値を超えて遅れる場合は、ファスト・スタート・フェイルオーバーが実行されません。設定可能な最小値は5秒です。

30秒

FastStartFailoverAutoReinstate

この構成プロパティを使用すると、プライマリ・データベースが分離またはクラッシュしたためにファスト・スタート・フェイルオーバーが開始した場合に、元のプライマリ・データベースが自動的に回復されます。この場合に元のプライマリ・データベースを自動的に回復しないようにするには、この構成プロパティをFALSEに設定します。ユーザー構成条件が検出されたためにファスト・スタート・フェイルオーバーが発生した場合、またはDBMS_DG.INITIATE_FS_FAILOVER関数をコールしてアプリケーションでファスト・スタート・フェイルオーバーを要求した場合は、ブローカは元のプライマリ・データベースを自動的に回復しません。

TRUE

ObserverConnectIdentifier

このデータベース・プロパティは、オブザーバがプライマリおよびスタンバイ・データベースに接続して監視する方法を指定するために使用されます。REDOデータの転送に使用される接続識別子とは異なる識別子(DGConnectIdentifierプロパティで指定される接続識別子)をオブザーバが使用する場合は、プライマリ・データベースとターゲット・スタンバイ・データベースにこのプロパティを設定してください。

オブザーバは、DGConnectIdentifierプロパティの値を使用してプライマリおよびターゲット・スタンバイ・データベースに接続し、監視します。

ObserverOverride

ObserverOverride構成プロパティをTRUEに設定すると、スタンバイがプライマリに正常に接続していても、オブザーバのプライマリへの接続が失われた場合、自動フェイルオーバーが発生します。

FALSE

ObserverReconnect

ObserverReconnect構成プロパティは、オブザーバがプライマリ・データベースに対して新しい接続を確立する頻度を指定します。このプロパティがデフォルト値の0に設定されている場合、オブザーバはプライマリ・データベースへの新しい接続を定期的に確立しません。これによりプライマリ・データベースに新しいオブザーバ接続を定期的に確立することによる処理オーバーヘッドがなくなる一方、オブザーバがプライマリ・データベースに新しい接続を作成できないことを検出できなくなります。このプロパティは、プライマリ・データベースの障害を適時に検出できる程度には小さいが、定期的なオブザーバ接続によるオーバーヘッドが許容できるレベルに収まる程度には大きい値に設定することをお薦めします。

0 (ゼロ)
5.5.2.6 ファスト・スタート・フェイルオーバーの有効化(タスク6): 追加のファスト・スタート・フェイルオーバー条件の有効化(省略可能)

デフォルトでは、構成された時間しきい値(FastStartFailoverThreshold)の経過後にオブザーバもスタンバイもプライマリにアクセスできないと、ファスト・スタート・フェイルオーバーが実行されます。

必要に応じて、ファスト・スタート・フェイルオーバーを発生させるデータベース健全性条件を指定することができます。次の表に、これらの条件を示します。

健全性条件 説明 デフォルトで有効化
データファイル書込みエラー ファスト・スタート・フェイルオーバーが有効化され、データファイル書込みエラー条件が指定されている場合、任意のデータ・ファイル(一時ファイル、システム・データ・ファイル、UNDOファイルなど)で書込みエラーが発生すると、ファスト・スタート・フェイルオーバーが開始されます。 はい

破損したディクショナリ

重要なデータベースのディクショナリが破損しました。現時点では、この状態は、データベースがオープンされている場合にのみ検出されます。

はい

破損した制御ファイル

ディスク障害のために制御ファイルが永続的に破損しました。

はい

アクセス不可能なログ・ファイル

I/OエラーのためにLGWRがログ・グループのどのメンバーにも書き込むことができません。

いいえ

スタック・アーカイバ

デバイスに空き容量がないかデバイスを使用できないためにアーカイバがREDOログをアーカイブできません。

いいえ

Oracle RAC構成では、アクセス不可能なログ・ファイルおよびスタック・アーカイバの健全性条件は、単一インスタンスにのみ適用できます。これらの条件によるファスト・スタート・フェイルオーバーは、Oracle Clusterwareによって提供される可用性オプションに優先して実行されるので、有効化する前によく検討してください。

Cloud ControlまたはDGMGRLのENABLE FAST_START FAILOVER CONDITIONコマンドおよびDISABLE FAST_START FAILOVER CONDITIONコマンドを使用して、ファスト・スタート・フェイルオーバーが実行される特定の条件を指定できます。

5.5.2.7 ファスト・スタート・フェイルオーバーの有効化(タスク7): DGMGRLまたはCloud Controlの使用

Cloud Controlのファスト・スタート・フェイルオーバー・ウィザードまたはDGMGRLのENABLE FAST_START FAILOVERコマンドを使用して、ファスト・スタート・フェイルオーバーを有効化します。

ファスト・スタート・フェイルオーバーを有効化するには、プライマリ・データベースおよびターゲット・スタンバイ・データベースの両方が動作しており、接続され、さらに「ファスト・スタート・フェイルオーバーを有効化するための前提条件」にリストされた前提条件をすべて満たしている必要があります。

ノート:

Cloud Controlのファスト・スタート・フェイルオーバー・ウィザードでは、複数のターゲットの指定は現在サポートされていません。複数のターゲットを指定する場合は、DGMGRLユーティリティを使用する必要があります。

Cloud Controlを使用したファスト・スタート・フェイルオーバーの有効化

Cloud Controlでファスト・スタート・フェイルオーバーを有効にするには、ファスト・スタート・フェイルオーバー・ウィザードを使用します。Oracle Data Guardの「概要」ページで、「ファスト・スタート・フェイルオーバー」ステータス・フィールドの横にある「無効」をクリックして、「ファスト・スタート・フェイルオーバー」ページを開きます。次に、「ファスト・スタート・フェイルオーバー: モードを変更」ページで、「有効」をクリックします。Cloud Controlによってオブザーバが起動されます。次に、「ファスト・スタート・フェイルオーバー: 構成」ページで、フェイルオーバーのターゲットとするスタンバイ・データベースを選択します。役立つアドバイスについては、「ターゲット・スタンバイ・データベースの選択」を参照してください。このページでは、保護モードを変更できません。ファスト・スタート・フェイルオーバーは、現在の保護モードに従って有効化されます。現在構成されているモードが最大保護の場合、Cloud Controlは、モードを最大可用性にダウングレードします。

DGMGRLを使用したファスト・スタート・フェイルオーバーの有効化

DGMGRLを使用してファスト・スタート・フェイルオーバーを有効化するには、オブザーバ・コンピュータ上のデータベースを含むブローカ構成内のいずれかのデータベースに接続している間に、ENABLE FAST_START FAILOVERコマンドを発行します。次に例を示します。 

DGMGRL> ENABLE FAST_START FAILOVER;
Enabled.

関連項目:

ノート:

スタンバイ・データベースが事前の予告なしにプライマリ・ロールを引き継ぐ場合があるため、ターゲット・スタンバイ・サイトでの管理はプライマリ・サイトでの管理と同じくらい包括的である必要があります。スタッフ・サポート、ハードウェアとソフトウェア、セキュリティ(ソフトウェアとサイトの両方)、ネットワーク接続および帯域幅が両方のサイトで同等である必要があります。

5.5.2.8 ファスト・スタート・フェイルオーバーの有効化(タスク8): オブザーバの起動

オブザーバを起動するには、プライマリ・データベースが実行されている必要があります。

ファスト・スタート・フェイルオーバーを有効化する前または後にオブザーバを起動できます。ファスト・スタート・フェイルオーバーが有効化されている場合、オブザーバは、プライマリ・データベースおよびターゲット・スタンバイ・データベースのステータスおよび接続の監視をただちに開始します。ファスト・スタート・フェイルオーバーが有効化されていない場合、オブザーバは、ファスト・スタート・フェイルオーバーが有効化されるまで待機してから監視を開始します。

Cloud Controlを使用したオブザーバの起動

Cloud Controlエージェントがオブザーバ・コンピュータにインストールされている場合、Cloud Controlを介してファスト・スタート・フェイルオーバーを有効にすると、オブザーバが自動的に起動されます。エージェントが存在しない場合、DGMGRLコマンドライン・インタフェースに関する次の手順を実行して、オブザーバを手動で起動する必要があります。

DGMGRLを使用したオブザーバの起動

DGMGRLを使用してオブザーバを起動するには、オブザーバ・コンピュータで次のコマンドを発行します。

DGMGRL> START OBSERVER;

オブザーバはSTART OBSERVERコマンドを発行したときに作成され、継続的に実行されるプロセスです。そのため、別のDGMGRLセッションからSTOP OBSERVERコマンドを発行するまで、オブザーバ・コンピュータ上のコマンドライン・プロンプトは戻されません。コマンドを発行し、ブローカ構成と対話するには、別のDGMGRLクライアント・セッションにより接続する必要があります。

1つのData Guard構成に対して最大3つのオブザーバを設定できます。1つはマスター・オブザーバ、その他はバックアップ・オブザーバです。

DGMGRLを使用したバックグラウンド・プロセスとしてのオブザーバの起動

オブザーバをバックグラウンド・プロセスとして起動するには、DGMGRLコマンドSTART OBSERVER IN BACKGROUNDを使用します。このコマンドが正常に発行されると、オブザーバ・コンピュータ上のコマンドライン・プロンプトがユーザーに戻り、ユーザーは引き続きコマンドを発行してブローカ構成と対話できます。オブザーバの起動には、この方法を使用することをお薦めします。

5.5.2.9 ファスト・スタート・フェイルオーバーの有効化(タスク9): ファスト・スタート・フェイルオーバー環境の検証

ファスト・スタート・フェイルオーバー構成の準備が整っているかどうかを検証するには、プライマリ・データベースでDGMGRLのSHOW CONFIGURATION VERBOSEコマンドまたはSHOW FAST_START FAILOVERコマンドを発行します。

次に例を示します。

DGMGRL> SHOW FAST_START FAILOVER;
 
Fast-Start Failover: Enabled in Zero Data Loss Mode

 Protection Mode: MaxAvailability
 Lag Limit: 0 seconds

 Threshold: 180 seconds
 Active Target: South_Sales
 Potential Targets: East_Sales, West_Sales
   East_Sales    valid
   West_Sales    valid
 Observer: observer.example.com
 Shutdown Primary: TRUE
 Auto-reinstate: TRUE
 Observer Reconnect: (none)
 Observer Override: FALSE
 
Configurable Failover Conditions
 Health Conditions:
  Corrupted Controlfile     YES
  Corrupted Dictionary      YES
  Inaccessible Logfile       NO
  Stuck Archiver             NO
  Datafile Write Errors     YES

Oracle Error Conditions:
(none)

次の各項では、ファスト・スタート・フェイルオーバー環境の詳細を説明しています。

5.5.2.10 ファスト・スタート・フェイルオーバーの有効化およびオブザーバの実行

ファスト・スタート・フェイルオーバーが有効化され、最大3つのオブザーバが起動された後、1つのオブザーバがマスター・オブザーバに指定され、継続的に環境を監視してプライマリ・データベースが使用可能であることを確認します。

この項では、マスター・オブザーバがファスト・スタート・フェイルオーバーの必要性を判別し、必要に応じてフェイルオーバーを実行するためのステップをリストしています。

  1. 環境を監視し、プライマリ・データベースが使用可能であることを確認します。

    次の状況のように、プライマリ・データベースがクラッシュした場合、またはオブザーバとの接続が失われた場合、マスター・オブザーバはFastStartFailoverThreshold構成プロパティで指定されている秒数を待機してから、ファスト・スタート・フェイルオーバーを試行します。

    • プライマリ・データベースと、オブザーバおよびターゲット・スタンバイ・データベースの両方との接続が失われた場合

    • インスタンス障害

      単一インスタンスのプライマリ・データベース(Oracle RACまたは非Oracle RAC)、またはOracle RACプライマリ・データベースのすべてのインスタンスに障害が発生した場合、オブザーバがファスト・スタート・フェイルオーバーを試行します。

    • 強制終了

      単一インスタンスのプライマリ・データベース(Oracle RACまたは非Oracle RAC)、またはOracle RACプライマリ・データベースのすべてのインスタンスがABORTオプションにより停止された場合、オブザーバがファスト・スタート・フェイルオーバーを試行します。他のタイプのデータベース停止(NORMAL、IMMEDIATE、TRANSACTIONAL)では、ファスト・スタート・フェイルオーバーは試行されません。

    次の状況では、マスター・オブザーバはしきい値を超えるまで待機せずに、ファスト・スタート・フェイルオーバーを実行します。

    • ユーザーが構成可能な条件

      マスター・オブザーバは、ユーザーが構成可能な条件が検出されたと判断すると、ファスト・スタート・フェイルオーバーを試行します。

    • DBMS_DG.INITIATE_FS_FAILOVERのアプリケーション・コール

      アプリケーションがこの機能をコールし、SUCCESSステータスを受け取ると、マスター・オブザーバがファスト・スタート・フェイルオーバーを試行します。

  2. FastStartFailoverThresholdプロパティにより指定された時間内に再接続します。

    プライマリ・データベースに可用性の問題があることをマスター・オブザーバが検出した場合、マスター・オブザーバは通常、FastStartFailoverThreshold構成プロパティに指定された時間内にプライマリ・データベースに再接続しようとします。FastStartFailoverThresholdの時間間隔は、オブザーバがプライマリ・データベースに障害があることを最初に検出したときに開始されます。

    ユーザーが構成可能な条件が発生したことをマスター・オブザーバが検出した場合、またはDBMS_DG.INITIATE_FS_FAILOVER関数でファスト・スタート・フェイルオーバーを要求した場合、FastStartFailoverThresholdプロパティに指定された時間間隔は無視されます。

    プライマリ・データベースがOracle Real Application Clusters (Oracle RAC)データベースである場合、マスター・オブザーバは残りのプライマリ・インスタンスのいずれかに接続しようとします。Oracle RACプライマリ・データベースを構成するすべてのインスタンスに障害が発生したことが検出されていないかぎり、ファスト・スタート・フェイルオーバーは実行されません。マスター・オブザーバは、データベース・プロパティDGConnectIdentifierまたはObserverConnectIdentifierに指定された値を使用して、プライマリ・データベースおよびファスト・スタート・フェイルオーバーのターゲット・スタンバイ・データベースに接続します。マスター・オブザーバは、これらのプロパティに指定された値を使用して、Oracle RACデータベースの任意のインスタンスに接続できる必要があります。

  3. ターゲット・スタンバイ・データベースがフェイルオーバー可能な状態であることを確認します。

    ファスト・スタート・フェイルオーバーが開始されると、マスター・オブザーバはターゲット・スタンバイ・データベースがプライマリ・データベース・ロールにフェイルオーバーする準備ができているかどうかを確認します。

    次の場合、ファスト・スタート・フェイルオーバーは実行できません。

    • ファスト・スタート・フェイルオーバーが有効でない場合

    • マスター・オブザーバがターゲット・スタンバイ・データベースに接続できない場合

      関連項目:

      オブザーバが動作していない場合は、「オブザーバに障害が発生した場合の動作」を参照

    • ブローカ構成の現在の状態に関して、マスター・オブザーバおよびターゲット・スタンバイ・データベースに一貫性がない場合

    • マスター・オブザーバが動作していない場合

    • 保護モードが最大可用性または最大保護で、プライマリ・データベースに障害が発生したときにターゲット・スタンバイ・データベースがプライマリ・データベースと同期化されていない場合

    • 保護モードが最大パフォーマンスで、プライマリ・データベースに障害が発生したときにターゲット・スタンバイ・データベースのREDO適用時点がプライマリ・データベースのREDO生成時点からFastStartFailoverLagLimit構成プロパティで指定された時間を超えて遅れる場合

    • ターゲット・スタンバイ・データベースがプライマリ・データベースと通信している場合。ただし、ObserverOverride構成プロパティがTRUEに設定されている場合は、フェイルオーバーが試みられます。

    • ターゲット・スタンバイ・データベースのV$DATABASEビュー内のFS_FAILOVER_STATUS列に、ファスト・スタート・フェイルオーバーを実行できない理由が表示された場合

    • 手動フェイルオーバーがすでに進行中です。手動フェイルオーバーの詳細は、「手動フェイルオーバー」を参照してください。

    • ABORTオプションを使用せずにプライマリ・データベースを停止した場合

  4. ファスト・スタート・フェイルオーバーを開始します。

    ターゲット・スタンバイ・データベースがフェイルオーバー可能な状態である場合、マスター・オブザーバの指示により、ただちにターゲット・スタンバイ・データベースがプライマリ・データベース・ロールにフェイルオーバーします。他のなんらかの理由でフェイルオーバーを実行できない場合、マスター・オブザーバはスタンバイ・データベースでフェイルオーバーの準備ができたかどうかをチェックし続けます。ただし、オブザーバはプライマリ・データベースへの再接続も無期限に試行し続けます。スタンバイがフェイルオーバーに同意する前にプライマリ・データベースに再接続すると、マスター・オブザーバはファスト・スタート・フェイルオーバーの開始の試行を中止します。

  5. 元のプライマリ・データベースを新規スタンバイ・データベースとして回復します。

    ファスト・スタート・フェイルオーバーが正常に完了した後、元のプライマリ・データベースへの接続が再確立され、FastStartFailoverAutoReinstate構成プロパティがTRUEに設定されている場合、マスター・オブザーバは元のプライマリ・データベースの新規スタンバイ・データベースとしての回復を試行します。FastStartFailoverPmyShutdown構成プロパティをTRUEに設定した場合、元のプライマリ・データベースは自動的に停止しているため、マスター・オブザーバが回復を試行する前に、手動で再起動する必要があります。

    プライマリがクラッシュしたか、オブザーバおよびターゲット・スタンバイ・データベースから分離したためにファスト・スタート・フェイルオーバーが発生した場合にのみ、これらのプロパティがプライマリの停止および自動回復の実行を左右する点に注意してください。

    関連項目:

    回復の詳細は、「ブローカ構成に含まれる元のプライマリ・データベースの回復」を参照

5.5.2.11 ファスト・スタート・フェイルオーバーが有効化されている場合の制限事項

このリストは、ファスト・スタート・フェイルオーバーが有効になっている場合の制限について説明します。

  • 変更:

    • 構成保護モード

    • REDOをターゲット・スタンバイ・データベースまたは現在プライマリ・ロールになっているデータベースに送信するために使用されるREDO転送モード

    • 新しいプロパティ値に現在のファスト・スタート・フェイルオーバー・ターゲットが含まれていない場合は、プライマリ・データベースのFastStartFailoverTarget構成プロパティ。

    • 新しい値ではプライマリ・データベースがファスト・スタート・フェイルオーバーの現在のターゲット・スタンバイにREDOを送信できなくなる場合は、プライマリ・データベースのRedoRoutesプロパティ。(ターゲット・スタンバイ・データベースを含むすべてのスタンバイ・データベースのRedoRoutesプロパティは変更可能です。)

    • 遠隔同期インスタンスがプライマリ・データベースからREDOを受け取ってターゲット・スタンバイ・データベースにREDOを送信する場合、そのRedoRoutesプロパティ

  • 無効化または削除:

    • ブローカ構成

    • ファスト・スタート・フェイルオーバーのターゲットであるスタンバイ・データベース

    • プライマリ・データベースからREDOを受け取ってターゲット・スタンバイ・データベースにREDOを送信する場合の遠隔同期インスタンス

  • 手動フェイルオーバーの実行:

    • 「ファスト・スタート・フェイルオーバーが有効化されている場合の手動によるロール変更の実行」にリストされた条件を満たしていない場合

    • ファスト・スタート・フェイルオーバーのターゲットとして構成されていないスタンバイ・データベースに対する実行

      構成がファスト・スタート・フェイルオーバーを実行可能な状態かどうかを判断するには、DGMGRLのSHOW DATABASE <target-standby-database>コマンドを発行するか、プライマリ・データベースまたはターゲット・スタンバイ・データベースのいずれかでV$DATABASEビューを問い合せます。ファスト・スタート・フェイルオーバーを実行できる状態である場合、V$DATABASE.FS_FAILOVER_STATUSの列値は、最大可用性モードではSYNCHRONIZED、最大パフォーマンス・モードではTARGET UNDER LAG LIMITです。ターゲット・スタンバイ・データベースについては、FS_FAILOVER_OBSERVER_PRESENT列にはYESと表示されます。

  • ファスト・スタート・フェイルオーバーのターゲットとして構成されていないスタンバイ・データベースへのスイッチオーバーの実行

  • スタンバイ・データベースがプライマリ・データベースと同期化されている場合を除く、最大可用性モードで動作している構成のターゲット・スタンバイ・データベースへのスイッチオーバーの実行

  • スタンバイ・データベースがプライマリ・データベースのラグ制限内にある場合を除く、最大パフォーマンス・モードで動作している構成のターゲット・スタンバイ・データベースへのスイッチオーバーの実行

  • プライマリ・データベースのオープンの試行。オープンを試行すると、次のエラーが戻される場合あります。

    ORA-16649: possible failover to another database prevents this database from being opened

    ファスト・スタート・フェイルオーバーの妥当性チェックが失敗するか、2分未満で完了しないと、このエラーが戻されることがあります。

  • スタンバイがマウントされているが、オープンされていない場合、SQL ALTER DATABASE MOVE DATAFILEコマンドを使用して、ファスト・スタート・フェイルオーバーのターゲットとなっているフィジカル・スタンバイ上のオンライン・データ・ファイルを名称変更するか、再配置します。

5.5.2.12 監視専用モードでのファスト・スタート・フェイルオーバーの構成

ファスト・スタート・フェイルオーバーの監視専用モードでは、使用している環境でファスト・スタート・フェイルオーバーの動作をテストできます。現在の構成またはアプリケーションに影響はありません。

このモードでは、ブローカ構成に対して実際に変更は行われません。ファスト・スタート・フェイルオーバーの条件が満たされると、ブローカはファスト・スタート・フェイルオーバーが開始された可能性があることを示すメッセージをオブザーバ・ログおよびブローカ・ログに追加します。ログには、フェイルオーバーの場合に実行されるアクションに関するその他の詳細も含まれています。

監視専用モードに関する次の点に注意してください。

  • プライマリ・データベースは、オブザーバまたはターゲット・スタンバイから応答がなくても、UNSYNCまたはLAGGING状態になることがあります。

  • オブザーバまたはターゲット・スタンバイから応答がない場合でも、プライマリ・データベースをオープンできます。

  • ファスト・スタート・フェイルオーバーのターゲットへの手動フェイルオーバーは、オブザーバから応答を受信することなく実行できます。

  • 事前条件チェックが満たされていない場合でも、手動フェイルオーバーを実行できます。これには、ブローカ構成がUNSYNCまたはLAGGING状態にあるか、監視されていない状態であるか、フェイルオーバー・ターゲットが無効であるか、回復が進行中であるか、マスター・オブザーバの切替えが進行中である場合が含まれます。

  • 他のデータベースにスイッチオーバーまたは手動フェイルオーバーできます。

監視専用モードでファスト・スタート・フェイルオーバーを構成するには、次のようにします。

DGMGRL> ENABLE FAST_START FAILOVER OBSERVE ONLY;
5.5.2.13 ファスト・スタート・フェイルオーバーが有効化されている場合のプライマリ・データベースの停止

プライマリ・データベースまたはスタンバイ・データベースが通常の方法で停止された場合、ファスト・スタート・フェイルオーバーは起動されません。

通常の停止では、SHUTDOWN NORMAL、SHUTDOWN IMMEDIATEまたはSHUTDOWN TRANSACTIONALを使用します。通常の停止では、プライマリ・データベースおよびスタンバイ・データベースが再度接続され通信状態になるまで、ファスト・スタート・フェイルオーバーを実行できません。

5.5.2.14 ファスト・スタート・フェイルオーバーが有効化されている場合の手動によるロール変更の実行

ファスト・スタート・フェイルオーバーが有効化されている場合でも、特定の条件を満たしているかぎり、スイッチオーバーまたは手動フェイルオーバーを実行できます。

条件は次のとおりです。

  • ロール変更の対象が、プライマリ・データベース上のFastStartFailoverTargetデータベース・プロパティで指定されたスタンバイ・データベースと同一であること。

  • ターゲット・スタンバイ・データベースがプライマリ・データベースと同期化されていること(最大可用性モードまたは最大保護モードで動作している構成の場合)またはターゲット・スタンバイ・データベースがラグ制限内にあること(最大パフォーマンス・モードで動作している構成の場合)。

  • 手動フェイルオーバーの場合、オブザーバが起動しており、ターゲット・スタンバイ・データベースと通信していること。手動フェイルオーバーを実行する前に、プライマリ・データベースが停止されていることを確認する必要があります。

ノート:

必要な場合は、FORCEオプションを使用してファスト・スタート・フェイルオーバーを無効化できます。「ファスト・スタート・フェイルオーバーの無効化」を参照してください。

関連項目:

スイッチオーバーおよび手動フェイルオーバーの詳細は、それぞれ「スイッチオーバー」および「手動フェイルオーバー」を参照してください

5.5.3 アプリケーションによるファスト・スタート・フェイルオーバーの指示

DBMS_DG PL/SQLパッケージを使用して、特定のアプリケーションのファスト・スタート・フェイルオーバー設定をカスタマイズできます。

アプリケーションに独自に認識される重大な条件が検出されたとき、アプリケーションはDBMS_DG.INITIATE_FS_FAILOVER機能をコールして、即時ファスト・スタート・フェイルオーバーを開始できます。この機能は、接続から構成内のプライマリ・データベースまたはいずれかのスタンバイ・データベースにコールできます。プロシージャがコールされたデータベースは、オブザーバにそれを通知します。フェイルオーバー・ターゲット・データベースがフェイルオーバーを受け入れるために適した状態であれば(監視されており、同期化されているかラグ制限内であれば)、オブザーバによりただちにファスト・スタート・フェイルオーバーが開始されます。オブザーバによってファスト・スタート・フェイルオーバーが開始されると、プライマリ・データベースは自動的に停止します。オブザーバは元のプライマリ・データベースの回復を試行しません。

構成がフェイルオーバー不能の場合、DBMS_DG.INITIATE_FS_FAILOVER機能は、ORAエラー番号(例外ではなく)を返して、ファスト・スタート・フェイルオーバーを実行できないことをコール元に通知します。

ノート:

可能であればオブザーバがフェイルオーバーを開始するため、アプリケーションでDBMS_DG.INITIATE_FS_FAILOVER機能をコールする際には注意が必要です。

関連項目:

DBMS_DGパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

5.5.4 ファスト・スタート・フェイルオーバー構成の統計およびステータスの表示

オブザーバが起動しており、構成がファスト・スタート・フェイルオーバー可能な状態かどうかを確認するには、DGMGRLのSHOW DATABASE <target-standby-database>コマンドを発行します。

または、ターゲット・スタンバイ・データベースでV$DATABASEビューを問い合せます。

V$FS_FAILOVER_STATSビューを問い合せて、システムで発生しているファスト・スタート・フェイルオーバーに関する統計を表示することもできます。

次に、DGMGRL SHOWコマンドを使用してファスト・スタート・フェイルオーバー情報を表示する例を示します。次のビューについても説明します。

例1: SHOW FAST_START FAILOVER

DGMGRLのSHOW FAST-START FAILOVERコマンドは、すべてのファスト・スタート・フェイルオーバー関連情報を表示します。次に例を示します。 

DGMGRL> SHOW FAST_START FAILOVER;
 
Fast-Start Failover: Enabled in Zero Data Loss Mode

 Protection Mode: MaxAvailability
 Lag Limit: 0 seconds

 Threshold:           180 seconds
 Active Target:       South_Sales
 Potential Targets: East_Sales, West_Sales
   East_Sales    valid
   West_Sales    valid
 Observer:            observer.example.com
 Shutdown Primary:    TRUE
 Auto-reinstate:      TRUE
 Observer Reconnect: (none)
 Observer Override: FALSE
 
Configurable Failover Conditions
 Health Conditions:
   Corrupted Controlfile          YES
   Corrupted Dictionary           YES
   Inaccessible Logfile            NO
   Stuck Archiver                  NO   
   Datafile Write Errors          YES 

Oracle Error Conditions:
   (none)

例2: SHOW CONFIGURATION VERBOSE

次の例は、DRSolution構成のファスト・スタート・フェイルオーバー情報を示しています。

Configuration - DRSolution
 
Protection Mode: MaxAvailability
Members:
North_Sales - Primary database
South_Sales - (*) Physical standby database
 
(*) Fast-Start Failover target
 
Properties:
  FastStartFailoverThreshold     = '60'
  OperationTimeout               = '30'
  TraceLevel                     = 'USER'
  FastStartFailoverLagLimit      = '30'
  CommunicationTimeout           = '180'
  ObserverReconnect              = '0'
  FastStartFailoverAutoReinstate = 'TRUE'
  FastStartFailoverPmyShutdown   = 'TRUE'
  BystandersFollowRoleChange     = 'ALL'
  ObserverOverride               = 'FALSE'
  ExternalDestination1           = ''
  ExternalDestination2           = ''
  PrimaryLostWriteAction         = 'CONTINUE'
  ConfigurationWideServiceName = 'North_Sales_CFG'

Fast-Start Failover: Enabled in Zero Data Loss Mode
 
  Lag Limit: 0 seconds
  Threshold: 30 seconds
  Active Target: South_Sales
  Potential Target: "South_Sales"
      South_Sales    valid
  Observer: observer.example.com
  Shutdown Primary: TRUE
  Auto-reinstate: TRUE
  Observer Reconnect: (none)
  Observer Override: FALSE
 
Configuration Status:
SUCCESS

例3: SHOW OBSERVER

次のSHOW OBSERVERコマンドは、DRSolutionブローカ構成内の複数のオブザーバに関する情報を表示します。 

DGMGRL> SHOW OBSERVER;

Configuration - DRSolution

Primary:               North_Sales
Active Target Standby: South_Sales

Observer "ob2" - Master

   Host Name:              observer2.example.com
   Last Ping to Primary:   1 second ago
   Last Ping to Target:    2 seconds ago

Observer "ob1" - Backup

   Host Name:              observer1.example.com
   Last Ping to Primary:   1 second ago
   Last Ping to Target:    3 seconds ago

Observer "ob3" - Backup

   Host Name:              observer3.example.com
   Last Ping to Primary:   4 seconds ago
   Last Ping to Target:    5 seconds ago
5.5.4.1 V$DATABASEビュー

V$DATABASEビューを問い合せて、オブザーバが起動しており、構成がファスト・スタート・フェイルオーバー可能な状態かどうかを確認できます。

V$DATABASEビューを問い合せる場合、次の列に特に注意してください。

  • 表5-1に示す値が含まれる可能性のあるFS_FAILOVER_STATUS列。V$DATABASE.FS_FAILOVER_STATUS列にDISABLEDの値が含まれる場合、ファスト・スタート・フェイルオーバーに関連する残りの列に対し戻される値(V$DATABASE.FS_FAILOVER_*)は無関係になります。

  • オブザーバが実行され、データベースをアクティブにpingしているかどうかを示すFS_FAILOVER_OBSERVER_PRESENT列。

表5-1 V$DATABASEビューのFS_FAILOVER_STATUS列

列値 説明 ファスト・スタート・フェイルオーバー ...

BYSTANDER

ファスト・スタート・フェイルオーバーは有効化されていますが、このスタンバイ・データベースはファスト・スタート・フェイルオーバーのターゲットではありません。このデータベースはファスト・スタート・フェイルオーバーのステータス情報を提供できません。

有効

DISABLED

ファスト・スタート・フェイルオーバーは無効化されています。

不可

LOADING DICTIONARY

プライマリ・データベースのデータ・ディクショナリのコピーをロードし終えていないロジカル・スタンバイ・データベースにのみ表示されます。

不可

PRIMARY UNOBSERVED

ターゲット・スタンバイ・データベースが、プライマリ・データベースとSYNCHRONIZEDされているかプライマリ・データベースのTARGET UNDER LAG LIMITにあり、オブザーバに接続されているとき、プライマリ・データベースがオブザーバに接続されていない場合、ターゲット・スタンバイ・データベースにのみ表示されます。

不可

REINSTATE FAILED

障害が発生したプライマリ・データベースの新規スタンバイ・データベースとしての回復に失敗しました。ブローカのdrc*ログ・ファイルの詳細は、「診断情報のソース」を参照してください。

完了済

REINSTATE REQUIRED

障害が発生したプライマリ・データベースは、新規プライマリに対する新規スタンバイ・データベースとして回復する必要があります。オブザーバにより回復プロセスが自動的に開始されます。REINSTATE REQUIREDは、ファスト・スタート・フェイルオーバーの発生後にのみ存在し、新規プライマリ・データベースと回復を実行しているデータベースの両方に表示されます。回復が完了すると、両方のデータベースでクリアされます。

完了済

STALLED

ターゲット・スタンバイ・データベースとの接続が切断され、UNSYNCHRONIZED状態(最大可用性モード)またはTARGET OVER LAG LIMIT状態(最大パフォーマンス・モード)の変更がターゲット・スタンバイ・データベースとオブザーバのどちらからも確認できない場合、プライマリ・データベースに表示されます。これらの条件でプライマリが無期限にストールするには、FastStartFailoverPmyShutdown構成プロパティの値がFALSEである必要があることに注意してください。このプロパティの値がTRUEの場合、プライマリは、FastStartFailoverThresholdプロパティで指定された秒数の間ストールした後に停止します。

フェイルオーバーが実行された可能性が高いため、プライマリ・データベースが停止またはストールします。

ノート: この状態は、ファスト・スタート・フェイルオーバーが可能で、ターゲット・スタンバイ・データベースもオブザーバも存在しないときに起動し、データベースのオープンを継続可能かどうかを確認した場合にもプライマリで発生します。

可

TARGET OVER LAG LIMIT

構成が最大パフォーマンス・モードで動作しているとき、プライマリ・データベースのREDO生成時点からのスタンバイ・データベースのREDO適用時点の遅れが、FastStartFailoverLagLimit構成プロパティに指定された秒数を超過した場合に表示されます。

不可

TARGET UNDER LAG LIMIT

構成が最大パフォーマンス・モードで動作しているとき、プライマリ・データベースのREDO生成時点からのスタンバイ・データベースのREDO適用時点の遅れが、FastStartFailoverLagLimit構成プロパティに指定された秒数を超過していない場合に表示されます。

可

SUSPENDED

プライマリ・データベースまたはターゲット・スタンバイ・データベースが制御された方法で(ABORTオプションではなく、NORMAL、IMMEDIATEまたはTRANSACTIONALオプションを使用して)停止された場合、ターゲット・スタンバイ・データベースにのみ表示されます。この場合、ファスト・スタート・フェイルオーバーは禁止されます。プライマリ・データベースとの接続がリストアされると、SUSPENDEDがクリアされます。

不可

SYNCHRONIZED

プライマリ・データベースとターゲット・スタンバイ・データベースが同期化されており、構成が最大可用性モードで動作している場合に表示されます。

ターゲット・スタンバイ・データベースがSYNCHRONIZEDを表示し、FS_FAILOVER_OBSERVER_PRESENT列がYESを表示する場合に可能です。

UNSYNCHRONIZED

ターゲット・スタンバイ・データベースがプライマリ・データベースのすべてのREDOデータを持たず、構成が最大可用性モードで動作している場合に表示されます。

不可

FS_FAILOVER_MODE

現在のファスト・スタート・フェイルオーバー・モードを表示します。

モードには、次のいずれかの値を含むことができます。

  • DISABLED: ファスト・スタート・フェイルオーバーは無効化されています。

  • OBSERVE-ONLY: ファスト・スタート・フェイルオーバーは監視専用モードで有効にされます。

  • ZERO DATA LOSS: ファスト・スタート・フェイルオーバーがデータ損失ゼロで有効にされます。このモードでは、FastStartFailoverLagLimit構成プロパティはゼロに設定されます。

  • POTENTIAL DATA LOSS: ファスト・スタート・フェイルオーバーがデータ損失一部ありで有効化されます。このモードでは、FastStartFailoverLagLimit構成プロパティはゼロ以外の値に設定されます。ファスト・スタート・フェイルオーバーでは、FastStartFailoverlagLimitで指定された時間内にデータ損失が発生する可能性があります。

5.5.4.2 V$FS_FAILOVER_STATSビュー

プライマリ・データベースのV$FS_FAILOVER_STATSビューを問い合せて、システムで発生したファスト・スタート・フェイルオーバーに関する統計を表示できます。

ファスト・スタート・フェイルオーバーは完全に自動化されており、いつでも発生する可能性があるので、このような問合せを実行すると役立つ場合があります。監視可能な統計の一部を次に示します。

  • LAST_FAILOVER_TIMEは、最後に発生したファスト・スタート・フェイルオーバーのタイムスタンプを示します。

  • LAST_FAILOVER_REASONは、最後に発生したファスト・スタート・フェイルオーバーの原因を示します。

次に、V$FS_FAILOVER_STATSビューの問合せの例を示します。 

SQL> SELECT LAST_FAILOVER_TIME, LAST_FAILOVER_REASON FROM V$FS_FAILOVER_STATS;
 
LAST_FAILOVER_TIME
--------------------
LAST_FAILOVER_REASON
------------------------------------------------------------------------------------------------------------------------------------
02/13/2007 16:53:10
Primary Disconnected

5.5.5 ファスト・スタート・フェイルオーバーの無効化

ファスト・スタート・フェイルオーバーを無効化すると、オブザーバはターゲット・スタンバイ・データベースへのフェイルオーバーを開始できなくなります。

ファスト・スタート・フェイルオーバーが無効化されている場合でも、手動フェイルオーバーを実行できることがあります。手動フェイルオーバーの詳細は、「手動フェイルオーバー」を参照してください。

ノート:

ファスト・スタート・フェイルオーバーを無効にしても、オブザーバは停止されません。オブザーバを停止するには、「オブザーバの停止」を参照してください。

ファスト・スタート・フェイルオーバーを無効にするには、Cloud Controlのファスト・スタート・フェイルオーバー・ウィザードまたはDGMGRLのDISABLE FAST_START FAILOVER [FORCE]コマンドを使用します。FORCEオプションを使用すると、エラーが発生した場合でも、接続先のデータベースでファスト・スタート・フェイルオーバーが無効化されます。FORCEオプションが必要かどうかは、プライマリ・データベースおよびターゲット・スタンバイ・データベースにネットワーク接続が存在するかどうかによって決まります。

  • プライマリ・データベースおよびターゲット・スタンバイ・データベースにネットワーク接続が存在し、接続先のデータベースがプライマリ・データベースとネットワークで接続されている場合、FORCEオプションを使用しても効果はありません。オプションを指定せずにDISABLE FAST_START FAILOVERを使用してください。この方法では、ブローカ構成内のすべてのデータベースでファスト・スタート・フェイルオーバーが無効化されます。

    無効化操作中にエラーが発生した場合、ブローカによりエラー・メッセージが戻され、無効化操作が停止されます。

  • プライマリ・データベースおよびターゲット・スタンバイ・データベースにネットワーク接続が存在しないか、または接続先のデータベースにプライマリ・データベースとのネットワーク接続が存在しない場合、DISABLE FAST_START FAILOVERをFORCEオプションとともに使用することを考慮します。

    DISABLE FAST_START FAILOVER FORCEコマンドを発行した場合、ブローカはブローカ構成内のすべてのデータベースでファスト・スタート・フェイルオーバーをi無効化できない場合があります。その結果、フェイルオーバーの条件を満たしているとオブザーバが判別した場合に、オブザーバがターゲット・スタンバイ・データベースへのファスト・スタート・フェイルオーバーを実行しないという保証がなくなります。次のリストに、プライマリ・データベース、ターゲット・スタンバイ・データベースおよびファスト・スタート・フェイルオーバーのターゲットでないスタンバイ・データベースでDISABLE FAST_START FAILOVER FORCEコマンドが発行された場合に、ブローカ構成でファスト・スタート・フェイルオーバーが無効化される範囲を示しています。

    次のデータベースでこのコマンドを発行した場合、次のようになります。

    • プライマリ・データベースとの接続が存在しないターゲット・スタンバイ・データベースで発行した場合、ターゲット・スタンバイ・データベースでのみファスト・スタート・フェイルオーバーが無効化されます。この場合、オブザーバではフェイルオーバーの条件を満たしていてもファスト・スタート・フェイルオーバーを実行できません。ファスト・スタート・フェイルオーバーの発生を確実に防ぐには、ターゲット・スタンバイ・データベースに接続しているときにFORCEオプションを使用してファスト・スタート・フェイルオーバーを無効化します。

      プライマリ・データベースおよびターゲット・スタンバイ・データベースのネットワーク接続が回復すると、ブローカによりブローカ構成全体のファスト・スタート・フェイルオーバーが無効化されます。

    • プライマリ・データベースで発行した場合、構成内のネットワーク接続が確立されたすべてのデータベースで、ファスト・スタート・フェイルオーバーの無効化が試行されます。プライマリ・データベースとターゲット・スタンバイ・データベースとの接続が確立されていない場合、ターゲット・スタンバイ・データベースではファスト・スタート・フェイルオーバーが有効のままとなり、フェイルオーバーの条件を満たした場合にオブザーバによりファスト・スタート・フェイルオーバーが試行されます。

      注意:

      この処理を実行すると、ファスト・スタート・フェイルオーバーが発生した場合に、構成内の2つのデータベースで同時にプライマリ・データベース・ロールが引き継がれる可能性があります。このため、ターゲット・スタンバイ・データベースにこのコマンドを最初に発行する必要があります。

    • プライマリ・データベースとの接続が存在しない別のスタンバイ・データベースで発行した場合、このデータベースではファスト・スタート・フェイルオーバーが無効化されます。ターゲット・スタンバイ・データベースでファスト・スタート・フェイルオーバーが無効化されていないため、フェイルオーバーの条件を満たした場合に、オブザーバによりターゲット・スタンバイ・データベースへのファスト・スタート・フェイルオーバーが試行される場合があります。

      プライマリ・データベースとスタンバイ・データベース(非ターゲット)のネットワーク接続が回復すると、ブローカの現在のファスト・スタート・フェイルオーバーの設定(ENABLEDまたはDISABLED)がターゲットでないスタンバイに伝播されます。

      注意:

      ネットワークが切断されており、プライマリ・データベースまたはプライマリ・データベースと接続されていないスタンバイ・データベースでDISABLE FAST_START FAILOVER FORCEコマンドを発行した場合、ブローカ構成内の一部のデータベースでファスト・スタート・フェイルオーバーが無効化されない場合があります。結果として、フェイルオーバーの条件を満たしている場合、オブザーバによりターゲット・スタンバイ・データベースへのファスト・スタート・フェイルオーバーが開始される可能性があります。これにより、構成内の2つのデータベースで同時にプライマリ・データベース・ロールが引き継がれる可能性があります。

FORCEオプションを必要とする条件

FORCEオプションを使用しないファスト・スタート・フェイルオーバーの無効化が正常に実行されるのは、コマンドが発行されたデータベースとプライマリ・データベースの間にネットワーク接続が存在し、プライマリ・データベースとターゲット・スタンバイ・データベースの間にネットワーク接続が存在する場合のみです。ファスト・スタート・フェイルオーバーを無効化するには、この方法をお薦めします。

ただし、プライマリ・データベースとターゲット・スタンバイ・データベースの間にネットワーク接続が存在しない場合、またはファスト・スタート・フェイルオーバーの無効化コマンドを発行したデータベースとプライマリ・データベースとの間にネットワーク接続が存在しない場合に、ファスト・スタート・フェイルオーバーを無効化する必要があることも考えられます。ネットワーク接続が失われている場合、フェイルオーバーの条件を満たした場合に、オブザーバによりターゲット・スタンバイ・データベースへのファスト・スタート・フェイルオーバーが試行される場合があるので注意してください。次の場合は、ファスト・スタート・フェイルオーバーの無効化にFORCEオプションを使用することをお薦めします。

  • ネットワーク障害により、プライマリ・データベースがオブザーバおよびターゲット・スタンバイ・データベースから分離された場合(フェイルオーバーの条件を満たす前)。

    この場合、プライマリ・データベースが分離されている間にファスト・スタート・フェイルオーバーが実行された可能性があるため、プライマリ・データベースがストールし、トランザクションをコミットできなくなります。ネットワークの切断が長時間にわたると予想され、プライマリ・データベースを使用可能にする必要がある場合は、まず、ターゲット・スタンバイ・データベースにファスト・スタート・フェイルオーバーが実行されていないことを確認します。次に、プライマリ・データベースでFORCEオプションによりファスト・スタート・フェイルオーバーを無効化します。可能な場合、プライマリ・データベースでFORCEオプションによりファスト・スタート・フェイルオーバーを無効化する前に、ターゲット・スタンバイ・データベースにファスト・スタート・フェイルオーバーが実行されていないことを確認します。

    注意:

    この処理により、構成内の2つのデータベースで同時にプライマリ・データベース・ロールが引き継がれる可能性があります。ターゲット・スタンバイでFORCEオプションによりファスト・スタート・フェイルオーバーを最初に無効化しておくと、これを回避できます。

  • 構成内のスタンバイ・データベースに手動フェイルオーバーを実行する場合(たとえば、プライマリ・データベースおよびターゲット・スタンバイ・データベースがフェイルオーバー可能でないときにプライマリ・データベースで障害が発生したため)。

    この場合、データベースがフェイルオーバー可能でないため、ファスト・スタート・フェイルオーバーを実行できません。同じ理由で、ターゲット・スタンバイ・データベースへの手動フェイルオーバーを実行できません。続行するには、まずFORCEオプションを使用してファスト・スタート・フェイルオーバーを無効にしてから、手動フェイルオーバーを実行する必要があります。

    注意:

    この処理によりデータが失われ、構成内の2つのデータベースで同時にプライマリ・データベース・ロールが引き継がれる可能性があります。ターゲット・スタンバイでFORCEオプションによりファスト・スタート・フェイルオーバーを最初に無効化しておくと、これを回避できます。

  • ターゲット・スタンバイ・データベースへのファスト・スタート・フェイルオーバーに失敗した場合。

    なんらかの理由でフェイルオーバーに失敗した場合、ターゲット・スタンバイ・データベースがフェイルオーバー可能かどうかにかかわらず、ターゲット・スタンバイ・データベースが動作不能になる可能性があります。フェイルオーバーに使用できる別のスタンバイ・データベースが存在する場合、まずそのスタンバイ・データベースでFORCEオプションを使用してファスト・スタート・フェイルオーバーを無効化してから、そのスタンバイ・データベースへの手動フェイルオーバーを実行できます。

  • まもなくプライマリ・データベースによりサービスが再開されるため、ファスト・スタート・フェイルオーバーを実行しないようにする場合。

    この場合、ターゲット・スタンバイ・データベースでFORCEオプションを使用してファスト・スタート・フェイルオーバーを無効にします。プライマリ・データベースとターゲット・スタンバイ・データベースとの接続が回復すると、構成内のすべてのデータベースでファスト・スタート・フェイルオーバーが無効化されます。

Cloud Controlを使用したファスト・スタート・フェイルオーバーの無効化

ファスト・スタート・フェイルオーバー・ウィザードで「無効化」をクリックします。次に、「続行」をクリックして次のページに進みます。詳細は、Cloud Controlのオンライン・ヘルプを参照してください。

DGMGRLを使用したファスト・スタート・フェイルオーバーの無効化

DISABLE FAST_START FAILOVERコマンドまたはDISABLE FAST_START FAILOVER FORCEコマンドを発行します。詳細は、「Oracle Data Guardコマンドライン・インタフェース・リファレンス」の「DISABLE FAST_START FAILOVER」コマンドを参照してください。

5.5.6 ファスト・スタート・フェイルオーバーのパフォーマンスに関する考慮事項

次のリストには、ファスト・スタート・フェイルオーバーを使用する際のパフォーマンスを向上させるための推奨事項が含まれています。

  • フェイルオーバー時間は、ターゲット・スタンバイ・データベース(フィジカルまたはロジカル・スタンバイ・データベース)がプライマリ・データベースから受け取ったREDOデータをすべて適用したかどうかによって決まります。

  • 最大パフォーマンス・モードで動作している構成でファスト・スタート・フェイルオーバーを有効化すると、REDOデータが非同期でターゲット・スタンバイに転送されるため、プライマリ・データベースでの全体的なパフォーマンスが向上します。この場合はデータが消失しないことが保証されないことに注意してください。

  • スタンバイ・データベースへのREDOデータの適用がプライマリ・データベースのREDO適用率と一致した状態が保たれるように、リカバリを最適化するステップを実行すると、ファスト・スタート・フェイルオーバーが高速になります。ログ適用率を最適化するには、次のようにします。

    • データベース・プロパティDelayMinsを設定することにより、スタンバイ・データベースへのアーカイブREDOログ・ファイルの適用を遅延させないでください(詳細は、「ログ適用サービスの管理」を参照してください)。

    • フィジカル・スタンバイ・データベースのログ適用率のチューニングの詳細は、『Oracle Data Guard概要および管理』を参照してください。

    • 次の場所にあるOracle Maximum Availability Architectureの簡単な技術的説明を参照してください。

      http://www.oracle.com/goto/maa

  • FastStartFailoverLagLimit構成プロパティを設定する際は、パフォーマンスとデータ消失の可能性の間のトレードオフを考慮してください。

    • ラグ制限を低くすると、データの消失は最小限に抑えられますが、プライマリ・データベースのパフォーマンスに影響を与える場合があります。

    • ラグ制限を高くすると、消失データ量が増加する可能性がありますが、プライマリ・データベースのパフォーマンスへの影響は緩和されます。

5.5.7 オブザーバの管理

オブザーバ・プロセスは、ブローカのDGMGRLクライアント側コンポーネントに統合されており、通常はプライマリ・データベースまたはスタンバイ・データベースおよびブローカ構成を管理するコンピュータとは異なるコンピュータ上で動作します。

1つのData Guard構成に対して最大3つのオブザーバを設定できます。オブザーバは、継続的にファスト・スタート・フェイルオーバー環境を監視して、プライマリ・データベースが使用可能であることを確認します。(「ファスト・スタート・フェイルオーバーの有効化およびオブザーバの実行」を参照)。オブザーバの主な目的は、停止時間が長くなる可能性がある、手動フェイルオーバー・プロセスで必要な人的操作を少なくすることで、高可用性および完全自動コンピューティングを強化することです。

Cloud ControlのOracle Data Guardの「概要」ページまたはDGMGRLコマンドを使用して、オブザーバを管理できます。図5-2に、オブザーバによるファスト・スタート・フェイルオーバー構成の監視を示しています。

図5-2 ファスト・スタート・フェイルオーバー環境でのオブザーバ

図5-2の説明が続きます
「図5-2 ファスト・スタート・フェイルオーバー環境でのオブザーバ」の説明

次の各項では、オブザーバの管理情報を説明します。

5.5.7.1 オブザーバのインストールおよび起動

オブザーバは、プライマリ・システムおよびスタンバイ・システムとは別のコンピュータ・システムにインストールし、動作させる必要があります。

オブザーバのインストールおよび起動は、ファスト・スタート・フェイルオーバーの使用における必須部分であり、次の各項で詳細に説明しています。

オブザーバを起動するには、SYSDGまたはSYSDBA権限を持つアカウントでDGMGRLにログインできる必要があります。オブザーバは、DGMGRLでOracle Data Guard構成に接続したときに使用したSYS資格証明を使用してプライマリ・データベースおよびターゲット・スタンバイ・データベースに接続するOCIクライアントです。

関連項目:

  • オブザーバとDGMGRLの間の互換性要件の詳細は、http://support.oracle.comにあるMy Oracle Supportノート1625597.1を参照してください

Data Guard Broker構成での複数のオブザーバの起動

ノート:

Oracle Databaseリリース12.2以上では、Oracle Enterprise Manager Cloud Control (Cloud Control)でEnterprise Managerコマンドライン・インタフェース(EM CLI)を使用した複数のオブザーバの構成がサポートされます。EMCLI動詞dg_configure_observersを使用します。この動詞のサブコマンドには、start、stop、setMaster、showおよびdelete_alternate_observerが含まれます。Oracle Enterprise Managerコマンドライン・インタフェースを参照してください。

1つのData Guard Broker構成を監視するには、最大で3つのオブザーバを登録できます。各オブザーバは、START OBSERVERコマンドの発行時に指定する名前で識別されます。1つの構成に対して複数のオブザーバが登録されている場合は、次の条件が適用されます。

  • ファスト・スタート・フェイルオーバーが有効化されている場合、オブザーバの1つはマスター・オブザーバです。残りのオブザーバはバックアップ・オブザーバと呼ばれます。ファスト・スタート・フェイルオーバーが無効化されている場合、どのオブザーバもマスター・オブザーバとは呼ばれず、すべてのオブザーバが同じ機能を持ちます。

  • 同一のData Guard Broker構成上で2つのオブザーバに同じ名前を付けることはできません。

  • オブザーバの名前を指定しない場合は、デフォルトのオブザーバ名(START OBSERVERコマンドが発行されたマシンのホスト名)が使用されます。

  • オブザーバ名の大/小文字は区別されません。

  • 文字列"NONAME"はオブザーバ名として使用できません。

  • 各オブザーバには独自のログ・ファイルがあります。ログ・ファイル名は、START OBSERVERコマンドのLOGFILE ISオプションで指定します。指定したログ・ファイルにアクセスできない場合、またはLOGFILE ISオプションが使用されていない場合、オブザーバの出力は標準出力に送信されます。

  • テスト目的の場合を除き、Data Guard Broker構成に対して同じホスト上で複数のオブザーバを起動しないことをお薦めします。

  • SHOW FAST_START FAILOVERコマンドは、登録済オブザーバのリストを表示して、どのオブザーバがマスターなのかを示します。

  • SHOW OBSERVERコマンドは、登録済オブザーバの詳細情報を表示します。

マスター・オブザーバとバックアップ・オブザーバ

ノート:

マスター・オブザーバは、Oracle Database 12cリリース2 (12.2.0.1)で複数オブザーバが登場する前に機能していた単一のオブザーバと同じように機能します。

ファスト・スタート・フェイルオーバーが無効化されている場合、オブザーバでファスト・スタート・フェイルオーバーを調整する必要がないため、プライマリおよびターゲット・スタンバイでは、ファスト・スタート・フェイルオーバーが有効化されるまでマスター・オブザーバは指定されません。ファスト・スタート・フェイルオーバーが有効化されている場合、プライマリおよびスタンバイは登録済オブザーバの1つをランダムに選択してマスターにします。ファスト・スタート・フェイルオーバーが有効化されていて、登録済オブザーバがない場合、最初に起動したオブザーバがマスター・オブザーバに指定され、その後に起動した他のオブザーバはすべてバックアップ・オブザーバになります。Data Guard Brokerでファスト・スタート・フェイルオーバーを調整できるのはマスター・オブザーバのみです。他の登録済オブザーバはすべてバックアップ・オブザーバとみなされます。

マスター・オブザーバの手動による変更

必要に応じてSET MASTEROBSERVER TO Observer-Nameコマンドを使用し、マスターにするオブザーバを変更できます。次に例を示します。 
DGMGRL> SET MASTEROBSERVER TO boston-obsever;
Succeeded.

このコマンドが発行された場合、実際に切替えが発生するのは、プライマリがターゲット・スタンバイと次回通信したとき(ファスト・スタート・フェイルオーバーが有効化されている場合、通常は3秒以内)です。SHOW OBSERVERコマンドを発行して、切替えが実行されたことを確認できます。詳細は、「SET MASTEROBSERVER TO」を参照してください。

バックグラウンド・プロセスとしてのオブザーバの起動

オブザーバをバックグラウンド・プロセスとして実行するには、DGMGRLコマンドSTART OBSERVER IN BACKGROUNDを使用します。特定のブローカ構成内にある1つ以上のデータベースに接続可能な接続識別子を指定する必要があります。次に、オブザーバをバックグラウンド・プロセスとして起動する例を示します。 

DGMGRL> START OBSERVER IN BACKGROUND 
FILE IS  /net/sales/dat/oracle/broker/fsfo.dat 
LOGFILE IS /net/sales/dat/oracle/broker/observer.log 
CONNECT IDENTIFIER IS sales_p

Submitted command "START OBSERVER" using connect identifier "sales_p" 

DGMGRL>

START OBSERVER IN BACKGROUNDコマンドではOracleウォレットを使用して資格証明を取得し、データベース・サーバーにログインして、オブザーバを登録します。CONNECTコマンドを使用してブローカ構成内のデータベース・サーバーに正常に接続している場合でも、このコマンドでは既存の接続が無視され、Oracleウォレットに格納されている資格証明が使用されます。詳細は、「START OBSERVER IN BACKGROUND」を参照してください。

単一ホスト上での複数のオブザーバの起動

1つのOracleホームを使用して複数のオブザーバを起動し、各オブザーバで異なるファスト・スタート・フェイルオーバー構成を監視する場合は、FILE修飾子を使用して、監視する各構成に一意のオブザーバ構成ファイルの場所を指定してください。オブザーバが生成するロギングを取得する場合は、START OBSERVERコマンドでLOGFILEオプションを使用し、一意のファイル名を指定してください。次に例を示します。 

% dgmgrl
DGMGRL> CONNECT /@primary1;
DGMGRL> START OBSERVER FILE IS '/u01/oracle/dbs/config1.dat' 
LOGFILE IS '/u01/oracle/log/config1.log'

% dgmgrl
DGMGRL> CONNECT /@primary2;
DGMGRL> START OBSERVER FILE IS '/u01/oracle/dbs/config2.dat' 
LOGFILE IS '/u01/oracle/log/config2.log'

ノート:

DGMGRLの-logfileオプションは、Oracle Database 12cリリース2 (12.2.0.1)では非推奨です。下位互換性のためにのみサポートされています。かわりに、START OBSERVERコマンドでLOGFILE IS句を使用してログ・ファイルが指定されるようになりました。
5.5.7.2 マスター・オブザーバに関する情報の表示

マスター・オブザーバに関する情報を検索するには、V$DATABASEビューを問い合せます。

  • FS_FAILOVER_OBSERVER_HOSTは、マスター・オブザーバが動作するコンピュータの名前を示します

  • FS_FAILOVER_OBSERVER_PRESENTは、マスター・オブザーバがローカル・データベースに接続しているかどうかを示します

次の表の列値は、Oracle Real Application Clusters (Oracle RAC)環境内の全インスタンスで一貫性が保たれています。つまり、オブザーバがOracle RAC内のインスタンスに接続されている場合、すべてのインスタンスにYESの値が示されます。

表5-2 V$DATABASEビューのFS_FAILOVER_OBSERVER_PRESENT列

列値 説明

YES

マスター・オブザーバは現在ローカル・データベースに接続している

NO

マスター・オブザーバはローカル・データベースに接続していない

たとえば、ファスト・スタート・フェイルオーバーが実行可能かどうかを判断するには、ターゲット・スタンバイ・データベースで、FS_FAILOVER_STATUS列にSYNCHRONIZEDまたはTARGET UNDER LAG LIMITが表示されており、FS_FAILOVER_OBSERVER_PRESENT列にYESと表示されていることを確認します。次に例を示します。

データベース FS_FAILOVER_STATUS 保護モード FS_FAILOVER_OBSERVER_PRESENT

プライマリ

SYNCHRONIZED

最大可用性

YES

スタンバイ

SYNCHRONIZED

最大可用性

YES

プライマリ

TARGET UNDER LAG LIMIT

最大パフォーマンス

YES

スタンバイ

TARGET UNDER LAG LIMIT

最大パフォーマンス

YES

次の例では、プライマリ・データベースとオブザーバの間のネットワークに障害が発生したと仮定しています。この場合、FS_FAILOVER_STATUSおよびFS_FAILOVER_OBSERVER_PRESENT列は次の表に示すように表示され、ファスト・スタート・フェイルオーバーは実行されません。

データベース FS_FAILOVER_STATUS FS_FAILOVER_OBSERVER_PRESENT

プライマリ

SYNCHRONIZED

NO

スタンバイ

PRIMARY UNOBSERVED

YES

関連項目:

5.5.7.3 すべてのオブザーバに関する情報の表示

V$FS_FAILOVER_OBSERVERSビューでは、マスター・オブザーバやバックアップ・オブザーバを含むすべてのオブザーバに関する詳細情報を検索できます。

V$FS_FAILOVER_OBSERVERSビューは、各オブザーバについて、そのオブザーバ名、ホスト、マスター・オブザーバかどうか、マスター・オブザーバになった時間、およびプライマリ・データベースとターゲット・スタンバイ・データベースに現在接続されているかどうかを示します。

関連項目:

5.5.7.4 マスター・オブザーバに障害が発生した場合の動作。

マスター・オブザーバに障害が発生した場合のブローカの動作は、ブローカ構成内のオブザーバが1つなのか、複数あるのかによって異なります。

オブザーバが1つしかない場合は、そのオブザーバがマスター・オブザーバとみなされます。オブザーバが複数ある場合は、そのうちの1つのみがマスター・オブザーバです。

ブローカ構成の登録済オブザーバが1つのみの場合

構成の登録済オブザーバが1つのみで、プライマリ・データベースとターゲット・スタンバイ・データベースの間の接続が維持された状態でオブザーバからの接続が失われた場合、ブローカにより、構成が監視されていないと報告されます。 構成およびデータベースのステータスにより、オブザーバが動作していないと報告され、次のいずれかのステータス・メッセージが戻されます。 

ORA-16658: unobserved fast-start failover configuration
ORA-16820: fast-start failover observer is no longer observing this database

構成が監視されない状態の場合、ファスト・スタート・フェイルオーバーは実行できません。そのため、ターゲット・スタンバイ・データベースに障害が発生した場合でも、プライマリ・データベースはトランザクションの処理を続行できます。オブザーバとプライマリ・データベースとの接続が再確立され、プライマリ・データベースによりターゲット・スタンバイ・データベースに通知が送られると、構成ステータスによりSUCCESSステータスが戻されます。

関連項目:

ファスト・スタート・フェイルオーバー構成の統計およびステータスの表示

ブローカ構成に複数の登録済オブザーバがある場合

構成に複数の登録済オブザーバがあり、プライマリ・データベースとターゲット・スタンバイ・データベースの間の接続が維持された状態でマスター・オブザーバからの接続が失われた場合、ブローカは、バックアップ・オブザーバを新しいマスター・オブザーバに指定しようとします。この指定はオブザーバ・ログ・ファイルおよびブローカ・ログ・ファイル(drc*.log)に記録されます。また、SHOW FAST_START FAILOVERコマンドおよびSHOW OBSERVERコマンドで表示される出力で、新しいマスター・オブザーバが識別されます。

ノート:

新しいマスター・オブザーバの識別中、新しいマスター・オブザーバが選択されて構成を監視し始めるまで、ファスト・スタート・フェイルオーバーは発生しません。

プライマリ・データベースまたはターゲット・スタンバイ・データベースとすべてのバックアップ・オブザーバとの接続が失われた場合、ブローカは、バックアップ・オブザーバを新しいマスター・オブザーバに指定しようとせずに、構成が監視されていないことを報告します。構成およびデータベースのステータスにより、登録済オブザーバが1つしかない場合に戻るエラー・メッセージと同じメッセージが報告されます。

5.5.7.5 オブザーバのプライマリへの接続の管理

ObserverOverrideおよびObserverReconnectプロパティを使用すると、プライマリへの接続をさらに制御できます。

オブザーバが、FastStartFailoverThresholdプロパティで指定されているより長い期間、プライマリ・データベースへの接続を失った場合、スタンバイ・データベースへのフェイルオーバーが試みられます。FastStartFailoverThresholdプロパティで指定された期間内にスタンバイがプライマリからアクセスを受けた場合、フェイルオーバーは試行されません。

この動作をオーバーライドして、オブザーバがFastStartFailoverThresholdで指定された秒数より長い間プライマリにアクセスできない場合にファスト・スタート・フェイルオーバーが行われるようにするには、ObserverOverrideプロパティをTRUEに設定します。次に例を示します。 

DGMGRL> EDIT CONFIGURATION SET PROPERTY ObserverOverride=TRUE;

通常、オブザーバは一度プライマリに接続したら、接続に障害が発生しないかぎり、再接続を試みません。プライマリへのネットワーク接続の健全性をテストする手段として、オブザーバがプライマリ・データベースに定期的に再接続する場合は、ObserverReconnect構成プロパティを使用します。これは、オブザーバがプライマリ・データベースに対して新しい接続を確立する頻度を指定します。次の例では、ObserverReconnectが30秒に設定されています。この場合、オブザーバは30秒ごとにプライマリ・データベースに対して新しい接続を確立します。 

DGMGRL> EDIT CONFIGURATION SET PROPERTY ObserverReconnect=30;
5.5.7.6 オブザーバの停止

特定のオブザーバまたはすべてのオブザーバを手動で停止できます。

オブザーバを停止する前に、次の点に注意してください。

  • オブザーバは、STOP OBSERVERコマンドを発行してすぐには停止しません。ブローカがSTOP OBSERVER要求を受け取ると、要求は次回オブザーバがブローカと通信する際にオブザーバに渡され、その後にオブザーバは停止します。

  • オブザーバを停止しても、ファスト・スタート・フェイルオーバーは無効化されません。ただし、ターゲット・スタンバイ・データベースが監視されない状態の場合、ファスト・スタート・フェイルオーバーは実行できません。

  • ファスト・スタート・フェイルオーバーが無効化されている場合にオブザーバを停止するには、プライマリ・データベースが動作している必要があります。

  • ファスト・スタート・フェイルオーバーが有効化されているときにオブザーバを停止するには、プライマリ・データベースおよびターゲット・スタンバイ・データベースが接続されており、相互に通信している必要があります。相互に分離している場合は、まずFORCEオプションを使用してファスト・スタート・フェイルオーバーを無効にしてから、オブザーバを停止する必要があります。(FORCEオプションを使用する際に考慮すべき重要事項については、「ファスト・スタート・フェイルオーバーの無効化」を参照してください。)

すべてのオブザーバの停止

STOP OBSERVER ALLを指定すると、ブローカ構成内に登録済のすべてのオブザーバを停止できます。

オブザーバが複数ある場合の特定のオブザーバの停止

複数の登録済オブザーバが動作している場合に特定のオブザーバを停止するには、次のコマンドを発行します。

DGMGRL> STOP OBSERVER observer_name;

任意のマシンからDGMGRLにログインして、オブザーバを停止できます。たとえば、observer1が動作しているシステムにログインして、observer2を停止できます。

複数のオブザーバが構成されている環境で、マスター・オブザーバは停止できません(ただし、それが動作中の最後のオブザーバである場合を除きます)。現在マスター・オブザーバに指定されているオブザーバを停止するには、まずSET MASTEROBSERVERコマンドを発行して、別のオブザーバをマスター・オブザーバに指定します。その後で、STOP OBSERVERコマンドを元のマスター・オブザーバに対して正常に発行できます。

オブザーバが1つしかない場合のオブザーバの停止

登録済オブザーバが1つしかない場合、そのオブザーバは、Oracle Database 12cリリース2 (12.2.0.1)で複数オブザーバが登場する前に機能していた単一のオブザーバと同じように機能します。これを停止するには、次のいずれかを実行します。

  • Cloud Controlの使用

    ファスト・スタート・フェイルオーバー・ウィザードの1ページ目で「オブザーバを停止」オプションを選択し、ページ下部の「続行」をクリックします。詳細は、Cloud Controlのオンライン・ヘルプを参照してください。

  • DGMGRLの使用

    次のコマンドを発行します。

    DGMGRL> STOP OBSERVER;

    登録済オブザーバが複数ある場合、このコマンドを実行するとエラーが戻ります。オブザーバが複数ある場合、名前は必須です。

ノート:

詳細は、STOP OBSERVERコマンドを参照してください。
5.5.7.7 オブザーバの別のコンピュータへの移動

オブザーバを1つのシステム上で停止し、別のシステム上で再起動する処理により、オブザーバをコンピュータ間で移動できます。

オブザーバを別のコンピュータに移動するには:

  1. 「オブザーバの停止」の説明に従って、ブローカ構成内の任意のコンピュータ・システムからオブザーバを停止します。
  2. 「ファスト・スタート・フェイルオーバーの有効化」のステップ8の説明に従って、新規コンピュータ・システムでオブザーバを起動します。

オブザーバを移動する際にファスト・スタート・フェイルオーバーを無効化する必要はありません。

5.5.7.8 オブザーバによるファスト・スタート・フェイルオーバー構成情報のメンテナンス方法

オブザーバでは、オブザーバを起動した作業ディレクトリに作成されているバイナリ・ファイルで、ファスト・スタート・フェイルオーバー構成に関する情報が永続的にメンテナンスされます。

デフォルトでは、オブザーバの起動時に、現行の作業ディレクトリにこのファイルが作成され、fsfo.datという名前が付けられます。このファイルには、プライマリ・データベースおよびターゲット・スタンバイ・データベースの両方に対する接続識別子が含まれます。

権限のないユーザーはこのファイルを読めないことを確認します。

オブザーバの起動後は、ファイルの名前および場所を変更できません。ただし、オブザーバの起動にDGMGRLのSTART OBSERVERコマンドを使用し、FILE IS修飾子を含める場合は、ファイルの名前または場所を変更できます。詳細は、START OBSERVERコマンドを参照してください。

ノート:

オブザーバが通常と異なる方法で(CTRL/Cを入力するなど)停止された場合、オブザーバを再起動し、FILE IS修飾子を含む既存のfsfo.datファイルを参照してください。

5.5.7.9 複数構成のオブザーバの管理

DGMGRLを使用して、ブローカ構成のグループ内にある複数のオブザーバを管理できます。

構成のグループに対応する複数のオブザーバを起動、停止および表示できます。また、構成のグループに対応する複数のマスター・オブザーバ・ホストを特定の1つのホストに切り替えることもできます。

管理対象のブローカ構成のグループは、オブザーバ構成ファイルで宣言されます。デフォルトのグループは、オブザーバ構成ファイルに定義されているすべての構成です。デフォルトを使用しない場合、特定のグループを定義できます。オブザーバ構成ファイルはテキスト・ファイルで、オブザーバとグループを定義する構文はlistener.oraファイルまたはtnsnames.oraファイルで使用されている構文と類似しています。次の順に、2つの部分で構成されます。

  1. 構成宣言 — このセクションは必須です。オブザーバ構成ファイルの最初の部分として表示される必要があります。

  2. グループ定義 — このセクションは省略可能です。指定する場合は、2番目の部分に、グループごとに1つ以上のブローカ構成が宣言されている必要があります。

必須の構成宣言の構文

構成宣言の構文を次に示します。

BROKER_CONFIGS = ( 
(configuration1-definition) 
(configuration2-definition)
...
(configuration-n-definition)
)

各ブローカ構成の定義を次に示します。

CONFIG= (NAME        =configuration-name)
        (CONNECT_ID  =connect-identifier) 
        (CONFIG_HOME =config-home-location) 
)

次の点に注意してください。

  • configuration-nameは、Data Guard Broker構成のメタデータに定義されている名前と異なっていてもかまいません。(メタデータに定義されている名前には、オブザーバ構成ファイルでは使用できない空白や国際文字が含まれている場合があるので、これは便利です。)

  • connect-identifierはtnsnames.oraに定義されているTNS別名であり、これを使用して、このData Guard Broker構成内のすべてのデータベースのすべてのインスタンスに接続できます。

  • Config-home-locationでは、オブザーバ・ログ・ファイルおよびFSFO.datファイルの場所を指定します。

  • 構成定義内で重複する構成名は使用できません。

グループ定義(省略可能)の構文

ブローカ構成グループの定義(省略可能)の構文を次に示します。

CONFIG_GROUPS = ( 
(group1-definition) 
(group2-definition)
...
(group-n-definition)
)

各グループの定義を次に示します。

GROUP =(NAME=group-name)
             (CONFIG_LIST= 
                   (NAME=configuration1-name)
                   (NAME=configuration2-name)
                   ...
                   (NAME=configuration-n-name)
              )

次の点に注意してください。

  • グループ定義セクションは省略可能です。グループが定義されていない場合でも、ファイルに定義されているすべての構成全体に対する操作は可能です。

  • ALLという語は予約済キーワードなので、グループ名としては使用できません。

  • 重複するグループ名は使用できません。
  • 定義するグループごとに1つ以上のブローカ構成が必要です。
  • 参照されるブローカ構成名はすべて構成宣言セクションに含まれている必要があります。
  • ブローカ構成は複数のグループに属することができます。

オブザーバ構成ファイルの指定

複数のオブザーバに影響するコマンドを実行する際、オブザーバ構成ファイルの名前と場所を指定しなかった場合、ブローカは現在の作業ディレクトリでobserver.oraという名前のファイルを検索します。ファイルが存在しない場合、コマンドは失敗します。

ただし、オブザーバ構成ファイルの名前と場所は指定できます。これを行うには、SET ObserverConfigFileコマンドおよびSHOW ObserverConfigFileコマンドを使用します。これらのコマンドはDGMGRLコマンドラインから発行できますが、コマンドの使用に先立ってログオンする必要はありません。

  • SET ObserverConfigFile — カスタマイズされたオブザーバ構成ファイルを指定する場合に使用します。ObserverConfigFileはDGMGRLセッションのランタイム・プロパティです。新しいDGMGRLクライアントを起動するたびに、これを指定する必要があります。

  • SHOW ObserverConfigFile — ランタイム・プロパティObserverConfigFileを確認する場合に使用します。現在のDGMGRLクライアントを起動した後にSET ObserverConfigFileコマンドを使用していない場合、結果は常にObserverConfigFile=observer.oraとなります。

複数構成でのオブザーバを管理するためのコマンド

(オブザーバ構成ファイルに宣言されている)構成のグループに対して実行可能なコマンドを次に示します。

  • START OBSERVING [cfg_group_name] — 指定したグループの各ブローカ構成に対応する新規オブザーバを起動します。グループ名が指定されていない場合は、observer.oraに定義されている各ブローカ構成に対して新規オブザーバが起動されます。

  • STOP OBSERVING [cfg_group_name] — このDGMGRLを実行中のこのホスト上で動作している、指定したグループのすべてのブローカ構成のローカル・オブザーバを停止します

  • SHOW OBSERVERS [FOR fg_group_name ] — 指定したグループのすべての構成のオブザーバに関する情報を表示します。このコマンドによって表示される情報は、個々の構成に対してSHOW OBSERVERコマンドを実行した場合に表示される情報と同じです。グループ名が指定されていない場合、SHOW OBSERVERSだけでもコマンドは有効です。その動作は、START OBSERVINGおよびSTOP OBSERVINGがオブザーバ構成ファイルに定義されているすべての構成に対して動作するのと同様です。

  • SET MASTEROBSERVER TO — オブザーバ構成ファイルを手動で変更できます。

関連項目:

ブローカ構成へのアクセスに必要な資格証明

管理対象のすべてのブローカ構成用の資格証明は、Oracleウォレットを使用して保存する必要があります。Data Guard Brokerでは資格証明を管理または保存しません。オブザーバ構成ファイルに指定されている接続識別子を使用して、ブローカ構成用の資格証明をOracleウォレットから探します。資格証明が取得できない場合、試行されたコマンドは失敗します(ただし、資格証明が取得されなかったブローカ構成に対してのみ)。

例5-1 オブザーバ構成ファイルの例

オブザーバ構成ファイルの例を次に示します。

# is the comment sign in this file
BROKER_CONFIGS = ( 
 #Broker configuration 'SALES'; the connect ID is 'SALES_P'
 (CONFIG = (NAME=SALES)
           (CONNECT_ID=SALES_P)
           (CONFIG_HOME= ORACLE_HOME/LOG/)) 
 #Broker configuration 'HR'; the connect ID is 'HR_P'
 (CONFIG = (NAME=HR)
           (CONNECT_ID=HR_P) 
           (CONFIG_HOME= ORACLE_HOME/LOG/))
 #Broker configuration 'CUSTOMER'; The connect ID is 'CUSTOMER_P'
 (CONFIG = (NAME =CUSTOMER)
                 (CONNECT_ID=CUSTOMER_P)
                 (CONFIG_HOME= ORACLE_HOME/LOG1/))
            )
# The portion 'CONFIG_GROUP' lists definitions of 
# all broker configuration groups
CONFIG_GROUPS= ( 
 # Configuration 'GRP_A' includes 'SALES' and 'HR'
 (GROUP = (NAME=GRP_A)
                (CONFIG_LIST= 
                   (NAME=SALES)
                   (NAME=HR)))
 # Configuration 'GRP_B' includes 'SALES' and 'CUSTOMER'
 (GROUP = (NAME=GRP_B)
          (CONFIG_LIST= 
            (NAME=SALES)
            (NAME=CUSTOMER)))
)

ブローカ構成SALESは、3つのデータベース(Boston、ChicagoおよびDallas)とCONNECT_IDのSALES_Pで構成されているため、SALES_P接続識別子は、構成内のすべてのデータベースのすべてのインスタンスに接続できるように定義されている必要があります。新しいConfigurationWideServiceName構成プロパティを使用すれば、この接続識別子の設定を簡素化できます。Data Guard Brokerは、各インスタンスが作成され、そのインスタンスのブローカ管理が開始されると、このサービスをインスタンスに公開します。 

SALES_P = (DESCRIPTION =
                (ADDRESS_LIST =
                    (ADDRESS=(PROTOCOL=TCP)(HOST=boston-cluster)(PORT = 1521))
                    (ADDRESS=(PROTOCOL=TCP)(HOST=chicago-cluster)(PORT = 1521))
                    (ADDRESS=(PROTOCOL=TCP)(HOST=dallas-cluster)(PORT = 1521)))
                (CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=cfgSvc.us.example.com)))
5.5.7.10 オブザーバが実行中でファスト・スタート・フェイルオーバーが有効化されている場合の環境へのパッチ適用

オブザーバが実行中でファスト・スタート・フェイルオーバーが有効化されている環境へパッチを適用する場合は、パッチを適用する前に次のステップを実行してください。

  1. DGMGRL STOP OBSERVERコマンドを使用してオブザーバを停止します。構成に対して複数のオブザーバが起動されている場合は、環境にパッチを適用するオブザーバの名前を必ず指定してください(STOP OBSERVER observer-name)。STOP OBSERVERコマンドを正常に実行するには、プライマリとターゲット・スタンバイの接続が確立されている必要があります。

  2. DGMGRL DISABLE FAST_START FAILOVERコマンドを使用してファスト・スタート・フェイルオーバーを無効化します。このコマンドを正常に実行するには、プライマリとターゲット・スタンバイの接続が確立されている必要があることに注意してください。

    ノート:

    パッチを適用する環境で動作しているのはバックアップ・オブザーバのみでマスター・オブザーバがない場合、ファスト・スタート・フェイルオーバーを無効化する必要はありません。

すべてのデータベースにパッチが正常に適用された後、次のステップに従ってファスト・スタート・フェイルオーバーを有効化しオブザーバを起動してください。

  1. DGMGRL ENABLE FAST_START FAILOVERコマンドを使用してファスト・スタート・フェイルオーバーを有効化します。このコマンドを正常に実行するには、プライマリとターゲット・スタンバイの接続が確立されている必要があります。
  2. DGMGRL START OBSERVERコマンドを使用してオブザーバを起動します。構成に複数のオブザーバがある場合は、環境にパッチが適用されたオブザーバの名前を必ず指定してください(START OBSERVER observer-name)。

5.5.8 ブローカ構成に含まれる元のプライマリ・データベースの回復

回復により、ブローカ構成に対する高可用性がリストアされるため、新規プライマリ・データベースに障害が発生した場合に、別のファスト・スタート・フェイルオーバーが実行されます。

FastStartFailoverAutoReinstate構成プロパティをTRUEに設定すると、プライマリ・データベースがクラッシュするか、マスター・オブザーバおよびターゲット・スタンバイ・データベースとの接続が失われたことが原因でファスト・スタート・フェイルオーバーが開始された場合、マスター・オブザーバは元のプライマリ・データベースのスタンバイ・データベースとしての回復を自動的に試行します。回復されたデータベースは、新規プライマリ・データベースのファスト・スタート・フェイルオーバーのターゲットとして機能し、後続のファスト・スタート・フェイルオーバーが可能になります。新規スタンバイ・データベースは、新規プライマリ・データベースからのREDOデータの受信を開始した時点で、フェイルオーバーの実行可能なターゲットとなります。

マスター・オブザーバによる元のプライマリ・データベースの自動回復を可能にするには、データベースを起動およびマウントする必要があります。ファスト・スタート・フェイルオーバーが有効化されていると、どのような場合もオープンできません。ブローカは、データベースを新しいプライマリ・データベースのスタンバイ・データベース(元のスタンバイと同じタイプ)として回復します。

元のプライマリ・データベースが自動的に回復されない場合、DGMGRLのREINSTATEコマンドまたはCloud Controlを使用して手動で回復できます。手動回復の段階的なステップは、「ロール変更後の無効化されたデータベースの再有効化」を参照してください。

5.5.8.1 要件

回復がサポートされるのは、ブローカ構成でフェイルオーバーを実行した後に限られます。また、プライマリ・データベースおよびターゲット・スタンバイ・データベースの両方でフラッシュバック・データベースを有効化する必要があります。

すべてのファスト・スタート・フェイルオーバーおよび回復の要件の詳細は、「ファスト・スタート・フェイルオーバーを有効化するための前提条件」を参照してください。

5.5.8.2 回復に関する制限事項

このリストでは、ブローカが以前のプライマリ・データベースを自動的に回復できない条件を説明します。

  • ユーザーが構成可能な条件が検出されたためにファスト・スタート・フェイルオーバーが発生した場合、またはDBMS_DG.INITIATE_FS_FAILOVER関数をコールしてアプリケーションで要求した場合

  • FastStartFailoverAutoReinstateがFALSEに設定されている場合

  • ファスト・スタート・フェイルオーバーの完了後、元のプライマリ・データベースが再起動されるまでに別のフェイルオーバーまたはスイッチオーバーが発生した場合

  • ファスト・スタート・フェイルオーバーが無効化されている場合

  • マスター・オブザーバが元のプライマリ・データベースに接続できない場合

  • 元のプライマリ・データベースが新規プライマリ・データベースに接続できない場合

  • 元のプライマリ・データベースおよび新規プライマリ・データベースが、同じファスト・スタート・フェイルオーバー環境内で構成されていない場合

  • ファスト・スタート・フェイルオーバーが無効化されているとき、手動フェイルオーバーによって元のプライマリ・データベースが無効化された場合

    ノート:

    スイッチオーバー、手動フェイルオーバーまたはファスト・スタート・フェイルオーバーの実行時にスタンバイ・データベースを無効した場合は、自動的に回復されません。

自動回復に失敗した場合、ブローカによりエラーがログに記録され、元のプライマリ・データベースはマウントされた状態のままとなります。この時点で、次のいずれかを実行できます。

5.5.8.3 失敗した回復のブローカによる処理方法

回復操作(自動または手動)が進行中のときに障害が発生した場合、ブローカにより、ブローカ構成ファイルおよびブローカ・ログ・ファイルに、適切な情報が記録されます。

元のプライマリ・データベースは無効化されます。進行中の障害のほとんどは再起動できません(プライマリ・データベースにおけるアーカイブREDOログ・ファイルの破損など)。データベースをスタンバイ・データベースとして手動で再作成してから再有効化する必要があります。

関連項目:

「無効化されたデータベースの再作成および再有効化の方法」

5.5.9 ファスト・スタート・フェイルオーバー環境でのデータベースの停止

必要に応じて、ファスト・スタート・フェイルオーバー環境のプライマリ・データベースまたはターゲット・スタンバイ・データベースを停止できます。

次のステップを実行します。

  1. オブザーバを停止し、プライマリ・データベースおよびターゲット・スタンバイ・データベースの両方について、V$FS_FAILOVER_OBSERVERS固定ビューのすべての行のREGISTERED列に値「NO」が含まれるまで待機します。こうすると、プライマリ・データベースの停止中に、ファスト・スタート・フェイルオーバーは実行されません。
  2. DGMGRLのSHUTDOWNコマンドまたはSQL*PlusのSHUTDOWN文を使用して、プライマリ・データベースおよびターゲット・スタンバイ・データベースを停止します。

データベースを再起動する場合、任意の順序で実行できます。両方のデータベースを再起動したら、オブザーバを再起動できます。

その他のスタンバイ・データベースは、いつでも、任意の順序で、ファスト・スタート・フェイルオーバーに影響なくシャットダウンできます。

5.6 データベース・クライアントに関する考慮事項

ブローカ管理のフェイルオーバーが発生したときに、ローカル・データベース・サービスに接続しているデータベース・クライアントでは、イベント通知およびデータベース接続フェイルオーバーのサポートを使用できます。

グローバル・サービスのイベント通知とデータベース接続フェイルオーバー・サポートの詳細は、『Oracle Database概要および管理ガイド』を参照してください。

フェイルオーバー後、ブローカは高速アプリケーション通知(FAN)イベントを発行します。FANイベントは次の方法で使用できます。

  • アプリケーションでOracle Database JDBC、Oracle Database Oracle Call Interface(OCI)、Oracle Data Provider for .NET(ODP.NET)、Universal Connection Pool for JavaのいずれかのOracle統合データベース・クライアントを使用している場合、プログラムを変更せずにFANを使用できます。これらのクライアントには、フェイルオーバー後に自動的に新規プライマリ・データベースに接続する高速接続フェイルオーバー(FCF)を構成できます。

  • JAVAアプリケーションはJDBC FANアプリケーション・プログラミング・インタフェースを利用してFANをプログラムで使用することで、FANイベントにサブスクライブし、イベント受信時にイベント処理アクションを実行できます。

  • FANのサーバー側コールアウトをデータベース層で構成できます。

Oracle Database 12c以降のすべてのOracle統合データベース・クライアントでは、FANイベントは、Oracle Notification Service(ONS)を使用して発行されます。以前のリリースの場合、OCIとODP.NETクライアントは、Oracle Advanced Queuing (AQ)を介してFAN通知を受け取ります。

ノート:

ONSを使用してFANイベントを発行するには、単一インスタンスのデータベースをOracle Restartに登録する必要があります。

関連項目:

5.6.1 Oracle Data Guard固有のFANおよびFCF構成要件

ブローカ管理のフェイルオーバーによって生成されたFANイベントを発行および適切に処理するために満たす必要のある構成要件があります。

これらの要件は、前述のマニュアルおよび次のクライアント固有ガイドに記載されている要件を補足するものです。

5.6.1.1 Oracle Netの構成要件

高速接続フェイルオーバー(FCF)を実行するには、クライアントはフェイルオーバー後に新しいプライマリ・データベースを検出できる必要があります。

この項では、この要件に合せてOracle Netの接続記述子を構成する方法について説明します。

接続記述子は次のいずれかの方法で構成できます。

  1. 接続時フェイルオーバーの接続記述子を構成します。プライマリ・データベースおよび各スタンバイ・データベースをアドレス・リストに追加します。ネットワーク・アドレスが指定されていない場合に遅延を最小限に抑えるために、CONNECT_TIMEOUTパラメータを小さい値に設定します。リソース競合により通常操作中に接続タイムアウトが発生する場合は、このパラメータの値を大きくします。

    次に例を示します。

    sales =
	  (DESCRIPTION= 
	    (FAILOVER=ON)
	    (CONNECT_TIMEOUT=5)
	    (ADDRESS_LIST=
	      (ADDRESS=(HOST=boston-scan)(PORT=1521))
	      (ADDRESS=(HOST=dallas-scan)(PORT=1521)))
	    (CONNECT_DATA=(SERVICE_NAME=sales)))
  2. DNSやLDAPなどのグローバル・ネーミング・サービスを使用して登録された単一ネットワーク名で、接続記述子を構成します。DB_ROLE_CHANGEシステム・イベントに基づいてトリガーを作成します。このシステム・イベントは、フェイルオーバー後に、ネットワーク名に関連付けられているネットワーク・アドレスを新規プライマリ・データベースのネットワーク・アドレスに変更します。

    関連項目:

どちらの場合も、接続記述子にSERVICE_NAMEパラメータを含める必要があります。

5.6.1.2 データベース・サービスの構成要件

データベース・サービスは、Oracle RACデータベースの特定のデータベース・ロール、およびOracle Restartにより管理される単一インスタンス・データベースでアクティブになるように構成できます。

ブローカはOracle ClusterwareまたはOracle Restartと相互に作用して、適切なデータベース・サービスがアクティブになり、ロール変更後に適切なFANイベントが発行されるようにします。

FANイベントは常にONSを使用して発行されます。ただし、データベースが新規プライマリ・データベースでプライマリ・ロールになっている場合、フェイルオーバーを通知するイベントは、アクティブに構成されているデータベース・サービスに対してのみ発行されます。

任意のデータベース・ロールでアクティブでなければならないサービス(プライマリ、フィジカル・スタンバイ、ロジカル・スタンバイまたはスナップショット・スタンバイ)は、サービスがアクティブでなければならない各データベースで明示的にServer Controlユーティリティ(SRVCTL)によって構成する必要があります。

次のコマンドの例では、サービスPAYROLLがプライマリ・データベースNORTHのPRIMARYでアクティブになるように構成されています。また、スタンバイ・データベースSOUTHのPRIMARYロールでもアクティブになるように構成されているため、ロール・トランジションが発生した場合にはそのデータベースでアクティブになります。これらのサンプル・コマンドで、省略記号(...)は、必要に応じて指定するadd serviceの他のオプションを示します。

ノート:

この項で示した例では、必ずしもご使用の環境で使用する必要のある特定の属性を示しているわけではありません。必要な属性は構成によって異なります(ご使用の環境がOracle RACベースか単一インスタンスかどうかも含めて)。詳細は、適切なOracle RACまたはOracle Restartのマニュアルを参照してください。

プライマリ・データベースNORTH上で、次を実行します。 

srvctl add service –db NORTH –service PAYROLL –role PRIMARY ...

スタンバイ・データベースSOUTH上で、次を実行します。 

srvctl add service –db SOUTH –service PAYROLL –role PRIMARY ...

サービスを現在のプライマリ・データベースで起動するかどうかにかかわらず、データベースがフィジカル・スタンバイ・ロールになっているときにアクティブにするサービスも、そのデータベースで作成および起動する必要があります。これは、サービス定義がREDOストリームを介してフィジカル・スタンバイ・データベースに伝播されるようにするためです。これにより、サービスをフィジカル・スタンバイ・データベースで起動できるようになります。サービスをフィジカル・スタンバイで起動できるのは、サービスを起動することによって生成されたREDOが適用された後のみです。サービスがロール変更の前後で同じように動作するように、すべてのデータベース上ですべてのSRVCTL add serviceオプションが同一であることが重要です。

すべてのデータベースが同じ値を持たない場合、SRVCTLは値を上書きしようとしますが、フィジカル・スタンバイ・データベースで失敗します。これは、データベースが読取り専用でオープンであるためです。次のコマンドの例では、サービスsalesがプライマリ・データベースNORTHのPHYSICAL_STANDBYロールでアクティブになるように構成されています。その後、プライマリ・データベースで起動および停止されます。このサービスを現在のプライマリ・データベース上で実行しない場合は、オプションでプライマリ・データベースから削除することもできます。これは、フィジカル・スタンバイ・データベースSOUTHのPHYSICAL_STANDBYロールでもアクティブになるように構成されます。

次をプライマリ・データベースNORTHで実行します。 

srvctl add service -db NORTH -service SALES -role PHYSICAL_STANDBY ...

srvctl start service –db NORTH –service SALES

srvctl stop service –db NORTH –service SALES

次をフィジカル・スタンバイ・データベースSOUTHで実行します。 

srvctl add service -db SOUTH -service SALES -role PHYSICAL_STANDBY ...

ここでブローカによりスイッチオーバーまたはフェイルオーバーが実行されると、データベースのロールに基づいて、適切なデータベース上でSALESサービスが自動的に開始されます。

前述の各例では、データベースに1つのサービスのみを設定する方法を説明しました。次の例では、データベースに複数のサービスを設定する方法を示し、また、ブローカを使用することによって適切なサービスが適切なデータベース上で確実に開始される仕組みについて説明します。

プライマリ・データベースがBOSTON、スタンバイ・データベースがCHICAGOであると仮定します。次のSRVCTLコマンドを発行して、Data Guard構成内の両方のデータベースが、各データベースで実行する可能性のある2つのサービスについて認識するようにします。

BOSTONの場合

srvctl add service -db BOSTON -service SALESRW  -role PRIMARY -y AUTOMATIC
srvctl add service -db BOSTON  -service SALESRO  -role PHYSICAL_STANDBY -policy AUTOMATIC

CHICAGOの場合: 

srvctl add service -db CHICAGO  -s SALESRW  -role PRIMARY -y AUTOMATIC
srvctl add service -db CHICAGO  -s SALESRO  -role PHYSICAL_STANDBY -policy AUTOMATIC

まず、正しいノード上でサービスを手動で開始する必要があります。また、SALESROサービスをプライマリ上で開始して停止し、このサービスをスタンバイ上で開始できるようにすることも必要です。次のSRVCTLコマンドを発行します。

BOSTONの場合: 

srvctl start service -db BOSTON -service SALESRW
srvctl start service -db BOSTON -service SALESRO
srvctl stop service -db BOSTON -service SALESRO

CHICAGOの場合: 

srvctl start service -db CHICAGO -service SALESRO

これで、適切なサービスが適切なデータベース上で実行されています。

ブローカによってスイッチオーバーまたはフェイルオーバーが実行されると、データベースの現在のロールに基づいて、サービスSALESRWまたはSALESROが開始されます。したがって、SALESRWはCHICAGO (現在のプライマリ)上で開始され、SALESROはBOSTON (現在のフィジカル・スタンバイ)上で開始されます。いずれかのデータベースが停止して起動した場合も、同じことが発生します。つまり、起動するデータベースのロールに適したサービスが開始されます。

これらのデータベースのそれぞれで次の手動コマンドを発行すると、SRVCTLの-role修飾子で以前に指定された内容に関係なく、SALESROおよびSALESRWの両方のサービスがこれらのデータベース上で開始されることに注意してください。これは、-role修飾子がData Guard Brokerによってのみ、データベースの起動時に考慮されるからです。

BOSTONの場合: 

srvctl start service -db CHICAGO

CHICAGOの場合: 

srvctl start service -db BOSTON

SRVCTLユーティリティではデータベース・ロールが自動的に考慮されないため、サービスを手動で開始するときは常に、開始するサービスの名前を指定する必要があります。

ノート:

サービスが自動的に起動するように構成されている場合(-policy AUTOMATIC)、データベース・ロールが変更された後にのみ、自動的に起動します。

ノート:

Oracle Data Guard構成では、スタンバイ・データベースのSRVCTL -startoptionは、スイッチオーバー後には、常にOPENに設定されます。

関連項目:

5.6.1.3 ONSの構成要件

クライアント側のONS構成を使用する場合、クライアント側のONS構成ファイルで、プライマリ・データベースおよび各スタンバイ・データベースのONSデーモンのホスト名およびポートを指定する必要があります。

クライアントでリモートONSサブスクリプションを使用する場合、クライアントでプライマリ・データベースおよび各スタンバイ・データベースのONSデーモンのホスト名およびポートを指定する必要があります。

5.6.1.4 アプリケーション・コンティニュイティ

アプリケーション・コンティニュイティは、データベース・セッションを使用不可にするリカバリ可能なエラーの後に、データベースに対するリクエストを中断せず、迅速な方法でリプレイできるようにするOracle Databaseの機能です。

Oracle Data Guardのフィジカル・スタンバイ・データベースへのスイッチオーバーに対し、アプリケーション・コンティニュイティがサポートされます。また、最大可用性データ保護モードのフィジカル・スタンバイに対するファスト・スタート・フェイルオーバーもサポートされます。プライマリ・データベースおよびスタンバイ・データベースでは、アプリケーション・コンティニュイティを使用するには、Oracle RACまたはOracle Active Data Guardのライセンスが必要です。

関連項目: