| Oracle® Data Guard Broker 12cリリース1 (12.1) B71305-08 |
|
 前 |
 次 |
Oracleデータベースは、プライマリまたはスタンバイという2つのロールのいずれかで動作します。Oracle Data Guardにより、スイッチオーバーまたはフェイルオーバーのいずれかを使用してデータベースのロールを変更できます。
スイッチオーバーとは、プライマリ・データベースとそのスタンバイ・データベースの1つとの間でロールを可逆的に推移させる操作です。スイッチオーバーでは、データの消失がないことが保証され、通常は予定されたプライマリ・システムのメンテナンスの際に実行されます。スイッチオーバー中は、プライマリ・データベースがスタンバイ・ロールに遷移し、スタンバイ・データベースがプライマリ・ロールに遷移します。
フェイルオーバーは、プライマリ・データベース(Oracle RACデータベースの場合はすべてのインスタンス)に障害が発生するか、アクセス不能になった場合に、スタンバイ・データベースの1つがプライマリ・ロールに移行されるロール・トランジションです。フェイルオーバーでは、フェイルオーバー時に有効な保護モードによって、データが消失する場合としない場合があります。
ブローカを使用しない場合、ロール遷移を実行するには、一連のSQL文を発行します(『Oracle Data Guard概要および管理』を参照)。ブローカでは、Oracle Enterprise Manager Cloud Control (Cloud Control)でキーを1回クリックするか、DGMGRLコマンドライン・インタフェースで単一のコマンドを使用してスイッチオーバーおよびフェイルオーバーを起動できるため(このドキュメントでは手動フェイルオーバーと呼びます)、これらの操作が簡素化されます。また、ファスト・スタート・フェイルオーバーを有効化すると、ファスト・スタート・フェイルオーバーの条件が満たされたときに自動的にフェイルオーバーが実行されます。ファスト・スタート・フェイルオーバーが有効化されている場合、ブローカによってフェイルオーバーの必要性が判断され、指定されたターゲット・スタンバイ・データベースへのフェイルオーバーが自動的に開始されます。DBAによる操作は不要です。
ファスト・スタート・フェイルオーバーにより、手動操作の必要性を少なくして可用性を高め、管理コストを削減できます。手動フェイルオーバーでは、フェイルオーバーを実行する正確なタイミングおよび対象となるターゲット・スタンバイ・データベースを管理できます。選択する方法に関係なく、ブローカによって構成内のすべてのデータベースのロール遷移が調整されます。
注意:
スイッチオーバーもフェイルオーバーも、遠隔同期インスタンスに対しては不可能です。
スイッチオーバーまたはフェイルオーバー後に次のプライマリ・データベースにするスタンバイ・データベースを選択する際には、多数の考慮事項があります。Oracle Data Guard構成を構築する際には、フィジカル・スタンバイ、ロジカル・スタンバイおよびスナップショット・スタンバイの各特性、スタンバイ・データベース・サイトに対するネットワーク待機時間、将来のプライマリ・データベース・サイトにおけるコンピューティング機能などの要素を含む、すべてのオプションを考慮する必要があります。
注意:
スナップショット・スタンバイを、スイッチオーバーまたはファスト・スタート・フェイルオーバー操作のターゲットにすることはできません。ただし、スナップショット・スタンバイへの手動フェイルオーバーは実行できます。
遠隔同期インスタンスはデータベースではなく、したがってロール遷移のターゲットにはなれません。
スイッチオーバーについては、すべての要素を理解することで、新規プライマリ・データベースとみなすスタンバイ・データベースを簡単に選択できます。フェイルオーバーが必要な障害が発生した場合、障害のあるプライマリ・データベースのアクティビティを再開するのに最適なスタンバイ・データベースは、スイッチオーバーの場合よりも絞られる可能性があります。「スイッチオーバーでのターゲット・スタンバイ・データベースの選択」と「フェイルオーバーでのターゲット・スタンバイ・データベースの選択」に、ターゲット・スタンバイ・データベースの選択に役立つガイドラインを示します。
注意:
ファスト・スタート・フェイルオーバーの場合、使用するターゲット・スタンバイ・データベースを事前に選択する必要があります。ファスト・スタート・フェイルオーバーの詳細は、「ファスト・スタート・フェイルオーバー」を参照してください。
データベースのロール変更可能状況の判定
適切なスイッチオーバーまたはフェイルオーバー・ターゲットの選択を助けるには、DGMGRL VALIDATE DATABASEコマンドを使用します。このコマンドは、データベースがロール変更を完了する準備ができているかどうかを決定する包括的なチェックを実行します。
参照:
VALIDATE DATABASEコマンドを使用してデータベースのロール・スイッチオーバー実行可能状況を表示する例は、「使用例9: スイッチオーバー操作の実行」を参照してください
VALIDATE DATABASEコマンドを使用してデータベースのロール・フェイルオーバー実行可能状況を表示する例は、「使用例10: 手動フェイルオーバー操作の実行」を参照してください
スタンバイ・データベースがすべて同じタイプである(すべてフィジカルまたはすべてロジカル・スタンバイ・データベース)構成内でスイッチオーバーを実行する場合、未適用のREDOの数が最も少ないスタンバイ・データベースを選択します。未適用のREDOの数が最も少ないスタンバイ・データベースを選択することで、スイッチオーバー操作が完了するまでの全体の所要時間を最小限にできます。次に例を示します。
DGMGRLを使用する場合、構成内にある各スタンバイ・データベースのSHOW DATABASE 出力のApply Lag行を調査します。
Cloud Controlを使用する場合は、Oracle Data Guardの概要ページの「スタンバイ・データベース」セクションで、各スタンバイ・データベースのApplyLag列の値を表示できます。
構成にフィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データベースの両方が含まれる場合、ターゲット・スタンバイ・データベースとして(未適用REDOの数が最も少ない)フィジカル・スタンバイ・データベースを選択することを考慮します。スイッチオーバー操作の完了後は、構成内のすべてのデータベースが新規プライマリ・データベースに対するスタンバイ・データベースとして使用可能になるため、フィジカル・スタンバイ・データベースへのスイッチオーバーをお薦めします。一方、ロジカル・スタンバイ・データベースにスイッチオーバーすると、構成内のフィジカルおよびスナップショット・スタンバイ・データベースがすべて無効化されます。そのため、フィジカル・スタンバイ・データベースを再有効化するには、新規プライマリ・データベースのコピーからフィジカル・スタンバイ・データベースを再作成する必要があります。
スナップショット・スタンバイ・データベースへのスイッチオーバーを実行するには、最初にフィジカル・スタンバイ・データベースに戻す必要があります。
注意:
Oracle Data Guard構成が最大保護モードで動作している場合、ブローカではロジカル・スタンバイ・データベースへのスイッチオーバーが許可されません。ロジカル・スタンバイ・データベースへのスイッチオーバーを実行するには、構成が最大可用性モードまたは最大パフォーマンス・モードのいずれかで動作している必要があります。
フェイルオーバーを実行するとき、構成内のスタンバイがすべて同じタイプである場合は、最も転送ラグの小さいスタンバイ・データベースを選択します。これにより、データの消失量を最小限に抑え、場合によってはデータの消失をゼロにすることができます。
構成にフィジカル・スタンバイ・データベース、スナップショット・スタンバイ・データベースおよびロジカル・スタンバイ・データベースが含まれる場合、ターゲット・スタンバイ・データベースとしてフィジカル・スタンバイ・データベースを選択することを考慮します。フェイルオーバー操作の完了後は、構成内のすべてのスタンバイ・データベースが新規プライマリ・データベースに対するスタンバイ・データベースとして使用可能になる可能性が高いため、フィジカル・スタンバイ・データベースへのフェイルオーバーをお薦めします。
スナップショット・スタンバイ・データベースにフェイルオーバーすることもできます。ただし、スナップショット・スタンバイ・データベースにフェイルオーバーするには、ブローカがこのデータベースを最初にフィジカル・スタンバイ・データベースに戻す必要があるため、時間がかかります。変換した後、ブローカは、プライマリ・ロールへのデータベースのフェイルオーバーを実行する前に、REDO Applyを起動して累積REDOデータを適用します。スナップショット・スタンバイ・データベースをフィジカル・スタンバイ・データベースに変換してからフェイルオーバーが実行されるため、フェイルオーバー操作の完了後、構成内のすべてのスタンバイ・データベースを新しいプライマリ・データベースへのスタンバイ・データベースとして使用することが可能になります。
ロジカル・スタンバイ・データベースにフェイルオーバーするには、フェイルオーバーの完了後に、新しいプライマリ・データベースのコピーからすべてのフィジカルおよびスナップショット・スタンバイ・データベースを再作成する必要があります。さらに、ロジカル・スタンバイ・データベースには、プライマリ・データベースに存在するデータのサブセットのみが含まれる可能性があります。(たとえば、プライマリ・データベース上で実行されるデータベース操作のうちロジカル・スタンバイ・データベースに適用しない操作を指定する際に、DBMS_LOGSTDBY.SKIPプロシージャが使用された場合など。)
ただし、例外として、ターゲット・スタンバイ・データベースとしてフィジカル・スタンバイ・データベースを選択することをお薦めできない場合があります。たとえば、フィジカル・スタンバイ・データベースもすべて利用できない場合は、ロジカル・スタンバイ・データベースへのフェイルオーバーが唯一の選択肢となります。
データベースは、プライマリ・ロールからスタンバイ・ロール、またはスタンバイ・ロールからプライマリ・ロールに切り替えることができます。この操作は、データを消失させることなく、指定したスタンバイ・データベースがプライマリ・データベースになり、元のプライマリ・データベースがスタンバイ・データベースになるため、データベースのスイッチオーバーと呼ばれます。
可能な場合は必ず、フィジカル・スタンバイ・データベースに対してスイッチオーバーしてください。
スイッチオーバーによりロジカル・スタンバイ・データベースをプライマリ・ロールに遷移する場合、次のようになります。
元のプライマリ・データベースはロジカル・スタンバイ・ロールに切り替えられます。
スイッチオーバーの完了後、プライマリ・データベースおよびロジカル・スタンバイ・データベースのどちらも再起動の必要はありません。
ブローカ構成内の他のロジカル・スタンバイ・データベースは、スイッチオーバー後も実行可能です。どのデータベースも再起動する必要はありません。ロジカル・スタンバイ・データベースへのスイッチオーバーの後、すべてのフィジカルおよびスナップショット・スタンバイ・データベースは無効化されるため、新しいプライマリ・データベースのコピーから再作成する必要があります。
構成が最大保護モードで動作している場合、ロジカル・スタンバイ・データベースへのスイッチオーバーは許可されません。
警告:
ロジカル・スタンバイ・データベースにスイッチオーバーすると、ブローカ構成内のスナップショット・スタンバイ・データベースとフィジカル・スタンバイ・データベースはブローカにより無効化され、これらのデータベースはスタンバイ・データベースとして実行できなくなります。スタンバイ・データベースとして実行可能な状態にリストアする方法は、「ロール変更後の無効化されたデータベースの再有効化」を参照してください。
比較的すぐに元のプライマリ・データベースにスイッチバックする場合は、フィジカルおよびスナップショット・スタンバイ・データベースを無効なままにしておくことができます。フィジカルおよびスナップショット・スタンバイ・データベースはまだ元のプライマリ・データベースの実行可能なスタンバイ・データベースであるため、元のプライマリ・データベースへのスイッチバックの完了後、これらを再有効化できます。
スイッチオーバーを開始する前に、次の点を考慮してください。
スイッチオーバーを開始すると、ブローカは、スイッチオーバーの完了後に少なくとも1つのスタンバイ・データベース(スタンバイ・ロールに遷移する予定のプライマリ・データベースも含む)が、全体の保護モード(最大保護、最大可用性または最大パフォーマンス)をサポートするように構成されているかどうかを検証します。
全体の保護モードとの関連で、将来考えられるスタンバイ・データベースとしてのロールに備えて、あらかじめプライマリ・データベースを準備しておきます(「データ保護モードの管理」を参照してください)。こうした準備には、次の操作が含まれます。
プライマリ・データベースでスタンバイREDOログ・ファイルが構成されていることを確認します。
LogXptMode、NetTimeout、StandbyArchiveLocation、AlternateLocationおよびRedoRoutesなど、REDO転送サービス関連のデータベース・プロパティをあらかじめ設定します。データベース・プロパティを使用したREDO転送サービスの管理の詳細は、「REDO転送サービスの管理」を参照してください。
DelayMinsなど、REDO Applyサービス関連のデータベース・プロパティをリセットします。遅延の適用がある場合は、スイッチオーバーを開始する前にすべて削除する必要があります。遅延を解除しないと、スイッチオーバー時間が長くなり、今後のリリースでスイッチオーバーが許可されなくなります。プロパティを使用したREDO Applyサービスの管理の詳細は、「ログ適用サービスの管理」を参照してください。
一時表ごとに、プライマリ・データベース上の一時表に関連付けられた一時ファイルがスタンバイ・データベースにも存在することを確認します。
これらのプロパティは、実際にプライマリ・データベースをスタンバイ・ロールに切り替えるまで、ブローカによってREDO転送サービスとREDO Applyサービスの設定に使用されないことに注意してください。そのため、これらのプロパティの値の妥当性は、スイッチオーバー後まで検証されません。これらのプロパティを設定すると、その値はスイッチオーバーおよびフェイルオーバー時のロール変更を通じて存続します。
リアルタイム問合せモードにあるフィジカル・スタンバイ・データベースへのスイッチオーバーを実行する前に、できるだけ迅速に、クリーンにロール・トランジションを実施させるために、そのスタンバイ・データベースのすべてのインスタンスを、マウント済だがオープンされていない状態にすることを検討します。
ファスト・スタート・フェイルオーバーが有効化されている場合、スイッチオーバーを実行できるのは、事前に指定されたターゲット・スタンバイ・データベースに対してのみであり、スタンバイ・データベースがプライマリ・データベースと同期化されているか(最大可用性モード)、構成されている制限範囲内にラグが収まっている(最大パフォーマンス・モード)場合に限られます。ファスト・スタート・フェイルオーバーの有効化の詳細は、「ファスト・スタート・フェイルオーバーの有効化」を参照してください。
スイッチオーバーの完了後、ブローカにより、保護モードがスイッチオーバー前と同じ保護レベル(最大保護、最大可用性または最大パフォーマンス)に維持され、スイッチオーバー・プロセスの一部として全体のOracle Data Guard保護モードが保持されます。他のすべてのその他のスタンバイ・データベースに対する適用サービスは、新しいプライマリ・データベースから受け取ったREDOデータの適用を自動的に開始します。
構成内にフィジカルまたはスナップショット・スタンバイ・データベースが存在するとき、ロジカル・スタンバイ・データベースへのスイッチオーバーが発生した場合は、「ロール変更後の無効化されたデータベースの再有効化」に示すように、新しいプライマリ・データベースのコピーからこれらのデータベースを再作成し、データベースを再び有効化する必要があります。
注意:
Oracle Data Guard構成では、スタンバイ・データベースのSRVCTL -startoptionは、スイッチオーバー後には、常にOPENに設定されます。ブローカとOracle Restartの対話に関する追加情報は、「データベース・サービスの構成要件」を参照してください。
ロールの切替えは、慎重に計画して実行する必要があります。スイッチオーバーに関係するプライマリ・データベースとスタンバイ・データベースのREDOラグは、できるかぎり低くする必要があります。スイッチオーバーに備えたデータベースの設定方法の詳細は、『Oracle Data Guard概要および管理』を参照してください。
Cloud Controlを使用してスイッチオーバーを開始するには、プライマリ・ロールに変更するスタンバイ・データベースを選択して「スイッチオーバー」をクリックします。DGMGRLを使用する場合は、SWITCHOVERコマンドを1つのみ発行し、プライマリ・ロールに変更するスタンバイ・データベースの名前を指定します。
「ブローカによるスイッチオーバーの実行方法」で説明するように、スイッチオーバーに関するその他の作業はブローカによって制御されます。
スイッチオーバーを開始すると、ブローカは次の作業を実行します。
プライマリ・データベースとターゲットのスタンバイ・データベースが次の状態であることを検証します。
プライマリ・データベースが有効化されてTRANSPORT-ON状態であること。
ターゲット・スタンバイ・データベースが有効化されてAPPLY-ON状態であること。
ブローカは、スイッチオーバー操作に関連して選択したプライマリ・データベースとスタンバイ・データベースにエラーがないかぎり、スイッチオーバーを続行します。その他のスタンバイ・データベースにエラーが発生しても、スイッチオーバーは影響を受けません。
必要に応じて、インスタンスのうち1つを残して、他のすべてのインスタンスを停止します。
フィジカル・スタンバイ・データベースへのスイッチオーバーを実行する場合、ブローカは、現在のプライマリ・データベース上のインスタンスのうち1つを残して他のすべてのインスタンスを停止します。ターゲット・フィジカル・スタンバイ・データベース上のインスタンスは停止されません。
ロジカル・スタンバイ・データベースへのスイッチオーバーの場合は、インスタンスを停止しません。スナップショット・スタンバイ・データベースにスイッチオーバーすることはできません。
プライマリ・データベースとスタンバイ・データベースの間でロールを切り替えます。
ブローカは最初に、元のプライマリ・データベースを変換してスタンバイ・ロールで実行するようにします。次に、ターゲットのスタンバイ・データベースをプライマリ・ロールに遷移させます。いずれかの変換時にエラーが発生すると、ブローカはスイッチオーバーを停止します。詳細は、「スイッチオーバー操作時の問題のトラブルシューティング」を参照してください。
ブローカ構成ファイルを更新し、ロールの変更を記録します。
これにより、その後なんらかの理由で各データベースが再起動した場合に、正しいロールと状態で動作することが保証されます。
フィジカル・スタンバイ・データベースへのスイッチオーバーを行った場合は新しいスタンバイ・データベース(元のプライマリ・データベース)を再起動すると、REDO Applyが新しいプライマリ・データベースからのREDOデータの適用を開始します。Oracle RACのフィジカル・スタンバイ・データベースの場合は、ブローカの指示により、Oracle Clusterwareがスイッチオーバーの前に停止されたインスタンスを再起動します。最大保護モードで動作している構成では、新しいプライマリ・データベースも再起動されます。
新しいプライマリ・データベースが読取り/書込みモードでオープンし、REDO転送サービスが開始します。
リアルタイム問合せが有効な状態で元のフィジカル・スタンバイ・データベースが実行されていた場合、新しいフィジカル・スタンバイ・データベースはリアルタイム問合せが有効な状態で実行されます。
ブローカは各データベースの状態とステータスを検証し、スイッチオーバーによって、各データベースが新しいロールにそれぞれ正常に遷移していることを確認します。スイッチオーバー後にブローカにより無効化されていないその他のスタンバイ・データベースは、スイッチオーバー前の状態で引き続き動作します。他のすべてのその他のスタンバイ・データベースに対するREDO ApplyおよびSQL Applyは、新しいプライマリ・データベースから受け取ったREDOデータの適用を自動的に開始します。
万一スイッチオーバー操作が失敗し、プライマリ・データベースがなくなった場合は、スイッチオーバー・コマンドを再試行します。元のプライマリにスイッチ・バックでき、その後、元のターゲット・スタンバイへのスイッチオーバーを再試行するか、スイッチオーバー先として構成内の別のスタンバイを選択できます。
元のプライマリ・データベースで障害が発生し、プライマリ・データベースを適時にリカバリできる可能性がない場合は、スタンバイ・データベースをプライマリ・データベースに変換できます。これは手動フェイルオーバーと呼ばれます。プライマリ・データベースに障害が発生した時点でプライマリ・データベースとターゲット・スタンバイ・データベースが同期化されていたかどうかによって、データが消失する場合があります。手動という用語は、このタイプのフェイルオーバーとファスト・スタート・フェイルオーバー(「ファスト・スタート・フェイルオーバー」を参照)を比較する目的で使用します。
注意:
ファスト・スタート・フェイルオーバーが有効化されている場合でも、手動フェイルオーバーを実行できます。詳細は、「ファスト・スタート・フェイルオーバーが有効化されている場合の手動によるロール変更の実行」を参照してください。
次の各項では、手動フェイルオーバーの実行方法について説明します。
Cloud ControlまたはDGMGRLを使用して、完全フェイルオーバー(推奨)または即時フェイルオーバーを実行できます。
完全フェイルオーバーは、推奨方法でありデフォルトのフェイルオーバー・オプションです。完全フェイルオーバーでは、構成が動作している保護モードに応じて最大量のREDOデータが自動的にリカバリされます。また、フェイルオーバーのターゲットではないスタンバイ・データベースの無効化をできるかぎり回避して、新しいプライマリ・データベースに対するスタンバイ・データベースとして機能し続けられるようにします。
フェイルオーバーのターゲットではないスタンバイ・データベース(その他のスタンバイ・データベース)を無効にするか否かは、フェイルオーバーのターゲットと比較して、ターゲットでないスタンバイに適用されたREDOデータの量、およびフェイルオーバー・ターゲットのスタンバイ・タイプに応じて異なります。
フェイルオーバーのターゲットがフィジカルまたはスナップショット・スタンバイ・データベースの場合、新しいプライマリ・データベースのスタンバイ・データベースにするには、元のプライマリ・データベースを回復または再作成する必要があります。また、一部のスタンバイ・データベースで新規プライマリ・データベースによる適用を超えてREDOを適用したことが検出された場合、ブローカはそれらのデータベースをフェイルオーバー中に無効化する場合があります。ブローカにより無効化されたデータベースは、新しいプライマリ・データベースのスタンバイ・データベースにする前に、「ロール変更後の無効化されたデータベースの再有効化」で説明する手順に従って回復または再作成する必要があります。
スナップショット・スタンバイ・データベースでフェイルオーバーを実行した場合は、元のプライマリをフィジカル・スタンバイ・データベースとして回復または再作成する必要があることに注意してください。
フェイルオーバーのターゲットがロジカル・スタンバイ・データベースである場合、元のプライマリ・データベースおよび構成内のすべてのフィジカルおよびスナップショット・スタンバイ・データベースが無効化されます。フラッシュバック・データベースが有効化されている場合、プライマリ・データベースを回復できます。フィジカルおよびスナップショット・スタンバイ・データベースは、新規プライマリ・データベースのコピーから再作成する必要があります。詳細は、「ロール変更後の無効化されたデータベースの再有効化」を参照してください。
プライマリ・データベースをマウントできる場合は、ALTER SYSTEM FLUSH REDO SQL文を使用して、プライマリ・データベースからターゲット・スタンバイ・データベースへの未送信REDOデータをすべてフラッシュできます。この操作が正常に完了すると、プライマリ・データベースがデータ消失ゼロの保護モードでなくても、データ消失がゼロのフェイルオーバーが可能になります。ALTER SYSTEM FLUSH REDO文の使用の詳細は、『Oracle Data Guard概要および管理』を参照してください。
完全フェイルオーバー中は、「ブローカによる完全フェイルオーバー操作の実行方法」に示すフェイルオーバー手順がブローカによって実行されます。
即時フェイルオーバーは、最も高速なタイプのフェイルオーバーです。ただし、フェイルオーバーの起動後は、スタンバイ・データベースに追加データが適用されません。即時フェイルオーバーを実行した場合は、構成内の他のすべてのデータベースが無効化されます。新規プライマリ・データベースのスタンバイ・データベースとして機能させるには、これらのデータベースを回復または再作成する必要があります。この方法は、「ロール変更後の無効化されたデータベースの再有効化」を参照してください。即時フェイルオーバー中は、「ブローカによる即時フェイルオーバー操作の実行方法」に示すフェイルオーバー手順がブローカによって実行されます。
注意:
ORA-752またはORA-600 [3020]エラーにより、フェイルオーバー・ターゲットでREDO Applyが停止されていないかぎり、常に完全フェイルオーバーを最初に実行するようにします。これらのエラーのいずれかが発生した場合は、先に進む前に、My Oracle Supportノート1265884.1のスタンバイ・リカバリ時のORA-752またはORA-600 [3020]の解決のガイドラインに従います。このサポート・ノートは、http://support.oracle.comにあります。
即時フェイルオーバーは、完全フェイルオーバーが失敗するか、前述のエラーの場合にのみ実行してください。完全フェイルオーバーは、REDO転送サービスの宛先属性に応じて、データ損失なしで実行できますが、即時フェイルオーバーでは、通常データ損失が発生します。
プライマリ・データベースを適時リカバリできる可能性がないと判断した場合は、プライマリ・データベースが停止していることを確認し、フェイルオーバー操作を開始します。
この項の各手順では、手動フェイルオーバーの実行に関連するタスクについて説明します。フェイルオーバーおよび関係するスタンバイ・データベースのタイプによって、一部のデータベースの回復または再作成が必要となる場合があります。
「ターゲット・スタンバイ・データベースの選択」に示したガイドラインに従います。
Cloud ControlまたはDGMGRLを使用して、完全フェイルオーバー(推奨)または即時フェイルオーバーを実行します。
Cloud Controlを使用した手動フェイルオーバー:
Cloud ControlのOracle Data Guardの概要ページで、プライマリ・ロールに変更するスタンバイ・データベースを選択して「フェイルオーバー」をクリックします。その後、フェイルオーバーの確認ページで「はい」をクリックし、デフォルトの「完全」フェイルオーバー・オプションを起動します。
DGMGRLを使用した手動フェイルオーバー
ターゲット・スタンバイ・データベースに接続し、FAILOVERコマンドを発行してフェイルオーバーを実行し、プライマリ・データベースにするスタンバイ・データベースの名前を指定します。
DGMGRL> FAILOVER TO database-name;
次のいずれかの条件に当てはまる場合は、オプションのIMMEDIATE句を指定して、即時フェイルオーバーを実行します。
ORA-752エラーがスタンバイ・データベースで発生した場合
ORA-600 [3020]エラーがスタンバイ・データベースで発生し、その原因がプライマリ・データベースでの書込み欠落であるとOracleサポートが判断した場合
完全フェイルオーバーが不可能な場合
DGMGRL> FAILOVER TO database-name IMMEDIATE;
参照:
完全フェイルオーバーを実行する場合、データベース・ロールがプライマリに変更される前に、すべての累積REDOデータが適用されます。即時フェイルオーバーを実行する場合、累積REDOデータは適用されずに、データベース・ロールがプライマリに変更されます。
ターゲットがスナップショット・スタンバイ・データベースの場合、ブローカは、最初にデータベースをフィジカル・スタンバイ・データベースに変換します。
フィジカルまたはロジカル・スタンバイ・データベースにフェイルオーバーする場合は、インスタンスを停止しません。
保護モードが最大保護だった場合は、最大パフォーマンスにリセットされます。必要に応じて、保護モードを後でアップグレードできます(「構成に対する保護モードの設定」を参照)。
保護モードが最大可用性または最大パフォーマンスだった場合は、変更されません。
注意:
ファスト・スタート・フェイルオーバーが有効化されている場合に手動フェイルオーバーを実行すると、次のようになります。
フェイルオーバーは、事前に選択されたターゲット・スタンバイ・データベースに対してのみ実行できます。
ブローカにより、フェイルオーバー前に有効になっていた保護モードが維持されます。
他の障害が発生した場合に実行可能な障害時リカバリ・ソリューションを維持するには、「ロール変更後の無効化されたデータベースの再有効化」で説明する追加手順を実行し、次の操作を行う必要があります。
元のプライマリ・データベースを回復し、新規構成のスタンバイ・データベースとして機能させます。
注意:
ORA-752またはORA-600 [3020]エラーがフェイルオーバー・ターゲットで発生した場合に、古いプライマリ・データベースを回復しようとすると、データ損失が発生する場合があるため、回復操作は行わないでください。かわりに、「無効化されたデータベースの再作成および再有効化の方法」で説明されている手順に従い、古いプライマリ・データベースを新しいプライマリのバックアップからスタンバイとして再作成する必要があります。
ブローカによって無効化された構成内のスタンバイ・データベースを回復または再作成します。
完全フェイルオーバーが完了すると、新しいプライマリ・データベースのスタンバイとして実行可能でないその他のスタンバイ・データベースは、ブローカにより無効化されます。これは次のいずれかの理由で実行されます。
その他のスタンバイ・データベースに、新しいプライマリ・データベースがスタンバイ・データベースであったときに適用されたよりも多くのREDOデータが適用された場合。新しいプライマリ・データベースのスタンバイとして機能させるには、このスタンバイ・データベースを再作成または回復する必要があります。
ロジカル・スタンバイ・データベースにフェイルオーバーした場合。構成内のすべてのフィジカルおよびスナップショット・スタンバイ・データベースがブローカにより無効化されます。新しいプライマリ・データベースのスタンバイとして機能させるには、これらを再作成する必要があります。
完全フェイルオーバーを開始すると、ブローカは次の作業を実行します。
ターゲット・スタンバイ・データベースが有効化されていることを確認します。データベースが有効化されていない場合、このデータベースに対するフェイルオーバーは実行できません。
ターゲットのスタンバイ・データベースで未適用のREDOデータの適用が完了するまで待機し、適用が完了した後でREDO Apply(ターゲットがフィジカル・スタンバイ・データベースの場合)またはSQL Apply(ターゲットがロジカル・スタンバイ・データベースの場合)を停止します。
ターゲットがスナップショット・スタンバイ・データベースの場合、ブローカは、最初にデータベースをフィジカル・スタンバイに戻し、次にREDO Applyを起動してすべての累積REDOを適用してから、フェイルオーバーを完了してデータベースをプライマリ・データベースとしてオープンします。
ターゲット・スタンバイ・データベースを、次のように、プライマリ・データベース・ロールに遷移させます。
データベースのロールをスタンバイからプライマリに変更します。
新しいプライマリ・データベースを読取り/書込みモードでオープンします。
フェイルオーバー操作に関係しなかったスタンバイ・データベースを、新しいプライマリ・データベースより多くのREDOデータが適用されたために無効化する必要があるかどうかを判断します。
このフェイルオーバー中に、その他のスタンバイ・データベースがブローカにより無効化されない場合は、フェイルオーバー前と同じ状態のままになります。たとえば、APPLY-OFF状態であったフィジカル・スタンバイ・データベースは、APPLY-OFF状態のままになります。
デフォルトでは、ブローカは、完全フェイルオーバーを実行するたびにその他のスタンバイ・データベースが新しいプライマリに対する実行可能なスタンバイ・データベースであるかどうかを判別します。完全フェイルオーバーの実行時に、その他のスタンバイ・データベースの実行可能性のチェックをスキップして、全フェイルオーバー時間を短縮するには、BystandersFollowRoleChange構成プロパティをNONEに設定してください。
このプロパティをNONEに設定すると、ブローカは、新しいプライマリ・データベースよりも多くのREDOデータが適用されているかどうかのチェックを実行せずに、その他のすべてのスタンバイ・データベースを無効にします。フェイルオーバーの完了後にスタンバイ・データベースを回復または再作成(「ロール変更後の無効化されたデータベースの再有効化」項を参照)する必要があります。SHOW CONFIGURATIONコマンドを使用して、回復可能なデータベースと再作成する必要のあるデータベースを表示します。このプロパティの値を表示するには、SHOW CONFIGURATION BystandersFollowRoleChangeコマンドを使用します。デフォルト値はALLです。
このプロパティは、ファスト・スタート・フェイルオーバーの発生時にその他のスタンバイ・データベースの実行可能性チェックをスキップするかどうかにも影響を与えます。
REDO転送サービスを起動して、無効化されていないすべてのその他のスタンバイ・データベースへのREDOデータの転送を開始します。
注意:
フェイルオーバー中には、その他のスタンバイ・データベースがブローカにより無効化される場合があります。新しいプライマリ・データベースのスタンバイ・データベースとして機能させるには、これらのデータベースを回復または再作成する必要があります。すべてのデータベースでフラッシュバック・データベースを構成し、フィジカル・スタンバイ・データベースにフェイルオーバーを実行した場合に、無効化されたスタンバイ・データベースをより簡単に回復できるようにすることをお薦めします。ロジカル・スタンバイ・データベースにフェイルオーバーを実行した場合、すべてのフィジカルおよびスナップショット・スタンバイ・データベースがブローカにより無効化されます。この場合、データベースの回復にフラッシュバック・データベースは使用できません。新しいプライマリ・データベースのコピーから再作成する必要があります。フェイルオーバー中に無効化されたロジカル・スタンバイ・データベースは回復できます。
Oracle RACのフィジカルまたはスナップショット・スタンバイ・データベースがフェイルオーバー・ターゲット・データベースである場合は、ブローカの指示により、Oracle Clusterwareがフェイルオーバーの前に停止されたインスタンスをすべて再起動します。
ブローカは、フェイルオーバーに関連して選択したスタンバイ・データベースにエラーがないかぎり、フェイルオーバーを続行します。その他のスタンバイ・データベースにエラーが発生しても、フェイルオーバーは停止されません。完全フェイルオーバーを開始して失敗した場合は、即時フェイルオーバーを使用する必要があります。
遠隔同期インスタンスを使用した構成内での完全フェイルオーバー
遠隔同期インスタンスからREDOデータを受け取るスタンバイ・データベースに、より完全なフェイルオーバーを手動で実行できます。フェイルオーバーするには、スタンバイ・データベースに接続し、DGMGRLのFAILOVER TO db-unique-nameコマンドを使用します。フィジカル・スタンバイをプライマリ・データベースに変換する前に、遠隔同期インスタンス上に存在して未送信のREDOデータがすべて、ターゲットのフィジカル・スタンバイに送信されます。
カスケーデッド・スタンバイを使用した構成内での完全フェイルオーバー
完全フェイルオーバーでは、別のスタンバイ・データベース(カスケーダ)からREDOを取得するスタンバイ・データベース(ターミナル・スタンバイ)にフェイルオーバーすることも可能です。この場合、未送信のREDOをカスケーダからターミナル・スタンバイに送信する試行は行われません。
即時フェイルオーバーは、次のDGMGRLコマンドで開始されます。
DGMGRL> FAILOVER TO database-name IMMEDIATE;
即時フェイルオーバーが開始されると、ブローカは次のことを行います。
ターゲット・スタンバイ・データベースが有効化されていることを確認します。スタンバイ・データベースがブローカによる管理に対応していない場合、フェイルオーバーは実行できません。
使用可能なREDOデータがすべて適用されるまで待機せずに、スタンバイ・データベースのREDO ApplyまたはSQL Applyを即時停止します。この作業によってデータが失われる可能性があります。
ターゲットのスタンバイ・データベースをプライマリ・ロールに遷移させ、新しいプライマリ・データベースを読取り/書込みモードでオープンし、REDO転送サービスを起動します。
即時フェイルオーバーが完了すると、構成内のすべてのスタンバイ・データベースはタイプに関係なく無効化されます。それらのデータベースでフラッシュバック・データベースが有効化されている場合、データベースは回復されます。それ以外の場合は、新しいプライマリ・データベースのコピーから再作成する必要があります。
ブローカは、フェイルオーバーに関係するように選択したスタンバイ・データベースにエラーがないかぎり、完全フェイルオーバーを続行します。
ブローカは、フェイルオーバーに関係するように選択したスタンバイ・データベースにエラーがあっても、即時フェイルオーバーを続行します。
遠隔同期インスタンスを使用した構成内での即時フェイルオーバー
遠隔同期インスタンスからREDOデータを受け取るスタンバイ・データベースに、即時フェイルオーバーを手動で実行できます。この場合、フィジカル・スタンバイをプライマリ・データベースに変換する前に、遠隔同期インスタンスからターゲットのフィジカル・スタンバイに未送信のREDOを送信する試行は行われません。
カスケーデッド・スタンバイを使用した構成内での即時フェイルオーバー
即時フェイルオーバーでは、別のスタンバイ・データベース(カスケーダ)からREDOを取得するスタンバイ・データベース(ターミナル・スタンバイ)にフェイルオーバーすることも可能です。この場合、未送信のREDOをカスケーダからターミナル・スタンバイに送信する試行は行われません。
ロジカル・スタンバイ・データベースへのスイッチオーバー後またはいずれかのスタンバイ・データベースへのフェイルオーバー後に元の障害時リカバリ・ソリューションをリストアするには、追加手順を実行する必要があります。
ロール遷移後に無効化されたデータベースは、ブローカ構成から削除されませんが、ブローカによって管理されなくなります。
これらのデータベースのブローカによる管理を再び有効化するには、次のいずれかの手順でデータベースを回復または再作成する必要があります。
データベースが回復可能な場合は、データベースで次のステータスが示されます。
ORA-16661: the standby database needs to be reinstated
「データベースの回復方法」の説明に従って、DGMGRLのREINSTATE DATABASEコマンドまたはCloud Controlの回復オプションを使用してデータベースを回復します。 ブローカにより、データベースは回復処理の一部として再有効化されます。
新規プライマリ・データベースのコピーからデータベースを再作成する必要がある場合、データベースのステータスが次のようになります。
ORA-16795: the standby database needs to be re-created
プライマリ・データベースのコピーからスタンバイ・データベースを再作成し、再び有効化します。スタンバイ・データベースの作成手順は、『Oracle Data Guard概要および管理』を参照してください。詳細は、「無効化されたデータベースの再作成および再有効化の方法」を参照してください。
注意:
複数のロール変更が実行されたときに無効化されたデータベースは、回復できません。現在のプライマリ・データベースのコピーからデータベースを手動で再作成し、ブローカ構成でデータベースを再有効化する必要があります。
データベースを回復するか再作成するかは、スイッチオーバーとフェイルオーバーのどちらを実行したか、さらに操作のターゲットとなったスタンバイ・データベースのタイプに応じて決まります。ロジカルおよびスナップショット・スタンバイ・データベースにロール変更すると、常にその他のフィジカル・スタンバイ・データベースは無効化されることに注意してください。これらのデータベースは回復できません。新しいプライマリ・データベースのコピーから再作成する必要があります。
次の各項では、データベースの回復または再有効化方法を説明します。
ブローカの回復機能を使用して、障害が発生したしたプライマリ・データベースを新しいプライマリ・データベースの実行可能なスタンバイ・データベースにすることができます。この処理は、フェイルオーバーがフィジカル、ロジカルまたはスナップショット・スタンバイ・データベースのいずれに実行されたかに関係なく行うことができます。
フェイルオーバー操作中に無効化されたその他のスタンバイ・データベースも回復できます。
回復可能なデータベースは、ステータス値が次のようになります。
ORA-16661: the standby database needs to be reinstated
REINSTATEコマンドを正常に実行するには、フェイルオーバー前にデータベース上でフラッシュバック・データベースが有効化されており、そのデータベースに十分なフラッシュバック・ログが存在する必要があります。さらに、回復するデータベースおよび新規プライマリ・データベースにネットワーク接続が必要です。
データベースを回復する手順は、次のとおりです。
データベースを再起動してマウント済状態にします。
新規プライマリ・データベースに接続します。
Cloud ControlまたはDGMGRLを使用して、データベースを回復します。
ブローカは、障害が発生したプライマリ・データベースを元のスタンバイ・データベースと同じタイプのスタンバイ・データベース(フィジカルまたはロジカル・スタンバイ・データベース)として回復します。唯一の例外は、スナップショット・スタンバイ・データベースへのフェイルオーバーです。そのような場合は、障害が発生したプライマリ・データベースがフィジカル・スタンバイ・データベースとして回復されます。
ブローカは、フェイルオーバー中に無効化されたその他のスタンバイ・データベースを、新しいプライマリ・データベースのスタンバイ・データベースとして回復します。
Oracle Data Guardの概要ページで、「データベースを回復する必要があります」をクリックします。これにより、「回復」ボタンが表示された「一般プロパティ」ページが開きます。「回復」ボタンをクリックすると、Cloud Controlでデータベースの回復が開始されます。
プロセスが完了すると、データベースが新規プライマリ・データベースのスタンバイ・データベースとして有効化され、Cloud ControlでOracle Data Guardの概要ページが表示されます。
DGMGRLを使用した回復
ブローカ構成内のデータベース(回復するデータベースを除く)に接続しているときに、次のコマンドを発行します。
DGMGRL> REINSTATE DATABASE db_unique_name;
新しく回復したスタンバイ・データベースは、新規プライマリ・データベースのスタンバイ・データベースとして機能し始めます。データベースの回復に失敗した場合、ステータスは「ORA-16795: スタンバイ・データベースを再作成する必要があります」に変更されます。この場合、「無効化されたデータベースの再作成および再有効化の方法」の説明に従って、新しいプライマリ・データベースのコピーから再作成して再有効化する必要があります。
障害が発生したプライマリ・データベースまたはロール遷移時に無効化されたスタンバイ・データベースの再作成が必要なフェイルオーバーまたはスイッチオーバーを実行した場合、『Oracle Data Guard概要および管理』の「フィジカル・スタンバイ・データベースの作成」、「ロジカル・スタンバイ・データベースの作成」および「Oracle Data Guard概要および管理」の手順を実行します。
元のプライマリ・データベースを作成する場合、元のスタンバイ・データベースのスタンバイ・タイプで作成する必要があることに注意してください。たとえば、元のスタンバイがフィジカルまたはスナップショット・スタンバイだった場合は、元のプライマリをフィジカル・スタンバイとして再作成する必要があります。
データベースが再作成された後、DGMGRLのENABLE DATABASEコマンドを使用して、再作成されたスタンバイ・データベースのブローカ管理を有効化します。
ファスト・スタート・フェイルオーバーでは、プライマリ・データベースが消失した場合、ブローカにより、事前に選択されたスタンバイ・データベースに自動的にフェイルオーバーできます。ファスト・スタート・フェイルオーバーでは、ターゲット・スタンバイ・データベースがプライマリ・データベース・ロールに迅速かつ確実にフェイルオーバーされます。このとき、手動手順を実行してフェイルオーバーを起動する必要はありません。ファスト・スタート・フェイルオーバーはブローカ構成でのみ使用でき、DGMGRLまたはCloud Controlによってのみ構成できます。
ファスト・スタート・フェイルオーバーでは、最大可用性モードまたは最大パフォーマンス・モードのいずれかを使用できます。最大可用性モードは、データが消失しないことを保証する自動フェイルオーバー環境を提供します。最大パフォーマンス・モードによる自動フェイルオーバー環境では、消失データがFastStartFailoverLagLimit構成プロパティで指定したデータ量(秒単位)以下であることが保証されます。このプロパティは、自動フェイルオーバーの実行に許容される最大消失データ量を示します。このプロパティは、ファスト・スタート・フェイルオーバーが有効化され、構成が最大パフォーマンス・モードで動作している場合にのみ使用されます。
ファスト・スタート・フェイルオーバーが有効化されると、ブローカでは、構成されている消失データ量が保証される場合にのみファスト・スタート・フェイルオーバーの実行が可能となります。構成されている消失データ量を保証できない場合、プライマリ・データベースのREDO生成が停止します。長期にわたる停止を回避するため、ファスト・スタート・フェイルオーバーを実行できないと記録された後、オブザーバまたはターゲット・スタンバイ・データベースにより、プライマリ・データベースでのREDO生成の続行が可能になる場合があります。
構成済の消失データ量の保証が適用可能になると、ブローカは自動フェイルオーバー機能をリストアします。このリストアが起こるのは、最大可用性モードで動作している構成の場合、ターゲットのスタンバイ・データベースがREDOデータの不足をすべて受信し終わったときです。最大パフォーマンス・モードで動作している構成の場合は、プライマリ・データベースのREDO生成時点とターゲット・スタンバイ・データベースのREDO適用時点の間に、FastStartFailoverLagLimit構成プロパティに指定された値を超過する遅れがなくなったときです。
ファスト・スタート・フェイルオーバーのターゲットが、遠隔同期インスタンスからREDOデータを受け取る論理またはフィジカル・スタンバイ・データベースの場合、ファスト・スタート・フェイルオーバーを最大可用性モードで有効化できます。これにより、距離に関係なくデータ損失がゼロになる保護が設定された構成で、ブローカの自動フェイルオーバー機能の利点を活用できます。(ターゲット・スタンバイが遠隔同期インスタンスからREDOを受け取る場合、最大パフォーマンス・モードではファスト・スタート・フェイルオーバーを有効化できません。)この設定方法の例は、「使用例7: 遠隔同期インスタンスが使用中の場合のファスト・スタート・フェイルオーバーの有効化」を参照してください。
この項では、ファスト・スタート・フェイルオーバーおよびファスト・スタート・フェイルオーバー環境を監視するオブザーバ・サイトを有効化する方法を説明します。オブザーバは、プライマリ・データベースおよびスタンバイ・データベースとは異なるコンピュータ上で動作する、独立したOCIクライアント側コンポーネントであり、プライマリ・データベースの可用性を監視します。オブザーバについては、「オブザーバの管理」で詳しく説明されています。
オブザーバの起動が完了したら、ユーザーによる操作は必要ありません。オブザーバおよび指定されたスタンバイ・データベースの両方で、FastStartFailoverThreshold構成プロパティに指定された秒数を超えてプライマリ・データベースとの接続が失われた場合、オブザーバはスタンバイ・データベースへのファスト・スタート・フェイルオーバーを開始します。また、FastStartFailoverPmyShutdown構成プロパティがTRUEに設定されている場合、FastStartFailoverThresholdの秒数よりも長い期間に及ぶ接続の消失を検出すると、プライマリ・データベースは停止します。FastStartFailoverAutoReinstate構成プロパティがTRUEに設定されている場合、フェイルオーバーの完了後、元のプライマリ・データベースへの接続が再度確立されたときに、元のプライマリ・データベースがスタンバイ・データベースとして自動的に回復されます。
注意:
ユーザーが構成可能なファスト・スタート・フェイルオーバー条件が検出されてファスト・スタート・フェイルオーバーが発生した場合、またはアプリケーションからDBMS_DG.INITIATE_FS_FAILOVER関数をコールしてファスト・スタート・フェイルオーバーを開始した場合、元のプライマリ・データベースは必ず停止し、自動的に回復されることはありません。これは、FastStartFailoverPmyShutdownおよびFastStartFailoverAutoReinstate構成プロパティの設定には関係ありません。詳細は、「ファスト・スタート・フェイルオーバーの有効化」を参照してください。
図5-1に、ファスト・スタート・フェイルオーバー時のプライマリ・データベース、ターゲット・スタンバイ・データベースおよびオブザーバの関係を示しています。
ファスト・スタート・フェイルオーバー前: Oracle Data Guardは安定した状態で動作しており、プライマリ・データベースがターゲット・スタンバイ・データベースにREDOデータを転送し、オブザーバが全体の構成の状態を監視しています。
ファスト・スタート・フェイルオーバーの実行: プライマリ・データベースに障害が発生し、オブザーバおよびターゲット・スタンバイ・データベースへのネットワーク接続がどちらも失われます。オブザーバは、通信の切断を検出すると、ファスト・スタート・フェイルオーバーの開始前にFastStartFailoverThresholdプロパティによって定義された時間内において、プライマリ・データベースとの接続の再確立を試行します。オブザーバが指定時間内にプライマリ・データベースへの接続を回復できず、ターゲット・スタンバイ・データベースがファスト・スタート・フェイルオーバー可能な状態である場合、ファスト・スタート・フェイルオーバーが実行されます。
ファスト・スタート・フェイルオーバー後: ファスト・スタート・フェイルオーバーが完了し、ターゲット・スタンバイ・データベースがプライマリ・データベース・ロールで動作しています。元のプライマリ・データベースが修復された後、オブザーバはそのデータベースとの接続を再確立し、新規スタンバイ・データベースとして回復します。新規プライマリ・データベースが新規スタンバイ・データベースへのREDOデータの転送を開始します。
以降の各項の内容は、次のとおりです。
ブローカでファスト・スタート・フェイルオーバーを有効化するには、次の前提条件を満たしている必要があります。
ブローカ構成が最大可用性モードまたは最大パフォーマンス・モードのいずれかで動作していることを確認します。
保護モード、スタンバイREDOログおよびREDO転送モードの構成の詳細は、「構成に対する保護モードの設定」を参照してください。
ファスト・スタート・フェイルオーバー・ターゲットになる選択したスタンバイ・データベースは、プライマリ・データベースまたは遠隔同期インスタンスから直接REDOを受け取る必要があります。
ファスト・スタート・フェイルオーバーのターゲットに選択したスタンバイ・データベースのLogXptModeプロパティがSYNCかFASTSYNC(最大可用性モードでファスト・スタート・フェイルオーバーを有効化する場合)、またはASYNC(最大パフォーマンス・モードでファスト・スタート・フェイルオーバーを有効化する場合)に設定されていることを確認します。現在のプライマリ・データベースは、LogXptModeプロパティが適切に設定され、スタンバイREDOログが構成されている必要があります。あるいは、RedoRoutesプロパティを使用して、ターゲット・スタンバイと、現在プライマリ・ロールになっているデータベースのためにREDO転送モードを構成します。
ファスト・スタート・フェイルオーバーで遠隔同期インスタンスを使用するには、遠隔同期インスタンスの転送モードはSYNCまたはFASTSYNCに、ターゲット・スタンバイ・データベースの転送モードはASYNCに設定される必要があります。
フラッシュバック・データベースを有効化し、プライマリ・データベースおよびターゲット・スタンバイ・データベースの両方でファスト・リカバリ領域を設定します。
『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
「Oracle Data Guardのインストール」の説明に従って、オブザーバ・コンピュータにDGMGRLコマンドライン・インタフェースをインストールします。
オブザーバ・システムでTNSNAMES.ORAファイルを構成し、オブザーバがプライマリ・データベースおよび事前に選択されたターゲット・スタンバイ・データベースに接続できるようにします。
Oracle ClusterwareもOracle Restartも使用していない場合、オブザーバが回復の一部として自動的にデータベースを再起動できるように、静的サービス名を作成する必要があります。詳細は、「前提条件」を参照してください。
ブローカ構成のデータベースに接続されている間は、任意のサイトからファスト・スタート・フェイルオーバーを有効化できます。ファスト・スタート・フェイルオーバーを有効化しても、フェイルオーバーは起動されません。かわりに、フェイルオーバーのデータベース条件が満たされた場合に、構成を監視しているオブザーバがファスト・スタート・フェイルオーバーを起動できるようになります。(ファスト・スタート・フェイルオーバーの条件を満たす、アプリケーションに固有の条件が他にある場合、これらの条件のいずれかが発生した場合に即時にDBMS_DG.INITIATE_FS_FAILOVER機能をコールしてファスト・スタート・フェイルオーバーを開始するように、アプリケーションを設定できます。「アプリケーションによるファスト・スタート・フェイルオーバーの指示」を参照してください)
ファスト・スタート・フェイルオーバーの有効化およびオブザーバの起動には、次のタスクがあります。これらのタスクでは、SYSとして接続しており、ブローカ構成でプライマリ・データベースおよびスタンバイ・データベースがすでに設定されていることを前提としています。
ファスト・スタート・フェイルオーバーの有効化(タスク1): 使用可能なスタンバイ・データベースのうち、フェイルオーバーのターゲットとして最適なデータベースの決定
ファスト・スタート・フェイルオーバーの有効化(タスク2): FastStartFailoverTarget構成プロパティを使用したターゲット・スタンバイ・データベースの指定
ファスト・スタート・フェイルオーバーの有効化(タスク4): FastStartFailoverThreshold構成プロパティの設定
ファスト・スタート・フェイルオーバーの有効化(タスク5): ファスト・スタート・フェイルオーバー関連の他のプロパティの設定(省略可能)
ファスト・スタート・フェイルオーバーの有効化(タスク6): 追加のファスト・スタート・フェイルオーバー条件の有効化(省略可能)
「ターゲット・スタンバイ・データベースの選択」に示したガイドラインに従います。
現行のプライマリ・データベースのFastStartFailoverTarget構成プロパティを設定する場合、ターゲット・スタンバイ・データベースを1つのみ指定できます。
構成内のスタンバイ・データベースが1つのみである場合、この手順をスキップして手順3に進みます。ファスト・スタート・フェイルオーバーを有効化する際、ブローカにより、プライマリ・データベースおよびスタンバイ・データベースのFastStartFailoverTargetプロパティが、フェイルオーバー時にお互いをそれぞれのターゲットとして指すように自動的に設定されます。
構成内に複数のスタンバイ・データベースがある場合、プライマリ・データベースでFastStartFailoverTargetプロパティを明示的に設定して、ターゲット・スタンバイ・データベースを選択する必要があります。ファスト・スタート・フェイルオーバーを有効化する際、ブローカによりこのプロパティが既存のスタンバイ・データベースを指していることが確認され、今度は反対にこのスタンバイ・データベースのFastStartFailoverTargetプロパティがプライマリ・データベースを指すように設定されます。(ターゲット・スタンバイは遠隔同期スタンバイになれないことに注意してください。ただし、ターゲットは遠隔同期インスタンスからREDOを受け取ることができます。)
注意:
FastStartFailoverTargetプロパティを変更して別のスタンバイ・データベースを指すようにするには、ファスト・スタート・フェイルオーバーを無効化し、FastStartFailoverTargetプロパティを設定し、さらにファスト・スタート・フェイルオーバーを再有効化してください。
このプロパティの詳細は、「FastStartFailoverTarget」を参照してください。
ファスト・スタート・フェイルオーバーは、最大可用性モードまた最大パフォーマンス・モードに対して有効化できます。いかなるデータの消失も許容できない場合は、構成の保護モードが最大可用性に設定されていることを確認してください。そうするには、プライマリ・データベースとターゲット・スタンバイ・データベースの両方のLogXptModeデータベース・プロパティをSYNCまたはFASTSYNCに設定します。次に例を示します。
DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY LogXptMode=SYNC; DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY LogXptMode=SYNC; DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MaxAvailability;
あるいは、RedoRoutesプロパティを使用して、ターゲット・スタンバイと、現在プライマリ・ロールになっているデータベースのためにREDO転送モードを設定します。その後、構成保護モードを最大可用性に設定してください。
わずかなデータの消失よりもプライマリ・データベースのパフォーマンスを重視する場合は、構成の保護モードを最大パフォーマンスに設定してファスト・スタート・フェイルオーバーを有効化することを検討してください。このモードでは、どれだけのデータ消失を許容できるかを秒単位で検討し、それに従ってFastStartFailoverLagLimit構成プロパティを設定する必要があります。このプロパティは、REDO適用に関してターゲット・スタンバイ・データベースがプライマリ・データベースから遅れることができるデータ量を秒単位で指定します。スタンバイ・データベースでREDOが適用された時点がプライマリ・データベースのREDO生成時点からその秒数以内であれば、ファスト・スタート・フェイルオーバーが許可されます。FastStartFailoverLagLimit構成プロパティは、最大パフォーマンス・モードで動作している構成のファスト・スタート・フェイルオーバーが有効化されている場合にのみブローカによって使用されます。デフォルト値は30秒で、設定できる最小値は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;
あるいは、RedoRoutesプロパティを使用して、ターゲット・スタンバイと、現在プライマリ・ロールになっているデータベースのためにREDO転送モードをASYNCに設定します。
オブザーバおよびターゲット・スタンバイ・データベースの両方で、FastStartFailoverThreshold構成プロパティで指定された時間にわたってプライマリ・データベースへの接続が失われた場合、ファスト・スタート・フェイルオーバーが実行されます。
FastStartFailoverThresholdプロパティを設定し、(プライマリ・データベースが使用できないことが検出されてから)フェイルオーバーを開始するまでにオブザーバおよびターゲット・スタンバイ・データベースを待機させる秒数を指定します。次に例を示します。
DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverThreshold = 45;
FastStartFailoverThresholdプロパティのデフォルト値は30秒で、設定できる最小値は6秒です。Oracle RACプライマリ・データベースが存在する場合、インスタンス障害が発生したときに誤ってフェイルオーバーが実行される可能性を最小限にするには、これより大きい値を指定することを考慮します。
この時間間隔は、オブザーバでプライマリ・データベースへの接続が最初に失われたときに開始されます。オブザーバが指定時間内にプライマリ・データベースへの接続を回復できない場合、スタンバイ・データベースがフェイルオーバー可能な状態であれば、オブザーバによりファスト・スタート・フェイルオーバーが開始されます。デフォルト値の30秒は、通常はほとんどの構成で停止および障害を検出できる値ですが、このプロパティでフェイルオーバーの感度を調整することで、一時的に不安定になった環境でフェイルオーバーが誤って実行される可能性を低くすることができます。
REDOの生成が停止し、プライマリ・データベースがオブザーバまたはターゲット・スタンバイ・データベースとの接続を再確立できない場合、FastStartFailoverPmyShutdown構成プロパティがTRUEに設定されていると、FastStartFailoverThresholdの秒数が経過した後にプライマリ・データベースが停止します。
ファスト・スタート・フェイルオーバーが有効化されている場合でもFastStartFailoverThresholdプロパティを変更できることに注意してください。
参照:
FastStartFailoverThresholdプロパティの詳細は、「FastStartFailoverThreshold」を参照してください
必要に応じて、次の表に示されているデータベース・プロパティを設定できます。
| プロパティ名 | 説明 | デフォルト値 |
|---|---|---|
|
この構成プロパティにより、ファスト・スタート・フェイルオーバーが有効化されていてプライマリが ユーザーの構成条件が検出されたためにファスト・スタート・フェイルオーバーが発生した場合、または |
|
|
構成プロパティは、REDOの適用に関して、プライマリよりスタンバイが遅れることができる許容範囲を秒単位で確立します。この値を超えて遅れる場合は、ファスト・スタート・フェイルオーバーが実行されません。設定可能な最小値は10秒です。 このプロパティは、ファスト・スタート・フェイルオーバーが有効化され、構成が最大パフォーマンス・モードで動作しているときに使用します。 |
30秒 |
|
この構成プロパティを使用すると、プライマリ・データベースが分離またはクラッシュしたためにファスト・スタート・フェイルオーバーが開始した場合に、元のプライマリ・データベースが自動的に回復されます。この場合に元のプライマリ・データベースを自動的に回復しないようにするには、この構成プロパティを |
|
|
このデータベース・プロパティは、オブザーバがプライマリおよびスタンバイ・データベースに接続して監視する方法を指定するために使用されます。REDOデータの転送に使用される接続識別子とは異なる識別子( |
オブザーバは、 |
|
|
|
|
|
0(ゼロ) |
デフォルトでは、構成された時間しきい値(FastStartFailoverThreshold)の経過後にオブザーバもスタンバイもプライマリにアクセスできないと、ファスト・スタート・フェイルオーバーが実行されます。
必要に応じて、ファスト・スタート・フェイルオーバーを発生させるデータベース健全性条件を指定することができます。次の表に、これらの条件を示します。
| 健全性条件 | 説明 | デフォルトで有効化 |
|---|---|---|
データファイル・オフライン |
書込みエラーのためにデータファイルがオフラインになりました。 |
はい |
破損したディクショナリ |
重要なデータベースのディクショナリが破損しました。現時点では、この状態は、データベースがオープンされている場合にのみ検出されます。 |
はい |
破損した制御ファイル |
ディスク障害のために制御ファイルが永続的に破損しました。 |
はい |
アクセス不可能なログ・ファイル |
I/OエラーのためにLGWRがログ・グループのどのメンバーにも書き込むことができません。 |
いいえ |
スタック・アーカイバ |
デバイスに空き容量がないかデバイスを使用できないためにアーカイバがREDOログをアーカイブできません。 |
いいえ |
Oracle RAC構成では、アクセス不可能なログ・ファイルおよびスタック・アーカイバの健全性条件は、単一インスタンスにのみ適用できます。これらの条件によるファスト・スタート・フェイルオーバーは、Oracle Clusterwareによって提供される可用性オプションに優先して実行されるので、有効化する前によく検討してください。
Cloud ControlまたはDGMGRLのENABLE FAST_START FAILOVER CONDITIONコマンドおよびDISABLE FAST_START FAILOVER CONDITIONコマンドを使用して、ファスト・スタート・フェイルオーバーが実行される特定の条件を指定できます。
Cloud Controlのファスト・スタート・フェイルオーバー・ウィザードまたはDGMGRLのENABLE FAST_START FAILOVERコマンドを使用して、ファスト・スタート・フェイルオーバーを有効化します。ファスト・スタート・フェイルオーバーを有効化するには、プライマリ・データベースおよびターゲット・スタンバイ・データベースの両方が動作しており、接続され、さらに「ファスト・スタート・フェイルオーバーを有効化するための前提条件」にリストされた前提条件をすべて満たしている必要があります。
Cloud Controlを使用したファスト・スタート・フェイルオーバーの有効化
Cloud Controlでファスト・スタート・フェイルオーバーを有効にするには、ファスト・スタート・フェイルオーバー・ウィザードを使用します。Oracle Data Guardの「概要」ページで、「ファスト・スタート・フェイルオーバー」ステータス・フィールドの横にある「無効」をクリックして、「ファスト・スタート・フェイルオーバー」ページを開きます。次に、「ファスト・スタート・フェイルオーバー: モードを変更」ページで、「有効」をクリックします。Cloud Controlによってオブザーバが起動されます。次に、「ファスト・スタート・フェイルオーバー: 構成」ページで、フェイルオーバーのターゲットとするスタンバイ・データベースを選択します。役立つアドバイスについては、「ターゲット・スタンバイ・データベースの選択」を参照してください。このページでは、保護モードを変更できません。ファスト・スタート・フェイルオーバーは、現在の保護モードに従って有効化されます。現在構成されているモードが最大保護の場合、Cloud Controlは、モードを最大可用性にダウングレードします。
DGMGRLを使用したファスト・スタート・フェイルオーバーの有効化
DGMGRLを使用してファスト・スタート・フェイルオーバーを有効化するには、オブザーバ・コンピュータ上のデータベースを含むブローカ構成内のいずれかのデータベースに接続している間に、ENABLE FAST_START FAILOVERコマンドを発行します。次に例を示します。
DGMGRL> ENABLE FAST_START FAILOVER; Enabled.
注意:
スタンバイ・データベースが事前の予告なしにプライマリ・ロールを引き継ぐ場合があるため、ターゲット・スタンバイ・サイトでの管理はプライマリ・サイトでの管理と同じくらい包括的である必要があります。スタッフ・サポート、ハードウェアとソフトウェア、セキュリティ(ソフトウェアとサイトの両方)、ネットワーク接続および帯域幅が両方のサイトで同等である必要があります。
オブザーバを起動するには、プライマリ・データベースが実行されている必要があります。
ファスト・スタート・フェイルオーバーを有効化する前または後にオブザーバを起動できます。ファスト・スタート・フェイルオーバーが有効化されている場合、オブザーバは、プライマリ・データベースおよびターゲット・スタンバイ・データベースのステータスおよび接続の監視をただちに開始します。ファスト・スタート・フェイルオーバーが有効化されていない場合、オブザーバは、ファスト・スタート・フェイルオーバーが有効化されるまで待機してから監視を開始します。
Cloud Controlを使用したオブザーバの起動
Cloud Controlエージェントがオブザーバ・コンピュータにインストールされている場合、Cloud Controlを介してファスト・スタート・フェイルオーバーを有効にすると、オブザーバが自動的に起動されます。エージェントが存在しない場合、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 Observer Reconnect: (none) Observer Override: FALSE 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構成プロパティに指定された時間内にプライマリ・データベースに再接続しようとします。FastStartFailoverThresholdの時間間隔は、オブザーバがプライマリ・データベースに障害があることを最初に検出したときに開始されます。
ユーザーが構成可能な条件が発生したことをオブザーバが検出した場合、またはDBMS_DG.INITIATE_FS_FAILOVER関数でファスト・スタート・フェイルオーバーを要求した場合、FastStartFailoverThresholdプロパティに指定された時間間隔は無視されます。
プライマリ・データベースがOracle Real Application Clusters(Oracle RAC)データベースである場合、オブザーバは残りのプライマリ・インスタンスのいずれかに接続しようとします。Oracle RACプライマリ・データベースを構成するすべてのインスタンスに障害が発生したことが検出されていないかぎり、ファスト・スタート・フェイルオーバーは実行されません。オブザーバは、データベース・プロパティDGConnectIdentifierまたはObserverConnectIdentifierに指定された値を使用して、プライマリ・データベースおよびファスト・スタート・フェイルオーバーのターゲット・スタンバイ・データベースに接続します。オブザーバは、これらのプロパティに指定された値を使用して、Oracle RACデータベースの任意のインスタンスに接続できる必要があります。
ターゲット・スタンバイ・データベースがフェイルオーバー可能な状態であることを確認します。
ファスト・スタート・フェイルオーバーが開始されると、オブザーバはターゲット・スタンバイ・データベースがプライマリ・データベース・ロールにフェイルオーバーする準備ができているかどうかを確認します。
次の場合、ファスト・スタート・フェイルオーバーは実行できません。
ファスト・スタート・フェイルオーバーが有効でない場合
オブザーバがターゲット・スタンバイ・データベースに接続できない場合
参照:
オブザーバが動作していない場合は、「オブザーバに障害が発生した場合の動作」を参照
ブローカ構成の現在の状態に関して、オブザーバおよびターゲット・スタンバイ・データベースに一貫性がない場合
オブザーバが動作していない場合
保護モードが最大可用性で、プライマリ・データベースに障害が発生したときにターゲット・スタンバイ・データベースがプライマリ・データベースと同期化されていない場合
保護モードが最大パフォーマンスで、プライマリ・データベースに障害が発生したときにターゲット・スタンバイ・データベースのREDO適用時点がプライマリ・データベースのREDO生成時点からFastStartFailoverLagLimit構成プロパティで指定された時間を超えて遅れる場合
ターゲット・スタンバイ・データベースがプライマリ・データベースと通信している場合。ただし、ObserverOverride構成プロパティがTRUEに設定されている場合は、フェイルオーバーが試みられます。
ターゲット・スタンバイ・データベースのV$DATABASEビュー内のFS_FAILOVER_STATUS列に、ファスト・スタート・フェイルオーバーを実行できない理由が表示された場合
手動フェイルオーバーがすでに進行中です。手動フェイルオーバーの詳細は、「手動フェイルオーバー」を参照してください。
ABORTオプションを使用せずにプライマリ・データベースを停止した場合
ファスト・スタート・フェイルオーバーを開始します。
ターゲット・スタンバイ・データベースがフェイルオーバー可能な状態である場合、オブザーバの指示により、ただちにターゲット・スタンバイ・データベースがプライマリ・データベース・ロールにフェイルオーバーします。他のなんらかの理由でフェイルオーバーを実行できない場合、オブザーバはスタンバイ・データベースでフェイルオーバーの準備ができたかどうかをチェックし続けます。ただし、オブザーバはプライマリ・データベースへの再接続も無期限に試行し続けます。スタンバイがフェイルオーバーに同意する前にプライマリ・データベースに再接続すると、オブザーバはファスト・スタート・フェイルオーバーの開始の試行を中止します。
元のプライマリ・データベースを新規スタンバイ・データベースとして回復します。
ファスト・スタート・フェイルオーバーが正常に完了した後、元のプライマリ・データベースへの接続が再確立され、FastStartFailoverAutoReinstate構成プロパティがTRUEに設定されている場合、オブザーバは元のプライマリ・データベースの新規スタンバイ・データベースとしての回復を試行します。FastStartFailoverPmyShutdown構成プロパティをTRUEに設定した場合、元のプライマリ・データベースは自動的に停止しているため、オブザーバが回復を試行する前に、手動で再起動する必要があります。
プライマリがクラッシュしたか、オブザーバおよびターゲット・スタンバイ・データベースから分離したためにファスト・スタート・フェイルオーバーが発生した場合にのみ、これらのプロパティがプライマリの停止および自動回復の実行を左右する点に注意してください。
参照:
回復の詳細は、「ブローカ構成に含まれる元のプライマリ・データベースの回復」を参照
ファスト・スタート・フェイルオーバーが有効化されている場合、次の操作は禁止されています。
変更:
構成保護モード
REDOをターゲット・スタンバイ・データベースまたは現在プライマリ・ロールになっているデータベースに送信するために使用されるREDO転送モード
プライマリ・データベースまたはターゲット・スタンバイ・データベースのFastStartFailoverTarget構成プロパティ
プライマリ・データベースまたはターゲット・スタンバイ・データベースのRedoRoutesプロパティ
遠隔同期インスタンスがプライマリ・データベースからREDOを受け取ってターゲット・スタンバイ・データベースにREDOを送信する場合、そのRedoRoutesプロパティ
無効化または削除:
ブローカ構成
ファスト・スタート・フェイルオーバーのターゲットであるスタンバイ・データベース
プライマリ・データベースからREDOを受け取ってターゲット・スタンバイ・データベースにREDOを送信する場合の遠隔同期インスタンス
手動フェイルオーバーの実行:
「ファスト・スタート・フェイルオーバーが有効化されている場合の手動によるロール変更の実行」にリストされた条件を満たしていない場合
ファスト・スタート・フェイルオーバーのターゲットとして構成されていないスタンバイ・データベースに対する実行
構成がファスト・スタート・フェイルオーバーを実行可能な状態かどうかを判断するには、DGMGRLのSHOW DATABASE <target-standby-database>コマンドを発行するか、プライマリ・データベースまたはターゲット・スタンバイ・データベースのいずれかでV$DATABASEビューを問い合せます。ファスト・スタート・フェイルオーバーを実行できる状態である場合、V$DATABASE.FS_FAILOVER_STATUSの列値は、最大可用性モードではSYNCHRONIZED、最大パフォーマンス・モードではTARGET UNDER LAG LIMITです。ターゲット・スタンバイ・データベースについては、FS_FAILOVER_OBSERVER_PRESENT列にはYESと表示されます。
ファスト・スタート・フェイルオーバーのターゲットとして構成されていないスタンバイ・データベースへのスイッチオーバーの実行
スタンバイ・データベースがプライマリ・データベースと同期化されている場合を除く、最大可用性モードで動作している構成のターゲット・スタンバイ・データベースへのスイッチオーバーの実行
スタンバイ・データベースがプライマリ・データベースのラグ制限内にある場合を除く、最大パフォーマンス・モードで動作している構成のターゲット・スタンバイ・データベースへのスイッチオーバーの実行
プライマリ・データベースのオープンの試行。オープンを試行すると、次のエラーが戻される場合あります。
ORA-16649: possible failover to another database prevents this database from being opened
ファスト・スタート・フェイルオーバーの妥当性チェックが失敗するか、2分未満で完了しないと、このエラーが戻されることがあります。
スタンバイがマウントされているが、オープンされていない場合、SQL ALTER DATABASE MOVE DATAFILEコマンドを使用して、ファスト・スタート・フェイルオーバーのターゲットとなっているフィジカル・スタンバイ上のオンライン・データ・ファイルを名称変更するか、再配置します。
プライマリ・データベースまたはスタンバイ・データベースが通常の方法で(SHUTDOWN NORMAL、SHUTDOWN IMMEDIATEまたはSHUTDOWN TRANSACTIONALを使用して)停止された場合、ファスト・スタート・フェイルオーバーは起動されません。通常の停止では、プライマリ・データベースおよびスタンバイ・データベースが再度接続され通信状態になるまで、ファスト・スタート・フェイルオーバーを実行できません。
ファスト・スタート・フェイルオーバーが有効化されている場合でも、次の条件を満たしているかぎり、スイッチオーバーまたは手動フェイルオーバーを実行できます。
ロール変更の対象が、プライマリ・データベース上のFastStartFailoverTargetデータベース・プロパティで指定されたスタンバイ・データベースと同一であること。
ターゲット・スタンバイ・データベースがプライマリ・データベースと同期化されていること(最大可用性モードで動作している構成の場合)またはターゲット・スタンバイ・データベースがラグ制限内にあること(最大パフォーマンス・モードで動作している構成の場合)。
手動フェイルオーバーの場合、オブザーバが起動しており、ターゲット・スタンバイ・データベースと通信していること。手動フェイルオーバーを実行する前に、プライマリ・データベースが停止されていることを確認する必要があります。
注意:
必要な場合は、FORCEオプションを使用してファスト・スタート・フェイルオーバーを無効化できます。「ファスト・スタート・フェイルオーバーの無効化」を参照してください。
参照:
スイッチオーバーおよび手動フェイルオーバーの詳細は、それぞれ「スイッチオーバー」および「手動フェイルオーバー」を参照してください
DBMS_DG PL/SQLパッケージを使用して、特定のアプリケーションのファスト・スタート・フェイルオーバー設定をカスタマイズできます。アプリケーションに独自に認識される重大な条件が検出されたとき、アプリケーションはDBMS_DG.INITIATE_FS_FAILOVER機能をコールして、即時ファスト・スタート・フェイルオーバーを開始できます。この機能は、接続から構成内のプライマリ・データベースまたはいずれかのスタンバイ・データベースにコールできます。プロシージャがコールされたデータベースは、オブザーバにそれを通知します。フェイルオーバー・ターゲット・データベースがフェイルオーバーを受け入れるために適した状態であれば(監視されており、同期化されているかラグ制限内であれば)、オブザーバによりただちにファスト・スタート・フェイルオーバーが開始されます。オブザーバによってファスト・スタート・フェイルオーバーが開始されると、プライマリ・データベースは自動的に停止します。オブザーバは元のプライマリ・データベースの回復を試行しません。
構成がフェイルオーバー不能の場合、DBMS_DG.INITIATE_FS_FAILOVER機能は、ORAエラー番号(例外ではなく)を返して、ファスト・スタート・フェイルオーバーを実行できないことをコール元に通知します。
注意:
可能であればオブザーバがフェイルオーバーを開始するため、アプリケーションでDBMS_DG.INITIATE_FS_FAILOVER機能をコールする際には注意が必要です。
参照:
DBMS_DGパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
オブザーバが起動しており、構成がファスト・スタート・フェイルオーバー可能な状態かどうかを確認するには、DGMGRLのSHOW DATABASE <target-standby-database>コマンドを発行するか、ターゲット・スタンバイ・データベースでV$DATABASEビューを問い合せます。
V$FS_FAILOVER_STATSビューを問い合せて、システムで発生しているファスト・スタート・フェイルオーバーに関する統計を表示することもできます。
次に、DGMGRL SHOWコマンドを使用してファスト・スタート・フェイルオーバー情報を表示する例を示します。次のビューについても説明します。
例1: SHOW FAST_START FAILOVER
DGMGRLのSHOW FAST-START FAILOVERコマンドは、すべてのファスト・スタート・フェイルオーバー関連情報を表示します。次に例を示します。
DGMGRL> SHOW FAST_START FAILOVER; Fast-Start Failover: ENABLED Threshold: 60 seconds Target: South_Sales Observer: observer.example.com Lag Limit: 30 seconds (not in use) Shutdown Primary: TRUE Auto-reinstate: TRUE Observer Reconnect: (none) Observer Override: FALSE Configurable Failover Conditions Health Conditions: Corrupted Controlfile YES Corrupted Dictionary YES Inaccessible Logfile NO Stuck Archiver NO Datafile Offline YES Oracle Error Conditions: (none)
例2: SHOW CONFIGURATION VERBOSE
次の例は、DRSolution構成のファスト・スタート・フェイルオーバー情報を示しています。
Configuration - DRSolution Protection Mode: MaxAvailability Databases: North_Sales - Primary database South_Sales - (*) Physical standby database (*) Fast-Start Failover target Properties: FastStartFailoverThreshold = '60' OperationTimeout = '30' TraceLevel = 'USER' FastStartFailoverLagLimit = '30' CommunicationTimeout = '180' ObserverReconnect = '0' FastStartFailoverAutoReinstate = 'TRUE' FastStartFailoverPmyShutdown = 'TRUE' BystandersFollowRoleChange = 'ALL' ObserverOverride = 'FALSE' ExternalDestination1 = '' ExternalDestination2 = '' PrimaryLostWriteAction = 'CONTINUE' Fast-Start Failover: ENABLED Threshold: 30 seconds Target: South_Sales Observer: observer.example.com Lag Limit: 30 seconds (not in use) Shutdown Primary: TRUE Auto-reinstate: TRUE Observer Reconnect: (none) Observer Override: FALSE 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列
| 列値 | 説明 | ファスト・スタート・フェイルオーバー |
|---|---|---|
|
ファスト・スタート・フェイルオーバーは有効化されていますが、このスタンバイ・データベースはファスト・スタート・フェイルオーバーのターゲットではありません。このデータベースはファスト・スタート・フェイルオーバーのステータス情報を提供できません。 |
有効 |
|
ファスト・スタート・フェイルオーバーは無効化されています。 |
不可 |
|
プライマリ・データベースのデータ・ディクショナリのコピーをロードし終えていないロジカル・スタンバイ・データベースにのみ表示されます。 |
不可 |
|
ターゲット・スタンバイ・データベースが、プライマリ・データベースと |
不可 |
|
障害が発生したプライマリ・データベースの新規スタンバイ・データベースとしての回復に失敗しました。ブローカの |
完了済 |
|
障害が発生したプライマリ・データベースは、新規プライマリに対する新規スタンバイ・データベースとして回復する必要があります。オブザーバにより回復プロセスが自動的に開始されます。 |
完了済 |
|
ターゲット・スタンバイ・データベースとの接続が切断され、 フェイルオーバーが実行された可能性が高いため、プライマリ・データベースが停止またはストールします。 注意: この状態は、ファスト・スタート・フェイルオーバーが可能で、ターゲット・スタンバイ・データベースもオブザーバも存在しないときに起動し、データベースのオープンを継続可能かどうかを確認した場合にもプライマリで発生します。 |
可 |
|
構成が最大パフォーマンス・モードで動作しているとき、プライマリ・データベースの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
ファスト・スタート・フェイルオーバーを無効化すると、オブザーバはターゲット・スタンバイ・データベースへのフェイルオーバーを開始できなくなります。この場合、手動フェイルオーバーが可能な場合があります。手動フェイルオーバーの詳細は、「手動フェイルオーバー」を参照してください。
注意:
ファスト・スタート・フェイルオーバーを無効にしても、オブザーバは停止されません。オブザーバを停止するには、「オブザーバの停止」を参照してください。
ファスト・スタート・フェイルオーバーを無効にするには、Cloud Controlのファスト・スタート・フェイルオーバー・ウィザードまたはDGMGRLのDISABLE FAST_START FAILOVER [FORCE]コマンドを使用します。FORCEオプションを使用すると、エラーが発生した場合でも、接続先のデータベースでファスト・スタート・フェイルオーバーが無効化されます。FORCEオプションが必要かどうかは、プライマリ・データベースおよびターゲット・スタンバイ・データベースにネットワーク接続が存在するかどうかによって決まります。
プライマリ・データベースおよびターゲット・スタンバイ・データベースにネットワーク接続が存在し、接続先のデータベースがプライマリ・データベースとネットワークで接続されている場合、FORCEオプションを使用しても効果はありません。オプションを指定せずにDISABLE FAST_START FAILOVERを使用してください。この方法では、ブローカ構成内のすべてのデータベースでファスト・スタート・フェイルオーバーが無効化されます。
無効化操作中にエラーが発生した場合、ブローカによりエラー・メッセージが戻され、無効化操作が停止されます。
プライマリ・データベースおよびターゲット・スタンバイ・データベースにネットワーク接続が存在しないか、または接続先のデータベースにプライマリ・データベースとのネットワーク接続が存在しない場合、DISABLE FAST_START FAILOVERをFORCEオプションとともに使用することを考慮します。
DISABLE FAST_START FAILOVER FORCEコマンドを発行した場合、ブローカはブローカ構成内のすべてのデータベースでファスト・スタート・フェイルオーバーをi無効化できない場合があります。その結果、フェイルオーバーの条件を満たしているとオブザーバが判別した場合に、オブザーバがターゲット・スタンバイ・データベースへのファスト・スタート・フェイルオーバーを実行しないという保証がなくなります。次のリストに、プライマリ・データベース、ターゲット・スタンバイ・データベースおよびファスト・スタート・フェイルオーバーのターゲットでないスタンバイ・データベースでDISABLE FAST_START FAILOVER FORCEコマンドが発行された場合に、ブローカ構成でファスト・スタート・フェイルオーバーが無効化される範囲を示しています。
次のデータベースでこのコマンドを発行した場合、次のようになります。
プライマリ・データベースとの接続が存在しないターゲット・スタンバイ・データベースで発行した場合、ターゲット・スタンバイ・データベースでのみファスト・スタート・フェイルオーバーが無効化されます。この場合、オブザーバではフェイルオーバーの条件を満たしていてもファスト・スタート・フェイルオーバーを実行できません。ファスト・スタート・フェイルオーバーの発生を確実に防ぐには、ターゲット・スタンバイ・データベースに接続しているときにFORCEオプションを使用してファスト・スタート・フェイルオーバーを無効化します。
プライマリ・データベースおよびターゲット・スタンバイ・データベースのネットワーク接続が回復すると、ブローカによりブローカ構成全体のファスト・スタート・フェイルオーバーが無効化されます。
プライマリ・データベースで発行した場合、構成内のネットワーク接続が確立されたすべてのデータベースで、ファスト・スタート・フェイルオーバーの無効化が試行されます。プライマリ・データベースとターゲット・スタンバイ・データベースとの接続が確立されていない場合、ターゲット・スタンバイ・データベースではファスト・スタート・フェイルオーバーが有効のままとなり、フェイルオーバーの条件を満たした場合にオブザーバによりファスト・スタート・フェイルオーバーが試行されます。
注意:
この処理を実行すると、ファスト・スタート・フェイルオーバーが発生した場合に、構成内の2つのデータベースで同時にプライマリ・データベース・ロールが引き継がれる可能性があります。このため、ターゲット・スタンバイ・データベースにこのコマンドを最初に発行する必要があります。
プライマリ・データベースとの接続が存在しない別のスタンバイ・データベースで発行した場合、このデータベースではファスト・スタート・フェイルオーバーが無効化されます。ターゲット・スタンバイ・データベースでファスト・スタート・フェイルオーバーが無効化されていないため、フェイルオーバーの条件を満たした場合に、オブザーバによりターゲット・スタンバイ・データベースへのファスト・スタート・フェイルオーバーが試行される場合があります。
プライマリ・データベースとスタンバイ・データベース(非ターゲット)のネットワーク接続が回復すると、ブローカの現在のファスト・スタート・フェイルオーバーの設定(ENABLEDまたはDISABLED)がターゲットでないスタンバイに伝播されます。
注意:
ネットワークが切断されており、プライマリ・データベースまたはプライマリ・データベースと接続されていないスタンバイ・データベースでDISABLE FAST_START FAILOVER FORCEコマンドを発行した場合、ブローカ構成内の一部のデータベースでファスト・スタート・フェイルオーバーが無効化されない場合があります。結果として、フェイルオーバーの条件を満たしている場合、オブザーバによりターゲット・スタンバイ・データベースへのファスト・スタート・フェイルオーバーが開始される可能性があります。これにより、構成内の2つのデータベースで同時にプライマリ・データベース・ロールが引き継がれる可能性があります。
FORCEオプションを必要とする条件
FORCEオプションを使用しないファスト・スタート・フェイルオーバーの無効化が正常に実行されるのは、コマンドが発行されたデータベースとプライマリ・データベースの間にネットワーク接続が存在し、プライマリ・データベースとターゲット・スタンバイ・データベースの間にネットワーク接続が存在する場合のみです。ファスト・スタート・フェイルオーバーを無効化するには、この方法をお薦めします。
ただし、プライマリ・データベースとターゲット・スタンバイ・データベースの間にネットワーク接続が存在しない場合、またはファスト・スタート・フェイルオーバーの無効化コマンドを発行したデータベースとプライマリ・データベースとの間にネットワーク接続が存在しない場合に、ファスト・スタート・フェイルオーバーを無効化する必要があることも考えられます。ネットワーク接続が失われている場合、フェイルオーバーの条件を満たした場合に、オブザーバによりターゲット・スタンバイ・データベースへのファスト・スタート・フェイルオーバーが試行される場合があるので注意してください。次の場合は、ファスト・スタート・フェイルオーバーの無効化にFORCEオプションを使用することをお薦めします。
ネットワーク障害により、プライマリ・データベースがオブザーバおよびターゲット・スタンバイ・データベースから分離された場合(フェイルオーバーの条件を満たす前)。
この場合、プライマリ・データベースが分離されている間にファスト・スタート・フェイルオーバーが実行された可能性があるため、プライマリ・データベースがストールし、トランザクションをコミットできなくなります。ネットワークの切断が長時間にわたると予想され、プライマリ・データベースを使用可能にする必要がある場合は、まず、ターゲット・スタンバイ・データベースにファスト・スタート・フェイルオーバーが実行されていないことを確認します。次に、プライマリ・データベースでFORCEオプションによりファスト・スタート・フェイルオーバーを無効化します。可能な場合、プライマリ・データベースでFORCEオプションによりファスト・スタート・フェイルオーバーを無効化する前に、ターゲット・スタンバイ・データベースにファスト・スタート・フェイルオーバーが実行されていないことを確認します。
注意:
この処理により、構成内の2つのデータベースで同時にプライマリ・データベース・ロールが引き継がれる可能性があります。ターゲット・スタンバイでFORCEオプションによりファスト・スタート・フェイルオーバーを最初に無効化しておくと、これを回避できます。
構成内のスタンバイ・データベースに手動フェイルオーバーを実行する場合(たとえば、プライマリ・データベースおよびターゲット・スタンバイ・データベースがフェイルオーバー可能でないときにプライマリ・データベースで障害が発生したため)。
この場合、データベースがフェイルオーバー可能でないため、ファスト・スタート・フェイルオーバーを実行できません。同じ理由で、ターゲット・スタンバイ・データベースへの手動フェイルオーバーを実行できません。続行するには、まずFORCEオプションを使用してファスト・スタート・フェイルオーバーを無効にしてから、手動フェイルオーバーを実行する必要があります。
注意:
この処理によりデータが失われ、構成内の2つのデータベースで同時にプライマリ・データベース・ロールが引き継がれる可能性があります。ターゲット・スタンバイでFORCEオプションによりファスト・スタート・フェイルオーバーを最初に無効化しておくと、これを回避できます。
ターゲット・スタンバイ・データベースへのファスト・スタート・フェイルオーバーに失敗した場合。
なんらかの理由でフェイルオーバーに失敗した場合、ターゲット・スタンバイ・データベースがフェイルオーバー可能かどうかにかかわらず、ターゲット・スタンバイ・データベースが動作不能になる可能性があります。フェイルオーバーに使用できる別のスタンバイ・データベースが存在する場合、まずそのスタンバイ・データベースでFORCEオプションを使用してファスト・スタート・フェイルオーバーを無効化してから、そのスタンバイ・データベースへの手動フェイルオーバーを実行できます。
まもなくプライマリ・データベースによりサービスが再開されるため、ファスト・スタート・フェイルオーバーを実行しないようにする場合。
この場合、ターゲット・スタンバイ・データベースでFORCEオプションを使用してファスト・スタート・フェイルオーバーを無効にします。プライマリ・データベースとターゲット・スタンバイ・データベースとの接続が回復すると、構成内のすべてのデータベースでファスト・スタート・フェイルオーバーが無効化されます。
Cloud Controlを使用したファスト・スタート・フェイルオーバーの無効化
ファスト・スタート・フェイルオーバー・ウィザードで「無効化」をクリックします。次に、「続行」をクリックして次のページに進みます。詳細は、Cloud Controlのオンライン・ヘルプを参照してください。
DGMGRLを使用したファスト・スタート・フェイルオーバーの無効化
DISABLE FAST_START FAILOVERコマンドまたはDISABLE FAST_START FAILOVER FORCEコマンドを発行します。詳細は、「Oracle Data Guardコマンドライン・インタフェース・リファレンス」の「DISABLE FAST_START FAILOVER」コマンドを参照してください。
ファスト・スタート・フェイルオーバーを使用する際のパフォーマンスを向上させるには、次の推奨事項を考慮します。
フェイルオーバー時間は、ターゲット・スタンバイ・データベース(フィジカルまたはロジカル・スタンバイ・データベース)がプライマリ・データベースから受け取ったREDOデータをすべて適用したかどうかによって決まります。
最大パフォーマンス・モードで動作している構成でファスト・スタート・フェイルオーバーを有効化すると、REDOデータが非同期でターゲット・スタンバイに転送されるため、プライマリ・データベースでの全体的なパフォーマンスが向上します。この場合はデータが消失しないことが保証されないことに注意してください。
スタンバイ・データベースへのREDOデータの適用がプライマリ・データベースのREDO適用率と一致した状態が保たれるように、リカバリを最適化する手順を実行すると、ファスト・スタート・フェイルオーバーが高速になります。ログ適用率を最適化するには、次のようにします。
データベース・プロパティDelayMinsを設定することにより、スタンバイ・データベースへのアーカイブREDOログ・ファイルの適用を遅延させないでください(詳細は、「ログ適用サービスの管理」を参照してください)。
フィジカル・スタンバイ・データベースのログ適用率のチューニングの詳細は、『Oracle Data Guard概要および管理』を参照してください。
次の場所にあるホワイト・ペーパー『Oracle Maximum Availability Architecture』を参照してください。
FastStartFailoverLagLimit構成プロパティを設定する際は、パフォーマンスとデータ消失の可能性の間のトレードオフを考慮してください。
ラグ制限を低くすると、データの消失は最小限に抑えられますが、プライマリ・データベースのパフォーマンスに影響を与える場合があります。
ラグ制限を高くすると、消失データ量が増加する可能性がありますが、プライマリ・データベースのパフォーマンスへの影響は緩和されます。
オブザーバは、ブローカのDGMGRLクライアント側コンポーネントに統合されており、プライマリ・データベースまたはスタンバイ・データベースおよびブローカ構成を管理するコンピュータとは異なるコンピュータ上で動作します。オブザーバは、継続的にファスト・スタート・フェイルオーバー環境を監視して、プライマリ・データベースが使用可能であることを確認します。(「ファスト・スタート・フェイルオーバーの有効化およびオブザーバの実行」を参照)。オブザーバの主な目的は、停止時間が長くなる可能性がある、手動フェイルオーバー・プロセスで必要な人的操作を少なくすることで、高可用性および完全自動コンピューティングを強化することです。
Cloud ControlのOracle Data Guardの概要ページまたはDGMGRLコマンドを使用して、オブザーバを管理できます。図5-2に、オブザーバによるファスト・スタート・フェイルオーバー構成の監視を示しています。
次の各項では、オブザーバの管理情報を説明します。
オブザーバは、プライマリ・システムおよびスタンバイ・システムとは別のコンピュータ・システムにインストールし、動作させる必要があります。オブザーバのインストールおよび起動は、ファスト・スタート・フェイルオーバーの使用における必須部分であり、次の各項で詳細に説明しています。
「Oracle Data Guardのインストール」では、オブザーバ・システムに、Oracle Client Administratorのみをインストールできるか、Oracle Database Enterprise EditionまたはPersonal Editionを完全インストールできるかのどちらかであることを説明しています。
「ファスト・スタート・フェイルオーバーの有効化」では、ファスト・スタート・フェイルオーバーを有効化する段階的なプロセスの一部として、オブザーバの起動方法を説明しています。DGMGRLを使用してオブザーバを起動する例は、「使用例6: ファスト・スタート・フェイルオーバーの有効化とオブザーバの起動」を参照してください。
ブローカ構成を監視するオブザーバは1つのみ存在できます。別のオブザーバを起動しようとすると、ブローカにより次のエラー・メッセージが戻されます。
ORA-16647: could not start more than one observer
オブザーバを起動するには、SYSDGまたはSYSDBA権限を持つアカウントでDGMGRLにログインできる必要があります。オブザーバは、DGMGRLでOracle Data Guard構成に接続したときに使用したSYS資格証明を使用してプライマリ・データベースおよびターゲット・スタンバイ・データベースに接続するOCIクライアントです。
参照:
オブザーバとDGMGRLの間の互換性要件の詳細は、http://support.oracle.comにあるMy Oracle Supportノート1625597.1を参照してください
単一ホスト上での複数のオブザーバの起動
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;
オブザーバに関する情報を検索するには、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 |
|---|---|---|---|
プライマリ |
|
最大可用性 |
|
スタンバイ |
|
最大可用性 |
|
プライマリ |
|
最大パフォーマンス |
|
スタンバイ |
|
最大パフォーマンス |
|
次の例では、プライマリ・データベースとオブザーバの間のネットワークに障害が発生したと仮定しています。この場合、FS_FAILOVER_STATUSおよびFS_FAILOVER_OBSERVER_PRESENT列は次の表に示すように表示され、ファスト・スタート・フェイルオーバーは実行されません。
| データベース | FS_FAILOVER_STATUS | FS_FAILOVER_OBSERVER_PRESENT |
|---|---|---|
プライマリ |
|
|
スタンバイ |
|
|
プライマリ・データベースとターゲット・スタンバイ・データベースの間の接続が維持された状態でオブザーバからの接続が失われた場合、ブローカにより、構成が監視されていないと報告されます。 構成およびデータベースのステータスにより、オブザーバが動作していないと報告され、次のいずれかのステータス・メッセージが戻されます。
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オンライン・ヘルプを参照してください。
ObserverOverrideおよびObserverReconnectプロパティを使用すると、プライマリへの接続をさらに制御できます。
オブザーバが、FastStartFailoverThresholdプロパティで指定されているより長い期間、プライマリ・データベースへの接続を失った場合、スタンバイ・データベースへのフェイルオーバーが試みられます。FastStartFailoverThresholdプロパティで指定された期間内にスタンバイがプライマリからアクセスを受けた場合、フェイルオーバーは試行されません。
この動作をオーバーライドして、オブザーバがFastStartFailoverThresholdで指定された秒数より長い間プライマリにアクセスできない場合にファスト・スタート・フェイルオーバーが行われるようにするには、ObserverOverrideプロパティをTRUEに設定します。次に例を示します。
DGMGRL> EDIT CONFIGURATION SET PROPERTY ObserverOverride=TRUE;
通常、オブザーバは一度プライマリに接続したら、接続に障害が発生しないかぎり、再接続を試みません。プライマリへのネットワーク接続の健全性をテストする手段として、オブザーバがプライマリ・データベースに定期的に再接続する場合は、ObserverReconnect構成プロパティを使用します。これは、オブザーバがプライマリ・データベースに対して新しい接続を確立する頻度を指定します。次の例では、ObserverReconnectが30秒に設定されています。この場合、オブザーバは30秒ごとにプライマリ・データベースに対して新しい接続を確立します。
DGMGRL> EDIT CONFIGURATION SET PROPERTY ObserverReconnect=30;
ファスト・スタート・フェイルオーバーを使用しない場合(「ファスト・スタート・フェイルオーバーの無効化」を参照)、またはオブザーバを別のホスト・マシンに移動する場合は(「オブザーバの別のコンピュータへの移動」を参照)、オブザーバを停止できます。
ファスト・スタート・フェイルオーバーが有効化されているときにオブザーバを停止するには、プライマリ・データベースおよびターゲット・スタンバイ・データベースが接続されており、相互に通信している必要があります。オブザーバを停止しても、ファスト・スタート・フェイルオーバーは無効化されません。ただし、ターゲット・スタンバイ・データベースが監視されない状態の場合、ファスト・スタート・フェイルオーバーは実行できません。
ファスト・スタート・フェイルオーバーが有効化されているが、プライマリ・データベースとスタンバイ・データベースが相互に分離している場合にオブザーバを停止するには、FORCEオプションを使用してまずファスト・スタート・フェイルオーバーを無効化してから、オブザーバを停止する必要があります。(FORCEオプションを使用する際に考慮すべき重要事項については、「ファスト・スタート・フェイルオーバーの無効化」を参照してください。)
ファスト・スタート・フェイルオーバーが有効化されていない場合にオブザーバを停止するには、プライマリ・データベースが動作している必要があります。プライマリ・データベースとネットワークで接続されたブローカ構成内のデータベースに接続しているときは、次の方法でオブザーバを停止できます。
Cloud Controlの使用
ファスト・スタート・フェイルオーバー・ウィザードの1ページ目で「オブザーバを停止」オプションを選択し、ページ下部の「続行」をクリックします。詳細は、Cloud Controlのオンライン・ヘルプを参照してください。
DGMGRLの使用
次のコマンドを発行します。
DGMGRL> STOP OBSERVER;
詳細は、STOP OBSERVERコマンドを参照してください。
注意:
オブザーバは、STOP OBSERVERコマンドを発行してすぐには停止しません。ブローカがSTOP OBSERVER要求を受け取ると、要求は次回オブザーバがブローカと通信する際にオブザーバに渡され、その後にオブザーバは停止します。
オブザーバを別のコンピュータに移動する手順は、次のとおりです。
オブザーバを移動する際にファスト・スタート・フェイルオーバーを無効化する必要はありません。
オブザーバでは、オブザーバを起動した作業ディレクトリに作成されているバイナリ・ファイルで、ファスト・スタート・フェイルオーバー構成に関する情報が永続的にメンテナンスされます。デフォルトでは、オブザーバの起動時に、現行の作業ディレクトリにこのファイルが作成され、fsfo.datという名前が付けられます。このファイルには、プライマリ・データベースおよびターゲット・スタンバイ・データベースの両方に対する接続識別子が含まれます。
権限のないユーザーはこのファイルを読めないことを確認します。
オブザーバの起動後は、ファイルの名前および場所を変更できません。ただし、オブザーバの起動にDGMGRLのSTART OBSERVERコマンドを使用し、FILE IS修飾子を含める場合は、ファイルの名前または場所を変更できます。詳細は、START OBSERVERコマンドを参照してください。
注意:
オブザーバが通常と異なる方法で(CTRL/Cを入力するなど)停止された場合、オブザーバを再起動し、FILE IS修飾子を含む既存のfsfo.datファイルを参照してください。
オブザーバが実行中でファスト・スタート・フェイルオーバーが有効化されている環境へパッチを適用する場合は、パッチを適用する前に次の手順を実行してください。
DGMGRL STOP OBSERVERコマンドを使用してオブザーバを停止します。このコマンドを正常に実行するには、プライマリとターゲット・スタンバイの接続が確立されている必要があります。
DGMGRL DISABLE FAST_START FAILOVERコマンドを使用してファスト・スタート・フェイルオーバーを無効化します。このコマンドを正常に実行するには、プライマリとターゲット・スタンバイの接続が確立されている必要があることに注意してください。
すべてのデータベースにパッチが正常に適用された後、次の手順に従ってファスト・スタート・フェイルオーバーを有効化しオブザーバを起動してください。
ENABLE FAST_START FAILOVERコマンドを使用してファスト・スタート・フェイルオーバーを有効化します。このコマンドを正常に実行するには、プライマリとターゲット・スタンバイの接続が確立されている必要があります。START OBSERVERコマンドを使用してオブザーバを起動します。FastStartFailoverAutoReinstate構成プロパティをTRUEに設定すると、プライマリ・データベースがクラッシュするか、オブザーバおよびターゲット・スタンバイ・データベースとの接続が失われたことが原因でファスト・スタート・フェイルオーバーが開始された場合、オブザーバは元のプライマリ・データベースのスタンバイ・データベースとしての回復を自動的に試行します。回復により、ブローカ構成に対する高可用性がリストアされるため、新規プライマリ・データベースに障害が発生した場合に、別のファスト・スタート・フェイルオーバーが実行されます。回復されたデータベースは、新規プライマリ・データベースのファスト・スタート・フェイルオーバーのターゲットとして機能し、後続のファスト・スタート・フェイルオーバーが可能になります。新規スタンバイ・データベースは、新規プライマリ・データベースからのREDOデータの受信を開始した時点で、フェイルオーバーの実行可能なターゲットとなります。
オブザーバによる元のプライマリ・データベースの自動回復を可能にするには、データベースを起動およびマウントする必要がありますが、オープンしないでください。オープンしている場合、オブザーバは元のプライマリ・データベースを再起動してマウント済状態にしてからデータベースを回復します。ブローカは、データベースを新しいプライマリ・データベースのスタンバイ・データベース(元のスタンバイと同じタイプ)として回復します。
元のプライマリ・データベースが自動的に回復されない場合、DGMGRLのREINSTATEコマンドまたはCloud Controlを使用して手動で回復できます。手動回復の段階的な手順は、「ロール変更後の無効化されたデータベースの再有効化」を参照してください。
回復がサポートされるのは、ブローカ構成でフェイルオーバーを実行した後に限られます。また、プライマリ・データベースおよびターゲット・スタンバイ・データベースの両方でフラッシュバック・データベースを有効化する必要があります。すべてのファスト・スタート・フェイルオーバーおよび回復の要件の詳細は、「ファスト・スタート・フェイルオーバーを有効化するための前提条件」を参照してください。
次の場合、ブローカでは元のプライマリ・データベースを自動的に回復できません。
ユーザーが構成可能な条件が検出されたためにファスト・スタート・フェイルオーバーが発生した場合、またはDBMS_DG.INITIATE_FS_FAILOVER関数をコールしてアプリケーションで要求した場合
FastStartFailoverAutoReinstateがFALSEに設定されている場合
ファスト・スタート・フェイルオーバーの完了後、元のプライマリ・データベースが再起動されるまでに別のフェイルオーバーまたはスイッチオーバーが発生した場合
ファスト・スタート・フェイルオーバーが無効化されている場合
オブザーバが元のプライマリ・データベースに接続できない場合
元のプライマリ・データベースが新規プライマリ・データベースに接続できない場合
元のプライマリ・データベースおよび新規プライマリ・データベースが、同じファスト・スタート・フェイルオーバー環境内で構成されていない場合
ファスト・スタート・フェイルオーバーが無効化されているとき、手動フェイルオーバーによって元のプライマリ・データベースが無効化された場合
注意:
スイッチオーバー、手動フェイルオーバーまたはファスト・スタート・フェイルオーバーの実行時にスタンバイ・データベースを無効した場合は、自動的に回復されません。
自動回復に失敗した場合、ブローカによりエラーがログに記録され、元のプライマリ・データベースはマウントされた状態のままとなります。この時点で、次のいずれかを実行できます。
ファスト・スタート・フェイルオーバーを無効化し(「ファスト・スタート・フェイルオーバーの無効化」を参照)、元のプライマリ・データベースのオープンを試行する
「ロール変更後の無効化されたデータベースの再有効化」の説明に従って、元のプライマリ・データベースを手動で回復する
この項では、ブローカ管理のフェイルオーバーが発生したときに、ローカル・データベース・サービスに接続しているデータベース・クライアントで使用可能な、イベント通知およびデータベース接続フェイルオーバーのサポートについて説明します。グローバル・サービスのイベント通知とデータベース接続フェイルオーバー・サポートの詳細は、『Oracle Database概要および管理ガイド』を参照してください。
フェイルオーバー後、ブローカは高速アプリケーション通知(FAN)イベントを発行します。FANイベントは次の方法で使用できます。
アプリケーションでOracle Database JDBC、Oracle Database Oracle Call Interface(OCI)、Oracle Data Provider for .NET(ODP.NET)、Universal Connection Pool for JavaのいずれかのOracle統合データベース・クライアントを使用している場合、プログラムを変更せずにFANを使用できます。これらのクライアントには、フェイルオーバー後に自動的に新規プライマリ・データベースに接続する高速接続フェイルオーバー(FCF)を構成できます。
JAVAアプリケーションはJDBC FANアプリケーション・プログラミング・インタフェースを利用してFANをプログラムで使用することで、FANイベントにサブスクライブし、イベント受信時にイベント処理アクションを実行できます。
FANのサーバー側コールアウトをデータベース層で構成できます。
Oracle Database 12c以降のすべてのOracle統合データベース・クライアントでは、FANイベントは、Oracle Notification Service(ONS)を使用して発行されます。以前のリリースの場合、OCIとODP.NETクライアントは、Oracle Advanced Queuing (AQ)を介してFAN通知を受け取ります。
注意:
ONSを使用してFANイベントを発行するには、単一インスタンスのデータベースをOracle Restartに登録する必要があります。
参照:
Oracle Real Application Clusters(Oracle RAC)データベースでのFAN、FCFおよびONSの構成の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。
単一インスタンス・データベースでのOracle Restart、FAN、FCFおよびONSの構成の詳細は、『Oracle Database管理者ガイド』を参照してください。
この項では、ブローカ管理のフェイルオーバーによって生成されたFANイベントを発行および適切に処理するために満たす必要のある構成要件について説明します。
これらの要件は、前述のマニュアルおよび次のクライアント固有ガイドに記載されている要件を補足するものです。
『Oracle Database JDBC開発者ガイド』
Oracle Call Interfaceプログラマーズ・ガイド
『Oracle Data Provider for .NET開発者ガイドfor Microsoft Windows』
FCFを実行するには、クライアントはフェイルオーバー後に新しいプライマリ・データベースを検出できる必要があります。この項では、この要件に合せてOracle Netの接続記述子を構成する方法について説明します。
接続記述子は次のいずれかの方法で構成できます。
どちらの場合も、接続記述子にSERVICE_NAMEパラメータを含める必要があります。
注意:
この項で示した例では、必ずしもご使用の環境で使用する必要のある特定の属性を示しているわけではありません。必要な属性は構成によって異なります(ご使用の環境がOracle RACベースか単一インスタンスかどうかも含めて)。詳細は、適切なOracle RACまたはOracle Restartのマニュアルを参照してください。
データベース・サービスは、Oracle RACデータベースの特定のデータベース・ロール、およびOracle Restartにより管理される単一インスタンス・データベースでアクティブになるように構成できます。ブローカはOracle ClusterwareまたはOracle Restartと相互に作用して、適切なデータベース・サービスがアクティブになり、ロール変更後に適切なFANイベントが発行されるようにします。
FANイベントは常にONSを使用して発行されます。ただし、データベースが新規プライマリ・データベースでプライマリ・ロールになっている場合、フェイルオーバーを通知するイベントは、アクティブに構成されているデータベース・サービスに対してのみ発行されます。
任意のデータベース・ロールでアクティブでなければならないサービス(プライマリ、フィジカル・スタンバイ、ロジカル・スタンバイまたはスナップショット・スタンバイ)は、サービスがアクティブでなければならない各データベースで明示的にServer Controlユーティリティ(SRVCTL)によって構成する必要があります。次のコマンドの例では、サービスPAYROLLがプライマリ・データベースNORTHのPRIMARYでアクティブになるように構成されています。また、スタンバイ・データベースSOUTHのPRIMARYロールでもアクティブになるように構成されているため、ロール・トランジションが発生した場合にはそのデータベースでアクティブになります。これらのサンプル・コマンドで、省略記号(...)は、必要に応じて指定するadd serviceの他のオプションを示します。
プライマリ・データベースNORTH上で、次を実行します。
srvctl add service –db NORTH –service PAYROLL –role PRIMARY ...
スタンバイ・データベースSOUTH上で、次を実行します。
srvctl add service –db SOUTH –service PAYROLL –role PRIMARY ...
サービスを現在のプライマリ・データベースで起動するかどうかにかかわらず、データベースがフィジカル・スタンバイ・ロールになっているときにアクティブにするサービスも、そのデータベースで作成および起動する必要があります。これは、サービス定義がREDOストリームを介してフィジカル・スタンバイ・データベースに伝播されるようにするためです。これにより、サービスをフィジカル・スタンバイ・データベースで起動できるようになります。サービスをフィジカル・スタンバイで起動できるのは、サービスを起動することによって生成されたREDOが適用された後のみです。サービスがロール変更の前後で同じように動作するように、すべてのデータベース上ですべてのSRVCTL add serviceオプションが同一であることが重要です。
すべてのデータベースが同じ値を持たない場合、SRVCTLは値を上書きしようとしますが、フィジカル・スタンバイ・データベースで失敗します。これは、データベースが読取り専用でオープンであるためです。次のコマンドの例では、サービスsalesがプライマリ・データベースNORTHのPHYSICAL_STANDBYロールでアクティブになるように構成されています。その後、プライマリ・データベースで起動および停止されます。このサービスを現在のプライマリ・データベース上で実行しない場合は、オプションでプライマリ・データベースから削除することもできます。これは、フィジカル・スタンバイ・データベースSOUTHのPHYSICAL_STANDBYロールでもアクティブになるように構成されます。
次をプライマリ・データベースNORTHで実行します。
srvctl add service -db NORTH -service SALES -role PHYSICAL_STANDBY ... srvctl start service –db NORTH –service SALES srvctl stop service –db NORTH –service SALES
次をフィジカル・スタンバイ・データベースSOUTHで実行します。
srvctl add service -db SOUTH -service SALES -role PHYSICAL_STANDBY ...
ここでブローカによりスイッチオーバーまたはフェイルオーバーが実行されると、データベースのロールに基づいて、適切なデータベース上でSALESサービスが自動的に開始されます。
前述の各例では、データベースに1つのサービスのみを設定する方法を説明しました。次の例では、データベースに複数のサービスを設定する方法を示し、また、ブローカを使用することによって適切なサービスが適切なデータベース上で確実に開始される仕組みについて説明します。
プライマリ・データベースがBOSTON、スタンバイ・データベースがCHICAGOであると仮定します。次のSRVCTLコマンドを発行して、Data Guard構成内の両方のデータベースが、各データベースで実行する可能性のある2つのサービスについて認識するようにします。
BOSTONの場合
srvctl add service -db BOSTON -service SALESRW -role PRIMARY -y AUTOMATIC srvctl add service -db BOSTON -service SALESRO -role PHYSICAL_STANDBY -policy AUTOMATIC
CHICAGOの場合:
srvctl add service -db CHICAGO -s SALESRW -role PRIMARY -y AUTOMATIC srvctl add service -db CHICAGO -s SALESRO -role PHYSICAL_STANDBY -policy AUTOMATIC
まず、正しいノード上でサービスを手動で開始する必要があります。また、SALESROサービスをプライマリ上で開始して停止し、このサービスをスタンバイ上で開始できるようにすることも必要です。次のSRVCTLコマンドを発行します。
BOSTONの場合:
srvctl start service -db BOSTON -service SALESRW srvctl start service -db BOSTON -service SALESRO srvctl stop service -db BOSTON -service SALESRO
CHICAGOの場合:
srvctl start service -db CHICAGO -service SALESRO
これで、適切なサービスが適切なデータベース上で実行されています。
ブローカによってスイッチオーバーまたはフェイルオーバーが実行されると、データベースの現在のロールに基づいて、サービスSALESRWまたはSALESROが開始されます。したがって、SALESRWはCHICAGO (現在のプライマリ)上で開始され、SALESROはBOSTON (現在のフィジカル・スタンバイ)上で開始されます。いずれかのデータベースが停止して起動した場合も、同じことが発生します。つまり、起動するデータベースのロールに適したサービスが開始されます。
これらのデータベースのそれぞれで次の手動コマンドを発行すると、SRVCTLの-role修飾子で以前に指定された内容に関係なく、SALESROおよびSALESRWの両方のサービスがこれらのデータベース上で開始されることに注意してください。これは、-role修飾子がData Guard Brokerによってのみ、データベースの起動時に考慮されるからです。
BOSTONの場合:
srvctl start service -db CHICAGO
CHICAGOの場合:
srvctl start service -db BOSTON
SRVCTLユーティリティではデータベース・ロールが自動的に考慮されないため、サービスを手動で開始するときは常に、開始するサービスの名前を指定する必要があります。
注意:
サービスが自動的に起動するように構成されている場合(-policy AUTOMATIC)、データベース・ロールが変更された後にのみ、自動的に起動します。
注意:
Oracle Data Guard構成では、スタンバイ・データベースのSRVCTL -startoptionは、スイッチオーバー後には、常にOPENに設定されます。
参照:
Oracle Restartにより管理される単一インスタンス・データベースでの、SRVCTLユーティリティを使用するデータベース・サービスの構成の詳細は、『Oracle Database管理者ガイド』を参照してください。
Oracle RACデータベースでの、SRVCTLユーティリティを使用するデータベース・サービスの構成の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。
クライアント側のONS構成を使用する場合、クライアント側のONS構成ファイルで、プライマリ・データベースおよび各スタンバイ・データベースのONSデーモンのホスト名およびポートを指定する必要があります。
クライアントでリモートONSサブスクリプションを使用する場合、クライアントでプライマリ・データベースおよび各スタンバイ・データベースのONSデーモンのホスト名およびポートを指定する必要があります。
アプリケーション・コンティニュイティは、データベース・セッションを使用不可にするリカバリ可能なエラーの後に、データベースに対するリクエストを中断せず、迅速な方法でリプレイできるようにするOracle Databaseの機能です。
Oracle Data Guardのフィジカル・スタンバイ・データベースへのスイッチオーバーに対し、アプリケーション・コンティニュイティがサポートされています。最大可用性のデータ保護モードの場合、フィジカル・スタンバイへのファスト・スタート・フェイルオーバーもサポートされます。プライマリ・データベースとスタンバイ・データベースには、Oracle RACまたはOracle Active Data Guardのライセンスを付与して、アプリケーション・コンティニュイティを使用できるようにする必要があります。
参照:
アプリケーション・コンティニュイティの詳細は、『Oracle Database開発ガイド』を参照してください
