この章では、ブローカによるスイッチオーバーおよびフェイルオーバー中のデータベース管理について説明します。内容は次のとおりです。
Oracleデータベースは、プライマリまたはスタンバイという2つのロールのいずれかで動作します。Data Guardにより、スイッチオーバーまたはフェイルオーバーのいずれかを使用してデータベースのロールを変更できます。
スイッチオーバーは、プライマリ・データベースとそのいずれかのスタンバイ・データベース間のロール・リバーサルです。スイッチオーバーでは、データの消失がないことが保証され、通常は予定されたプライマリ・システムのメンテナンスの際に実行されます。スイッチオーバー中は、プライマリ・データベースがスタンバイ・ロールに遷移し、スタンバイ・データベースがプライマリ・ロールに遷移します。
フェイルオーバーは、プライマリ・データベース(Oracle RACプライマリ・データベースのすべてのインスタンス)に障害が発生するかアクセス不能になり、いずれかのスタンバイ・データベースが遷移してプライマリ・ロールを引き継ぐときに実行されます。フェイルオーバーでは、フェイルオーバー時に有効な保護モードによって、データが消失する場合としない場合があります。
ブローカを使用しない場合、ロール遷移を実行するには、一連のSQL文を発行します(『Oracle Data Guard概要および管理』を参照)。ブローカでは、Oracle Enterprise Managerでキーを1回クリックするか、DGMGRLコマンドライン・インタフェースで単一のコマンドを使用してスイッチオーバーおよびフェイルオーバーを起動できるため(このマニュアルでは手動フェイルオーバーと呼びます)、これらの操作が簡素化されます。また、ファスト・スタート・フェイルオーバーを有効化すると、ファスト・スタート・フェイルオーバーの条件が満たされたときに自動的にフェイルオーバーが実行されます。ファスト・スタート・フェイルオーバーが有効化されている場合、ブローカによってフェイルオーバーの必要性が判断され、指定されたターゲット・スタンバイ・データベースへのフェイルオーバーが自動的に開始されます。DBAによる操作は不要です。
ファスト・スタート・フェイルオーバーにより、手動操作の必要性を少なくして可用性を高め、管理コストを削減できます。手動フェイルオーバーでは、フェイルオーバーを実行する正確なタイミングおよび対象となるターゲット・スタンバイ・データベースを管理できます。選択する方法に関係なく、ブローカによって構成内のすべてのデータベースのロール遷移が調整されます。
スイッチオーバーまたはフェイルオーバー後に次のプライマリ・データベースにするスタンバイ・データベースを選択する際には、多数の考慮事項があります。Data Guard構成を構築する際には、フィジカル・スタンバイ、ロジカル・スタンバイおよびスナップショット・スタンバイの各特性、スタンバイ・データベース・サイトに対するネットワーク待機時間、将来のプライマリ・データベース・サイトにおけるコンピューティング機能などの要素を含む、すべてのオプションを考慮する必要があります。
注意: スナップショット・スタンバイを、スイッチオーバーまたはファスト・スタート・フェイルオーバー操作のターゲットにすることはできません。ただし、スナップショット・スタンバイへの手動フェイルオーバーは実行できます。 |
スイッチオーバーについては、すべての要素を理解することで、新規プライマリ・データベースとみなすスタンバイ・データベースを簡単に選択できます。フェイルオーバーが必要な障害が発生した場合、障害のあるプライマリ・データベースのアクティビティを再開するのに最適なスタンバイ・データベースは、スイッチオーバーの場合よりも絞られる可能性があります。次の各項では、ターゲット・スタンバイ・データベースの選択に役立つガイドラインを示します。
注意: ファスト・スタート・フェイルオーバーの場合、使用するターゲット・スタンバイ・データベースを事前に選択する必要があります。ファスト・スタート・フェイルオーバーの詳細は、5.5項を参照してください。 |
スタンバイ・データベースがすべて同じタイプである(すべてフィジカルまたはすべてロジカル・スタンバイ・データベース)構成内でスイッチオーバーを実行する場合、未適用のREDOの数が最も少ないスタンバイ・データベースを選択します。未適用のREDOの数が最も少ないスタンバイ・データベースを選択することで、スイッチオーバー操作が完了するまでの全体の所要時間を最小限にできます。次に例を示します。
DGMGRLを使用する場合、構成内にある各スタンバイ・データベースのSHOW DATABASE
出力のApply Lag行を調査します。
Enterprise Managerを使用する場合は、Data Guardの概要ページの
セクションで、各スタンバイ・データベースの「スタンバイ・データベース」
ApplyLag
列の値を表示できます。
構成にフィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データベースの両方が含まれる場合、ターゲット・スタンバイ・データベースとして(未適用REDOの数が最も少ない)フィジカル・スタンバイ・データベースを選択することを考慮します。スイッチオーバー操作の完了後は、構成内のすべてのデータベースが新規プライマリ・データベースに対するスタンバイ・データベースとして使用可能になるため、フィジカル・スタンバイ・データベースへのスイッチオーバーをお薦めします。一方、ロジカル・スタンバイ・データベースにスイッチオーバーすると、構成内のフィジカルおよびスナップショット・スタンバイ・データベースがすべて無効化されます。そのため、フィジカル・スタンバイ・データベースを再有効化するには、新規プライマリ・データベースのコピーからフィジカル・スタンバイ・データベースを再作成する必要があります。
スナップショット・スタンバイ・データベースへのスイッチオーバーを実行するには、最初にフィジカル・スタンバイ・データベースに戻す必要があります。
注意: Data Guard構成が最大保護モードで動作している場合、ブローカではロジカル・スタンバイ・データベースへのスイッチオーバーが許可されません。ロジカル・スタンバイ・データベースへのスイッチオーバーを実行するには、構成が最大可用性モードまたは最大パフォーマンス・モードのいずれかで動作している必要があります。 |
フェイルオーバーを実行するとき、構成内のスタンバイがすべて同じタイプである場合は、最も転送ラグの小さいスタンバイ・データベースを選択します。これにより、データの消失量を最小限に抑え、場合によってはデータの消失をゼロにすることができます。
構成にフィジカル・スタンバイ・データベース、スナップショット・スタンバイ・データベースおよびロジカル・スタンバイ・データベースが含まれる場合、ターゲット・スタンバイ・データベースとしてフィジカル・スタンバイ・データベースを選択することを考慮します。フェイルオーバー操作の完了後は、構成内のすべてのスタンバイ・データベースが新規プライマリ・データベースに対するスタンバイ・データベースとして使用可能になる可能性が高いため、フィジカル・スタンバイ・データベースへのフェイルオーバーをお薦めします。
スナップショット・スタンバイ・データベースにフェイルオーバーすることもできます。ただし、スナップショット・スタンバイ・データベースにフェイルオーバーするには、ブローカがこのデータベースを最初にフィジカル・スタンバイ・データベースに戻す必要があるため、時間がかかります。変換した後、ブローカは、プライマリ・ロールへのデータベースのフェイルオーバーを実行する前に、REDO Applyを起動して累積REDOデータを適用します。スナップショット・スタンバイ・データベースをフィジカル・スタンバイ・データベースに変換してからフェイルオーバーが実行されるため、フェイルオーバー操作の完了後、構成内のすべてのスタンバイ・データベースを新しいプライマリ・データベースへのスタンバイ・データベースとして使用することが可能になります。
ロジカル・スタンバイ・データベースにフェイルオーバーするには、フェイルオーバーの完了後に、新しいプライマリ・データベースのコピーからすべてのフィジカルおよびスナップショット・スタンバイ・データベースを再作成する必要があります。さらに、ロジカル・スタンバイ・データベースには、プライマリ・データベースに存在するデータのサブセットのみが含まれる可能性があります。(たとえば、プライマリ・データベース上で実行されるデータベース操作のうちロジカル・スタンバイ・データベースに適用しない操作を指定する際に、DBMS_LOGSTDBY.SKIP
プロシージャが使用された場合など。)
ただし、例外として、ターゲット・スタンバイ・データベースとしてフィジカル・スタンバイ・データベースを選択することをお薦めできない場合があります。たとえば、フィジカル・スタンバイ・データベースもすべて利用できない場合は、ロジカル・スタンバイ・データベースへのフェイルオーバーが唯一の選択肢となります。
データベースは、プライマリ・ロールからスタンバイ・ロール、またはスタンバイ・ロールからプライマリ・ロールに切り替えることができます。この操作は、データを消失させることなく、指定したスタンバイ・データベースがプライマリ・データベースになり、元のプライマリ・データベースがスタンバイ・データベースになるため、データベースのスイッチオーバーと呼ばれます。
可能な場合は必ず、フィジカル・スタンバイ・データベースに対してスイッチオーバーしてください。
スイッチオーバーによりフィジカル・スタンバイ・データベースをプライマリ・ロールに遷移する場合、次のようになります。
元のプライマリ・データベースはフィジカル・スタンバイ・ロールに切り替えられます。
オンラインREDOログ・ファイルは、新しいプライマリ・データベースから構成内のすべてのスタンバイ・データベースに継続的にアーカイブされます。
スイッチオーバー操作の一部として、元のプライマリ・データベースが再起動されます。新しいプライマリ・データベースを再起動する必要がないことに注意してください。
スイッチオーバーに関係しないスタンバイ・データベース(その他のスタンバイ・データベース)は、スイッチオーバーが発生する前の状態で引き続き動作し、新しいプライマリ・データベースから受け取ったREDOデータの適用を自動的に開始します。
スイッチオーバーによりロジカル・スタンバイ・データベースをプライマリ・ロールに遷移する場合、次のようになります。
元のプライマリ・データベースはロジカル・スタンバイ・ロールに切り替えられます。
スイッチオーバーの完了後、プライマリ・データベースおよびロジカル・スタンバイ・データベースのどちらも再起動の必要はありません。
ブローカ構成内の他のロジカル・スタンバイ・データベースは、スイッチオーバー後も実行可能です。どのデータベースも再起動する必要はありません。ロジカル・スタンバイ・データベースへのスイッチオーバーの後、すべてのフィジカルおよびスナップショット・スタンバイ・データベースは無効化されるため、新しいプライマリ・データベースのコピーから再作成する必要があります。
構成が最大保護モードで動作している場合、ロジカル・スタンバイ・データベースへのスイッチオーバーは許可されません。
警告: ロジカル・スタンバイ・データベースにスイッチオーバーすると、ブローカ構成内のスナップショット・スタンバイ・データベースとフィジカル・スタンバイ・データベースはブローカにより無効化され、これらのデータベースはスタンバイ・データベースとして実行できなくなります。スタンバイ・データベースとして実行可能な状態にリストアする方法は、5.4.3項を参照してください。 比較的すぐに元のプライマリ・データベースにスイッチバックする場合は、フィジカルおよびスナップショット・スタンバイ・データベースを無効なままにしておくことができます。フィジカルおよびスナップショット・スタンバイ・データベースはまだ元のプライマリ・データベースの実行可能なスタンバイ・データベースであるため、元のプライマリ・データベースへのスイッチバックの完了後、これらを再有効化できます。 |
スイッチオーバーを開始する前に、次の点を考慮してください。
スイッチオーバーを開始すると、ブローカは、スイッチオーバーの完了後に少なくとも1つのスタンバイ・データベース(スタンバイ・ロールに遷移する予定のプライマリ・データベースも含む)が、全体の保護モード(最大保護、最大可用性または最大パフォーマンス)をサポートするように構成されているかどうかを検証します。
全体の保護モードとの関連で、将来考えられるスタンバイ・データベースとしてのロールに備えて、あらかじめプライマリ・データベースを準備しておきます(4.6項を参照してください)。こうした準備には、次の操作が含まれます。
プライマリ・データベースでスタンバイREDOログ・ファイルが構成されていることを確認します。
LogXptMode
、NetTimeout
、StandbyArchiveLocation
およびAlternateLocation
など、REDO転送サービス関連のデータベース・プロパティをあらかじめ設定します。データベース・プロパティを使用したREDO転送サービスの管理の詳細は、4.4項を参照してください。
DelayMins
など、REDO Applyサービス関連のデータベース・プロパティをあらかじめ設定します。プロパティを使用したREDO Applyサービスの管理の詳細は、4.5項を参照してください。
一時表ごとに、プライマリ・データベース上の一時表に関連付けられた一時ファイルがスタンバイ・データベースにも存在することを確認します。
これらのプロパティは、実際にプライマリ・データベースをスタンバイ・ロールに切り替えるまで、ブローカによってREDO転送サービスとREDO Applyサービスの設定に使用されないことに注意してください。そのため、これらのプロパティの値の妥当性は、スイッチオーバー後まで検証されません。これらのプロパティを設定すると、その値はスイッチオーバーおよびフェイルオーバー時のロール変更を通じて存続します。
リアルタイム問合せモードにあるフィジカル・スタンバイ・データベースへのスイッチオーバーを実行する前に、できるだけ迅速に、クリーンにロール・トランジションを実施させるために、そのスタンバイ・データベースのすべてのインスタンスを、マウント済だがオープンされていない状態にすることを検討します。
最大可用性モードまたは最大パフォーマンス・モードのいずれかでファスト・スタート・フェイルオーバーが有効化されている場合、スイッチオーバーを実行できるのは、事前に指定されたターゲット・スタンバイ・データベースに対してのみであり、スタンバイ・データベースがプライマリ・データベースと同期化されている場合に限られます。ファスト・スタート・フェイルオーバーの有効化の詳細は、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つを残して、他のすべてのインスタンスを停止します。
フィジカル・スタンバイ・データベースへのスイッチオーバーを実行する場合、ブローカは、現在のプライマリ・データベース上のインスタンスのうち1つを残して他のすべてのインスタンスを停止します。ターゲット・フィジカル・スタンバイ・データベース上のインスタンスは停止されません。
ロジカル・スタンバイ・データベースへのスイッチオーバーの場合は、インスタンスを停止しません。スナップショット・スタンバイ・データベースにスイッチオーバーすることはできません。
プライマリ・データベースとスタンバイ・データベースの間でロールを切り替えます。
ブローカは最初に、元のプライマリ・データベースを変換してスタンバイ・ロールで実行するようにします。次に、ターゲットのスタンバイ・データベースをプライマリ・ロールに遷移させます。いずれかの変換時にエラーが発生すると、ブローカはスイッチオーバーを停止します。詳細は、9.3項「スイッチオーバー操作時の問題のトラブルシューティング」を参照してください。
ブローカ構成ファイルを更新し、ロールの変更を記録します。
構成ファイルには構成内のデータベース・オブジェクトがすべて記述されるため、なんらかの原因で後から再起動された場合にも、各データベースが確実に適切なロールおよび状態で動作します。
フィジカル・スタンバイ・データベースへのスイッチオーバーを行った場合は新しいスタンバイ・データベース(元のプライマリ・データベース)を再起動すると、REDO Applyが新しいプライマリ・データベースからのREDOデータの適用を開始します。Oracle RACのフィジカル・スタンバイ・データベースの場合は、ブローカの指示により、Oracle Clusterwareがスイッチオーバーの前に停止されたインスタンスを再起動します。最大保護モードで動作している構成では、新しいプライマリ・データベースも再起動されます。
新しいプライマリ・データベースが読取り/書込みモードでオープンし、REDO転送サービスが開始します。
リアルタイム問合せが有効な状態で元のフィジカル・スタンバイ・データベースが実行されていた場合、新しいフィジカル・スタンバイ・データベースはリアルタイム問合せが有効な状態で実行されます。
ブローカは各データベースの状態とステータスを検証し、スイッチオーバーによって、各データベースが新しいロールにそれぞれ正常に遷移していることを確認します。スイッチオーバー後にブローカにより無効化されていないその他のスタンバイ・データベースは、スイッチオーバー前の状態で引き続き動作します。他のすべてのその他のスタンバイ・データベースに対するREDO ApplyおよびSQL Applyは、新しいプライマリ・データベースから受け取ったREDOデータの適用を自動的に開始します。
元のプライマリ・データベースで障害が発生し、プライマリ・データベースを適時にリカバリできる可能性がない場合は、スタンバイ・データベースをプライマリ・データベースに変換できます。これは手動フェイルオーバーと呼ばれます。プライマリ・データベースに障害が発生した時点でプライマリ・データベースとターゲット・スタンバイ・データベースが同期化されていたかどうかによって、データが消失する場合があります。手動という用語は、このタイプのフェイルオーバーとファスト・スタート・フェイルオーバー(5.5項を参照)を比較する目的で使用します。
次の各項では、手動フェイルオーバーの実行方法について説明します。
Enterprise ManagerまたはDGMGRLを使用して、完全フェイルオーバー(推奨)または即時フェイルオーバーを実行できます。
完全フェイルオーバーは、推奨方法でありデフォルトのフェイルオーバー・オプションです。完全フェイルオーバーでは、構成が動作している保護モードに応じて最大量のREDOデータが自動的にリカバリされます。また、フェイルオーバーのターゲットではないスタンバイ・データベースの無効化をできるかぎり回避して、新しいプライマリ・データベースに対するスタンバイ・データベースとして機能し続けられるようにします。
フェイルオーバーのターゲットではないスタンバイ・データベース(その他のスタンバイ・データベース)を無効にするか否かは、フェイルオーバーのターゲットと比較して、ターゲットでないスタンバイに適用されたREDOデータの量、およびフェイルオーバー・ターゲットのスタンバイ・タイプに応じて異なります。
フェイルオーバーのターゲットがフィジカルまたはスナップショット・スタンバイ・データベースの場合、新しいプライマリ・データベースのスタンバイ・データベースにするには、元のプライマリ・データベースを回復または再作成する必要があります。また、一部のスタンバイ・データベースで新規プライマリ・データベースによる適用を超えてREDOを適用したことが検出された場合、ブローカはそれらのデータベースをフェイルオーバー中に無効化する場合があります。ブローカにより無効化されたデータベースは、新しいプライマリ・データベースのスタンバイ・データベースにする前に、5.4.3項で説明する手順に従って回復または再作成する必要があります。
スナップショット・スタンバイ・データベースでフェイルオーバーを実行した場合は、元のプライマリをフィジカル・スタンバイ・データベースとして回復または再作成する必要があることに注意してください。
フェイルオーバーのターゲットがロジカル・スタンバイ・データベースである場合、元のプライマリ・データベースおよび構成内のすべてのフィジカルおよびスナップショット・スタンバイ・データベースが無効化されます。フラッシュバック・データベースが有効化されている場合、プライマリ・データベースを回復できます。フィジカルおよびスナップショット・スタンバイ・データベースは、新規プライマリ・データベースのコピーから再作成する必要があります。詳細は、5.4.3項を参照してください。
プライマリ・データベースをマウントできる場合は、ALTER SYSTEM FLUSH REDO
SQL文を使用して、プライマリ・データベースからターゲット・スタンバイ・データベースへの未送信REDOデータをすべてフラッシュできます。この操作が正常に完了すると、プライマリ・データベースがデータ消失ゼロの保護モードでなくても、データ消失がゼロのフェイルオーバーが可能になります。ALTER SYSTEM FLUSH REDO文の使用の詳細は、『Oracle Data Guard概要および管理』を参照してください。
完全フェイルオーバー中は、5.4.2.1項に示すフェイルオーバー手順がブローカによって実行されます。
即時フェイルオーバーは、最も高速なタイプのフェイルオーバーです。ただし、フェイルオーバーの起動後は、スタンバイ・データベースに追加データが適用されません。即時フェイルオーバーを実行した場合は、構成内の他のすべてのデータベースが無効化されます。新規プライマリ・データベースのスタンバイ・データベースとして機能させるには、これらのデータベースを回復または再作成する必要があります。この方法については、5.4.3項を参照してください。即時フェイルオーバー中は、5.4.2.2項に示すフェイルオーバー手順がブローカによって実行されます。
注意: ORA-752 またはORA-600 [3020] エラーにより、フェイルオーバー・ターゲットでREDO Applyが停止されていないかぎり、常に完全フェイルオーバーを最初に実行するようにします。これらのエラーのいずれかが発生した場合は、先に進む前に、My Oracle Supportノート1265884.1のスタンバイ・リカバリ時のORA-752またはORA-600 [3020]の解決のガイドラインに従います。このサポート・ノートは、http://support.oracle.com にあります。
即時フェイルオーバーは、完全フェイルオーバーが失敗するか、前述のケースにのみ実行してください。完全フェイルオーバーは、REDO転送サービスの宛先属性に応じて、データ損失なしで実行できますが、即時フェイルオーバーでは、通常データ損失が発生します。 |
プライマリ・データベースを適時リカバリできる可能性がないと判断した場合は、プライマリ・データベースが停止していることを確認し、フェイルオーバー操作を開始します。
この項の各手順では、手動フェイルオーバーの実行方法について説明します。フェイルオーバーおよび関係するスタンバイ・データベースのタイプによって、一部のデータベースの回復または再作成が必要となる場合があります。状況のタイプごとに対応する手順を順を追って説明します。
5.2項「ターゲット・スタンバイ・データベースの選択」に示したガイドラインに従います。
Enterprise ManagerまたはDGMGRLを使用して、完全フェイルオーバー(推奨)または即時フェイルオーバーを実行します。
Enterprise Managerを使用した手動フェイルオーバー
Enterprise ManagerのData Guardの概要ページで、プライマリ・ロールに変更するスタンバイ・データベースを選択して「フェイルオーバー」をクリックします。その後、フェイルオーバーの確認ページで「はい」をクリックし、デフォルトの「完全」フェイルオーバー・オプションを起動します。
DGMGRLを使用した手動フェイルオーバー
ターゲット・スタンバイ・データベースで、FAILOVER
コマンドを発行してフェイルオーバーを実行し、プライマリ・データベースにするスタンバイ・データベースの名前を指定します。
DGMGRL> FAILOVER TO database-name;
次のいずれかの条件に当てはまる場合は、オプションのIMMEDIATE
句を指定して、即時フェイルオーバーを実行します。
ORA-752
エラーがスタンバイ・データベースで発生した場合
ORA-600
[3020]
エラーがスタンバイ・データベースで発生し、その原因がプライマリ・データベースでの書込み欠落であるとOracleサポートが判断した場合
完全フェイルオーバーが不可能な場合
DGMGRL> FAILOVER TO database-name IMMEDIATE;
ターゲットがスナップショット・スタンバイ・データベースの場合、ブローカは、最初にデータベースをフィジカル・スタンバイ・データベースに変換します。完全フェイルオーバーを実行する場合、すべての累積REDOデータが適用されてから、データベースのロールがプライマリに変更されます。即時フェイルオーバーを実行する場合、累積REDOデータは適用されずに、データベースのロールがプライマリに変更されます。
フィジカルまたはロジカル・スタンバイ・データベースにフェイルオーバーする場合は、インスタンスを停止しません。
手動フェイルオーバー(完全または即時)の後、全体のData Guard保護モードは次のように処理されます。
保護モードが最大保護だった場合は、最大パフォーマンスにリセットされます。その後、必要な場合は、4.6.1項の説明に従って保護モードをアップグレードできます。
保護モードが最大可用性または最大パフォーマンスだった場合は、変更されません。
注意: ファスト・スタート・フェイルオーバーが有効化されている場合に手動フェイルオーバーを実行すると、次のようになります。
|
他の障害が発生した場合に実行可能な障害時リカバリ・ソリューションを維持するには、5.4.3項で説明する追加手順を実行し、次の操作を行う必要があります。
元のプライマリ・データベースを回復し、新規構成のスタンバイ・データベースとして機能させます。
注意: ORA-752 またはORA-600 [3020] エラーがフェイルオーバー・ターゲットで発生した場合に、古いプライマリ・データベースを回復しようとすると、データ損失が発生する場合があるため、回復操作は行わないでください。かわりに、5.4.3.2項で説明されている手順に従い、古いプライマリ・データベースを新しいプライマリのバックアップからスタンバイとして再作成する必要があります。 |
ブローカによって無効化された構成内のスタンバイ・データベースを回復または再作成します。
完全フェイルオーバーが完了すると、新しいプライマリ・データベースのスタンバイとして実行可能でないその他のスタンバイ・データベースは、ブローカにより無効化されます。これは次のいずれかの理由で実行されます。
その他のスタンバイ・データベースに、新しいプライマリ・データベースがスタンバイ・データベースであったときに適用されたよりも多くのREDOデータが適用された場合。新しいプライマリ・データベースのスタンバイとして機能させるには、このスタンバイ・データベースを再作成または回復する必要があります。
ロジカル・スタンバイ・データベースにフェイルオーバーした場合。構成内のすべてのフィジカルおよびスナップショット・スタンバイ・データベースがブローカにより無効化されます。新しいプライマリ・データベースのスタンバイとして機能させるには、これらを再作成する必要があります。
完全フェイルオーバーを開始すると、ブローカは次の作業を実行します。
ターゲット・スタンバイ・データベースが有効化されていることを確認します。データベースが有効化されていない場合、このデータベースに対するフェイルオーバーは実行できません。
ターゲットのスタンバイ・データベースで未適用のREDOデータの適用が完了するまで待機し、適用が完了した後でREDO Apply(ターゲットがフィジカル・スタンバイ・データベースの場合)またはSQL Apply(ターゲットがロジカル・スタンバイ・データベースの場合)を停止します。
ターゲットがスナップショット・スタンバイ・データベースの場合、ブローカは、最初にデータベースをフィジカル・スタンバイに戻し、次にREDO Applyを起動してすべての累積REDOを適用してから、フェイルオーバーを完了してデータベースをプライマリ・データベースとしてオープンします。
ターゲット・スタンバイ・データベースを、次のように、プライマリ・データベース・ロールに遷移させます。
データベースのロールをスタンバイからプライマリに変更します。
新しいプライマリ・データベースを読取り/書込みモードでオープンします。
フェイルオーバー操作に関係しなかったスタンバイ・データベースを、新しいプライマリ・データベースより多くのREDOデータが適用されたために無効化する必要があるかどうかを判断します。
このフェイルオーバー中に、その他のスタンバイ・データベースがブローカにより無効化されない場合は、フェイルオーバー前と同じ状態のままになります。たとえば、APPLY-OFF
状態であったフィジカル・スタンバイ・データベースは、APPLY-OFF
状態のままになります。
デフォルトでは、ブローカは、完全フェイルオーバーを実行するたびにその他のスタンバイ・データベースが新しいプライマリに対する実行可能なスタンバイ・データベースであるかどうかを判別します。完全フェイルオーバーの実行時に、その他のスタンバイ・データベースの実行可能性のチェックをスキップして、全フェイルオーバー時間を短縮するには、BystandersFollowRoleChange
構成プロパティをNONE
に設定してください。
このプロパティをNONE
に設定すると、ブローカは、新しいプライマリ・データベースよりも多くのREDOデータが適用されているかどうかのチェックを実行せずに、その他のすべてのスタンバイ・データベースを無効にします。フェイルオーバーの完了後にスタンバイ・データベースを回復または再作成(5.4.3項を参照)する必要があります。SHOW CONFIGURATION
コマンドを使用して、回復可能なデータベースと再作成する必要のあるデータベースを表示します。このプロパティの値を表示するには、SHOW CONFIGURATION BystandersFollowRoleChange
コマンドを使用します。デフォルト値はALL
です。
このプロパティは、ファスト・スタート・フェイルオーバーの発生時にその他のスタンバイ・データベースの実行可能性チェックをスキップするかどうかにも影響を与えます。
REDO転送サービスを起動して、無効化されていないすべてのその他のスタンバイ・データベースへのREDOデータの転送を開始します。
Oracle RACのフィジカルまたはスナップショット・スタンバイ・データベースがフェイルオーバー・ターゲット・データベースである場合は、ブローカの指示により、Oracle Clusterwareがフェイルオーバーの前に停止されたインスタンスをすべて再起動します。
ブローカは、フェイルオーバーに関連して選択したスタンバイ・データベースにエラーがないかぎり、フェイルオーバーを続行します。その他のスタンバイ・データベースにエラーが発生しても、フェイルオーバーは停止されません。完全フェイルオーバーを開始して失敗した場合は、即時フェイルオーバーを使用する必要があります。
即時フェイルオーバーを開始すると、ブローカは次の作業を実行します。
ターゲット・スタンバイ・データベースが有効化されていることを確認します。スタンバイ・データベースがブローカによる管理に対応していない場合、フェイルオーバーは実行できません。
使用可能なREDOデータがすべて適用されるまで待機せずに、スタンバイ・データベースのREDO ApplyまたはSQL Applyを即時停止します。この作業によってデータが失われる可能性があります。
ターゲットのスタンバイ・データベースをプライマリ・ロールに遷移させ、新しいプライマリ・データベースを読取り/書込みモードでオープンし、REDO転送サービスを起動します。
即時フェイルオーバーが完了すると、構成内のすべてのスタンバイ・データベースはタイプに関係なく無効化されます。それらのデータベースでフラッシュバック・データベースが有効化されている場合、データベースは回復されます。それ以外の場合は、新しいプライマリ・データベースのコピーから再作成する必要があります。
ブローカは、フェイルオーバーに関係するように選択したスタンバイ・データベースにエラーがないかぎり、完全フェイルオーバーを続行します。
ブローカは、フェイルオーバーに関係するように選択したスタンバイ・データベースにエラーがあっても、即時フェイルオーバーを続行します。
ロジカル・スタンバイ・データベースへのスイッチオーバー後またはいずれかのスタンバイ・データベースへのフェイルオーバー後に元の障害時リカバリ・ソリューションをリストアするには、追加手順を実行する必要があります。
ロール遷移後に無効化されたデータベースは、ブローカ構成から削除されませんが、ブローカによって管理されなくなります。
これらのデータベースのブローカによる管理を再び有効化するには、次のいずれかの手順でデータベースを回復または再作成する必要があります。
データベースが回復可能な場合は、データベースで次のステータスが示されます。
ORA-16661: the standby database needs to be reinstated
データベースの回復方法に関する項の説明に従って、DGMGRLのREINSTATE DATABASE
コマンドまたはEnterprise Managerの回復オプションを使用してデータベースを回復します。 ブローカにより、データベースは回復処理の一部として再有効化されます。
新規プライマリ・データベースのコピーからデータベースを再作成する必要がある場合、データベースのステータスが次のようになります。
ORA-16795: the standby database needs to be re-created
プライマリ・データベースのコピーからスタンバイ・データベースを再作成し、再び有効化します。スタンバイ・データベースの作成手順は、『Oracle Data Guard概要および管理』を参照してください。詳細は、5.4.3.2項「無効化されたデータベースの再作成および再有効化の方法」を参照してください。
注意: 複数のロール変更が実行されたときに無効化されたデータベースは、回復できません。現在のプライマリ・データベースのコピーからデータベースを手動で再作成し、ブローカ構成でデータベースを再有効化する必要があります。 |
データベースを回復するか再作成するかは、スイッチオーバーとフェイルオーバーのどちらを実行したか、さらに操作のターゲットとなったスタンバイ・データベースのタイプに応じて決まります。ロジカルおよびスナップショット・スタンバイ・データベースにロール変更すると、常にその他のフィジカル・スタンバイ・データベースは無効化されることに注意してください。これらのデータベースは回復できません。新しいプライマリ・データベースのコピーから再作成する必要があります。
次の各項では、データベースの回復または再有効化方法を説明します。
ブローカの回復機能を使用して、障害が発生したしたプライマリ・データベースを新しいプライマリ・データベースの実行可能なスタンバイ・データベースにすることができます。この処理は、フェイルオーバーがフィジカル、ロジカルまたはスナップショット・スタンバイ・データベースのいずれに実行されたかに関係なく行うことができます。
フェイルオーバー操作中に無効化されたその他のスタンバイ・データベースも回復できます。
回復可能なデータベースは、ステータス値が次のようになります。
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;
新しく回復したスタンバイ・データベースは、新規プライマリ・データベースのスタンバイ・データベースとして機能し始めます。データベースの回復に失敗した場合、ステータスは「ORA-16795: スタンバイ・データベースを再作成する必要があります
」に変更されます。この場合、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.5.2項を参照してください。 |
図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
として接続しており、ブローカ構成でプライマリ・データベースおよびスタンバイ・データベースがすでに設定されていることを前提としています。
5.2項「ターゲット・スタンバイ・データベースの選択」に示したガイドラインに従います。
現行のプライマリ・データベースのFastStartFailoverTarget
構成プロパティを設定する場合、ターゲット・スタンバイ・データベースを1つのみ指定できます。
構成内のスタンバイ・データベースが1つのみである場合、この手順をスキップして手順3に進みます。ファスト・スタート・フェイルオーバーを有効化する際、ブローカにより、プライマリ・データベースおよびスタンバイ・データベースのFastStartFailoverTarget
プロパティが、フェイルオーバー時にお互いをそれぞれのターゲットとして指すように自動的に設定されます。
構成内に複数のスタンバイ・データベースがある場合、プライマリ・データベースでFastStartFailoverTarget
プロパティを明示的に設定して、ターゲット・スタンバイ・データベースを選択する必要があります。ファスト・スタート・フェイルオーバーを有効化する際、ブローカによりこのプロパティが既存のスタンバイ・データベースを指していることが確認され、今度は反対にこのスタンバイ・データベースのFastStartFailoverTarget
プロパティがプライマリ・データベースを指すように設定されます。
注意: FastStartFailoverTarget プロパティを変更して別のスタンバイ・データベースを指すようにするには、ファスト・スタート・フェイルオーバーを無効化し、FastStartFailoverTarget プロパティを設定し、さらにファスト・スタート・フェイルオーバーを再有効化してください。 |
このプロパティの詳細は、8.3.10項「FastStartFailoverTarget」を参照してください。
ファスト・スタート・フェイルオーバーは、最大可用性モードまた最大パフォーマンス・モードに対して有効化できます。いかなるデータの消失も許容できない場合は、構成の保護モードが最大可用性に設定されていることを確認してください。それには、プライマリ・データベースとターゲット・スタンバイ・データベースの両方でデータベース・プロパティLogXptMode
がSYNC
に設定されている必要があります。その後、構成保護モードを最大可用性に設定してください。次に例を示します。
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;
わずかなデータの消失よりもプライマリ・データベースのパフォーマンスを重視する場合は、構成の保護モードを最大パフォーマンスに設定してファスト・スタート・フェイルオーバーを有効化することを検討してください。このモードでは、どれだけのデータ消失を許容できるかを秒単位で検討し、それに従ってFastStartFailoverLagLimit
構成プロパティを設定する必要があります。このプロパティは、REDO適用に関してターゲット・スタンバイ・データベースがプライマリ・データベースから遅れることができるデータ量を秒単位で指定します。スタンバイ・データベースでREDOが適用された時点がプライマリ・データベースのREDO生成時点からその秒数以内であれば、ファスト・スタート・フェイルオーバーが許可されます。FastStartFailoverLagLimit
構成プロパティは、最大パフォーマンス・モードで動作している構成のファスト・スタート・フェイルオーバーが有効化されている場合にのみブローカによって使用されます。デフォルト値は30秒で、設定できる最小値は10秒です。
構成の保護モードを最大パフォーマンスに設定することに加えて、プライマリ・データベースとターゲットスタンバイ・データベースの両方でデータベース・プロパティ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;
オブザーバおよびターゲット・スタンバイ・データベースの両方で、FastStartFailoverThreshold
構成プロパティで指定された時間にわたってプライマリ・データベースへの接続が失われた場合、ファスト・スタート・フェイルオーバーが実行されます。
FastStartFailoverThreshold
プロパティを設定し、(プライマリ・データベースが使用できないことが検出されてから)フェイルオーバーを開始するまでにオブザーバおよびターゲット・スタンバイ・データベースを待機させる秒数を指定します。次に例を示します。
DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverThreshold = 45;
FastStartFailoverThreshold
プロパティのデフォルト値は30秒で、設定できる最小値は6秒です。Oracle RACプライマリ・データベースが存在する場合、インスタンス障害が発生したときに誤ってフェイルオーバーが実行される可能性を最小限にするには、これより大きい値を指定することを考慮します。
この時間間隔は、オブザーバでプライマリ・データベースへの接続が最初に失われたときに開始されます。オブザーバが指定時間内にプライマリ・データベースへの接続を回復できない場合、スタンバイ・データベースがフェイルオーバー可能な状態であれば、オブザーバによりファスト・スタート・フェイルオーバーが開始されます。デフォルト値の30秒は、通常はほとんどの構成で停止および障害を検出できる値ですが、このプロパティでフェイルオーバーの感度を調整することで、一時的に不安定になった環境でフェイルオーバーが誤って実行される可能性を低くすることができます。
REDOの生成が停止し、プライマリ・データベースがオブザーバまたはターゲット・スタンバイ・データベースとの接続を再確立できない場合、FastStartFailoverPmyShutdown
構成プロパティがTRUE
に設定されていると、FastStartFailoverThreshold
の秒数が経過した後にプライマリ・データベースが停止します。
ファスト・スタート・フェイルオーバーが有効化されている場合でもFastStartFailoverThreshold
プロパティを変更できることに注意してください。
必要に応じて、次の表に示されているデータベース・プロパティを設定できます。
プロパティ名 | 説明 | デフォルト値 |
---|---|---|
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 プロパティの値を使用してプライマリおよびターゲット・スタンバイ・データベースに接続し、監視します。 |
デフォルトでは、構成された時間しきい値(FastStartFailoverThreshold
)の経過後にオブザーバもスタンバイもプライマリにアクセスできないと、ファスト・スタート・フェイルオーバーが実行されます。
必要に応じて、ファスト・スタート・フェイルオーバーを発生させるデータベース健全性条件を指定することができます。次の表に、これらの条件を示します。
健全性条件 | 説明 | デフォルトで有効化 |
---|---|---|
データファイル・オフライン | 書込みエラーのためにデータファイルがオフラインになりました。 | はい |
破損したディクショナリ | 重要なデータベース・オブジェクトのディクショナリが破損しました。現時点では、この状態は、データベースがオープンされている場合にのみ検出されます。 | はい |
破損した制御ファイル | ディスク障害のために制御ファイルが永続的に破損しました。 | はい |
アクセス不可能なログ・ファイル | I/OエラーのためにLGWRがログ・グループのどのメンバーにも書き込むことができません。 | いいえ |
スタック・アーカイバ | デバイスに空き容量がないかデバイスを使用できないためにアーカイバがREDOログをアーカイブできません。 | いいえ |
Oracle RAC構成では、アクセス不可能なログ・ファイルおよびスタック・アーカイバの健全性条件は、単一インスタンスにのみ適用できます。これらの条件によるファスト・スタート・フェイルオーバーは、Oracle Clusterwareによって提供される可用性オプションに優先して実行されるので、有効化する前によく検討してください。
Oracleサーバーで発生するエラー(ORAエラー)をファスト・スタート・フェイルオーバーが発生するための条件として指定することもできます。
Oracle Enterprise ManagerまたはDGMGRLのENABLE FAST_START FAILOVER CONDITION
コマンドおよびDISABLE FAST_START FAILOVER CONDITION
コマンドを使用して、ファスト・スタート・フェイルオーバーが実行される特定条件を指定することができます。
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.
注意: スタンバイ・データベースが事前の予告なしにプライマリ・ロールを引き継ぐ場合があるため、ターゲット・スタンバイ・サイトでの管理はプライマリ・サイトでの管理と同じくらい包括的である必要があります。スタッフ・サポート、ハードウェアとソフトウェア、セキュリティ(ソフトウェアとサイトの両方)、ネットワーク接続および帯域幅が両方のサイトで同等である必要があります。 |
オブザーバを起動するには、プライマリ・データベースが実行されている必要があります。
ファスト・スタート・フェイルオーバーを有効化する前または後にオブザーバを起動できます。ファスト・スタート・フェイルオーバーが有効化されている場合、オブザーバは、プライマリ・データベースおよびターゲット・スタンバイ・データベースのステータスおよび接続の監視をただちに開始します。ファスト・スタート・フェイルオーバーが有効化されていない場合、オブザーバは、ファスト・スタート・フェイルオーバーが有効化されるまで待機してから監視を開始します。
Enterprise Managerを使用したオブザーバの起動
Enterprise Managerエージェントがオブザーバ・コンピュータにインストールされている場合、Enterprise Managerを使用してファスト・スタート・フェイルオーバーを有効化すると、Enterprise Managerによりオブザーバが自動的に起動されます。エージェントが存在しない場合、DGMGRLコマンドライン・インタフェースに関する次の手順を実行して、オブザーバを手動で起動する必要があります。
DGMGRLを使用したオブザーバの起動
DGMGRLを使用してオブザーバを起動するには、オブザーバ・コンピュータで次のコマンドを発行します。
DGMGRL> START OBSERVER;
オブザーバはSTART OBSERVER
コマンドを発行したときに作成され、継続的に実行されるプロセスです。そのため、別のDGMGRLセッションからSTOP OBSERVER
コマンドを発行するまで、オブザーバ・コンピュータ上のコマンドライン・プロンプトは戻されません。コマンドを発行し、ブローカ構成と対話するには、別のDGMGRLクライアント・セッションにより接続する必要があります。
詳細は、START OBSERVERコマンドを参照してください。
ファスト・スタート・フェイルオーバー構成の準備が整っているかどうかを検証するには、プライマリ・データベースでDGMGRLのSHOW CONFIGURATION VERBOSE
コマンドまたはSHOW FAST_START FAILOVER
コマンドを発行します。次に例を示します。
DGMGRL> SHOW FAST_START FAILOVER; Fast-Start Failover: ENABLED Threshold: 60 seconds Target: South_Sales Observer: observer.example.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)
次の各項では、ファスト・スタート・フェイルオーバー環境の詳細を説明しています。
ファスト・スタート・フェイルオーバーを有効化してオブザーバを起動した後は、オブザーバが継続的に環境を監視してプライマリ・データベースが使用可能であることを確認します。この項では、オブザーバがファスト・スタート・フェイルオーバーの必要性を判別し、必要に応じてフェイルオーバーを実行するための手順をリストしています。
次の状況のように、プライマリ・データベースがクラッシュした場合、またはオブザーバとの接続が失われた場合、オブザーバはFastStartFailoverThreshold
構成プロパティで指定されている秒数を待機してから、ファスト・スタート・フェイルオーバーを試行します。
プライマリ・データベースと、オブザーバおよびターゲット・スタンバイ・データベースの両方との接続が失われた場合
単一インスタンスのプライマリ・データベース(Oracle RACまたは非Oracle RAC)、またはOracle RACプライマリ・データベースのすべてのインスタンスに障害が発生した場合、オブザーバがファスト・スタート・フェイルオーバーを試行します。
単一インスタンスのプライマリ・データベース(Oracle RACまたは非Oracle RAC)、またはOracle RACプライマリ・データベースのすべてのインスタンスがABORT
オプションにより停止された場合、オブザーバがファスト・スタート・フェイルオーバーを試行します。他のタイプのデータベース停止(NORMAL
、IMMEDIATE
、TRANSACTIONAL
)では、ファスト・スタート・フェイルオーバーは試行されません。
次の状況では、オブザーバはしきい値を超えるまで待機せずに、ファスト・スタート・フェイルオーバーを実行します。
ユーザーが構成可能な条件
オブザーバは、ユーザーが構成可能な条件が検出されたと判断すると、ファスト・スタート・フェイルオーバーを試行します。
DBMS_DG.INITIATE_FS_FAILOVER
のアプリケーション・コール
アプリケーションがこの機能をコールし、SUCCESS
ステータスを受け取ると、オブザーバがファスト・スタート・フェイルオーバーを試行します。
プライマリ・データベースに可用性の問題があることをオブザーバが検出した場合、オブザーバは通常、FastStartFailoverThreshold
構成プロパティに指定された時間内にプライマリ・データベースに再接続しようとします。FastStartFailoverThreshold
の時間間隔は、オブザーバがプライマリ・データベースに障害があることを最初に検出したときに開始されます。
ユーザーが構成可能な条件が発生したことをオブザーバが検出した場合、またはDBMS_DG.INITIATE_FS_FAILOVER
関数でファスト・スタート・フェイルオーバーを要求した場合、FastStartFailoverThreshold
プロパティに指定された時間間隔は無視されます。
プライマリ・データベースがOracle Real Application Clusters(Oracle RAC)データベースである場合、オブザーバは残りのプライマリ・インスタンスのいずれかに接続しようとします。Oracle RACプライマリ・データベースを構成するすべてのインスタンスに障害が発生したことが検出されていないかぎり、ファスト・スタート・フェイルオーバーは実行されません。オブザーバは、データベース・プロパティDGConnectIdentifier
またはObserverConnectIdentifier
に指定された値を使用して、プライマリ・データベースおよびファスト・スタート・フェイルオーバーのターゲット・スタンバイ・データベースに接続します。オブザーバは、これらのプロパティに指定された値を使用して、Oracle RACデータベースの任意のインスタンスに接続できる必要があります。
ファスト・スタート・フェイルオーバーが開始されると、オブザーバはターゲット・スタンバイ・データベースがプライマリ・データベース・ロールにフェイルオーバーする準備ができているかどうかを確認します。
次の場合、ファスト・スタート・フェイルオーバーは実行できません。
ファスト・スタート・フェイルオーバーが有効でない場合
オブザーバがターゲット・スタンバイ・データベースに接続できない場合
ブローカ構成の現在の状態に関して、オブザーバおよびターゲット・スタンバイ・データベースに一貫性がない場合
オブザーバが動作していない場合
保護モードが最大可用性で、プライマリ・データベースに障害が発生したときにターゲット・スタンバイ・データベースがプライマリ・データベースと同期化されていない場合
保護モードが最大パフォーマンスで、プライマリ・データベースに障害が発生したときにターゲット・スタンバイ・データベースのREDO適用時点がプライマリ・データベースのREDO生成時点からFastStartFailoverLagLimit
構成プロパティで指定された時間を超えて遅れる場合
ターゲット・スタンバイ・データベースがプライマリ・データベースと通信している場合
ターゲット・スタンバイ・データベースのV$DATABASE
ビュー内のFS_FAILOVER_STATUS
列に、ファスト・スタート・フェイルオーバーを実行できない理由が表示された場合
手動フェイルオーバーがすでに進行中です。手動フェイルオーバーの詳細は、5.4項を参照してください。
ABORT
オプションを使用せずにプライマリ・データベースを停止した場合
ターゲット・スタンバイ・データベースがフェイルオーバー可能な状態である場合、オブザーバの指示により、ただちにターゲット・スタンバイ・データベースがプライマリ・データベース・ロールにフェイルオーバーします。他のなんらかの理由でフェイルオーバーを実行できない場合、オブザーバはスタンバイ・データベースでフェイルオーバーの準備ができたかどうかをチェックし続けます。ただし、オブザーバはプライマリ・データベースへの再接続も無期限に試行し続けます。スタンバイがフェイルオーバーに同意する前にプライマリ・データベースに再接続すると、オブザーバはファスト・スタート・フェイルオーバーの開始の試行を中止します。
ファスト・スタート・フェイルオーバーが正常に完了した後、元のプライマリ・データベースへの接続が再確立され、FastStartFailoverAutoReinstate
構成プロパティがTRUE
に設定されている場合、オブザーバは元のプライマリ・データベースの新規スタンバイ・データベースとしての回復を試行します。FastStartFailoverPmyShutdown
構成プロパティをTRUE
に設定した場合、元のプライマリ・データベースは自動的に停止しているため、オブザーバが回復を試行する前に、手動で再起動する必要があります。
プライマリがクラッシュしたか、オブザーバおよびターゲット・スタンバイ・データベースから分離したためにファスト・スタート・フェイルオーバーが発生した場合にのみ、これらのプロパティがプライマリの停止および自動回復の実行を左右する点に注意してください。
ファスト・スタート・フェイルオーバーが有効化されている場合、次の操作は禁止されています。
変更:
構成保護モード
プライマリ・データベースまたはターゲット・スタンバイ・データベースのデータベース・プロパティLogXptMode
プライマリ・データベースまたはターゲット・スタンバイ・データベースのFastStartFailoverTarget構成プロパティ
無効化または削除:
ブローカ構成
ファスト・スタート・フェイルオーバーのターゲットであるスタンバイ・データベース
手動フェイルオーバーの実行:
5.5.2.4項にリストした条件を満たしていない場合の実行
ファスト・スタート・フェイルオーバーのターゲットとして構成されていないスタンバイ・データベースに対する実行
構成がファスト・スタート・フェイルオーバーを実行可能な状態かどうかを判断するには、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分未満で完了しないと、このエラーが戻されることがあります。
プライマリ・データベースまたはスタンバイ・データベースが通常の方法で(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>
コマンドを発行するか、ターゲット・スタンバイ・データベースで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: South_Sales Observer: observer.example.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 - DRSolution Protection Mode: MaxAvailability Databases: North_Sales - Primary database South_Sales - (*) Physical standby database (*) Fast-Start Failover target Properties: FastStartFailoverThreshold = '60' OperationTimeout = '30' FastStartFailoverLagLimit = '30' CommunicationTimeout = '180' FastStartFailoverAutoReinstate = 'TRUE' FastStartFailoverPmyShutdown = 'TRUE' BystandersFollowRoleChange = 'ALL' Fast-Start Failover: ENABLED Threshold: 180 seconds Target: South_Sales Observer: observer.example.com Lag Limit: 30 seconds (not in use) Shutdown Primary: TRUE Auto-reinstate: TRUE Configuration Status: SUCCESS
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列
列値 | 説明 | ファスト・スタート・フェイルオーバー |
---|---|---|
|
ファスト・スタート・フェイルオーバーは有効化されていますが、このスタンバイ・データベースはファスト・スタート・フェイルオーバーのターゲットではありません。このデータベースはファスト・スタート・フェイルオーバーのステータス情報を提供できません。 |
有効 |
|
ファスト・スタート・フェイルオーバーは無効化されています。 |
不可 |
|
プライマリ・データベースのデータ・ディクショナリのコピーをロードし終えていないロジカル・スタンバイ・データベースにのみ表示されます。 |
不可 |
|
ターゲット・スタンバイ・データベースが、プライマリ・データベースと |
不可 |
|
障害が発生したプライマリ・データベースの新規スタンバイ・データベースとしての回復に失敗しました。ブローカのdrc*ログ・ファイルの詳細は、 |
完了済 |
|
障害が発生したプライマリ・データベースは、新規プライマリに対する新規スタンバイ・データベースとして回復する必要があります。オブザーバにより回復プロセスが自動的に開始されます。 |
完了済 |
|
ターゲット・スタンバイ・データベースとの接続が切断され、 フェイルオーバーが実行された可能性が高いため、プライマリ・データベースが停止またはストールします。 注意: この状態は、ファスト・スタート・フェイルオーバーが可能で、ターゲット・スタンバイ・データベースもオブザーバも存在しないときに起動し、データベースのオープンを継続可能かどうかを確認した場合にもプライマリで発生します。 |
可 |
|
構成が最大パフォーマンス・モードで動作しているとき、プライマリ・データベースの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
コマンドを発行します。詳細は、第7章のDISABLE FAST_START FAILOVERコマンドに関する項を参照してください。
ファスト・スタート・フェイルオーバーを使用する際のパフォーマンスを向上させるには、次の推奨事項を考慮します。
フェイルオーバー時間は、ターゲット・スタンバイ・データベース(フィジカルまたはロジカル・スタンバイ・データベース)がプライマリ・データベースから受け取ったREDOデータをすべて適用したかどうかによって決まります。
最大パフォーマンス・モードで動作している構成でファスト・スタート・フェイルオーバーを有効化すると、REDOデータが非同期でターゲット・スタンバイに転送されるため、プライマリ・データベースでの全体的なパフォーマンスが向上します。この場合はデータが消失しないことが保証されないことに注意してください。
スタンバイ・データベースへのREDOデータの適用がプライマリ・データベースのREDO適用率と一致した状態が保たれるように、リカバリを最適化する手順を実行すると、ファスト・スタート・フェイルオーバーが高速になります。ログ適用率を最適化するには、次のようにします。
データベース・プロパティDelayMins
を設定することにより、スタンバイ・データベースへのアーカイブREDOログ・ファイルの適用を遅延させないでください(詳細は、4.5項を参照してください)。
フィジカル・スタンバイ・データベースのログ適用率のチューニングの詳細は、『Oracle Data Guard概要および管理』を参照してください。
次の場所にあるホワイト・ペーパー『Oracle Maximum Availability Architecture』を参照してください。
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項では、ファスト・スタート・フェイルオーバーを有効化する段階的なプロセスの一部として、オブザーバの起動方法を説明しています。DGMGRLを使用したオブザーバの起動例は、6.6項に示しています。
ブローカ構成を監視するオブザーバは1つのみ存在できます。別のオブザーバを起動しようとすると、ブローカにより次のエラー・メッセージが戻されます。
ORA-16647: could not start more than one observer
オブザーバを起動するには、SYSDBA権限を持つアカウントでDGMGRLにログインできる必要があります。オブザーバは、DGMGRLでData Guard構成に接続したときに使用したSYS
資格証明を使用してプライマリ・データベースおよびターゲット・スタンバイ・データベースに接続するOCIクライアントです。
オブザーバとDGMGRLは同じOracle Databaseリリースを実行している必要があります。たとえば、DGMGRLがOracle Databaseリリース2 (11.2.0.4)システムで実行されている場合は、オブザーバも11.2.0.4で実行されている必要があります。
オブザーバに関する情報を検索するには、V$DATABASE
ビューで次の列を問い合せます。
表5-2 V$DATABASEビューのFS_FAILOVER_OBSERVER_PRESENT列
列値脚注1 | 説明 |
---|---|
|
オブザーバは現在ローカル・データベースに接続している |
|
オブザーバはローカル・データベースに接続していない |
脚注1 この値は、Oracle Real Application Clusters(Oracle RAC)環境内の全インスタンスで一貫性が保たれています。つまり、オブザーバがOracle 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
ステータスが戻されます。
オブザーバの高可用化
Oracle Enterprise Manager Cloud Control (Cloud Control)は、オブザーバ・プロセスが失敗したことを検出した場合に、同じホストでのオブザーバの自動再起動をサポートします。この自動再起動機能は、ファスト・スタート・フェイルオーバーが有効になっている場合にアクティブ化されます。
Cloud Controlでは、最初のホストに障害が発生した場合に代替ホストでのオブザーバの自動再起動もサポートします。代替オブザーバ・ホストの指定方法の詳細は、Cloud Controlのオンライン・ヘルプを参照してください。
ファスト・スタート・フェイルオーバーを使用しない場合(5.5.5項「ファスト・スタート・フェイルオーバーの無効化」を参照)、またはオブザーバを別のホスト・マシンに移動する場合は(5.5.7.5項「オブザーバの別のコンピュータへの移動」を参照)、オブザーバを停止できます。
ファスト・スタート・フェイルオーバーが有効化されているときにオブザーバを停止するには、プライマリ・データベースおよびターゲット・スタンバイ・データベースが接続されており、相互に通信している必要があります。オブザーバを停止しても、ファスト・スタート・フェイルオーバーは無効化されません。ただし、ターゲット・スタンバイ・データベースが監視されない状態の場合、ファスト・スタート・フェイルオーバーは実行できません。
ファスト・スタート・フェイルオーバーが有効化されているが、プライマリ・データベースとスタンバイ・データベースが相互に分離している場合にオブザーバを停止するには、FORCE
オプションを使用してまずファスト・スタート・フェイルオーバーを無効化してから、オブザーバを停止する必要があります。(FORCEオプションを使用する際に考慮すべき重要事項については、5.5.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
に設定されている場合
ファスト・スタート・フェイルオーバーの完了後、元のプライマリ・データベースが再起動されるまでに別のフェイルオーバーまたはスイッチオーバーが発生した場合
ファスト・スタート・フェイルオーバーが無効化されている場合
オブザーバが元のプライマリ・データベースに接続できない場合
元のプライマリ・データベースが新規プライマリ・データベースに接続できない場合
元のプライマリ・データベースおよび新規プライマリ・データベースが、同じファスト・スタート・フェイルオーバー環境内で構成されていない場合
ファスト・スタート・フェイルオーバーが無効化されているとき、手動フェイルオーバーによって元のプライマリ・データベースが無効化された場合
注意: スイッチオーバー、手動フェイルオーバーまたはファスト・スタート・フェイルオーバーの実行時にスタンバイ・データベースを無効した場合は、自動的に回復されません。 |
自動回復に失敗した場合、ブローカによりエラーがログに記録され、元のプライマリ・データベースはマウントされた状態のままとなります。この時点で、次のいずれかを実行できます。
プライマリ・データベースまたはスタンバイ・データベースを停止する必要がある場合、次の手順を実行します。
オブザーバを停止し、プライマリ・データベースおよびターゲット・スタンバイ・データベースの両方について、V$DATABASE固定ビューの
FS_FAILOVER_OBSERVER_PRESENT
列に値「NO
」が含まれるまで待機します。こうすると、プライマリ・データベースの停止中に、ファスト・スタート・フェイルオーバーは実行されません。
DGMGRLのSHUTDOWN
コマンドまたはSQL*PlusのSHUTDOWN
文を使用して、プライマリ・データベースおよびターゲット・スタンバイ・データベースを停止します。
この項では、ブローカ管理のフェイルオーバーが発生したときにデータベース・クライアントで使用可能な、イベント通知およびデータベース接続フェイルオーバーのサポートについて説明します。
フェイルオーバー後、ブローカは高速アプリケーション通知(FAN)イベントを発行します。FANイベントは次の方法で使用できます。
アプリケーションでOracle Database JDBC、Oracle Database Oracle Call Interface(OCI)、Oracle Data Provider for .NET(ODP.NET)のいずれかのOracle統合データベース・クライアントを使用している場合、プログラムを変更せずにFANを使用できます。これらのクライアントには、フェイルオーバー後に自動的に新規プライマリ・データベースに接続する高速接続フェイルオーバー(FCF)を構成できます。
JAVAアプリケーションはJDBC FANアプリケーション・プログラミング・インタフェースを利用してFANをプログラムで使用することで、FANイベントにサブスクライブし、イベント受信時にイベント処理アクションを実行できます。
FANのサーバー側コールアウトをデータベース層で構成できます。
FANイベントは、Oracle Notification Service(ONS)とOracle Streamsアドバンスト・キューイング(AQ)を使用して発行されます。
注意: ONSを使用してFANイベントを発行するには、単一インスタンスのデータベースをOracle Restartに登録する必要があります。 |
参照:
|
この項では、ブローカ管理のフェイルオーバーによって生成されたFANイベントを発行および適切に処理するために満たす必要のある構成要件について説明します。
これらの要件は、前述のマニュアルおよび次のクライアント固有ガイドに記載されている要件を補足するものです。
『Oracle Database JDBC開発者ガイド』
Oracle Call Interfaceプログラマーズ・ガイド
Oracle Data Provider for .NET開発者ガイド
FCFを実行するには、クライアントはフェイルオーバー後に新しいプライマリ・データベースを検出できる必要があります。この項では、この要件に合せてOracle Netの接続記述子を構成する方法について説明します。
接続記述子は次のいずれかの方法で構成できます。
接続時フェイルオーバーの接続記述子を構成します。プライマリ・データベースおよび各スタンバイ・データベースをアドレス・リストに追加します。ネットワーク・アドレスが指定されていない場合に遅延を最小限に抑えるために、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)))
DNSやLDAPなどのグローバル・ネーミング・サービスを使用して登録された単一ネットワーク名で、接続記述子を構成します。DB_ROLE_CHANGE
システム・イベントに基づいてトリガーを作成します。このシステム・イベントは、フェイルオーバー後に、ネットワーク名に関連付けられているネットワーク・アドレスを新規プライマリ・データベースのネットワーク・アドレスに変更します。
参照:
|
どちらの場合も、接続記述子にSERVICE_NAME
パラメータを含める必要があります。
注意: この項で示した例では、必ずしもご使用の環境で使用する必要のある特定の属性を示しているわけではありません。必要な属性は構成によって異なります(ご使用の環境がOracle RACベースか単一インスタンスかどうかも含めて)。詳細は、適切なOracle RACまたはOracle Restartのマニュアルを参照してください。 |
データベース・サービスは、Oracle RACデータベースの特定のデータベース・ロール、およびOracle Restartにより管理される単一インスタンス・データベースでアクティブになるように構成できます。ブローカはOracle ClusterwareまたはOracle Restartと相互に作用して、適切なデータベース・サービスがアクティブになり、ロール変更後に適切なFANイベントが発行されるようにします。
FANイベントは常にONSを使用して発行されます。ただし、データベースが新規プライマリ・データベースでプライマリ・ロールになっている場合、フェイルオーバーを通知するイベントは、アクティブに構成されているデータベース・サービスに対してのみ発行されます。FANイベントがAQを使用して発行されるように、サービスを構成することもできます。OCIまたはODP.NETクライアントを使用している場合、これらのクライアントが使用するFANイベント通知メカニズムである、AQによるFANイベント発行を明示的に有効化する必要があります。
任意のデータベース・ロールでアクティブでなければならないサービス(プライマリ、フィジカル・スタンバイ、ロジカル・スタンバイまたはスナップショット・スタンバイ)は、サービスがアクティブでなければならない各データベースで明示的にSRVCTLユーティリティによって構成する必要があります。次のコマンドの例では、サービスPAYROLL
がプライマリ・データベースNORTH
のPRIMARY
ロール(-l
オプション)でアクティブになるように構成されています。また、スタンバイ・データベースSOUTH
のPRIMARY
ロールでもアクティブになるように構成されているため、ロール・トランジションが発生した場合にはそのデータベースでアクティブになります。AQによるFANイベント通知も有効化されています。
次をプライマリ・データベースNORTH
で実行します。
srvctl add service –d NORTH –s PAYROLL –l PRIMARY -q TRUE -e SELECT -m BASIC -w 10 -z 150
次をスタンバイ・データベースSOUTH
で実行します。
srvctl add service –d SOUTH –s PAYROLL –l PRIMARY -q TRUE -e SELECT -m BASIC -w 10 -z 150
サービスを現在のプライマリ・データベースで起動するかどうかにかかわらず、データベースがフィジカル・スタンバイ・ロールになっているときにアクティブにするサービスも、そのデータベースで作成および起動する必要があります。これは、サービス定義がREDOストリームを介してフィジカル・スタンバイ・データベースに伝播されるようにするためです。これにより、サービスをフィジカル・スタンバイ・データベースで起動できるようになります。サービスをフィジカル・スタンバイで起動できるのは、サービスを起動することによって生成されたREDOが適用された後のみです。次のSRVCTL追加サービスオプションを指定して、すべてのデータベース上で同じ値を持つことは重要です。
オプション | 説明 |
---|---|
-B | ロード・バランシング・アドバイザの目標。 |
-x | 分散トランザクション処理を有効化するかどうかを示します。 |
-q | AQ HA通知を有効化するかどうかを示します。 |
-m | フェイルオーバーのメソッド。 |
-e | フェイルオーバーのタイプ。 |
-z | フェイルオーバー再試行。 |
-w | フェイルオーバーの遅延。 |
-j | 接続ロード・バランシングの目標。 |
-t | エディション名。 |
すべてのデータベースが同じ値を持たない場合、SRVCTLは値を上書きしようとしますが、フィジカル・スタンバイ・データベースで失敗します。これは、データベースが読取り専用でオープンであるためです。次のコマンドの例では、サービスsales
がプライマリ・データベースNORTH
のPHYSICAL_STANDBY
ロール(-l
オプション)でアクティブになるように構成されています。その後、プライマリ・データベースで起動および停止されます。このサービスを現在のプライマリ・データベース上で実行しない場合は、オプションでプライマリ・データベースから削除することもできます。これは、フィジカル・スタンバイ・データベースSOUTH
のPHYSICAL_STANDBY
ロールでもアクティブになるように構成されます。
次をプライマリ・データベースNORTH
で実行します。
srvctl add service -d NORTH -s sales -l PHYSICAL_STANDBY -q TRUE -e SELECT -m BASIC -w 10 -z 150 srvctl start service –d NORTH –s sales srvctl stop service –d NORTH –s sales
次をフィジカル・スタンバイ・データベースSOUTH
で実行します。
srvctl add service -d SOUTH -s sales -l PHYSICAL_STANDBY -q TRUE -e SELECT -m BASIC -w 10 -z 150
注意: サービスが自動的に起動するように構成されている場合(-y AUTOMATIC )、データベース・ロールが変更された後にのみ、自動的に起動します。 |
参照:
|