| Oracle Data Guard Broker 11gリリース1（11.1） E05756-02 |
|
 戻る |
 次へ |
この章では、ブローカによるスイッチオーバーおよびフェイルオーバー中のデータベース管理について説明します。この付録の内容は、次のとおりです。
Oracleデータベースは、プライマリまたはスタンバイという2つのロールのいずれかで動作します。Data Guardにより、スイッチオーバーまたはフェイルオーバーのいずれかを使用してデータベースのロールを変更できます。
スイッチオーバーは、プライマリ・データベースとそのいずれかのスタンバイ・データベース間のロール・リバーサルです。スイッチオーバーでは、データの消失がないことが保証され、通常は予定されたプライマリ・システムのメンテナンスの際に実行されます。スイッチオーバー中は、プライマリ・データベースがスタンバイ・ロールに推移し、スタンバイ・データベースがプライマリ・ロールに推移します。
フェイルオーバーは、プライマリ・データベース（Oracle RACプライマリ・データベースのすべてのインスタンス）に障害が発生するかアクセス不能になり、いずれかのスタンバイ・データベースが推移してプライマリ・ロールを引き継ぐときに実行されます。フェイルオーバーは、プライマリ・データベースを適時にリカバリできない場合に実行されます。フェイルオーバーでは、フェイルオーバー時に有効な保護モードによって、データが消失する場合としない場合があります。
ブローカを使用しない場合、ロール推移を実行するには、まずロール推移が必要かどうかを判断してから、一連のSQL文を発行します（『Oracle Data Guard概要および管理』を参照）。ブローカでは、Oracle Enterprise Managerでキーを1回クリックするか、DGMGRLコマンドライン・インタフェースで単一のコマンドを使用することでスイッチオーバーおよびフェイルオーバーを起動できるため、これらの操作が簡素化されます（このマニュアルでは手動フェイルオーバーと呼ばれます）。また、ファスト・スタート・フェイルオーバーを有効化すると、ファスト・スタート・フェイルオーバーの条件が満たされたときに自動的にフェイルオーバーが実行されます。ファスト・スタート・フェイルオーバーが有効化されている場合、ブローカによってフェイルオーバーの必要性が判断され、指定されたターゲット・スタンバイ・データベースへのフェイルオーバーが自動的に開始されます。DBAによる操作は不要です。
ファスト・スタート・フェイルオーバーにより、手動操作の必要性を少なくして可用性を高め、管理コストを削減できます。手動フェイルオーバーでは、フェイルオーバーを実行する正確なタイミングおよび対象となるターゲット・スタンバイ・データベースを管理できます。選択する方法に関係なく、ブローカによって構成内のすべてのデータベースのロール推移が調整されます。
ロール推移後に初めてデータベースがオープンされると、DB_ROLE_CHANGEシステム・イベントが起動します。このシステム・イベントに関連付けられたトリガーを記述し、ロール変更の発生後にタスクを管理させることができます。詳細は、『Oracle Database PL/SQL言語リファレンス』のシステム・イベントの表を参照してください。フェイルオーバーの後、ブローカはDB_ROLE_CHANGEシステム・イベントを起動するとともに、高速アプリケーション通知（FAN）OCI DATABASE_DOWNイベントをポストします。両方のイベントを使用すると、たとえば、ユーザー・アプリケーションで新しいプライマリ・データベース上のサービスを見つけるのに役立ちます。
スイッチオーバーまたはフェイルオーバー後に次のプライマリ・データベースにするスタンバイ・データベースを選択する際には、多数の考慮事項があります。Data Guard構成を構築する際には、フィジカル・スタンバイ、ロジカル・スタンバイおよびスナップショット・スタンバイの各特性、スタンバイ・データベース・サイトに対するネットワーク待機時間、将来のプライマリ・データベース・サイトにおけるコンピューティング機能などの要素を含む、すべてのオプションを考慮する必要があります。
|
注意: スナップショット・スタンバイを、スイッチオーバーまたはファスト・スタート・フェイルオーバー操作のターゲットにすることはできません。ただし、スナップショット・スタンバイへの手動フェイルオーバーは実行できます。 |
スイッチオーバーについては、すべての要素を理解することで、新規プライマリ・データベースとみなすスタンバイ・データベースを簡単に選択できます。フェイルオーバーが必要な障害が発生した場合、障害のあるプライマリ・データベースのアクティビティを再開するのに最適なスタンバイ・データベースは、スイッチオーバーの場合よりも絞られる可能性があります。次の各項では、ターゲット・スタンバイ・データベースの選択に役立つガイドラインを示します。
|
注意: ファスト・スタート・フェイルオーバーの場合、使用するターゲット・スタンバイ・データベースを事前に選択する必要があります。ファスト・スタート・フェイルオーバーの詳細は、5.5項を参照してください。 |
スタンバイ・データベースがすべて同じタイプである（すべてフィジカルまたはすべてロジカルのスタンバイ・データベース）構成内でスイッチオーバーを実行する場合、未適用のREDOの数が最も少ないスタンバイ・データベースを選択します。未適用のREDOの数が最も少ないスタンバイ・データベースを選択することで、スイッチオーバー操作が完了するまでの全体の所要時間を最小限にできます。次に例を示します。
DGMGRLを使用する場合、構成内の各スタンバイ・データベースの監視可能なデータベース・プロパティRecvQEntriesを調査します。たとえば、構成内のいずれかのデータベースに接続し、SHOW DATABASE database_name RecvQEntriesコマンドを発行します。（スタンバイが動作しつづけている場合、このプロパティでは行は戻されません。）
Enterprise Managerを使用する場合は、Data Guardの概要ページの「スタンバイ・データベース」セクションで、各スタンバイ・データベースのApplyLag列の値を表示できます。
構成にフィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データベースの両方が含まれる場合、ターゲット・スタンバイ・データベースとして（未適用REDOの数が最も少ない）フィジカル・スタンバイ・データベースを選択することを考慮します。スイッチオーバー操作の完了後は、構成内のすべてのデータベースが新規プライマリ・データベースに対するスタンバイ・データベースとして使用可能になるため、フィジカル・スタンバイ・データベースへのスイッチオーバーをお薦めします。一方、ロジカル・スタンバイ・データベースにスイッチオーバーすると、構成内のフィジカルおよびスナップショット・スタンバイ・データベースがすべて無効化されます。そのため、フィジカル・スタンバイ・データベースを再び有効化するには、新規プライマリ・データベースのバックアップからフィジカル・スタンバイ・データベースを再び有効化する必要があります。
スナップショット・スタンバイ・データベースへのスイッチオーバーを実行するには、最初にフィジカル・スタンバイ・データベースに戻す必要があります。
|
注意: Data Guard構成が最大保護モードで動作している場合、ブローカではロジカル・スタンバイ・データベースへのスイッチオーバーが許可されません。ロジカル・スタンバイ・データベースへのスイッチオーバーを実行するには、構成が最大可用性モードまたは最大パフォーマンス・モードのいずれかで動作している必要があります。 |
フェイルオーバーを実行するとき、構成内のスタンバイがすべて同じタイプである場合は、最も多くのREDOデータがアーカイブされているスタンバイ・データベースを選択します。アーカイブされたREDOデータの量が最も多いスタンバイ・データベースを選択することで、データの消失量を最小限に抑え、場合によってはデータの消失をゼロにすることができます。
構成にフィジカル・スタンバイ・データベース、スナップショット・スタンバイ・データベースおよびロジカル・スタンバイ・データベースが含まれる場合、ターゲット・スタンバイ・データベースとしてフィジカル・スタンバイ・データベースを選択することを考慮します。フェイルオーバー操作の完了後は、構成内のすべてのスタンバイ・データベースが新規プライマリ・データベースに対するスタンバイ・データベースとして使用可能になる可能性が高いため、フィジカル・スタンバイ・データベースへのフェイルオーバーをお薦めします。
スナップショット・スタンバイ・データベースにフェイルオーバーすることもできます。ただし、スナップショット・スタンバイ・データベースにフェイルオーバーするには、ブローカがこのデータベースを最初にフィジカル・スタンバイ・データベースに戻す必要があるため、時間がかかります。変換した後、ブローカは、プライマリ・ロールへのデータベースのフェイルオーバーを実行する前に、REDO Applyを起動して累積REDOデータを適用します。スナップショット・スタンバイ・データベースをフィジカル・スタンバイ・データベースに変換してからフェイルオーバーが実行されるため、フェイルオーバー操作の完了後、構成内のすべてのスタンバイ・データベースを新しいプライマリ・データベースへのスタンバイ・データベースとして使用することが可能になります。
ロジカル・スタンバイ・データベースにフェイルオーバーするには、フェイルオーバーの完了後に、新しいプライマリ・データベースのコピーから他のすべてのスタンバイ・データベースを再び有効化する必要があります。さらに、ロジカル・スタンバイ・データベースには、プライマリ・データベースに存在するデータのサブセットのみが含まれる可能性があります。（たとえば、プライマリ・データベース上で実行されるデータベース操作のうちロジカル・スタンバイ・データベースに適用しない操作を指定する際に、DBMS_LOGSTDBY.SKIPプロシージャが使用された場合など。）
ただし、例外として、ターゲット・スタンバイ・データベースとしてフィジカル・スタンバイ・データベースを選択することをお薦めできない場合があります。たとえば、フィジカル・スタンバイ・データベースがロジカル・スタンバイ・データベースから大幅に遅れており（フィジカル・スタンバイ・データベースが構成可能なデータベース・プロパティDelayMinsによりログ適用遅延モードで動作している）、停止時間を最小限に抑えるという要件がある場合は、フェイルオーバー・ターゲットとしてロジカル・スタンバイ・データベースの選択を検討してください。
データベースは、プライマリ・ロールからスタンバイ・ロール、またはスタンバイ・ロールからプライマリ・ロールに切り替えることができます。この操作は、データを消失させることなく、指定したスタンバイ・データベースがプライマリ・データベースになり、元のプライマリ・データベースがスタンバイ・データベースになるため、データベースのスイッチオーバーと呼ばれます。
可能な場合は必ず、フィジカル・スタンバイ・データベースに対してスイッチオーバーしてください。
スイッチオーバーによりフィジカル・スタンバイ・データベースをプライマリ・ロールに推移する場合、次のようになります。
元のプライマリ・データベースはフィジカル・スタンバイ・ロールに切り替えられます。
オンラインREDOログ・ファイルは、新しいプライマリ・データベースから構成内のすべてのスタンバイ・データベースに継続的にアーカイブされます。
スイッチオーバー操作の一部として、元のプライマリ・データベースが再起動されます。
スイッチオーバーに関係しないスタンバイ・データベースは、スイッチオーバーが発生する前の状態で引き続き動作し、新しいプライマリ・データベースから受け取ったREDOデータの適用を自動的に開始します。
スイッチオーバーによりロジカル・スタンバイ・データベースをプライマリ・ロールに推移する場合、次のようになります。
元のプライマリ・データベースはロジカル・スタンバイ・ロールに切り替えられます。
スイッチオーバーの完了後、プライマリ・データベースおよびロジカル・スタンバイ・データベースのどちらも再起動の必要はありません。
スイッチオーバーに関係していないブローカ構成内の他のロジカル・スタンバイ・データベースは、スイッチオーバー後も実行可能です。どのデータベースも再起動する必要はありません。ロジカル・スタンバイ・データベースへのスイッチオーバーの後、すべてのフィジカルおよびスナップショット・スタンバイ・データベースは無効化されます。
構成が最大保護モードで動作している場合、ロジカル・スタンバイ・データベースへのスイッチオーバーは許可されません。
|
警告: ロジカル・スタンバイ・データベースにスイッチオーバーすると、ブローカ構成内のスナップショット・スタンバイ・データベースとフィジカル・スタンバイ・データベースはブローカにより無効化され、これらのデータベースはスタンバイ・データベースとして実行できなくなります。スタンバイ・データベースとして実行可能な状態にリストアする方法は、5.4.3項を参照してください。 |
スイッチオーバーを開始する前に、次の点を考慮してください。
スイッチオーバーを開始すると、ブローカは、スイッチオーバーの完了後に少なくとも1つのスタンバイ・データベース（スタンバイ・ロールに推移する予定のプライマリ・データベースも含む）が、全体の保護モード（最大保護、最大可用性または最大パフォーマンス）をサポートするように構成されているかどうかを検証します。
全体の保護モードのコンテキスト内で、将来考えられるスタンバイ・データベースとしてのロールに備えて、あらかじめプライマリ・データベースを準備しておきます（4.6項を参照してください）。こうした準備には、次の操作が含まれます。
プライマリ・データベースでスタンバイREDOログ・ファイルが構成されていることを確認します。
LogXptMode、NetTimeout、StandbyArchiveLocationおよびAlternateLocationなど、REDO転送サービス関連の構成可能なデータベース・プロパティをあらかじめ設定します。構成可能なデータベース・プロパティを使用したREDO転送サービスの管理の詳細は、4.4項を参照してください。
DelayMinsなど、ログ適用サービス関連の構成可能なデータベース・プロパティをあらかじめ設定します。構成可能なプロパティを使用したログ適用サービスの管理の詳細は、4.5項を参照してください。
一時表ごとに、プライマリ・データベース上の一時表に関連付けられた一時ファイルがスタンバイ・データベースにも存在することを確認します。
これらのプロパティは、実際にプライマリ・データベースをスタンバイ・ロールに切り替えるまで、ブローカによってREDO転送サービスとログ適用サービスの設定に使用されないことに注意してください。そのため、これらのプロパティの値の妥当性は、スイッチオーバー後まで検証されません。これらのプロパティを設定すると、その値はスイッチオーバーおよびフェイルオーバー時のロール変更を通じて存続します。
最大可用性モードまたは最大パフォーマンス・モードのいずれかでファスト・スタート・フェイルオーバーが有効化されている場合、スイッチオーバーを実行できるのは、事前に指定されたターゲット・スタンバイ・データベースに対してのみであり、スタンバイ・データベースがプライマリ・データベースと同期化されている場合に限られます。ファスト・スタート・フェイルオーバーの有効化の詳細は、5.5.2項を参照してください。
スイッチオーバーの完了後、ブローカにより、保護モードがスイッチオーバー前と同じ保護レベル（最大保護、最大可用性または最大パフォーマンス）に維持され、スイッチオーバー・プロセスの一部として全体のData Guard保護モードが保持されます。また、スイッチオーバーに関係しない他のスタンバイ・データベースにREDOを転送するためのネットワーク転送モード（SYNCまたはASYNC）は、スイッチオーバー後も変更されません。スイッチオーバーに関係しない他のすべてのスタンバイ・データベースに対するログ適用サービスは、新しいプライマリ・データベースから受け取ったREDOデータの適用を自動的に開始します。
構成内にフィジカルまたはスナップショット・スタンバイ・データベースが存在するとき、ロジカル・スタンバイ・データベースへのスイッチオーバーが発生した場合は、5.4.3項に示すように、新しいプライマリ・データベースのコピーからこれらのデータベースを再作成し、データベースを再び有効化する必要があります。
ロールの切替えは、慎重に計画して実行する必要があります。スイッチオーバーに関係するプライマリ・データベースとスタンバイ・データベースのREDOラグは、できるかぎり低くする必要があります。スイッチオーバーに備えたデータベースの設定方法の詳細は、『Oracle Data Guard概要および管理』を参照してください）。
Enterprise Managerを使用してスイッチオーバーを開始するには、プライマリ・ロールに変更するスタンバイ・データベースを選択して「スイッチオーバー」をクリックします。DGMGRLを使用する場合は、SWITCHOVERコマンドを1つのみ発行し、プライマリ・ロールに変更するスタンバイ・データベースの名前を指定します。
5.3.3項で説明するように、スイッチオーバーに関するその他の作業はブローカによって制御されます。
スイッチオーバーを開始すると、ブローカは次の作業を実行します。
プライマリ・データベースとターゲットのスタンバイ・データベースが次の状態であることを検証します。
プライマリ・データベースが有効化されてTRANSPORT-ON状態であること。
ターゲット・スタンバイ・データベースが有効化されてAPPLY-ON状態であること。
ブローカは、スイッチオーバー操作に関連して選択したプライマリ・データベースとスタンバイ・データベースにエラーがないかぎり、スイッチオーバーを続行します。スイッチオーバーに関係しない他のスタンバイ・データベースにエラーが発生しても、スイッチオーバーは影響を受けません。
インスタンスのうち1つを残して、他のすべてのインスタンスが停止します。
フィジカル・スタンバイ・データベースへのスイッチオーバーを実行するとき、スタンバイ・データベースまたはプライマリ・データベースがRACデータベースである場合、ブローカは、スイッチオーバーを続行する前に、データベースで実行中のインスタンスが1つのみとなるように、他のすべてのインスタンスを停止します。Oracle RACのフィジカル・スタンバイの場合は、実行中のインスタンスが適用インスタンスのみになります。データベース上の他のインスタンスを停止できない場合はスイッチオーバーが失敗し、他のインスタンスを手動で停止してスイッチオーバー・コマンドを再発行する必要があります。また、スイッチオーバーの実行中には新しいインスタンスを起動しないことが重要です。フィジカル・スタンバイ・データベースのインスタンスを手動で停止する必要がある場合は、適用インスタンスを停止しないでください。
ロジカル・スタンバイ・データベースへのスイッチオーバーの場合は、インスタンスを停止しません。スナップショット・スタンバイ・データベースにスイッチオーバーすることはできません。
プライマリ・データベースとスタンバイ・データベースの間でロールを切り替えます。
ブローカは最初に、元のプライマリ・データベースを変換してスタンバイ・ロールで実行するようにします。次に、ターゲットのスタンバイ・データベースをプライマリ・ロールに推移させます。いずれかの変換時にエラーが発生すると、ブローカはスイッチオーバーを停止します。詳細は、10.3項「スイッチオーバー操作時の問題のトラブルシューティング」を参照してください。
ブローカ構成ファイルを更新し、ロールの変更を記録します。
構成ファイルには構成内のデータベース・オブジェクトがすべて記述されるため、なんらかの原因で後から再起動された場合にも、各データベースが確実に適切なロールおよび状態で動作します。
フィジカル・スタンバイ・データベースに対してスイッチオーバーを行った場合は新しいスタンバイ・データベース（元のプライマリ・データベース）を再起動すると、Redo Applyが新しいプライマリ・データベースからREDOデータの適用を開始します。Oracle RACのフィジカル・スタンバイ・データベースの場合は、CRSにより、スイッチオーバーの前に停止されたインスタンスが再起動されます。最大保護モードで動作している構成では、新しいプライマリ・データベースも再起動されます。
新しいプライマリ・データベースが読取り/書込みモードでオープンし、REDO転送サービスが開始します。Oracle RACのフィジカル・スタンバイ・データベースの場合は、ブローカにより、スイッチオーバーの前に停止したインスタンスが再起動されます。
ブローカは各データベースの状態とステータスを検証し、スイッチオーバーによって、各データベースが新しいロールにそれぞれ正常に推移していることを確認します。スイッチオーバーに関係せず、スイッチオーバー後にブローカにより無効化されていないスタンバイ・データベースは、スイッチオーバー前の状態で引き続き動作します。スイッチオーバーに関係しない他のすべてのスタンバイ・データベースに対するRedo ApplyおよびSQL Applyは、新しいプライマリ・データベースからのREDOデータの適用を自動的に開始します。
元のプライマリ・データベースで障害が発生し、プライマリ・データベースを適時にリカバリできる可能性がない場合は、スタンバイ・データベースをプライマリ・データベースに変換できます。これは手動フェイルオーバーと呼ばれます。プライマリ・データベースに障害が発生した時点でプライマリ・データベースとターゲット・スタンバイ・データベースが同期化されていたかどうかによって、データが消失する場合があります。手動という用語は、このタイプのフェイルオーバーとファスト・スタート・フェイルオーバー（5.5項を参照）を比較する目的で使用します。
次の各項では、手動フェイルオーバーの実行方法について説明します。
Enterprise ManagerまたはDGMGRLを使用して、完全フェイルオーバー（推奨）または即時フェイルオーバーを実行できます。
完全フェイルオーバーは、推奨方法でありデフォルトのフェイルオーバー・オプションです。完全フェイルオーバーでは、構成が動作している保護モードに応じて最大量のREDOデータが自動的にリカバリされます。また、フェイルオーバーのターゲットではないスタンバイ・データベースの無効化をできるかぎり回避して、新しいプライマリ・データベースに対するスタンバイ・データベースとして機能し続けられるようにします。
フェイルオーバーのターゲットではないスタンバイ・データベース（その他のスタンバイ・データベース）を無効にするか否かは、フェイルオーバーのターゲットと比較して、ターゲットでないスタンバイに適用されたREDOデータの量、およびフェイルオーバー・ターゲットのスタンバイ・タイプに応じて異なります。
フェイルオーバーのターゲットがフィジカルまたはスナップショット・スタンバイ・データベースの場合、新しいプライマリ・データベースのスタンバイ・データベースにするには、元のプライマリ・データベースを再有効化する必要があります。また、一部のスタンバイ・データベースで新規プライマリ・データベースによる適用を超えてREDOを適用したことが検出された場合、ブローカはそれらのデータベースをフェイルオーバー中に無効化する場合があります。ブローカにより無効化されたデータベースは、5.4.3項で説明する手順に従って再び有効化する必要があります。
スナップショット・スタンバイ・データベースでフェイルオーバーを実行した場合は、元のプライマリをフィジカル・スタンバイ・データベースとして再有効化する必要があることに注意してください。
フェイルオーバーのターゲットがロジカル・スタンバイ・データベースである場合、元のプライマリ・データベースと構成内のすべてのスタンバイ・データベース（フェイルオーバーのターゲット以外）が無効化されるため、これらを再び有効化し、新しいプライマリ・データベースのスタンバイ・データベースとして機能させる必要があります。ブローカにより無効化されたデータベースは、5.4.3項で説明する手順に従って再び有効化する必要があります。
フェイルオーバーの一環として無効化されたデータベースでフラッシュバックが有効化されているものがある場合、DGMGRLのREINSTATEコマンドまたはEnterprise Managerの「回復」ボタンを使用してそれらを回復することができます。
完全フェイルオーバー中は、5.4.2.1項に示すフェイルオーバー手順がブローカによって実行されます。
即時フェイルオーバーは、最も高速なタイプのフェイルオーバーです。ただし、フェイルオーバーの起動後は、スタンバイ・データベースに追加データが適用されません。即時フェイルオーバーを実行した場合は、元のプライマリ・データベースと、フェイルオーバーに関係しない他のすべてのスタンバイ・データベースを再び有効化する必要があります。再び有効化しない場合、新規プライマリ・データベースのスタンバイ・データベースとして機能できません。この方法については、5.4.3項を参照してください。即時フェイルオーバー中は、5.4.2.2項に示すフェイルオーバー手順がブローカによって実行されます。
|
注意: 必ず最初に完全フェイルオーバーの実行を試みてください。即時フェイルオーバーを実行するのは、完全フェイルオーバーに失敗した場合のみです。REDO転送サービスの宛先属性によっては、即時フェイルオーバーでは通常データが消失する場合でも、完全フェイルオーバーはデータの消失なしで実行できます。 |
プライマリ・データベースを適時リカバリできる可能性がないと判断した場合は、プライマリ・データベースが停止していることを確認し、フェイルオーバー操作を開始します。
この項の各手順では、手動フェイルオーバーの実行方法について説明します。フェイルオーバーおよび関係するスタンバイ・データベースのタイプによって、一部のデータベースの再起動または再有効化が必要となる場合があります。状況のタイプごとに対応する手順を順を追って説明します。
手順1 使用可能なスタンバイ・データベースのうち、フェイルオーバーのターゲットとして最適なデータベースを判断します。
5.2項「ターゲット・スタンバイ・データベースの選択」に示したガイドラインに従います。
手順2 フェイルオーバーを開始します。
Enterprise ManagerまたはDGMGRLを使用して、完全フェイルオーバー（推奨）または即時フェイルオーバーを実行します。
Enterprise Managerを使用した手動フェイルオーバー
Enterprise ManagerのData Guardの概要ページで、プライマリ・ロールに変更するスタンバイ・データベースを選択して「フェイルオーバー」をクリックします。その後、フェイルオーバーの確認ページで「はい」をクリックし、デフォルトの「完全」フェイルオーバー・オプションを起動します。
DGMGRLを使用した手動フェイルオーバー
ターゲット・スタンバイ・データベースで、FAILOVERコマンドを発行して完全フェイルオーバーを起動し、プライマリ・ロールに変更するスタンバイ・データベースの名前を指定します。
DGMGRL> FAILOVER TO database-name [IMMEDIATE];
ターゲットのスタンバイ・データベースがOracle RACのフィジカルまたはスナップショット・スタンバイ・データベースである場合は、ブローカがフェイルオーバーを続行する前に、CRSにより、適用インスタンス以外のすべてのインスタンスが停止されます。他のインスタンスを停止できない場合、フェイルオーバーは失敗します。その場合は、適用インスタンス以外のすべてのインスタンスを手動で停止し、FAILOVERコマンドを再発行する必要があります。また、フェイルオーバーの実行中には、新しいインスタンスを起動しないことが重要です。フェイルオーバーの前に停止されたインスタンスは、ブローカの指示により、CRSによって再起動されます。
ロジカル・スタンバイ・データベースにフェイルオーバーする場合は、インスタンスを停止しません。
手順3 保護モードをリセットします。
手動フェイルオーバー（完全または即時）の後、全体のData Guard保護モードは次のように処理されます。
保護モードが最大保護だった場合は、最大パフォーマンスにリセットされます。その後、必要な場合は、4.6.1項の説明に従って保護モードをアップグレードできます。
保護モードが最大可用性だった場合は、最大可用性モードが維持されます。
|
注意: ファスト・スタート・フェイルオーバーが有効化されている場合に手動フェイルオーバーを実行すると、次のようになります。
|
手順4 障害時リカバリ構成を再確立します。
他の障害が発生した場合に実行可能な障害時リカバリ・ソリューションを維持するには、5.4.3項で説明する追加手順を実行し、次の操作を行う必要があります。
元のプライマリ・データベースを回復し、新規構成のスタンバイ・データベースとして機能させます。
ブローカによって無効化された構成内のスタンバイ・データベースを回復または再作成します。
完全フェイルオーバーが完了すると、フェイルオーバーに関係せず、新しいプライマリ・データベースのスタンバイとして実行可能でないスタンバイ・データベースは、ブローカにより無効化されます。これは次のいずれかの理由で実行されます。
ブローカにより、スタンバイ・データベースで新規プライマリ・データベースに適用された以上のREDOデータが適用されたことが検出されると、ブローカにより無効化されます。
たとえば、フェイルオーバーに関係しないスタンバイ・データベースは、新しいプライマリ・データベース自体よりも多くのREDOデータが適用されると、ブローカにより無効化されます。新しいプライマリ・データベースのスタンバイとして機能させるには、スタンバイ・データベースを再び有効化または回復する必要があります。
ロジカル・スタンバイ・データベースにフェイルオーバーした場合、フェイルオーバーに関係していない構成内のすべての（フィジカル、スナップショットおよびロジカル）スタンバイ・データベースがブローカにより無効化されます。新しいプライマリ・データベースのスタンバイとして機能させるには、再び有効化する必要があります。
完全フェイルオーバーを開始すると、ブローカは次の作業を実行します。
ターゲット・スタンバイ・データベースが有効化されていることを確認します。データベースが有効化されていない場合、このデータベースに対するフェイルオーバーは実行できません。ターゲットがOracle RACのフィジカルまたはスナップショット・スタンバイ・データベースである場合は、ブローカの指示により、CRSが適用インスタンス以外のすべてのインスタンスを停止します。
ターゲットのスタンバイ・データベースで未適用のREDOデータの適用が完了するまで待機し、適用が完了した後でRedo Apply（ターゲットがフィジカル・スタンバイ・データベースの場合）またはSQL Apply（ターゲットがロジカル・スタンバイ・データベースの場合）を停止します。
ターゲットがスナップショット・スタンバイ・データベースの場合、ブローカは、データベースをフィジカル・スタンバイに戻し、次にREDO Applyを起動してすべての累積REDOを適用してから、フェイルオーバーを完了してデータベースをプライマリ・データベースとしてオープンします。
ターゲット・スタンバイ・データベースを、次のように、プライマリ・データベース・ロールに推移させます。
新しいプライマリ・データベースを読取り/書込みモードでオープンします。
フェイルオーバー操作に関係しなかったスタンバイ・データベースが新しいプライマリ・データベースを超えてREDOデータが適用されたために再び有効化する必要があるかどうかを判断します。
このフェイルオーバー中に、フェイルオーバーに関係しないスタンバイ・データベースがブローカにより無効化されない場合は、フェイルオーバー前と同じ状態のままになります。たとえば、APPLY-OFF状態であったフィジカル・スタンバイ・データベースは、APPLY-OFF状態のままになります。
デフォルトでは、ブローカは、完全フェイルオーバーを実行するたびにその他のスタンバイ・データベースが新しいプライマリに対する実行可能なスタンバイ・データベースであるかどうかを判別します。完全フェイルオーバーの実行時に、その他のスタンバイ・データベースの実行可能性のチェックをスキップして、全フェイルオーバー時間を短縮するには、BystandersFollowRoleChange構成プロパティをNONEに設定してください。
このプロパティをNONEに設定すると、ブローカは、新しいプライマリ・データベースよりも多くのREDOデータが適用されているかどうかのチェックを実行せずに、その他のすべてのスタンバイ・データベースを無効にします。スタンバイ・データベースは、フェイルオーバーの完了後に手動で有効化する必要があります。このプロパティの値を表示するには、SHOW CONFIGURATION BystandersFollowRoleChangeコマンドを使用します。デフォルト値はALLです。
このプロパティは、ファスト・スタート・フェイルオーバーの発生時にその他のスタンバイ・データベースの実行可能性チェックをスキップするかどうかにも影響を与えます。
REDO転送サービスを起動して、フェイルオーバーに関係せず無効化されていない全スタンバイ・データベースへのREDOデータの転送を開始します。
Oracle RACのフィジカルまたはスナップショット・スタンバイ・データベースがターゲットである場合、フェイルオーバーの前に停止されたインスタンスをすべて再起動するようにCRSに指示が送られます。
ブローカは、フェイルオーバーに関連して選択したスタンバイ・データベースにエラーがないかぎり、フェイルオーバーを続行します。フェイルオーバーに関係しない他のスタンバイ・データベースにエラーが発生しても、フェイルオーバーは停止されません。完全フェイルオーバーを開始して失敗した場合は、即時フェイルオーバーを使用する必要があります。
即時フェイルオーバーを開始すると、ブローカは次の作業を実行します。
ターゲット・スタンバイ・データベースが有効化されていることを確認します。スタンバイ・データベースがブローカによる管理に対応していない場合、フェイルオーバーは実行できません。
使用可能なREDOデータがすべて適用されるまで待機せずに、スタンバイ・データベースのRedo ApplyまたはSQL Applyを即時停止します。この作業によってデータが失われる可能性があります。
ターゲットのスタンバイ・データベースをプライマリ・ロールに推移させ、新しいプライマリ・データベースを読取り/書込みモードでオープンし、REDO転送サービスを起動します。
即時フェイルオーバーが完了すると、構成内のすべてのスタンバイ・データベースはタイプに関係なく無効化されます。新しいプライマリ・データベースのスタンバイ・データベースとして機能させるには、再び有効化する必要があります。詳細は、5.4.3項を参照してください。
ブローカは、フェイルオーバーに関連して選択したスタンバイ・データベースにエラーがないかぎり、フェイルオーバーを続行します。
ロジカル・スタンバイ・データベースへのスイッチオーバー後またはいずれかのスタンバイ・データベースへのフェイルオーバー後に元の障害時リカバリ・ソリューションをリストアするには、追加手順を実行する必要があります。
ロール推移後に無効化されたデータベースは、ブローカ構成から削除されませんが、ブローカによって管理されなくなるという意味で無効化されます。
これらのデータベースのブローカによる管理を再び有効化するには、次のいずれかの手順でデータベースを回復または再作成する必要があります。
データベースが回復可能な場合は、完全フェイルオーバー後にデータベースで次のステータスが示されます。
ORA-16661: the standby database needs to be reinstated
5.4.3.1項「データベースの回復方法」の説明に従って、DGMGRLのREINSTATE DATABASEコマンドまたはEnterprise Managerの回復オプションを使用してデータベースを回復します。
新規プライマリ・データベースのコピーからデータベースを再作成する必要がある場合、データベースのステータスが次のようになります。
ORA-16795: the standby database needs to be re-created
プライマリ・データベースのコピーからスタンバイ・データベースを再作成し、再び有効化します。スタンバイ・データベースの作成手順は、『Oracle Data Guard概要および管理』を参照してください。詳細は、5.4.3.2項「無効化されたデータベースの再作成および再有効化の方法」を参照してください。
|
注意: 複数のロール変更が実行されたときに無効化されたデータベースは、回復できません。データベースを手動で再作成し、ブローカ構成でデータベースを再び有効化する必要があります。 |
データベースを回復するか再作成するかは、スイッチオーバーとフェイルオーバーのどちらを実行したか、さらに操作のターゲットとなったスタンバイ・データベースのタイプに応じて決まります。
次の表に、実行されたロール推移のタイプに基づく無効化されたデータベースの再有効化方法を示します。使用する手順を選択する際には、スイッチオーバーまたはフェイルオーバー後に無効化されたデータベースに関連付けられたステータス値も参考になります。これらのステータス値は、DGMGRLのSHOW DATABASEからの出力またはEnterprise ManagerのData Guardの概要ページで参照できます。
表5-1 フェイルオーバーまたはスイッチオーバー後の無効化されたデータベースの再有効化
次の各項では、データベースの回復または再有効化方法を説明します。
フィジカル、スナップショットまたはロジカル・スタンバイ・データベースへの完全フェイルオーバーを実行した後、ブローカのREINSTATEコマンドを使用して、障害が発生したプライマリ・データベースを再有効化できます。また、ブローカのREINSTATEコマンドを使用して、フェイルオーバー操作のターゲットではないがフィジカル・スタンバイ・データベースへの完全フェイルオーバー時に無効化されたフィジカル・スタンバイ・データベースを再有効化できます。
回復可能なデータベースは、ステータス値が次のようになります。
ORA-16661: the standby database needs to be reinstated
REINSTATEコマンドを正常に実行するには、フェイルオーバー前にデータベース上でフラッシュバック・データベースが有効化されており、そのデータベースに十分なフラッシュバック・ログが存在する必要があります。さらに、回復するデータベースおよび新規プライマリ・データベースにネットワーク接続が必要です。
データベースを回復する手順は、次のとおりです。
データベースを再起動してマウント済状態にします。
新規プライマリ・データベースに接続します。
Enterprise ManagerまたはDGMGRLを使用してデータベースを回復します。
障害が発生したプライマリ・データベースを回復する場合、ブローカにより、このデータベースは元のスタンバイ・データベースと同じタイプのスタンバイ・データベース（フィジカルまたはロジカル・スタンバイ・データベース）として再有効化されます。フェイルオーバー時に無効化されたフィジカル・スタンバイ・データベースを回復する場合、ブローカにより、これらのデータベースは新規プライマリ・データベースのフィジカル・スタンバイ・データベースとして再有効化されます。
Data Guardの概要ページで、「データベースを回復する必要があります」リンクをクリックします。これにより、「回復」ボタンが表示された「一般プロパティ」ページが開きます。「回復」ボタンをクリックすると、Enterprise Managerでデータベースの回復が開始されます。
プロセスが完了すると、データベースが新規プライマリ・データベースのスタンバイ・データベースとして有効化され、Enterprise ManagerでData Guardの概要ページが表示されます。
ブローカ構成内のデータベース（回復するデータベースを除く）に接続しているときに、次のコマンドを発行します。
DGMGRL> REINSTATE DATABASE db_unique_name;
新しく回復したスタンバイ・データベースは、新規プライマリ・データベースのスタンバイ・データベースとして機能し始めます。データベースが正常に回復しない場合、5.4.3.2項の説明に従って、新規プライマリ・データベースのコピーから再有効化する必要があります。
障害が発生したプライマリ・データベースまたはロール推移時に無効化されたスタンバイ・データベースの再作成が必要なフェイルオーバーまたはスイッチオーバーを実行した場合、『Oracle Data Guard概要および管理』の手順を実行します。
元のプライマリ・データベースを作成する場合、元のスタンバイ・データベースのスタンバイ・タイプで作成する必要があることに注意してください。たとえば、元のスタンバイがフィジカル・スタンバイだった場合は、元のプライマリをフィジカル・スタンバイとして再作成する必要があります。そのスタンバイは、その後、適切に有効化できます。
データベースが再作成された後、DGMGRLのENABLE DATABASEコマンドを使用して、再作成されたスタンバイ・データベースのブローカ管理を有効化します。
ファスト・スタート・フェイルオーバーでは、プライマリ・データベースに障害が発生した場合、ブローカにより、事前に選択されたスタンバイ・データベースに自動的にフェイルオーバーできます。ファスト・スタート・フェイルオーバーでは、ターゲット・スタンバイ・データベースがプライマリ・データベース・ロールに迅速かつ確実にフェイルオーバーされます。このとき、手動手順を実行してフェイルオーバーを起動する必要はありません。ファスト・スタート・フェイルオーバーはブローカ構成でのみ使用でき、DGMGRLまたはEnterprise Managerによってのみ構成できます。
ファスト・スタート・フェイルオーバーでは、最大可用性モードまたは最大パフォーマンス・モードのいずれかを使用できます。最大可用性モードは、データが消失しないことを保証する自動フェイルオーバー環境を提供します。最大パフォーマンス・モードによる自動フェイルオーバー環境では、消失データがFastStartFailoverLagLimit構成プロパティで指定したデータ量（秒単位）以下であることが保証されます。このプロパティは、自動フェイルオーバーの実行に許容される最大消失データ量を示します。このプロパティは、ファスト・スタート・フェイルオーバーが有効化され、構成が最大パフォーマンス・モードで動作している場合にのみ使用されます。
ファスト・スタート・フェイルオーバーが有効化されると、ブローカでは、構成されている消失データ量が保証される場合にのみファスト・スタート・フェイルオーバーの実行が可能となります。構成されている消失データ量を保証できない場合、プライマリ・データベースのREDO生成が停止します。長期にわたる停止を回避するため、ファスト・スタート・フェイルオーバーを実行できないと記録された後、オブザーバまたはターゲット・スタンバイ・データベースにより、プライマリ・データベースでのREDO生成の続行が可能になる場合があります。
構成済の消失データ量の保証がリストアされると、ブローカは自動フェイルオーバー機能をリストアします。このリストアが起こるのは、最大可用性モードで動作している構成の場合、ターゲットのスタンバイ・データベースがREDOデータの不足をすべて受信し終わったときです。最大パフォーマンス・モードで動作している構成の場合は、プライマリ・データベースのREDO生成時点とターゲット・スタンバイ・データベースのREDO適用時点の間に、FastStartFailoverLagLimit構成プロパティに指定された値の遅れがなくなったときです。
この項では、ファスト・スタート・フェイルオーバーおよびファスト・スタート・フェイルオーバー環境を監視するオブザーバ・サイトを有効化する方法を説明します。オブザーバは、プライマリ・データベースおよびスタンバイ・データベースとは異なるコンピュータ上で動作する、独立したOCIクライアント側コンポーネントであり、プライマリ・データベースの可用性を監視します。オブザーバについては、5.5.7項で詳しく説明されています。
オブザーバの起動が完了したら、ユーザーによる操作は必要ありません。オブザーバおよび指定されたスタンバイ・データベースの両方で、FastStartFailoverThreshold構成プロパティに指定された秒数を超えてプライマリ・データベースとの接続が失われた場合、オブザーバはスタンバイ・データベースへのファスト・スタート・フェイルオーバーを開始します。また、FastStartFailoverPmyShutdown構成プロパティがTRUEに設定されている場合、FastStartFailoverThresholdの秒数よりも長い期間に及ぶ接続の消失を検出すると、プライマリ・データベースは停止します。FastStartFailoverAutoReinstate構成プロパティがTRUEに設定されている場合、フェイルオーバーの完了後、元のプライマリ・データベースへの接続が再度確立されたときに、元のプライマリ・データベースがスタンバイ・データベースとして自動的に回復されます。
|
注意: ユーザーが構成可能なファスト・スタート・フェイルオーバー条件が検出されてファスト・スタート・フェイルオーバーが発生した場合、またはアプリケーションからDBMS_DG.INITIATE_FS_FAILOVER関数をコールしてファスト・スタート・フェイルオーバーを開始した場合、FastStartFailoverPmyShutdownおよびFastStartFailoverAutoReinstate構成プロパティは、元のプライマリ・データベースが停止されるかどうか、および自動的に回復されるかどうかに影響しません。この場合、元のプライマリ・データベースは必ず停止し、自動的に回復されることはありません。 |
図5-1に、ファスト・スタート・フェイルオーバー時のプライマリ・データベース、ターゲット・スタンバイ・データベースおよびオブザーバの関係を示しています。
ファスト・スタート・フェイルオーバー前: Data Guardは安定した状態で動作しており、プライマリ・データベースがターゲット・スタンバイ・データベースにREDOデータを転送し、オブザーバが全体の構成の状態を監視しています。
ファスト・スタート・フェイルオーバーの実行: プライマリ・データベースに障害が発生し、オブザーバおよびターゲット・スタンバイ・データベースへのネットワーク接続がどちらも失われます。オブザーバは、通信の切断を検出すると、ファスト・スタート・フェイルオーバーの開始前にFastStartFailoverThresholdプロパティによって定義された時間内において、プライマリ・データベースとの接続の再確立を試行します。オブザーバが指定時間内にプライマリ・データベースへの接続を回復できず、ターゲット・スタンバイ・データベースがファスト・スタート・フェイルオーバー可能な状態である場合、ファスト・スタート・フェイルオーバーが実行されます。
ファスト・スタート・フェイルオーバー後: ファスト・スタート・フェイルオーバーが完了し、ターゲット・スタンバイ・データベースがプライマリ・データベース・ロールで動作しています。元のプライマリ・データベースが修復された後、オブザーバはそのデータベースとの接続を再確立し、新規スタンバイ・データベースとして回復します。新規プライマリ・データベースが新規スタンバイ・データベースへのREDOデータの転送を開始します。
以降の各項の内容は、次のとおりです。
ブローカでファスト・スタート・フェイルオーバーを有効化するには、次の前提条件を満たしている必要があります。
ブローカ構成が最大可用性モードまたは最大パフォーマンス・モードのいずれかで動作していることを確認します。
保護モード、スタンバイREDOログおよびLogXptModeプロパティの構成の詳細は、4.6.1項を参照してください。
ファスト・スタート・フェイルオーバーのターゲットに選択したスタンバイ・データベースのLogXptModeプロパティがSYNC（最大可用性モードでファスト・スタート・フェイルオーバーを有効化する場合）またはASYNC（最大パフォーマンス・モードでファスト・スタート・フェイルオーバーを有効化する場合）に設定されていることを確認します。現在のプライマリ・データベースは、LogXptModeプロパティが適切に設定され、スタンバイREDOログが構成されている必要があります。
フラッシュバック・データベースを有効化し、プライマリ・データベースおよびターゲット・スタンバイ・データベースの両方でフラッシュ・リカバリ領域を設定します。
『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
2.1項の説明に従って、オブザーバ・コンピュータにDGMGRLコマンドライン・インタフェースをインストールします。
オブザーバ・システムでTNSNAMES.ORAファイルを構成し、オブザーバがプライマリ・データベースおよび事前に選択されたターゲット・スタンバイ・データベースに接続できるようにします。
静的なサービス名を作成して、回復処理の一部としてオブザーバがデータベースを自動的に再起動できるようにします。詳細は、2.2項「前提条件」を参照してください。
ブローカ構成のデータベースに接続されている間は、任意のサイトからファスト・スタート・フェイルオーバーを有効化できます。ファスト・スタート・フェイルオーバーを有効化しても、フェイルオーバーは起動されません。かわりに、オブザーバが、プライマリ・データベースとスタンバイ・データベースの監視を開始し、フェイルオーバーの条件が満たされた場合に、ファスト・スタート・フェイルオーバーを起動できるようになります。
ファスト・スタート・フェイルオーバーを有効化し、オブザーバを起動するには、次の手順を実行します。これらの手順では、SYSとして接続しており、ブローカ構成でプライマリ・データベースおよびスタンバイ・データベースがすでに設定されていることを前提としています。
手順1 使用可能なスタンバイ・データベースのうち、フェイルオーバーのターゲットとして最適なデータベースを判断します。
5.2項「ターゲット・スタンバイ・データベースの選択」に示したガイドラインに従います。
手順2 FastStartFailoverTarget構成プロパティを使用してターゲット・スタンバイ・データベースを指定します。
現行のプライマリ・データベースのFastStartFailoverTarget構成プロパティを設定する場合、ターゲット・スタンバイ・データベースを1つのみ指定できます。
構成内のスタンバイ・データベースが1つのみである場合、この手順をスキップして手順3に進みます。ブローカにより、プライマリ・データベースおよびスタンバイ・データベースのFastStartFailoverTargetプロパティが、フェイルオーバー時にお互いをそれぞれのターゲットとして指すように自動的に設定されます。
構成内に複数のスタンバイ・データベースが存在する場合、ファスト・スタート・フェイルオーバーのターゲットとなるスタンバイ・データベースを定義するために、プライマリ・データベースと選択したターゲット・スタンバイ・データベースが互いを指すようにFastStartFailoverTargetプロパティを明示的に設定する必要があります。次に例を示します。
DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY FastStartFailoverTarget = 'DR_Sales'; DGMGRL> EDIT DATABASE 'DR_Sales' SET PROPERTY FastStartFailoverTarget = 'North_Sales';
この例では、現行のプライマリ・データベースNorth_Salesでは、フェイルオーバーのターゲットとしてDR_Salesが指定されており、ターゲット・スタンバイ・データベースDR_Salesでは、現行のプライマリ・データベースがターゲットとして指定されています。DR_Salesがプライマリ・データベースとなる場合、フェイルオーバー先のスタンバイ・ターゲットが必要です。
|
注意: FastStartFailoverTargetプロパティを変更して別のスタンバイ・データベースを指すようにするには、ファスト・スタート・フェイルオーバーを無効化し、FastStartFailoverTargetプロパティを設定し、さらにファスト・スタート・フェイルオーバーを再有効化してください。 |
このプロパティの詳細は、9.2.14項「FastStartFailoverTarget」を参照してください。
手順3 使用する保護モードを決定します。
ファスト・スタート・フェイルオーバーは、最大可用性モードまた最大パフォーマンス・モードに対して有効化できます。いかなるデータの消失も許容できない場合は、構成の保護モードが最大可用性に設定されていることを確認してください。これには、プライマリ・データベースとターゲット・スタンバイ・データベースの両方で構成可能なデータベース・プロパティLogXptModeがSYNCに設定されている必要があります。その後、構成保護モードを最大可用性に設定してください。次に例を示します。
DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY LogXptMode=SYNC; DGMGRL> EDIT DATABASE 'DR_Sales' SET PROPERTY LogXptMode=SYNC; DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MaxAvailability;
わずかなデータの消失よりもプライマリ・データベースのパフォーマンスを重視する場合は、構成の保護モードを最大パフォーマンスに設定してファスト・スタート・フェイルオーバーを有効化することを検討してください。このモードでは、どれだけのデータ消失を許容できるかを秒単位で検討し、それに従ってFastStartFailoverLagLimit構成プロパティを設定する必要があります。このプロパティは、REDO適用に関してターゲット・スタンバイ・データベースがプライマリ・データベースから遅れることができるデータ量を秒単位で指定します。スタンバイ・データベースでREDOが適用された時点がプライマリ・データベースのREDO生成時点からその秒数以内であれば、ファスト・スタート・フェイルオーバーが許可されます。FastStartFailoverLagLimit構成プロパティは、最大パフォーマンス・モードで動作している構成のファスト・スタート・フェイルオーバーが有効化されている場合にのみブローカによって使用されます。デフォルト値は30秒で、設定できる最小値は10秒です。
構成の保護モードを最大パフォーマンスに設定することに加えて、プライマリ・データベースとターゲットスタンバイ・データベースの両方で構成可能なデータベース・プロパティLogXptModeがASYNCに設定されていることを確認する必要もあります。次に例を示します。
DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY LogXptMode=ASYNC; DGMGRL> EDIT DATABASE 'DR_Sales' SET PROPERTY LogXptMode=ASYNC; DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MaxPerformance; DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverLagLimit=45;
手順4 FastStartFailoverThreshold構成プロパティを設定します。
オブザーバおよびターゲット・スタンバイ・データベースの両方で、FastStartFailoverThreshold構成プロパティで指定された時間にわたってプライマリ・データベースへの接続が失われた場合、ファスト・スタート・フェイルオーバーが実行されます。
FastStartFailoverThresholdプロパティを設定し、（プライマリ・データベースが使用できないことが検出されてから）フェイルオーバーを開始するまでにオブザーバおよびターゲット・スタンバイ・データベースを待機させる秒数を指定します。次に例を示します。
DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverThreshold = 45;
これは構成レベルのプロパティです。FastStartFailoverThresholdプロパティのデフォルト値は30秒で、設定できる最小値は6秒です。Oracle RACプライマリ・データベースが存在する場合、インスタンス障害が発生したときに誤ってフェイルオーバーが実行される可能性を最小限にするには、これより大きい値を指定することを考慮します。
この時間間隔は、オブザーバでプライマリ・データベースへの接続が最初に失われたときに開始されます。オブザーバが指定時間内にプライマリ・データベースへの接続を回復できない場合、スタンバイ・データベースがフェイルオーバー可能な状態であれば、オブザーバによりファスト・スタート・フェイルオーバーが開始されます。デフォルト値の30秒は、通常はほとんどの構成で停止および障害を検出できる値ですが、このプロパティでフェイルオーバーの感度を調整することで、一時的に不安定になった環境でフェイルオーバーが誤って実行される可能性を低くすることができます。
REDOの生成が停止し、プライマリ・データベースがオブザーバまたはターゲット・スタンバイ・データベースとの接続を再確立できない場合、FastStartFailoverPmyShutdown構成プロパティがTRUEに設定されていると、FastStartFailoverThresholdの秒数が経過した後にプライマリ・データベースが停止します。
ファスト・スタート・フェイルオーバーが有効化されている場合でもFastStartFailoverThresholdプロパティを変更できることに注意してください。
手順5 その他のデータベース・プロパティを設定します（オプション）。
必要に応じて、次の表に示されているデータベース・プロパティを設定できます。
| プロパティ名 | 説明 | デフォルト値 |
|---|---|---|
FastStartFailoverPmyShutdown |
この構成プロパティにより、ファスト・スタート・フェイルオーバーが有効化されていてプライマリがFastStartFailoverThresholdの秒数よりも長くSTALLEDになったことをV$DATABASE.FS_FAILOVER_STATUSが示すと、プライマリ・データベースが停止します。TRUEの値は、分離されたプライマリ・データベースがユーザーの問合せに対応できないことを確認するのに役立ちます。
ユーザーの構成条件が検出されたためにファスト・スタート・フェイルオーバーが発生した場合、または |
TRUE |
FastStartFailoverLagLimit |
構成プロパティは、REDOの適用に関して、プライマリよりスタンバイが遅れることができる許容範囲を秒単位で確立します。この値を超えて遅れる場合は、ファスト・スタート・フェイルオーバーが実行されません。設定可能な最小値は10秒です。
このプロパティは、ファスト・スタート・フェイルオーバーが有効化され、構成が最大パフォーマンス・モードで動作しているときに使用します。 |
30秒 |
FastStartFailoverAutoReinstate |
この構成プロパティを使用すると、プライマリ・データベースが分離またはクラッシュしたためにファスト・スタート・フェイルオーバーが開始した場合に、元のプライマリ・データベースが自動的に回復されます。この場合に元のプライマリ・データベースを自動的に回復しないようにするには、この構成プロパティをFALSEに設定します。ユーザー構成条件が検出されたためにファスト・スタート・フェイルオーバーが発生した場合、またはDBMS_DG.INITIATE_FS_FAILOVER関数をコールしてアプリケーションでファスト・スタート・フェイルオーバーを要求した場合は、ブローカは元のプライマリ・データベースを自動的に回復しません。 |
TRUE |
ObserverConnectIdentifier |
この構成可能なデータベース・プロパティは、オブザーバがプライマリおよびスタンバイ・データベースに接続して監視する方法を指定するために使用されます。REDOデータの転送に使用される接続識別子とは異なる識別子（DGConnectIdentifierプロパティで指定される接続識別子）をオブザーバが使用する場合は、プライマリ・データベースとターゲット・スタンバイ・データベースにこのプロパティを設定してください。 |
オブザーバは、DGConnectIdentifier構成可能プロパティの値を使用してプライマリおよびターゲット・スタンバイ・データベースに接続し、監視します。 |
手順6 追加のファスト・スタート・フェイルオーバー条件を有効化します（オプション）。
デフォルトでは、構成された時間しきい値（FastStartFailoverThreshold）の経過後にオブザーバもスタンバイもプライマリにアクセスできないと、ファスト・スタート・フェイルオーバーが実行されます。
必要に応じて、ファスト・スタート・フェイルオーバーを発生させるデータベース健全性条件を指定することができます。次の表に、これらの条件を示します。
| 健全性条件 | 説明 | デフォルトで有効化 |
|---|---|---|
| データファイル・オフライン | 書込みエラーのためにデータファイルがオフラインになりました。 | される |
| 破損したディクショナリ | 重要なデータベース・オブジェクトのディクショナリが破損しました。現時点では、この状態は、データベースがオープンされている場合にのみ検出されます。 | される |
| 破損した制御ファイル | ディスク障害のために制御ファイルが永続的に破損しました。 | される |
| アクセス不可能なログ・ファイル | I/OエラーのためにLGWRがログ・グループのどのメンバーにも書き込むことができません。 | 不要 |
| スタック・アーカイバ | デバイスに空き容量がないかデバイスを使用できないためにアーカイバがREDOログをアーカイブできません。 | 不要 |
Oracle RAC構成では、アクセス不可能なログ・ファイルおよびスタック・アーカイバの健全性条件は、単一インスタンスにのみ適用できます。これらの条件によるファスト・スタート・フェイルオーバーは、CRSによって提供される可用性オプションに優先して実行されるので、有効化する前によく検討してください。
Oracleサーバーで発生するエラー（ORAエラー）をファスト・スタート・フェイルオーバーが発生するための条件として指定することもできます。
Oracle Enterprise ManagerまたはDGMGRLのENABLE FAST_START FAILOVER CONDITIONコマンドおよびDISABLE FAST_START FAILOVER CONDITIONコマンドを使用して、ファスト・スタート・フェイルオーバーが実行される特定条件を指定することができます。
手順7 ファスト・スタート・フェイルオーバーを有効化します。
Enterprise Managerのファスト・スタート・フェイルオーバー・ウィザードまたはDGMGRLのENABLE FAST_START FAILOVERコマンドを使用して、ファスト・スタート・フェイルオーバーを有効化します。ファスト・スタート・フェイルオーバーを有効化するには、プライマリ・データベースおよびターゲット・スタンバイ・データベースの両方が動作しており、接続され、さらに5.5.1項にリストされた前提条件をすべて満たしている必要があります。
Enterprise Managerを使用したファスト・スタート・フェイルオーバーの有効化
Enterprise Managerでファスト・スタート・フェイルオーバーを有効化するには、ファスト・スタート・フェイルオーバー・ウィザードを使用します。「ファスト・スタート・フェイルオーバー」ステータス・フィールドの横にあるData Guardの概要ページで、「無効」をクリックして「ファスト・スタート・フェイルオーバー」ページを開きます。次に、「ファスト・スタート・フェイルオーバー: モードを変更」ページで、「有効」をクリックします。Enterprise Managerがオブザーバを起動します。次に、「ファスト・スタート・フェイルオーバー: 構成」ページで、フェイルオーバーのターゲットとするスタンバイ・データベースを選択します。役立つアドバイスについては、5.2項「ターゲット・スタンバイ・データベースの選択」を参照してください。このページでは、保護モードを変更できません。ファスト・スタート・フェイルオーバーは、現在の保護モードに従って有効化されます。現在構成されているモードが最大保護の場合、Enterprise Managerは、モードを最大可用性にダウングレードします。
DGMGRLを使用したファスト・スタート・フェイルオーバーの有効化
DGMGRLを使用してファスト・スタート・フェイルオーバーを有効化するには、オブザーバ・コンピュータ上のデータベースを含むブローカ構成内のいずれかのデータベースに接続している間に、ENABLE FAST_START FAILOVERコマンドを発行します。次に例を示します。
DGMGRL> ENABLE FAST_START FAILOVER; Enabled.
|
注意: スタンバイ・データベースが事前の予告なしにプライマリ・ロールを引き継ぐ場合があるため、ターゲット・スタンバイ・サイトでの管理はプライマリ・サイトでの管理と同じくらい包括的である必要があります。スタッフ・サポート、ハードウェアとソフトウェア、セキュリティ（ソフトウェアとサイトの両方）、ネットワーク接続および帯域幅が両方のサイトで同等である必要があります。 |
手順8 オブザーバを起動します。
オブザーバを起動するには、プライマリ・データベースが実行されている必要があります。
ファスト・スタート・フェイルオーバーを有効化する前または後にオブザーバを起動できます。ただし、ファスト・スタート・フェイルオーバーが有効化されているときは常に、オブザーバを動作させることをお薦めします。ファスト・スタート・フェイルオーバーが有効化されると、オブザーバは、プライマリ・データベースおよびターゲット・スタンバイ・データベースのステータスおよび接続の監視をただちに開始します。
Enterprise Managerを使用したオブザーバの起動
Enterprise Managerエージェントがオブザーバ・コンピュータにインストールされている場合、Enterprise Managerを使用してファスト・スタート・フェイルオーバーを有効化すると、Enterprise Managerによりオブザーバが自動的に起動されます。エージェントが存在しない場合、DGMGRLコマンドライン・インタフェースに関する次の手順を実行して、オブザーバを手動で起動する必要があります。
DGMGRLを使用したオブザーバの起動
DGMGRLを使用してオブザーバを起動するには、オブザーバ・コンピュータで次のコマンドを発行します。
DGMGRL> START OBSERVER;
オブザーバはSTART OBSERVERコマンドを発行したときに作成され、継続的に実行されるプロセスです。そのため、別のDGMGRLセッションからSTOP OBSERVERコマンドを発行するまで、オブザーバ・コンピュータ上のコマンドライン・プロンプトは戻されません。コマンドを発行し、ブローカ構成と対話するには、別のDGMGRLクライアント・セッションにより接続する必要があります。
詳細は、START OBSERVERコマンドを参照してください。
手順9 ファスト・スタート・フェイルオーバー環境を検証します。
ファスト・スタート・フェイルオーバー構成の準備が整っているかどうかを検証するには、プライマリ・データベースでDGMGRLのSHOW CONFIGURATION VERBOSEコマンドまたはSHOW FAST_START FAILOVERコマンドを発行します。次に例を示します。
DGMGRL> SHOW FAST_START FAILOVER; Fast-Start Failover: ENABLED Threshold: 60 seconds Target: DR_Sales Observer: observer.foo.com Lag Limit: 30 seconds (not in use) Shutdown Primary: TRUE Auto-reinstate: TRUE Configurable Failover Conditions Health Conditions: Corrupted Controlfile YES Corrupted Dictionary YES Inaccessible Logfile NO Stuck Archiver NO Datafile Offline YES Oracle Error Conditions: (none)
次の各項では、ファスト・スタート・フェイルオーバー環境の詳細を説明しています。
ファスト・スタート・フェイルオーバーを有効化してオブザーバを起動した後は、オブザーバが継続的に環境を監視してプライマリ・データベースが使用可能であることを確認します。この項では、オブザーバがファスト・スタート・フェイルオーバーの必要性を判別し、必要に応じてフェイルオーバーを実行するための手順をリストしています。
手順1 環境を監視し、プライマリ・データベースが使用可能であることを確認します。
次のリストに、オブザーバがファスト・スタート・フェイルオーバーを試行する原因となる、プライマリ・データベース、システムまたはサイトの条件をいくつか示しています。
プライマリ・データベースと、オブザーバおよびターゲット・スタンバイ・データベースの両方との接続が失われた場合
単一インスタンスのプライマリ・データベース（RACまたは非RAC）、またはOracle RACプライマリ・データベースのすべてのインスタンスに障害が発生した場合、オブザーバがファスト・スタート・フェイルオーバーを試行します。
単一インスタンスのプライマリ・データベース（RACまたは非RAC）、またはOracle RACプライマリ・データベースのすべてのインスタンスがABORTオプションにより停止された場合、オブザーバがファスト・スタート・フェイルオーバーを試行します。他のタイプのデータベース停止（NORMAL、IMMEDIATE、TRANSACTIONAL）では、ファスト・スタート・フェイルオーバーは試行されません。
ユーザーが構成可能な条件
オブザーバは、ユーザーが構成可能な条件が検出されたと判断すると、ファスト・スタート・フェイルオーバーを試行します。
DBMS_DG.INITIATE_FS_FAILOVERのアプリケーション・コール
アプリケーションがこの機能をコールし、SUCCESSステータスを受け取ると、オブザーバがファスト・スタート・フェイルオーバーを試行します。
ユーザーが構成可能な条件およびアプリケーションで開始されたファスト・スタート・フェイルオーバーの場合を除き、オブザーバは、ファスト・スタート・フェイルオーバーの試行前に、FastStartFailoverThreshold構成プロパティによって指定された時間内において、プライマリ・データベースへの再接続を試行します。ユーザーが構成可能な条件が検出されるか、アプリケーションによってファスト・スタート・フェイルオーバーが開始された場合、オブザーバはFastStartFailoverThresholdプロパティで指定された時間が過ぎるまで待機せずに、ただちにファスト・スタート・フェイルオーバーを開始します。
手順2 FastStartFailoverThresholdにより指定された時間内に再接続します。
プライマリ・データベースに可用性の問題があることをオブザーバが検出した場合、オブザーバは通常、FastStartFailoverThreshold構成プロパティに指定された時間内にプライマリ・データベースに再接続しようとします。FastStartFailoverThresholdの時間間隔は、オブザーバがプライマリ・データベースに障害があることを最初に検出したときに開始されます。
ユーザーが構成可能な条件が発生したことをオブザーバが検出した場合、またはDBMS_DG.INITIATE_FS_FAILOVER関数でファスト・スタート・フェイルオーバーを要求した場合、FastStartFailoverThresholdプロパティに指定された時間間隔は無視されます。
プライマリ・データベースがOracle Real Application Clusters（RAC）データベースである場合、オブザーバは残りのプライマリ・インスタンスのいずれかに接続しようとします。RACプライマリ・データベースを構成するすべてのインスタンスに障害が発生したことが検出されていないかぎり、ファスト・スタート・フェイルオーバーは実行されません。オブザーバは、構成可能なデータベース・プロパティDGConnectIdentifierまたはObserverConnectIdentifierに指定された値を使用して、プライマリ・データベースおよびファスト・スタート・フェイルオーバーのターゲット・スタンバイ・データベースに接続します。オブザーバは、これらのプロパティに指定された値を使用して、Oracle RACデータベースの任意のインスタンスに接続できる必要があります。
手順3 ターゲット・スタンバイ・データベースがフェイルオーバー可能な状態であることを確認します。
ファスト・スタート・フェイルオーバーが開始されると、オブザーバはターゲット・スタンバイ・データベースがプライマリ・データベース・ロールにフェイルオーバーする準備ができているかどうかを確認します。
次の場合、ファスト・スタート・フェイルオーバーは実行できません。
ファスト・スタート・フェイルオーバーが有効でない場合
オブザーバがターゲット・スタンバイ・データベースに接続できない場合
ブローカ構成の現在の状態に関して、オブザーバおよびターゲット・スタンバイ・データベースに一貫性がない場合
オブザーバが動作していない場合
保護モードが最大可用性で、プライマリ・データベースに障害が発生したときにターゲット・スタンバイ・データベースがプライマリ・データベースと同期化されていない場合
保護モードが最大パフォーマンスで、プライマリ・データベースに障害が発生したときにターゲット・スタンバイ・データベースのREDO適用時点がプライマリ・データベースのREDO生成時点からFastStartFailoverLagLimit構成プロパティで指定された時間を超えて遅れる場合
ターゲット・スタンバイ・データベースがプライマリ・データベースと通信している場合
ターゲット・スタンバイ・データベースのV$DATABASEビュー内のFS_FAILOVER_STATUS列に、ファスト・スタート・フェイルオーバーを実行できない理由が表示された場合
手動フェイルオーバーがすでに進行中です。手動フェイルオーバーの詳細は、5.4項を参照してください。
ABORTオプションを使用せずにプライマリ・データベースを停止した場合
手順4 ファスト・スタート・フェイルオーバーを開始します。
ターゲット・スタンバイ・データベースがフェイルオーバー可能な状態である場合、オブザーバはただちにファスト・スタート・フェイルオーバーを起動します。オブザーバにより、ターゲット・スタンバイ・データベースがプライマリ・データベース・ロールにフェイルオーバーします。他のなんらかの理由でフェイルオーバーを実行できない場合、オブザーバはスタンバイ・データベースでフェイルオーバーの準備ができたかどうかのチェックし続けます。ただし、オブザーバはプライマリ・データベースへの再接続も無期限に試行し続けます。スタンバイがフェイルオーバーに同意する前にプライマリ・データベースに再接続すると、オブザーバはファスト・スタート・フェイルオーバーの開始の試行を中止します。
手順5 元のプライマリ・データベースを新規スタンバイ・データベースとして回復します。
ファスト・スタート・フェイルオーバーが正常に完了した後、元のプライマリ・データベースへの接続が再確立され、FastStartFailoverAutoReinstate構成プロパティがTRUEに設定されている場合、オブザーバは元のプライマリ・データベースの新規スタンバイ・データベースとしての回復を試行します。FastStartFailoverPmyShutdown構成プロパティをTRUEに設定した場合、元のプライマリ・データベースは自動的に停止しているため、オブザーバが回復を試行する前に、手動で再起動する必要があります。
プライマリがクラッシュしたか、オブザーバおよびターゲット・スタンバイ・データベースから分離したためにファスト・スタート・フェイルオーバーが発生した場合にのみ、これらのプロパティがプライマリの停止および自動回復の実行を左右する点に注意してください。
ファスト・スタート・フェイルオーバーが有効化されている場合、次の操作は禁止されています。
変更:
構成保護モード
プライマリ・データベースまたはターゲット・スタンバイ・データベースの構成可能なデータベース・プロパティLogXptMode
プライマリ・データベースまたはターゲット・スタンバイ・データベースのFastStartFailoverTarget構成プロパティ
無効化または削除:
ブローカ構成
ファスト・スタート・フェイルオーバーのターゲットであるスタンバイ・データベース
手動フェイルオーバーの実行:
5.5.2.4項にリストした条件を満たしていない場合の実行
ファスト・スタート・フェイルオーバーのターゲットとして構成されていないスタンバイ・データベースに対する実行
構成がファスト・スタート・フェイルオーバーを実行可能な状態かどうかを判断するには、DGMGRLのSHOW DATABASE <target-standby-database> StatusReportコマンドを発行するか、プライマリ・データベースまたはターゲット・スタンバイ・データベースのいずれかで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 being opened
ファスト・スタート・フェイルオーバーの妥当性チェックが失敗するか、2分未満で完了しないと、このエラーが戻されることがあります。
プライマリ・データベースまたはスタンバイ・データベースが通常の方法で（SHUTDOWN NORMAL、SHUTDOWN IMMEDIATEまたはSHUTDOWN TRANSACTIONALを使用して）停止された場合、ファスト・スタート・フェイルオーバーは起動されません。通常の停止では、プライマリ・データベースおよびスタンバイ・データベースが再度接続され通信状態になるまで、ファスト・スタート・フェイルオーバーを実行できません。
ファスト・スタート・フェイルオーバーが有効化されている場合でも、次の条件を満たしているかぎり、スイッチオーバーまたは手動フェイルオーバーを実行できます。
ロール変更の対象が、FastStartFailoverTarget構成プロパティで指定されたスタンバイ・データベースと同一であること
ターゲット・スタンバイ・データベースがプライマリ・データベースと同期化されていること（最大可用性モードで動作している構成の場合）またはターゲット・スタンバイ・データベースがラグ制限内にあること（最大パフォーマンス・モードで動作している構成の場合）
手動フェイルオーバーの場合、オブザーバが起動しており、ターゲット・スタンバイ・データベースと通信していること
DBMS_DG PL/SQLパッケージを使用して、特定の条件が満たされたときにアプリケーションによりファスト・スタート・フェイルオーバーを指示することができます。アプリケーションに独自に認識される重大な条件が検出されたとき、DBMS_DG.INITIATE_FS_FAILOVER機能をコールして、プライマリ・データベースに、ファスト・スタート・フェイルオーバーをすぐに開始することを通知するアラートを送信できます。プライマリ・データベースはオブザーバにこれを通知し、スタンバイがフェイルオーバーを実行可能な状態であれば、オブザーバはただちにファスト・スタート・フェイルオーバーを開始します。オブザーバによってファスト・スタート・フェイルオーバーが開始されると、プライマリ・データベースは自動的に停止します。オブザーバは元のプライマリ・データベースの回復を試行しません。
構成がフェイルオーバー不能の場合、DBMS_DG.INITIATE_FS_FAILOVER機能は、ORAエラー番号（例外ではなく）を返して、ファスト・スタート・フェイルオーバーを実行できないことをコール元に通知します。
|
注意: オブザーバがターゲット・スタンバイ・データベースへのフェイルオーバーを開始するため、アプリケーションは、この機能をコールする際に注意が必要です。 |
|
関連項目: DBMS_DGパッケージの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。 |
オブザーバが起動しており、構成がファスト・スタート・フェイルオーバー可能な状態かどうかを確認するには、DGMGRLのSHOW DATABASE <target-standby-database> StatusReportコマンドを発行するか、ターゲット・スタンバイ・データベースでV$DATABASEビューを問い合せます。
V$FS_FAILOVER_STATSビューを問い合せて、システムで発生しているファスト・スタート・フェイルオーバーに関する統計を表示することもできます。
次に、DGMGRL SHOWコマンドを使用してファスト・スタート・フェイルオーバー情報を表示する例を示します。次のビューについても説明します。
DGMGRLのSHOW FAST-START FAILOVERコマンドは、すべてのファスト・スタート・フェイルオーバー関連情報を表示します。次に例を示します。
DGMGRL> SHOW FAST_START FAILOVER; Fast-Start Failover: ENABLED Threshold: 60 seconds Target: DR_Sales Observer: observer.foo.com Lag Limit: 30 seconds (not in use) Shutdown Primary: TRUE Auto-reinstate: TRUE Configurable Failover Conditions Health Conditions: Corrupted Controlfile YES Corrupted Dictionary YES Inaccessible Logfile NO Stuck Archiver NO Datafile Offline YES Oracle Error Conditions: (none)
次の例は、DRSolution構成のファスト・スタート・フェイルオーバー情報を示しています。
DGMGRL> SHOW CONFIGURATION VERBOSE;
Configuration
Name: DRSolution
Enabled: YES
Protection Mode: MaxAvailability
Databases:
North_Sales - Primary database
DR_Sales - Physical standby database
- Fast-Start Failover target
Fast-Start Failover: ENABLED
Threshold: 60 seconds
Target: DR_Sales
Observer: observer.foo.com
Lag Limit: 30 seconds (not in use)
Shutdown Primary: TRUE
Auto-reinstate: TRUE
Current status for "DRSolution":
SUCCESS
V$DATABASEビューを問い合せて、オブザーバが起動しており、構成がファスト・スタート・フェイルオーバー可能な状態かどうかを確認できます。V$DATABASEビューを問い合せる場合、表5-2に示す値が含まれる可能性のあるFS_FAILOVER_STATUS列には特に注意してください。また、オブザーバが実行され、データベースをアクティブにpingしているかどうかを示すFS_FAILOVER_OBSERVER_PRESENT列にも注意してください。
表5-2 V$DATABASEビューのFS_FAILOVER_STATUS列
| 列値 | 説明 | ファスト・スタート・フェイルオーバー |
|---|---|---|
|
|
ファスト・スタート・フェイルオーバーは有効化されていますが、このスタンバイ・データベースはファスト・スタート・フェイルオーバーのターゲットではありません。このデータベースはファスト・スタート・フェイルオーバーのステータス情報を提供できません。 |
有効 |
|
|
ファスト・スタート・フェイルオーバーは無効化されています。 |
不可 |
|
|
プライマリ・データベースのデータ・ディクショナリのコピーをロードし終えていないロジカル・スタンバイ・データベースにのみ表示されます。 |
不可 |
|
|
ターゲット・スタンバイ・データベースが、プライマリ・データベースと |
不可 |
|
|
障害が発生したプライマリ・データベースの新規スタンバイ・データベースとしての回復に失敗しました。ブローカの |
完了済 |
|
|
障害が発生したプライマリ・データベースの新規スタンバイ・データベースとしての回復が進行中です。 |
完了済 |
|
|
障害が発生したプライマリ・データベースは、新規プライマリに対する新規スタンバイ・データベースとして回復する必要があります。オブザーバにより回復プロセスが自動的に開始されます。 |
完了済 |
|
|
ターゲット・スタンバイ・データベースとの接続が切断され、 フェイルオーバーが実行された可能性が高いため、プライマリ・データベースが停止またはストールします。 注意: この状態は、ファスト・スタート・フェイルオーバーが可能で、ターゲット・スタンバイ・データベースもオブザーバも存在しないときに起動し、データベースのオープンを継続可能かどうかを確認した場合にもプライマリで発生します。 |
可 |
|
|
構成が最大パフォーマンス・モードで動作しているとき、プライマリ・データベースのREDO生成時点からのスタンバイ・データベースのREDO適用時点の遅れが、 |
不可 |
|
|
構成が最大パフォーマンス・モードで動作しているとき、プライマリ・データベースのREDO生成時点からのスタンバイ・データベースのREDO適用時点の遅れが、 |
可 |
|
|
プライマリ・データベースまたはターゲット・スタンバイ・データベースが制御された方法で（ |
不可 |
|
|
プライマリ・データベースとターゲット・スタンバイ・データベースが同期化されており、構成が最大可用性モードで動作している場合に表示されます。 |
ターゲット・スタンバイ・データベースが |
|
|
ターゲット・スタンバイ・データベースがプライマリ・データベースのすべてのREDOデータを持たず、構成が最大可用性モードで動作している場合に表示されます。 |
不可 |
ファスト・スタート・フェイルオーバーは完全に自動化されており、いつでも発生する可能性があるので、プライマリ・データベースのこのビューを問い合せて、システムで発生したファスト・スタート・フェイルオーバーに関する次の統計を表示する場合に役立ちます。
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.4項を参照してください。
ファスト・スタート・フェイルオーバーを無効化するには、Enterprise Managerのファスト・スタート・フェイルオーバー・ウィザードまたはDGMGRLのDISABLE FAST_START FAILOVER [FORCE]コマンドを使用します。FORCEオプションを使用すると、エラーが発生した場合でも、接続先のデータベースでファスト・スタート・フェイルオーバーが無効化されます。FORCEオプションが必要かどうかは、プライマリ・データベースおよびターゲット・スタンバイ・データベースにネットワーク接続が存在するかどうかによって決まります。
プライマリ・データベースおよびターゲット・スタンバイ・データベースにネットワーク接続が存在し、接続先のデータベースがプライマリ・データベースとネットワークで接続されている場合、FORCEオプションを使用しても効果はありません。オプションを指定せずにDISABLE FAST_START FAILOVERを使用してください。この方法では、ブローカ構成内のすべてのデータベースでファスト・スタート・フェイルオーバーが無効化されます。
無効化操作中にエラーが発生した場合、ブローカによりエラー・メッセージが戻され、無効化操作が停止されます。
プライマリ・データベースおよびターゲット・スタンバイ・データベースにネットワーク接続が存在しないか、または接続先のデータベースにプライマリ・データベースとのネットワーク接続が存在しない場合、DISABLE FAST_START FAILOVERをFORCEオプションとともに使用することを考慮します。
DISABLE FAST_START FAILOVER FORCEコマンドを発行した場合、ブローカはブローカ構成内のすべてのデータベースでファスト・スタート・フェイルオーバーを無効化できない場合があります。その結果、フェイルオーバーの条件を満たしているとオブザーバが判別した場合に、オブザーバがターゲット・スタンバイ・データベースへのファスト・スタート・フェイルオーバーを実行しないという保証がなくなります。次のリストに、プライマリ・データベース、ターゲット・スタンバイ・データベースおよびファスト・スタート・フェイルオーバーのターゲットでないスタンバイ・データベースで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オプションを使用してファスト・スタート・フェイルオーバーを無効にします。プライマリ・データベースとターゲット・スタンバイ・データベースとの接続が回復すると、構成内のすべてのデータベースでファスト・スタート・フェイルオーバーが無効化されます。
Enterprise Managerを使用したファスト・スタート・フェイルオーバーの無効化
ファスト・スタート・フェイルオーバー・ウィザードで「無効化」をクリックします。次に、「続行」をクリックして次のページに進みます。詳細は、Enterprise Managerのオンライン・ヘルプ・システムを参照してください。
DGMGRLを使用したファスト・スタート・フェイルオーバーの無効化
DISABLE FAST_START FAILOVERコマンドまたはDISABLE FAST_START FAILOVER FORCEコマンドを発行します。詳細は、第8章のDISABLE FAST_START FAILOVERコマンドに関する項を参照してください。
ファスト・スタート・フェイルオーバーを使用する際のパフォーマンスを向上させるには、次の推奨事項を考慮します。
フェイルオーバー時間は、ターゲット・スタンバイ・データベース（フィジカルまたはロジカル・スタンバイ・データベース）がプライマリ・データベースから受け取ったREDOデータをすべて適用したかどうかによって決まります。
最大パフォーマンス・モードで動作している構成でファスト・スタート・フェイルオーバーを有効化すると、REDOデータが非同期でターゲット・スタンバイに転送されるため、プライマリ・データベースでの全体的なパフォーマンスが向上します。この場合はデータが消失しないことが保証されないことに注意してください。
スタンバイ・データベースへのREDOデータの適用がプライマリ・データベースのREDO適用率と一致した状態が保たれるように、リカバリを最適化する手順を実行すると、ファスト・スタート・フェイルオーバーが高速になります。ログ適用率を最適化するには、次のようにします。
構成可能なデータベース・プロパティDelayMinsを設定することにより、スタンバイ・データベースへのアーカイブREDOログ・ファイルの適用を遅延させないでください（詳細は、4.5項を参照してください）。
フィジカル・スタンバイ・データベースのログ適用率のチューニングの詳細は、『Oracle Data Guard概要および管理』を参照してください。
次のURLにあるホワイト・ペーパー『Oracle Maximum Availability Architecture』を参照してください。
http://otn.oracle.com/deploy/availability/
FastStartFailoverLagLimit構成プロパティを設定する際は、パフォーマンスとデータ消失の可能性の間のトレードオフを考慮してください。
ラグ制限を低くすると、データの消失は最小限に抑えられますが、プライマリ・データベースのパフォーマンスに影響を与える場合があります。
ラグ制限を高くすると、消失データ量が増加する可能性がありますが、プライマリ・データベースのパフォーマンスへの影響は緩和されます。
オブザーバは、ブローカのDGMGRLクライアント側コンポーネントに統合されており、プライマリ・データベースまたはスタンバイ・データベースおよびブローカ構成を管理するコンピュータとは異なるコンピュータ上で動作します。オブザーバは、ファスト・スタート・フェイルオーバー環境を継続的に監視し、プライマリ・データベースが使用可能であることを確認します（5.5.2.1項を参照）。オブザーバの主な目的は、停止時間が長くなる可能性がある、手動フェイルオーバー・プロセスで必要な人的操作を少なくすることで、高可用性および簡易式コンピューティングを強化することです。
Oracle Enterprise ManagerのData Guardの概要ページまたはDGMGRLコマンドを使用して、オブザーバを管理できます。図5-2に、オブザーバによるファスト・スタート・フェイルオーバー構成の監視を示しています。
次の各項では、オブザーバの管理情報を説明します。
オブザーバは、プライマリ・システムおよびスタンバイ・システムとは別のコンピュータ・システムにインストールし、動作させる必要があります。オブザーバのインストールおよび起動は、ファスト・スタート・フェイルオーバーの使用における必須部分であり、次の各項で詳細に説明しています。
2.1項では、オブザーバ・システムでのOracle Database Enterprise EditionまたはOracle Personal Editionのインストールについて説明しています。
5.5.2項では、ファスト・スタート・フェイルオーバーを有効化する段階的なプロセスの一部として、オブザーバの起動方法を説明しています。Oracle Enterprise ManagerおよびDGMGRLを使用したオブザーバの起動例は、それぞれ6.4項および7.6項に示しています。
ブローカ構成を監視するオブザーバは1つのみ存在できます。別のオブザーバを起動しようとすると、ブローカにより次のエラー・メッセージが戻されます。
ORA-16647: could not start more than one observer
オブザーバを起動するには、SYSとしてDGMGRLにログインできる必要があります。オブザーバは、DGMGRLでData Guard構成に接続したときに使用したSYS接続情報を使用してプライマリ・データベースおよびターゲット・スタンバイ・データベースに接続するOCIクライアントです。
オブザーバに関する情報を検索するには、V$DATABASEビューで次の列を問い合せます。
表5-3 V$DATABASEビューのFS_FAILOVER_OBSERVER_PRESENT列
| 列値脚注1 | 説明 |
|---|---|
|
|
オブザーバは現在ローカル・データベースに接続している |
|
|
オブザーバはローカル・データベースに接続していない |
脚注1 この値は、Oracle Real Application Clusters（RAC）環境内の全インスタンスで一貫性が保たれています。つまり、オブザーバがRAC内のインスタンスに接続されている場合、すべてのインスタンスにYESの値が示されます。
たとえば、ファスト・スタート・フェイルオーバーが実行可能かどうかを判断するには、ターゲット・スタンバイ・データベースで、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 |
プライマリ・データベースとターゲット・スタンバイ・データベースの間の接続が維持された状態でオブザーバからの接続が失われた場合、ブローカにより、構成が監視されていないと報告されます。構成およびデータベースのステータスにより、オブザーバが動作していないと報告され、次のいずれかのステータス・メッセージが戻されます。
ORA-16658: unobserved fast-start failover configuration ORA-16820: fast-start failover observer is no longer observing this database
構成が監視されない状態の場合、ファスト・スタート・フェイルオーバーは実行できません。そのため、ターゲット・スタンバイ・データベースに障害が発生した場合でも、プライマリ・データベースはトランザクションの処理を続行できます。オブザーバとプライマリ・データベースとの接続が再確立され、プライマリ・データベースによりターゲット・スタンバイ・データベースに通知が送られると、構成ステータスによりSUCCESSステータスが戻されます。
ファスト・スタート・フェイルオーバーを使用しない場合（5.5.5項「ファスト・スタート・フェイルオーバーの無効化」を参照）、またはオブザーバを別のホスト・マシンに移動する場合は（5.5.7.5項「オブザーバの別のコンピュータへの移動」を参照）、オブザーバを停止できます。
ファスト・スタート・フェイルオーバーが有効化されているときにオブザーバを停止するには、プライマリ・データベースおよびターゲット・スタンバイ・データベースが接続されており、相互に通信している必要があります。オブザーバを停止しても、ファスト・スタート・フェイルオーバーは無効化されません。ただし、ターゲット・スタンバイ・データベースが監視されない状態の場合、ファスト・スタート・フェイルオーバーは実行できません。
ファスト・スタート・フェイルオーバーが有効化されていない場合にオブザーバを停止するには、プライマリ・データベースが動作している必要があります。プライマリ・データベースとネットワークで接続されたブローカ構成内のデータベースに接続しているときは、次の方法でオブザーバを停止できます。
Enterprise Managerの使用
ファスト・スタート・フェイルオーバー・ウィザードの1ページ目で「オブザーバを停止」オプションを選択し、ページ下部の「続行」をクリックします。詳細は、Enterprise Managerのオンライン・ヘルプ・システムを参照してください。
DGMGRLの使用
次のコマンドを発行します。
DGMGRL> STOP OBSERVER;
詳細は、STOP OBSERVERコマンドを参照してください。
|
注意: オブザーバは、STOP OBSERVERコマンドを発行してすぐには停止しません。ブローカがSTOP OBSERVER要求を受け取った場合、次回オブザーバがブローカと通信する際にオブザーバに通知します。 |
オブザーバを別のコンピュータに移動する手順は、次のとおりです。
オブザーバを移動する際にファスト・スタート・フェイルオーバーを無効化する必要はありません。
オブザーバでは、オブザーバを起動した作業ディレクトリに作成されているバイナリ・ファイルで、ファスト・スタート・フェイルオーバー構成に関する情報が永続的にメンテナンスされます。デフォルトでは、オブザーバの起動時に、現行の作業ディレクトリにこのファイルが作成され、fsfo.datという名前が付けられます。このファイルには、プライマリ・データベースおよびターゲット・スタンバイ・データベースの両方に対する接続識別子が含まれます。
権限のないユーザーはこのファイルを読めないことを確認します。
オブザーバの起動後は、ファイルの名前および場所を変更できません。ただし、オブザーバの起動にDGMGRLのSTART OBSERVERコマンドを使用し、FILE修飾子を含める場合は、ファイルの名前または場所を変更できます。詳細は、START OBSERVERコマンドを参照してください。
|
注意: オブザーバが通常と異なる方法で（CTRL/Cを入力するなど）停止された場合、オブザーバを再起動し、FILE修飾子を含む既存のfsfo.datファイルを参照してください。 |
1つのOracleホームを使用して複数のオブザーバを起動し、各オブザーバで異なるファスト・スタート・フェイルオーバー構成を監視する場合は、FILE修飾子を使用して、監視する各構成に一意のオブザーバ構成ファイルの場所を指定してください。オブザーバが生成するロギングを取得する場合は、LOGFILEオプションを使用し、一意のファイル名を指定してください。次に例を示します。
% dgmgrl -logfile $ORACLE_HOME/rdbms/log/config1.log DGMGRL> CONNECT /@primary1; DGMGRL> START OBSERVER FILE=$ORACLE_HOME/dbs/config1.dat; % dgmgrl -logfile $ORACLE_HOME/rdbms/log/config2.log DGMGRL> CONNECT /@primary2; DGMGRL> START OBSERVER FILE=$ORACLE_HOME/dbs/config2.dat;
FastStartFailoverAutoReinstate構成プロパティをTRUEに設定すると、プライマリ・データベースがクラッシュするか、オブザーバおよびターゲット・スタンバイ・データベースとの接続が失われたことが原因でファスト・スタート・フェイルオーバーが開始された場合、オブザーバは元のプライマリ・データベースのスタンバイ・データベースとしての回復を自動的に試行します。回復により、ブローカ構成に対する高可用性がリストアされるため、新規プライマリ・データベースに障害が発生した場合に、別のファスト・スタート・フェイルオーバーが実行されます。回復されたデータベースは、新規プライマリ・データベースのファスト・スタート・フェイルオーバーのターゲットとして機能し、後続のファスト・スタート・フェイルオーバーが可能になります。新規スタンバイ・データベースは、新規プライマリ・データベースからのREDOデータの受信を開始した時点で、フェイルオーバーの実行可能なターゲットとなります。
オブザーバによる元のプライマリ・データベースの自動回復を可能にするには、データベースを起動およびマウントする必要がありますが、オープンしないでください。ブローカは、データベースを新しいプライマリ・データベースのスタンバイ・データベース（元のスタンバイと同じタイプ）として回復します。
元のプライマリ・データベースが自動的に回復されない場合、DGMGRLのREINSTATEコマンドまたはEnterprise Managerを使用して手動で回復できます。手動回復の段階的な手順は、5.4.3項を参照してください。
回復がサポートされるのは、ブローカ構成でフェイルオーバーを実行した後に限られます。また、プライマリ・データベースおよびターゲット・スタンバイ・データベースの両方でフラッシュバック・データベースを有効化する必要があります。すべてのファスト・スタート・フェイルオーバーおよび回復の要件の詳細は、5.5.1項を参照してください。
次の場合、ブローカでは元のプライマリ・データベースを自動的に回復できません。
ユーザーが構成可能な条件が検出されたためにファスト・スタート・フェイルオーバーが発生した場合、またはDBMS_DG.INITIATE_FS_FAILOVER関数をコールしてアプリケーションで要求した場合
FastStartFailoverAutoReinstateがFALSEに設定されている場合
ファスト・スタート・フェイルオーバーの完了後、元のプライマリ・データベースが再起動されるまでに別のフェイルオーバーまたはスイッチオーバーが発生した場合
ファスト・スタート・フェイルオーバーが無効化されている場合
オブザーバが元のプライマリ・データベースに接続できない場合
元のプライマリ・データベースが新規プライマリ・データベースに接続できない場合
元のプライマリ・データベースおよび新規プライマリ・データベースが、同じファスト・スタート・フェイルオーバー環境内で構成されていない場合
ファスト・スタート・フェイルオーバーが無効化されているとき、手動フェイルオーバーによって元のプライマリ・データベースが無効化された場合
|
注意: スイッチオーバー、手動フェイルオーバーまたはファスト・スタート・フェイルオーバーの実行時にスタンバイ・データベースを無効した場合は、自動的に回復されません。 |
自動回復に失敗した場合、ブローカによりエラーがログに記録され、元のプライマリ・データベースはマウントされた状態のままとなります。この時点で、次のいずれかを実行できます。
