手動フェイルオーバー

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

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

ノート:

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

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

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

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]の解決のガイドラインに従います。このサポート・ノートは、https://support.oracle.comにあります。

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

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

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

データベースがOracle Clusterwareによって管理されている場合、ブローカはどのインスタンスのプラガブル・データベース(PDB)もオープンしません。かわりに、ブローカがスイッチオーバーの完了をOracle Clusterwareエージェントに通知すると、Oracle Clusterwareエージェントがサービス構成に基づいて特定のインスタンスのPDBをオープンします。

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

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

ターゲット・スタンバイ・データベースを選択するためのガイドラインは、次のとおりです。

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

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

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

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

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

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

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

DGMGRL> FAILOVER TO database-name;

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

ORA-752エラーがスタンバイ・データベースで発生した場合
ORA-600 [3020]エラーがスタンバイ・データベースで発生し、その原因がプライマリ・データベースでの書込み欠落であるとOracleサポートが判断した場合
完全フェイルオーバーが不可能な場合

DGMGRL> FAILOVER TO database-name IMMEDIATE;

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

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

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

ノート:

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

フェイルオーバーは、現在のターゲット・スタンバイ・データベースに対してのみ実行できます。
ブローカでは、保護モードが最大保護である場合を除き、フェイルオーバー前に有効であった保護モードが保持されます。この場合は、ブローカにより保護モードが最大可用性に設定され、後で、同期されたフィジカル・スタンバイ・データベースが使用可能になったときに最大保護モードにアップグレードされます。

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

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

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

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

注意:

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

完全フェイルオーバーが完了すると、新しいプライマリ・データベースのスタンバイとして実行可能でないその他のスタンバイ・データベースは、ブローカにより無効化されます。これは次のいずれかの理由で実行されます。
- その他のスタンバイ・データベースに、新しいプライマリ・データベースがスタンバイ・データベースであったときに適用されたよりも多くのREDOデータが適用された場合。新しいプライマリ・データベースのスタンバイとして機能させるには、このスタンバイ・データベースを再作成または回復する必要があります。
- ロジカル・スタンバイ・データベースにフェイルオーバーした場合。構成内のすべてのフィジカルおよびスナップショット・スタンバイ・データベースがブローカにより無効化されます。それらが新しいプライマリ・データベースのスタンバイになるようにするには、それらを新しいプライマリ・データベースのコピーから再作成する必要があります。

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

完全フェイルオーバーの起動後にブローカが実行するアクションは、次のとおりです。

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

ターゲットがスナップショット・スタンバイ・データベースの場合、ブローカは、最初にデータベースをフィジカル・スタンバイに戻し、次にREDO Applyを起動してすべての累積REDOを適用してから、フェイルオーバーを完了してデータベースをプライマリ・データベースとしてオープンします。
ターゲット・スタンバイ・データベースを、次のように、プライマリ・データベース・ロールに遷移させます。
1. データベースのロールをスタンバイからプライマリに変更します。
2. 新しいプライマリ・データベースを読取り/書込みモードでオープンします。
3. フェイルオーバー操作に関係しなかったスタンバイ・データベースを、新しいプライマリ・データベースより多くのREDOデータが適用されたために無効化する必要があるかどうかを判断します。
  
  このフェイルオーバー中に、その他のスタンバイ・データベースがブローカにより無効化されない場合は、フェイルオーバー前と同じ状態のままになります。たとえば、APPLY-OFF状態であったフィジカル・スタンバイ・データベースは、APPLY-OFF状態のままになります。
  
  デフォルトでは、ブローカは、完全フェイルオーバーを実行するたびにその他のスタンバイ・データベースが新しいプライマリに対する実行可能なスタンバイ・データベースであるかどうかを判別します。完全フェイルオーバーの実行時に、その他のスタンバイ・データベースの実行可能性のチェックをスキップして、全フェイルオーバー時間を短縮するには、BystandersFollowRoleChange構成プロパティをNONEに設定してください。
  
  このプロパティをNONEに設定すると、ブローカは、新しいプライマリ・データベースよりも多くのREDOデータが適用されているかどうかのチェックを実行せずに、その他のすべてのスタンバイ・データベースを無効にします。フェイルオーバーの完了後にスタンバイ・データベースを回復または再作成(「ロール変更後の無効化されたデータベースの再有効化」項を参照)する必要があります。SHOW CONFIGURATIONコマンドを使用して、回復可能なデータベースと再作成する必要のあるデータベースを表示します。このプロパティの値を表示するには、SHOW CONFIGURATION BystandersFollowRoleChangeコマンドを使用します。デフォルト値はALLです。
  
  このプロパティは、ファスト・スタート・フェイルオーバーの発生時にその他のスタンバイ・データベースの実行可能性チェックをスキップするかどうかにも影響を与えます。
4. REDO転送サービスを起動して、無効化されていないすべてのその他のスタンバイ・データベースへのREDOデータの転送を開始します。
  
  ノート:
  
  フェイルオーバー中には、その他のスタンバイ・データベースがブローカにより無効化される場合があります。新しいプライマリ・データベースのスタンバイ・データベースとして機能させるには、これらのデータベースを回復または再作成する必要があります。すべてのデータベースでフラッシュバック・データベースを構成し、フィジカル・スタンバイ・データベースにフェイルオーバーを実行した場合に、無効化されたスタンバイ・データベースをより簡単に回復できるようにすることをお薦めします。ロジカル・スタンバイ・データベースにフェイルオーバーを実行した場合、すべてのフィジカルおよびスナップショット・スタンバイ・データベースがブローカにより無効化されます。この場合、データベースの回復にフラッシュバック・データベースは使用できません。新しいプライマリ・データベースのコピーから再作成する必要があります。フェイルオーバー中に無効化されたロジカル・スタンバイ・データベースは回復できます。
Oracle Clusterwareに、フェイルオーバーのターゲット・データベースがOracle RACフィジカルまたはスナップショット・スタンバイ・データベースである場合にはフェイルオーバー前に停止された可能性があるインスタンスをすべて再起動するよう指示します。

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

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

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

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

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

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

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

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

使用可能なREDOデータがすべて適用されるまで待機せずに、スタンバイ・データベースのREDO ApplyまたはSQL Applyを即時停止します。この作業によってデータが失われる可能性があります。
ターゲットのスタンバイ・データベースをプライマリ・ロールに遷移させ、新しいプライマリ・データベースを読取り/書込みモードでオープンし、REDO転送サービスを起動します。

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

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

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

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

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

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

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

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

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

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

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

データベースが回復可能な場合は、データベースで次のステータスが示されます。
```
ORA-16661: The standby database must be reinstated
```
「データベースの回復方法」の説明に従って、DGMGRLのREINSTATE DATABASEコマンドまたはCloud Controlの回復オプションを使用してデータベースを回復します。ブローカにより、データベースは回復処理の一部として再有効化されます。
新規プライマリ・データベースのコピーからデータベースを再作成する必要がある場合、データベースのステータスが次のようになります。
```
ORA-16795: The standby database needs to be re-created
```
無効化されたデータベースの再作成および再有効化の方法の説明に従って、プライマリ・データベースのコピーからスタンバイ・データベースを再作成し、再有効化します。

ノート:

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

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

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

データベースの回復方法

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

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

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

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

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

データベースを再起動してマウント済状態にします。
新規プライマリ・データベースに接続します。
Cloud ControlまたはDGMGRLを使用して、データベースを回復します。

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

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

Cloud Controlを使用した回復

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

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

DGMGRLを使用した回復

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

DGMGRL> REINSTATE DATABASE db_unique_name;

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

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

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

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

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

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