| Oracle® Data Guard概要および管理 12c リリース1 (12.1) B71304-07 |
|
 前 |
 次 |
Oracle Data Guard構成は、プライマリ・ロールで機能する1つのデータベース、およびスタンバイ・ロールで機能する1つ以上のデータベースで構成されています。データベースの現行のロールを確認するには、V$DATABASEビューのDATABASE_ROLE列を問い合せます。
Oracle Data Guard構成内のスタンバイ・データベースの数、位置、タイプおよびプライマリ・データベースからのREDOデータを各スタンバイ・データベースに伝播する方法に応じて、プライマリ・データベースの停止に対して設定できるロール管理オプションが決定します。
Oracle Data Guard構成でロールの推移を管理する方法の詳細は、次の各項を参照してください。
注意:
これらの項では、SQL文を使用して、手動でロールの推移を実行する方法について説明します。ブローカにより管理されるOracle Data Guard構成でロールの推移を実行する場合は、これらのマニュアルの手順は使用しないでください。Oracle Data Guard Brokerで提供されているトランジション・プロシージャをかわりに使用します。
関連項目:
Oracle Data Guard Brokerの使用による以下の詳細は、『Oracle Data Guard Broker』を参照してください。
Oracle Enterprise Manager Cloud Controlでキー・クリックを1回する、あるいはDGMGRLコマンドライン・インタフェースで単一のコマンドを使用すると起動できることにより、スイッチオーバーおよびフェイルオーバーを単純化します。
プライマリ・データベースが使用できなくなった場合に、ファスト・スタート・フェイルオーバーを有効化し、フェイルオーバーを自動的に行います。ファスト・スタート・フェイルオーバーが有効化されている場合、Oracle Data Guardブローカによってフェイルオーバーの必要性が判断され、指定されたターゲット・スタンバイ・データベースへのフェイルオーバーが自動的に開始されます。DBAによる操作は不要です。
データベースは、プライマリまたはスタンバイという相互に排他的なロールのいずれかで動作します。Oracle Data Guardでは、SQL文を使用して、またはOracle Data Guard Brokerのいずれかのインタフェースを使用して、これらのロールを動的に変更できます。Oracle Data Guardは、次のロール・トランジションをサポートしています。
プライマリ・データベースが、スタンバイ・データベースの1つを使用してロールを切り替えられるようにします。スイッチオーバー時には、データは消失しません。スイッチオーバーの完了後、各データベースは、新しいロールとともにOracle Data Guard構成に継続して含まれます。
プライマリ・データベースの障害時に、スタンバイ・データベースをプライマリ・ロールに変更します。障害の前にプライマリ・データベースが最大保護モードまたは最大可用性モードで動作していなかった場合、データ消失が発生することがあります。フラッシュバック・データベースがプライマリ・データベースで使用可能になっている場合は、障害の原因が修正された後、元どおり新しいプライマリ・データベースのスタンバイに戻すことができます。
「ロールの推移の準備」では、停止時間およびデータ消失のリスクを最小限にするために、どのロールの推移を選択するかについて説明します。「スイッチオーバー」および「フェイルオーバー」では、それぞれスイッチオーバーとフェイルオーバーの詳細を説明します。
関連項目:
ブローカの管理対象のフェイルオーバーが発生した場合にデータベース・クライアントが使用可能なイベント通知、およびデータベース接続フェイルオーバー・サポートの詳細は、『Oracle Data Guard Broker』を参照してください。
各データベースが、担う予定のロールについて正しく構成されていることを確認します。プライマリ・データベースとスタンバイ・データベースでデータベース初期化パラメータ、ARCHIVELOGモード、スタンバイREDOログ、オンラインREDOログを構成する方法の詳細は、「フィジカル・スタンバイ・データベースの作成」および「ロジカル・スタンバイ・データベースの作成」を参照してください。
注意:
スイッチオーバーまたはフェイルオーバーの発生時に、すべてのスタンバイ・サイトが新しいプライマリ・データベースから引き続きREDOデータを受信するように、各スタンバイ・データベース上でLOG_ARCHIVE_DEST_nおよびLOG_ARCHIVE_DEST_STATE_nパラメータを定義する必要があります。
プライマリ・データベースでV$ARCHIVE_DEST_STATUSビューを問い合せて、スタンバイ・データベースにREDO転送エラー、またはREDOギャップがないことを確認します。
たとえば、LOG_ARCHIVE_DEST_2に関連付けられているスタンバイ・データベースのステータスをチェックするには、次の問合せを使用します。
SQL> SELECT STATUS, GAP_STATUS FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2; STATUS GAP_STATUS --------- ------------------------ VALID NO GAP
スタンバイ・データベースに対応する行のSTATUS列の値がVALID、GAP_STATUS列の値がNOGAPになるまで、次に進まないでください。
スタンバイ・データベースに存在する一時ファイルが、プライマリ・データベースの一時ファイルと一致することを確認します。
新たにプライマリ・データベースになるスタンバイ・データベースで現在有効になっているREDOの適用遅延を解除します。 遅延を解除しないと、スイッチオーバー時間が長くなり、今後のリリースでスイッチオーバーが許可されなくなります。
リアルタイム問合せモードにあるフィジカル・スタンバイ・データベースへのスイッチオーバーを実行する前に、できるだけ迅速に、クリーンにロール・トランジションを実施させるために、そのスタンバイ・データベースのすべてのインスタンスを、マウント済だがオープンされていない状態にすることを検討します。
Oracle Database 12cリリース1 (12.1)現在、Oracle RACプライマリ・データベースからフィジカル・スタンバイ・データベースにスイッチオーバーを実行する場合、1つを残してすべてのプライマリ・データベース・インスタンスを停止する必要はなくなりました。
複数のスタンバイ・データベースがあるOracle Data Guard構成の場合、ロールの推移のターゲット・スタンバイ・データベースを選択する際には、多数の要因を考慮する必要があります。次のような要因があります。
スタンバイ・データベースのローカリティ。
スタンバイ・データベースの機能(CPU数、使用可能なI/O帯域幅などのハードウェア仕様)。
ロールの推移の実行に要する時間。これは、スタンバイ・データベースがREDOデータの適用でどの程度遅れているか、およびアプリケーションの可用性とデータ消失をどの程度柔軟にトレードオフできるかに影響を受けます。
スタンバイ・データベースのタイプ。
ロールの推移のターゲットとして選択されたスタンバイのタイプにより、構成内の他のスタンバイ・データベースがロールの推移後にどのように動作するかが決まります。ロールの推移の前に新しいプライマリがフィジカル・スタンバイだった場合、構成内の他のスタンバイ・データベースは新しいプライマリのスタンバイになります。ロールの推移の前に新しいプライマリがロジカル・スタンバイだった場合、構成内の他のロジカル・スタンバイは新しいプライマリのスタンバイになりますが、構成内のフィジカル・スタンバイは引き続き古いプライマリのスタンバイであるため、新しいプライマリを保護しません。後者の場合、次回のスイッチオーバーまたはフェイルオーバーで元のプライマリ・データベースに戻ると、すべてのスタンバイが現行のプライマリのスタンバイとしての元のロールに戻ります。これらの理由により、フィジカル・スタンバイとロジカル・スタンバイの両方が含まれる構成内におけるロールの推移の最適なターゲットは、通常、フィジカル・スタンバイです。
注意:
スナップショット・スタンバイは、ロールの推移のターゲットにはできません。スナップショット・スタンバイ・データベースをロールの推移のターゲットとして使用するには、最初にこのデータベースをフィジカル・スタンバイ・データベースに変換し、プライマリ・データベースから受信したすべてのREDOを適用できるようにします。「フィジカル・スタンバイ・データベースへのスナップショット・スタンバイ・データベースの変換」を参照してください。
Oracle Data GuardにはV$DATAGUARD_STATSビューが用意されています。このビューを使用して、スタンバイ・データベースのデータの最新性の観点で各スタンバイ・データベースを評価し、使用可能なREDOデータがすべてスタンバイ・データベースに適用された場合のロールの推移の実行に必要な時間を評価できます。次に例を示します。
SQL> COLUMN NAME FORMAT A24 SQL> COLUMN VALUE FORMAT A16 SQL> COLUMN DATUM_TIME FORMAT A24 SQL> SELECT NAME, VALUE, DATUM_TIME FROM V$DATAGUARD_STATS; NAME VALUE DATUM_TIME ------------------------ ---------------- ------------------------ transport lag +00 00:00:00 06/18/2009 12:22:06 apply lag +00 00:00:00 06/18/2009 12:22:06 apply finish time +00 00:00:00.000 estimated startup time 9
この問合せの出力は、スタンバイ・データベースが、プライマリ・データベースにより生成されたすべてのREDOを受信し、適用したことを示しています。これらの統計は、2009年6月18日12:22.06にプライマリ・データベースから受信したデータを使用して計算されたものです。
apply lagおよびtransport lagメトリックは、プライマリ・データベースから受信されるデータに基づいて計算されます。これらのメトリックは、プライマリ・データベースとスタンバイ・データベースの間の通信が中断されると失効します。apply lagおよびtransport lagメトリックのDATUM_TIME列の値が変化していないことは、プライマリ・データベースとスタンバイ・データベース間の通信障害と考えられる原因で、これらのメトリックが更新されずに失効したことを示しています。
スイッチオーバーは、通常、オペレーティング・システムやハードウェアのアップグレード、またはOracleデータベース・ソフトウェアとパッチ・セットのローリング・アップグレードなど、計画的な停止によるプライマリ・データベースの停止時間を短縮するために使用します(「SQL Applyを使用したOracle Databaseのアップグレード」を参照)。
スイッチオーバーは、2つのフェーズで実行されます。最初のフェーズで、既存のプライマリ・データベースがスタンバイ・ロールに推移します。2番目のフェーズで、スタンバイ・データベースがプライマリ・ロールに推移します。
図9-1は、データベースのロールを切り替える前の2つのサイトにあるOracle Data Guard構成を示します。この構成では、プライマリ・データベースはサンフランシスコにあり、スタンバイ・データベースはボストンにあります。
図9-2に、元のプライマリ・データベースがスタンバイ・データベースにスイッチオーバーされた後、元のスタンバイ・データベースがまだ新しいプライマリ・データベースになっていないOracle Data Guard環境を示します。このとき、Oracle Data Guard構成には一時的に2つのスタンバイ・データベースが存在することになります。
図9-3は、スイッチオーバー実行後のOracle Data Guard環境を示します。元のスタンバイ・データベースは新しいプライマリ・データベースになります。現在、プライマリ・データベースはボストンにあり、スタンバイ・データベースはサンフランシスコにあります。
スイッチオーバーの準備
「ロールの推移の準備」に示した前提条件が満たされていることを確認します。また、スイッチオーバーの場合は、次の前提条件が満たされている必要があります。
フィジカル・スタンバイ・データベースが関与するスイッチオーバーの場合は、プライマリ・データベースがオープンし、REDO Applyがスタンバイ・データベースでアクティブであることを確認します。REDO Applyの詳細は、「REDOデータのフィジカル・スタンバイ・データベースへの適用」を参照してください。
ロジカル・スタンバイ・データベースが関与するスイッチオーバーの場合は、プライマリおよびスタンバイ・データベース・インスタンスの両方がオープンし、SQL Applyがアクティブであることを確認します。REDO Applyの詳細は、「REDOデータのロジカル・スタンバイ・データベースへの適用」を参照してください。
通常、フェイルオーバーは、プライマリ・データベースが使用不可能になり、適正な時間内にプライマリ・データベースをリストアしてサービスを再開できない場合にのみ使用します。フェイルオーバー時に実行するアクションは、フェイルオーバーに関与するスタンバイ・データベースがロジカルかフィジカルか、フェイルオーバー時のOracle Data Guard構成の状態、およびフェイルオーバーを開始するために使用する特定のSQL文によって異なります。
図9-4に、サンフランシスコにあるプライマリ・データベースからボストンにあるフィジカル・スタンバイ・データベースへのフェイルオーバーの結果を示します。
フェイルオーバーの準備
注意:
フェイルオーバーのために選択した物理スタンバイ・データベースで管理されているスタンバイ・リカバリが、ORA-752またはORA-600 [3020]のエラーで停止した場合は、このまま「プライマリ・データベースでの書込みの欠落エラーからのリカバリ」に進んでください。
可能な場合は、フェイルオーバーを実行する前に、使用可能な未適用のプライマリ・データベースREDOデータを可能なかぎりスタンバイ・データベースに転送します。
「ロールの推移の準備」に示した前提条件が満たされていることを確認します。また、フェイルオーバーの場合は、次の前提条件が満たされている必要があります。
最大保護モードで実行中のスタンバイ・データベースがフェイルオーバーに関与する場合は、スタンバイ・データベースで次の文を発行して、データベースを最大パフォーマンス・モードにします。
SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;
適切なスタンバイ・データベースが使用できる場合は、フェイルオーバーが完了した後に、新しいプライマリ・データベースで希望の保護モードをリセットできます。
最大保護モードに設定されているスタンバイ・データベースはフェイルオーバーできないため、この作業が必要になります。さらに、最大保護モードのプライマリ・データベースがスタンバイ・データベースと通信中の場合は、スタンバイ・データベースを最大保護モードから最大パフォーマンス・モードに変更するためにALTER DATABASE文を発行しても失敗します。フェイルオーバーを実行すると元のプライマリ・データベースはOracle Data Guard構成から削除されるため、この機能によって、最大保護モードで実行されているプライマリ・データベースを計画外のフェイルオーバーの影響から保護します。
この項では、フィジカル・スタンバイ・データベースへのスイッチオーバーおよびフェイルオーバーの実行方法について説明します。これらの操作を実行する手順は、Oracle Database 12cリリース1 (12.1)を実行している場合には簡略化されています。以前の手順も引き続きサポートされますが、次の項で説明している新しい手順を使用することをお薦めします。
関連項目:
フィジカル・スタンバイ・データベースへのロールの推移を実行するときに発生する可能性のある問題のトラブルシューティング方法については、「Oracle Data Guardのトラブルシューティング」を参照してください。
以前のリリースで使用された手順の詳細と、古い構文と新しい構文の比較については、「古い構文を使用したロールの推移の実行」を参照してください。
この項では、フィジカル・スタンバイ・データベースへのスイッチオーバーを実行する方法について説明します。
注意:
プライマリ・データベースおよびスタンバイ・データベースに接続する遠隔同期インスタンス(または優先および代替の遠隔同期インスタンスの組合せ)が存在する場合、スタンバイにスイッチオーバーする手順はこの項で説明しているものと同じです。遠隔同期インスタンスが使用可能か否かは、スイッチオーバーに影響しません。スイッチオーバー中、プライマリとスタンバイは直接相互に通信し、遠隔同期インスタンスを意識せずにスイッチオーバーのロールの推移手順を実行できる必要があります。スイッチオーバー後、遠隔同期インスタンスが新しいロールの2つのデータベースにサービスを提供できるように構成を正しく設定する方法の例は、「遠隔同期」を参照してください。
後続の項では、ロジカル・スタンバイ・データベースが関与するスイッチオーバーおよびフェイルオーバーの実行方法を説明します。
注意:
ロジカル・スタンバイでは、データベース・サービスはレプリケートしません。ロジカル・スタンバイに対するフェイルオーバーまたはスイッチオーバーのイベントでは、プライマリでのサービスに接続している中間層が接続できなくなる(サービスの作成がレプリケートされないため)か、正しくないエディションに接続するようになります(サービス属性の変更がレプリケートされないため)。
Oracle Clusterwareでは、管理するサービスをロジカル・スタンバイにレプリケートしません。それらのプライマリとスタンバイ間での同期を手動で維持する必要があります。Oracle Clusterwareの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。
プライマリ・データベースとロジカル・スタンバイ・データベースとの間でスイッチオーバーを実行する場合、スイッチオーバーは、常にプライマリ・データベースで開始し、ロジカル・スタンバイ・データベースで完了してください。スイッチオーバーが成功するためには、次の手順を記載されているとおりの順序で実行する必要があります。
スイッチオーバーを実行できるかどうかを確認するには、現行のプライマリ・データベースでV$DATABASE固定ビューのSWITCHOVER_STATUS列を問い合せます。
次に例を示します。
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS ----------------- TO STANDBY 1 row selected
SWITCHOVER_STATUS列の値TO STANDBYまたはSESSIONS ACTIVEは、プライマリ・データベースをロジカル・スタンバイ・ロールに切替え可能であることを示します。これらの値のいずれかが表示されない場合は、Oracle Data Guard構成が正常に機能していることを確認してください(たとえば、LOG_ARCHIVE_DEST_nパラメータのすべての値が正しく指定されていることを確認します)。V$DATABASEビューのSWITCHOVER_STATUS列に有効なその他の値の詳細は、『Oracle Databaseリファレンス』を参照してください。
ロジカル・スタンバイ・データベース・ロール用に現行のプライマリ・データベースを準備するには、プライマリ・データベースで次のSQL文を発行します。
SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO LOGICAL STANDBY;
この文は現行プライマリ・データベースに対して、間もなくロジカル・スタンバイ・ロールに切り替わり、新しいプライマリ・データベースからREDOデータを受信し始めることを通知します。LogMinerディクショナリの受信に備えてプライマリ・データベースでこの手順を実行し、手順3で説明したように、現行のロジカル・スタンバイ・データベースのREDOストリームに記録できるようにします。
この操作に成功すると、V$DATABASE.SWITCHOVER_STATUS列に値PREPARING SWITCHOVERが表示されます。
スイッチオーバーのターゲットであるロジカル・スタンバイ・データベースでLogMinerディクショナリを作成するには、次の文を使用します。
SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO PRIMARY;
また、この文は、現行のプライマリ・データベース、およびOracle Data Guard構成内の他のスタンバイ・データベースにREDOデータの転送を開始するロジカル・スタンバイ・データベースで、REDO転送サービスを開始します。このロジカル・スタンバイ・データベースからREDOデータを受信するサイトは、REDOデータを受け入れますが、適用はしません。
ロジカル・スタンバイ・データベースのV$DATABASE.SWITCHOVER_STATUSには、LogMinerディクショナリがREDOストリームに記録されている間、最初はPREPARING DICTIONARYが表示されます。正常に完了すると、SWITCHOVER_STATUS列にPREPARING SWITCHOVERが表示されます。
プライマリ・データベースからロジカル・スタンバイ・ロールへのロール・トランジションを完了するには、プライマリ・データベースのV$DATABASE固定ビューのSWITCHOVER_STATUS列を問い合せることで、プライマリ・データベースがLogMinerディクショナリを受信したことを確認する必要があります。LogMinerディクショナリを受信しなければスイッチオーバーを続行できません。現行のプライマリ・データベースが以降のプライマリ・データベースから受信するREDOレコードを解釈できる必要があるためです。SWITCHOVER_STATUS列にスイッチオーバーの進捗が示されています。
問合せがTO LOGICAL STANDBY値を戻した場合は、手順5に進むことができます。次に例を示します。
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS ----------------- TO LOGICAL STANDBY 1 row selected
注意:
次の文を示された順序で発行すると、スイッチオーバー操作を取り消すことができます。
プライマリ・データベースでスイッチオーバーを取り消します。
SQL> ALTER DATABASE PREPARE TO SWITCHOVER CANCEL;
ロジカル・スタンバイ・データベースでスイッチオーバーを取り消します。
SQL> ALTER DATABASE PREPARE TO SWITCHOVER CANCEL;
プライマリ・データベースからロジカル・スタンバイ・データベース・ロールへのロールの推移を完了するには、次のSQL文を発行します。
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY;
この文は、プライマリ・データベースで現在のトランザクションがすべて終了するまで待機し、新規ユーザーによる新規トランザクションの開始を防止し、スイッチオーバーがコミットされる時点を設定します。
この文を実行すると、ユーザーはロジカル・スタンバイ・データベースでメンテナンスされているデータの変更もできません。スイッチオーバーを迅速に実行するには、スイッチオーバー文を発行する前に、プライマリ・データベースが静止状態で更新アクティビティが実行されていないことを確認してください(たとえば、すべてのユーザーをプライマリ・データベースから一時的にログオフします)。V$TRANSACTIONビューを問い合せると、この文の実行を遅延させる可能性のある現在進行中のトランザクションのステータス情報を取得できます。
この時点でプライマリ・データベースのロールが推移して、スタンバイ・データベース・ロールで実行されます。
プライマリ・データベースをロジカル・スタンバイ・データベース・ロールに推移した場合は、データベースを停止して再起動する必要はありません。
プライマリ・データベースからロジカル・スタンバイ・ロールへのロールの推移を完了し、構成内のスタンバイ・データベースがスイッチオーバー通知を受け取った後、ターゲット・スタンバイ・データベースでV$DATABASE固定ビューのSWITCHOVER_STATUS列を問い合せ、ターゲット・スタンバイ・データベースがスイッチオーバー通知を処理したことを確認します。使用可能なすべてのREDOレコードがロジカル・スタンバイ・データベースに適用されると、SQL Applyは予想されるロールの推移の準備を自動的に停止します。
スイッチオーバー中にSWITCHOVER_STATUS値が更新され、進捗を示します。ステータスがTO PRIMARYの場合は、手順7に進むことができます。
次に例を示します。
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS ----------------- TO PRIMARY 1 row selected
V$DATABASEビューのSWITCHOVER_STATUS列に有効なその他の値の詳細は、『Oracle Databaseリファレンス』を参照してください。
プライマリ・ロールに切り替えるロジカル・スタンバイ・データベースで、次のSQL文を使用し、ロジカル・スタンバイ・データベースをプライマリ・ロールに切り替えます。
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
Oracle Data Guard構成内のロジカル・スタンバイ・データベースは、停止して再起動する必要はありません。ロールの推移のターゲット・スタンバイ・データベースの選択で説明したように、構成内の他のすべてのロジカル・スタンバイは新しいプライマリのスタンバイになりますが、フィジカル・スタンバイ・データベースは、元のプライマリ・データベースのスタンバイのままです。
新しいロジカル・スタンバイ・データベースでSQL Applyを開始します。
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
この項では、ロジカル・スタンバイ・データベースが関与するフェイルオーバーの実行方法を説明します。ロジカル・スタンバイ・データベースが関与するフェイルオーバーによるロールの推移では、障害の発生したプライマリ・データベースとすべてのロジカル・スタンバイ・データベースで対処措置を実行する必要があります。障害の発生したプライマリ・データベースでフラッシュバック・データベースが有効化されていない場合は、現行のプライマリ・データベースから作成したバックアップを使用してデータベースを再作成する必要があります。それ以外の場合は、「フラッシュバック・データベースを使用した障害の発生したプライマリのスタンバイ・データベースへの変換」で説明する手順に従って、障害の発生したプライマリ・データベースを新しいプライマリ・データベースのロジカル・スタンバイ・データベースに変換できます。
構成に対する保護モードおよびREDO転送サービスに対して選択した属性に従って、プライマリ・データベースの修正の一部またはすべてを自動的にリカバリすることも可能です。
プライマリ・データベースをマウントできる場合、プライマリ・データベースからスタンバイ・データベースに、未送信のアーカイブされた現行のREDOをフラッシュします。この操作が正常に終了した場合、プライマリ・データベースがデータ消失ゼロのデータ保護モードで実行されていなくても、データの消失がないようにフェイルオーバーすることができます。
まず、ターゲット・スタンバイ・データベースでREDO Applyがアクティブであることを確認します。次にプライマリ・データベースをマウントします。オープンはしないでください。
次のSQL文をプライマリ・データベースで発行します。
SQL> ALTER SYSTEM FLUSH REDO TO target_db_name;
target_db_nameには、プライマリ・データベースからフラッシュされたREDOを受信するスタンバイ・データベースのDB_UNIQUE_NAMEを指定します。
この文は、未送信のREDOをすべて、プライマリ・データベースからスタンバイ・データベースにフラッシュし、このREDOがスタンバイ・データベースに適用されるまで待機します。
構成に含まれるコンポーネントの状態によっては、プライマリ・データベースのアーカイブREDOログ・ファイルにアクセスできる場合があります。アクセスする場合の手順は、次のとおりです。
ロジカル・スタンバイ・データベースでアーカイブREDOログ・ファイルが欠落しているかどうかを判断します。
欠落しているログ・ファイルを、プライマリ・データベースからロジカル・スタンバイ・データベースにコピーします。
コピーしたログ・ファイルを登録します。
次の文を発行して、アーカイブREDOログ・ファイルをロジカル・スタンバイ・データベースに登録できます。次に例を示します。
SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE - > '/disk1/oracle/dbs/log-%r_%s_%t.arc'; Database altered.
ロールベースの宛先をまだ構成していない場合は、新しいプライマリ・データベースのリモート・ロジカル・スタンバイ宛先に対応する初期化パラメータを特定して、これらの宛先ごとにREDOデータのアーカイブを手動で使用可能にします。
たとえば、LOG_ARCHIVE_DEST_2パラメータで定義したリモート宛先のアーカイブを可能にするには、次の文を発行します。
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE SCOPE=BOTH;
後で新しいプライマリ・データベースを再起動した場合にもこの変更を保持するには、適切なテキスト初期化パラメータ・ファイルまたはサーバー・パラメータ・ファイルを更新します。通常、データベースがプライマリ・ロールで動作する場合はリモート宛先へのアーカイブを可能にし、データベースがスタンバイ・ロールで動作する場合はリモート宛先へのアーカイブを不可能にする必要があります。
ターゲット・ロジカル・スタンバイ・データベース(新規プライマリ・ロールに推移させるデータベース)で、次の文を発行します。
SQL> ALTER DATABASE ACTIVATE LOGICAL STANDBY DATABASE FINISH APPLY;
この文はリモート・ファイル・サーバー(RFS)プロセスを停止し、ロジカル・スタンバイ・データベースがプライマリ・データベースになる前にスタンバイREDOログ・ファイルに残っているREDOデータを適用し、SQL Applyを停止して、データベースをプライマリ・データベース・ロールでアクティブ化します。
FINISH APPLY句が指定されていない場合、現在のスタンバイREDOログ・ファイルからの適用されていないREDOログ・ファイルはスタンバイ・データベースがプライマリ・データベースになる前には適用されません。
「フェイルオーバー後のロジカル・スタンバイ・データベースの構成」で説明する方法に従って、既存のロジカル・スタンバイ・データベースが新しいプライマリ・データベースを引き続き保護できるようにします。
Oracle Data Guardデータベース・フェイルオーバー直後に、新しいプライマリ・データベースのバックアップを行います。データベースの完全なバックアップ・コピーがなければ、フェイルオーバー後の変更をリカバリすることができないので、バックアップをすぐに実行することは安全策として必要な作業です。
フェイルオーバーの完了後、元のプライマリ・データベースは「フラッシュバック・データベースを使用した障害が発生したプライマリのスタンバイ・データベースへの変換」で説明する方法に従って、新しいプライマリ・データベースのロジカル・スタンバイ・データベースに変換するか、「ロジカル・スタンバイ・データベースの作成」で説明した方法に従って、新しいプライマリ・データベースのバックアップからロジカル・スタンバイ・データベースとして再作成できます。
元のプライマリ・データベースをスタンバイ・データベースに変換したら、スイッチオーバーを実行してプライマリ・ロールにリストアできます。
ロール・トランジションの後に、オプションでFLASHBACK DATABASEコマンドを使用してデータベースをロール・トランジション前のある時点、またはシステム変更番号(SCN)に戻すことができます。プライマリ・データベースのフラッシュバックを行う場合、同じ(または以前の)SCNまたは時刻にすべてのスタンバイ・データベースをフラッシュバックする必要があります。この方法でプライマリまたはスタンバイ・データベースのフラッシュバックを行う場合は、過去のスイッチオーバーを気にする必要はありません。SCN/時刻が過去の任意の時点でのスイッチオーバーより前の場合、Oracleは自動的に過去のスイッチオーバーを越えてフラッシュバックを行うことができます。
注意:
ロールの推移が発生する前に、データベースでフラッシュバック・データベースを有効化しておく必要があります。詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
スイッチオーバー後にFLASHBACK DATABASEコマンドを使用して、データベースをスイッチオーバー発生前の時点またはシステム変更番号(SCN)に戻すことができます。
スイッチオーバーにフィジカル・スタンバイ・データベースが関与していた場合、フラッシュバック操作中はプライマリおよびスタンバイ・データベース・ロールが保持されます。データベースが実行中のロールは、フラッシュバックした時点またはターゲットSCNまでデータベースがフラッシュバックされても変化しません。スイッチオーバー後からフラッシュバックの前までフィジカル・スタンバイ・ロールで実行されていたデータベースは、フラッシュバック・データベース操作後もフィジカル・スタンバイ・データベースで実行されます。
スイッチオーバーにロジカル・スタンバイ・データベースが関与していた場合、フラッシュバックするとスタンバイ・データベースのロールはフラッシュバックした時点またはターゲットSCNでのロールに変更されます。
フラッシュバック・データベースを使用して、障害の発生したプライマリ・データベースをフェイルオーバー発生前の時点に変換してから、スタンバイ・データベースに変換できます。詳細な手順は、「フラッシュバック・データベースを使用した障害が発生したプライマリのスタンバイ・データベースへの変換」を参照してください。
