1. 概要および管理
  2. 概要および管理
  3. Oracle Data Guardの使用例

15 Oracle Data Guardの使用例

これらのシナリオは、Oracle Data Guard構成の管理中に遭遇する可能性がある様々な状況を示します。それぞれ、ユーザー固有の環境に適応できます。

ノート:

マルチテナント・コンテナ・データベースが、Oracle Database 21c以降のリリースで唯一サポートされているアーキテクチャです。ドキュメントが改訂されている間は、従来の用語が残っている可能性があります。ほとんどの場合、「データベース」と「非CDB」は、コンテキストに応じてCDBまたはPDBを指しています。アップグレードなどのコンテキストでは、「非CDB」が以前のリリースの非CDBを指す場合もあります。

フェイルオーバー後のロジカル・スタンバイ・データベースの構成

プライマリ・データベースを別のスタンバイ・データベースにフェイルオーバーした後にロジカル・スタンバイ・データベースで実行する必要のあるステップを次に示します。

フェイルオーバーの発生後、ロジカル・スタンバイ・データベースは、元のプライマリ・データベースからの最後のREDOが適用されるまで、新規プライマリ・データベースのスタンバイ・データベースとして機能できません。これは、フェイルオーバー中に新規のプライマリ・データベースで最後のREDOが適用される場合と同じです。実行するステップは、新規プライマリ・データベースがフェイルオーバー前にフィジカル・スタンバイ・データベースであったかロジカル・スタンバイ・データベースであったかに応じて異なります。

新規プライマリ・データベースがフィジカル・スタンバイ・データベースだった場合

このステップでは、プライマリ・ロールを担う前はフィジカル・スタンバイ・データベースだった新規プライマリ・データベースをサポートするようにロジカル・スタンバイ・データベースを構成する方法について説明します。

この使用例では、SATはロジカル・スタンバイ・データベース、NYCはプライマリ・データベースです。

  1. SATデータベースで次の文を発行して、ログ・ファイルの自動リカバリを有効化するためにFAL_SERVERパラメータを構成します。

    SQL> ALTER SYSTEM SET FAL_SERVER='<tns_name_to_new_primary>';
SQL> ALTER SYSTEM SET FAL_CLIENT='<tns_name_to_local_database>';

  2. PREPARE_FOR_NEW_PRIMARYルーチンを呼び出して、ロジカル・スタンバイ・データベースが新規プライマリ・データベースのスタンバイ・データベースとして機能できることを確認します。このステップの間、データに相違を生じさせるおそれのあるログ・ファイルのローカル・コピーは、ローカル・データベースから削除されます。その後、これらのログ・ファイルは、新しいプライマリ・データベースから直接、再アーカイブが要求されます。

    SATデータベースで、次の文を発行します。

    SQL> EXECUTE DBMS_LOGSTDBY.PREPARE_FOR_NEW_PRIMARY( -
>  former_standby_type => 'PHYSICAL' -
>  dblink => 'nyc_link');

    ノート:

    ORA-16109メッセージが戻され、alert.logに「LOGSTDBY: prepare_for_new_primary failure -- applied too far, flashback required.」という警告が書き込まれる場合は、次のステップを実行します。

    1. データベースを警告に示されたSCNまでフラッシュバックします。

    2. 続行する前に、このステップを繰り返します。

    ロジカル・スタンバイ・データベースをApply SCNまでフラッシュバックする方法の例は、「特定の適用済SCNへのロジカル・スタンバイ・データベースのフラッシュバック」を参照してください。

  3. SATデータベースで、次のコマンドを発行してSQL Applyを開始します。

    SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

新規プライマリ・データベースがロジカル・スタンバイ・データベースだった場合

このステップでは、プライマリ・ロールを担う前はロジカル・スタンバイ・データベースだった新規プライマリ・データベースをサポートするようにロジカル・スタンバイ・データベースを構成する方法について説明します。

この使用例では、SATはロジカル・スタンバイ・データベース、NYCはプライマリ・データベースです。

  1. 新規プライマリ・データベースで、ロジカル・スタンバイ・データベースのサポート準備が完了していることを確認します。NYCデータベースで、次の問合せにより値NONEが戻されることを確認します。それ以外の場合、新しいプライマリ・データベースは、ロジカル・スタンバイ・データベースに対するサポートを可能にするために必要な作業を完了していません。たとえば: 

    SQL> SELECT PENDING_ROLE_CHANGE_TASKS FROM V$DATABASE;

    古いプライマリ・データベースを修復しようとする前に、NONEの値が戻される必要があります。

  2. SATデータベースで次の文を発行して、ログ・ファイルの自動リカバリを有効化するためにFAL_SERVERパラメータを構成します。

    SQL> ALTER SYSTEM SET FAL_SERVER='<tns_name_to_new_primary>';
SQL> ALTER SYSTEM SET FAL_CLIENT='<tns_name_to_local_database>';

  3. PREPARE_FOR_NEW_PRIMARYルーチンを呼び出して、ロジカル・スタンバイ・データベースが新規プライマリのスタンバイとして機能できることを確認します。このステップの間、データに相違を生じさせるおそれのあるログ・ファイルのローカル・コピーは、ローカル・データベースから削除されます。その後、これらのログ・ファイルは、新しいプライマリ・データベースから直接、再アーカイブが要求されます。

    SATデータベースで、次の文を発行します。

    SQL> EXECUTE DBMS_LOGSTDBY.PREPARE_FOR_NEW_PRIMARY( -
> former_standby_type => 'LOGICAL' -
> dblink => 'nyc_link');

    ノート:

    ORA-16109メッセージが戻され、alert.logファイルに「LOGSTDBY: prepare_for_new_primary failure -- applied too far, flashback required」という警告が書き込まれる場合は、次のステップを実行します。

    1. データベースを警告に示されたSCNまでフラッシュバックします。

    2. 続行する前に、このステップを繰り返します。

    ロジカル・スタンバイ・データベースをApply SCNまでフラッシュバックする方法の例は、「特定の適用済SCNへのロジカル・スタンバイ・データベースのフラッシュバック」を参照してください。

  4. SATデータベースで、次のコマンドを発行してSQL Applyを開始します。

    SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY nyc_link;

    この文は、常にリアルタイム適用オプションを有効化せずに発行する必要があります。ロジカル・スタンバイ・データベースでリアルタイム適用を有効化する必要がある場合は、前述の文が正常終了するまで待機してから、次の文を発行します。

    SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

フラッシュバック・データベースを使用した障害が発生したプライマリのスタンバイ・データベースへの変換

フェイルオーバーの発生後、元のプライマリ・データベースは、修正され、新しい構成のスタンバイ・データベースとして確立されるまで、Oracle Data Guard構成に含められません。

これを行うには、フラッシュバック・データベース機能を使用して、障害が発生したプライマリ・データベースをフェイルオーバーが発生する前の時点にリカバリしてから、新しい構成内のフィジカルまたはロジカル・スタンバイ・データベースに変換します。この項では、次の項目について説明します。

障害が発生したプライマリ・データベースのフィジカル・スタンバイ・データベースへのフラッシュバックに関する項

このステップは、古いプライマリ・データベースをフィジカル・スタンバイ・データベースとしてOracle Data Guard構成に戻します。

次のステップでは、フィジカル・スタンバイ・データベースに対してフェイルオーバーが実行され、ファイルオーバーの際に古いプライマリ・データベースでフラッシュバック・データベースが使用可能にされていることを前提としています。

  1. 新しいプライマリ・データベース上で次の問合せを発行し、古いスタンバイ・データベースが新しいプライマリ・データベースになったSCNを判別します。

    SQL> SELECT TO_CHAR(STANDBY_BECAME_PRIMARY_SCN) FROM V$DATABASE;

  2. 必要に応じて古いプライマリ・データベースを停止し、マウントして、前のステップで判別したSTANDBY_BECAME_PRIMARY_SCNの値にフラッシュバックします。 

    SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> FLASHBACK DATABASE TO SCN standby_became_primary_scn;

  3. データベースをフィジカル・スタンバイ・データベースに変換するには、古いプライマリ・データベースで次の文を発行します。

    SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

  4. 新しいフィジカル・スタンバイ・データベースへのREDO転送を開始するには、新しいプライマリ・データベースで次のステップを実行します。

    1. 次の問合せを発行し、アーカイブ宛先の現在の状態を調べます。

      SQL> SELECT DEST_ID, DEST_NAME, STATUS, PROTECTION_MODE, DESTINATION, -
> ERROR,SRL FROM V$ARCHIVE_DEST_STATUS;

    2. 必要に応じて、宛先を使用可能にします。

      SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_n=ENABLE;

    3. スタンバイ・データベースが新しいプライマリ・データベースからのREDOデータの受信を確実に開始するよう、ログ・スイッチを実行し、これが成功したことを確認します。次のSQL文を新しいプライマリ・データベースで発行します。

      SQL> ALTER SYSTEM SWITCH LOGFILE;
SQL> SELECT DEST_ID, DEST_NAME, STATUS, PROTECTION_MODE, DESTINATION,- 
> ERROR,SRL FROM V$ARCHIVE_DEST_STATUS;

      新しいスタンバイ・データベースで、REDO転送サービスがREDOデータを別のデータベースに転送しないよう、LOG_ARCHIVE_DEST_n初期化パラメータも変更する必要があります。

  5. 新しいフィジカル・スタンバイ・データベースでREDO Applyを開始します。

    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

    REDO Applyは、ロールの推移により生成されるREDOレコードが検出されるたびに自動的に停止するため、新しいプライマリ・データベースがプライマリ・データベースとなったSCNを超えて適用されるまで、1回以上再起動する必要があります。障害が発生したプライマリ・データベースがリストアされてスタンバイ・ロールで稼働し始めた後、オプションでスイッチオーバーを実行し、それぞれのデータベースを元の(障害発生前の)ロールに推移できます。詳細は、「フィジカル・スタンバイ・データベースへのスイッチオーバーの実行」を参照してください。

障害が発生したプライマリ・データベースのロジカル・スタンバイ・データベースへのフラッシュバック

このステップは、新しいプライマリ・データベースから古いプライマリ・データベースを正式にインスタンス化せずに、古いプライマリ・データベースを新しいロジカル・スタンバイ・データベースとしてOracle Data Guard構成に戻します。

次のステップでは、Oracle Data Guard構成ですでにロジカル・スタンバイ・データベースを使用したフェイルオーバーが実行済で、古いプライマリ・データベースでフラッシュバック・データベースが使用可能にされていることを前提としています。

  1. フラッシュバックSCNおよびリカバリSCNを判別します。フラッシュバックSCNは、障害が発生したプライマリ・データベースのフラッシュバック先となるSCNです。リカバリSCNは、障害が発生したプライマリ・データベースのリカバリ先となるSCNです。新しいプライマリで次の問合せを発行し、これらのSCNを特定します。
    SQL> SELECT merge_change# AS FLASHBACK_SCN, processed_change# AS RECOVERY_SCN -
> FROM DBA_LOGSTDBY_HISTORY -
> WHERE stream_sequence# = (SELECT MAX(stream_sequence#)-1 -
> FROM DBA_LOGSTDBY_HISTORY);
  2. 障害が発生したプライマリ・データベースを前のステップで特定したフラッシュバックSCNまでフラッシュバックします。
    SQL> FLASHBACK DATABASE TO SCN flashback_scn;
  3. 障害が発生したプライマリをフィジカル・スタンバイに変換し、リカバリの準備としてスタンバイ・データベースを再度マウントします。
    SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
  4. ログ・ファイルの自動リカバリを有効化するために、FAL_SERVERパラメータを構成します。フィジカル・スタンバイ(障害の発生したプライマリ)で、次の文を発行します。
    SQL> ALTER SYSTEM SET FAL_SERVER='<tns_name_to_new_primary>';
  5. フェイルオーバー操作以後に作成されたアーカイブ・ログをすべて、障害が発生したプライマリ・データベースから削除します。障害が発生したプライマリ・データベースがスタンバイから分離されていた場合は、現行のプライマリ・データベースと一貫性がない不一致のアーカイブ・ログが存在する可能性があります。これらの不一致のアーカイブ・ログを適用しないようにするには、バックアップおよび高速リカバリ領域から削除する必要があります。次のRMANコマンドを使用すると、関連アーカイブ・ログを高速リカバリ領域から削除できます。
    RMAN> DELETE FORCE ARCHIVELOG FROM SCN FLASHBACK_SCN;

    削除されると、これらの不一致のログおよび後続のトランザクションはリカバリできなくなります。

  6. ステップ1で特定したリカバリSCNまでリカバリします。
    SQL> RECOVER MANAGED STANDBY DATABASE UNTIL CHANGE recovery_scn;
  7. データベース・ガードを有効にします。
    SQL> ALTER DATABASE GUARD ALL;
  8. フィジカル・スタンバイをアクティブにしてプライマリ・データベースにします。
    SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;
  9. データベースをオープンします。
    SQL> ALTER DATABASE OPEN;
  10. 新しいプライマリへのデータベース・リンクを作成してSQL Applyを開始します。
    SQL> CREATE PUBLIC DATABASE LINK mylink -
> CONNECT TO system IDENTIFIED BY password -
> USING 'service_name_of_new_primary_database';

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY mylink;

    これで、ロールの可逆的な推移が完了しました。

特定の適用済SCNへのロジカル・スタンバイ・データベースのフラッシュバック

スタンバイ・データベースのメリットの1つは、プライマリ・データベース・サービスに影響を与えずに、スタンバイ・データベースでフラッシュバック・データベースを実行できることです。データベースを特定の時点までフラッシュバックするタスクは簡単ですが、ロジカル・スタンバイ・データベースでは、既知のトランザクションがコミットされる直前の時点までフラッシュバックする操作が必要になる場合があります。このような必要が生じるのは、フェイルオーバー後に新しいプライマリ・データベースを使用してロジカル・スタンバイ・データベースを構成する場合です。これらのステップでは、フラッシュバック・データベースとSQL Applyを使用して既知の適用済SCNまでリカバリする方法について説明します。
  1. プライマリでの既知のSCN(APPLIED_SCN)の特定後に、フラッシュバック操作に使用するためにロジカル・スタンバイ・データベースで次の問合せを発行して対応するSCNを判別します。
    SQL> SELECT DBMS_LOGSTDBY.MAP_PRIMARY_SCN (PRIMARY_SCN => APPLIED_SCN) -
> AS TARGET_SCN FROM DUAL;
  2. 次のSQL文を発行し、ロジカル・スタンバイ・データベースを指定したSCNまでフラッシュバックし、RESETLOGSオプションを指定してロジカル・スタンバイ・データベースをオープンします。
    SQL> SHUTDOWN;
SQL> STARTUP MOUNT EXCLUSIVE;
SQL> FLASHBACK DATABASE TO SCN <TARGET_SCN>;
SQL> ALTER DATABASE OPEN RESETLOGS;
  3. 次の問合せを発行して、SQL ApplyがAPPLIED_SCNまで適用されたことを確認します。
    SQL> SELECT APPLIED_SCN FROM V$LOGSTDBY_PROGRESS;

Open Resetlogs文の発行後のフラッシュバック・データベースの使用

Oracle Data Guard構成のプライマリ・データベースで、スタンバイ・データベースがリアルタイム適用を使用しているというエラーが発生した場合、同じエラーがスタンバイ・データベースにも適用されます。フラッシュバック・データベースが有効になっている場合は、プライマリ・データベースとスタンバイ・データベースをエラー前の状態に戻すことができます。

これを行うには、プライマリ・データベースでFLASHBACK DATABASE文とOPEN RESETLOGS文を実行してから、適用サービスを再起動する前に、スタンバイ・データベースで同様のFLASHBACK STANDBY DATABASE文を発行します。(フラッシュバック・データベースが有効化されていない場合は、プライマリ・データベースのポイント・イン・タイム・リカバリを実行後、「フィジカル・スタンバイ・データベースの作成」と「ロジカル・スタンバイ・データベースの作成」で説明しているスタンバイ・データベースの再作成が必要です。)

特定時点へのフィジカル・スタンバイ・データベースのフラッシュバック

これらのステップでは、プライマリ・データベースでOPEN RESETLOGS文を発行した後、フィジカル・スタンバイ・データベースの再作成を回避する方法を説明します。

Oracle Databaseリリース19cでは、スタンバイがマウント・モードで、かつフラッシュバック・データベースが有効になっている場合、何も実行する必要はありません。一般的なケースでは、十分なフラッシュバック・データが使用可能な場合は、引き続きスタンバイがプライマリを継ぐように、スタンバイは自動的にフラッシュバックされます。

スタンバイがオープンし、フラッシュバック・データベースが有効になっている場合は、スタンバイをマウント・モードにしてからスタンバイ・リカバリを開始できます。プライマリをスタンバイに継がせるための試みとして、MRPにより、スタンバイの自動フラッシュバックがトリガーされます。この操作が成功した場合は、アラート・ログにレポートされるため、続いてActive Data Guardインスタンスを開く必要があります。

自動フラッシュバックがトリガーされない場合、または自動フラッシュバックによってプライマリをスタンバイが継がなかった場合は、この項で説明するステップを実行できます。

  1. RESETLOGS操作が発生した前のSCNを判別します。たとえば、プライマリ・データベースで、次の問合せを使用してRESETLOGS操作がプライマリ・データベースで発生したよりも2つ前のシステム変更番号(SCN)の値を取得します。
    SQL> SELECT TO_CHAR(RESETLOGS_CHANGE# - 2) FROM V$DATABASE;
  2. スタンバイ・データベースで、次の問合せを使用して現行のSCNを取得します。
    SQL> SELECT TO_CHAR(CURRENT_SCN) FROM V$DATABASE;
  3. CURRENT_SCNの値がresetlogs_change# - 2の値より大きい場合、次の文を発行してスタンバイ・データベースをフラッシュバックします。
    SQL> FLASHBACK STANDBY DATABASE TO SCN resetlogs_change# -2;

    • CURRENT_SCNの値がresetlogs_change# - 2の値より小さい場合、ステップ4に進みます。

    • スタンバイ・データベースのSCNがプライマリ・データベースのSCNよりも大幅に遅れており、OPEN RESETLOGS文のREDOの新規ブランチがスタンバイに登録されている場合、適用サービスは、OPEN RESETLOGS文中も停止せずに継続できます。この場合、適用サービスはREDOデータ内のOPEN RESETLOGS文に到達しても停止しないため、データベースのフラッシュバックは不要です。

  4. フィジカル・スタンバイ・データベースでREDO Applyを開始するには、次の文を発行します。 
    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

    スタンバイ・データベースはプライマリ・データベースからREDOを受信し、適用できます。

特定時点へのロジカル・スタンバイ・データベースのフラッシュバック

これらのステップでは、プライマリ・データベースをフラッシュバックし、OPEN RESETLOGS文を発行してオープンした後、ロジカル・スタンバイ・データベースの再作成を回避する方法を説明します。

ノート:

SQL Applyは、プライマリ・データベースでリセットログ操作の発生を検出すると、ロジカル・スタンバイ・データベースをフラッシュバックしなくてもマイニングできる場合は、REDOの正しいブランチを自動的にマイニングします。それ以外の場合、SQL Applyは「ORA-1346: 指定されたリセット・ログscnを超えてLogMinerがREDOを処理しました」エラーで停止します。この項では、SQL Applyはこのエラーですでに停止していると仮定しています。

  1. プライマリ・データベースで、次の問合せを使用してRESETLOGS操作がプライマリ・データベースで発生したよりも2つ前のシステム変更番号(SCN)の値を取得します。
    SQL> SELECT TO_CHAR(RESETLOGS_CHANGE# - 2) AS FLASHBACK_SCN FROM V$DATABASE;
  2. ロジカル・スタンバイ・データベースでフラッシュバック操作のターゲットSCNを特定します。

    このステップでは、PRIMARY_SCNのFLASHBACK_SCN値はステップ1から得られたものです。 

    SQL> SELECT DBMS_LOGSTDBY.MAP_PRIMARY_SCN (PRIMARY_SCN => FLASHBACK_SCN) -
> AS TARGET_SCN FROM DUAL;
  3. 次のSQL文を発行し、ロジカル・スタンバイ・データベースを指定したSCNまでフラッシュバックし、RESETLOGSオプションを指定してロジカル・スタンバイ・データベースをオープンします。
    SQL> SHUTDOWN;
SQL> STARTUP MOUNT EXCLUSIVE;
SQL> FLASHBACK DATABASE TO SCN <TARGET_SCN>;
SQL> ALTER DATABASE OPEN RESETLOGS;
  4. SQL Applyが開始される前に、プライマリの新しいブランチからのログ・ファイルが登録されていることを確認します。プライマリ・データベースで次の問合せを発行します。
    SQL> SELECT resetlogs_id FROM V$DATABASE_INCARNATION WHERE status = 'CURRENT';

    スタンバイ・データベースで次の問合せを発行します。

    SQL> SELECT * FROM DBA_LOGSTDBY_LOG WHERE resetlogs_id = resetlogs_id_at_primary;

    1以上の行が返された場合、これは、プライマリの新しいブランチからの登録されたログ・ファイルであることを確認します。

  5. SQL Applyを開始します。
    SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

NOLOGGING句を指定した後のリカバリ

一部のSQL文では、NOLOGGING句を指定して、操作がオンラインREDOログ・ファイルに記録されないようにできます。

実際には、NOLOGGINGを指定すると、REDOレコードはオンラインREDOログ・ファイルに書き込まれますが、レコードに関連付けられたデータはありません。この指定により、スタンバイ・サイトでログ・アプリケーションまたはデータ・アクセス・エラーが発生する可能性があります。ログ・ファイルの適用を再開するには、手動リカバリが必要な場合があります。ロジカル・スタンバイとフィジカル・スタンバイのどちらを使用するかに応じて次の操作を行うことで、これらのエラーを防止できます。

  • ロジカル・スタンバイ

    CREATE DATABASE文またはALTER DATABASE文にFORCE LOGGING句を指定します。

  • フィジカル・スタンバイ

    Data Guard構成の使用方法に適したロギング・モードを指定します。

    適切なロギング・モードの有効化を参照してください。

現在のロギング・モードは、V$DATABASE.FORCE_LOGGING列(CDBの場合)またはDBA_PDBS.FORCE_LOGGING列(PDBの場合)で確認できます。

ロジカル・スタンバイ・データベースのリカバリ・ステップ

ロジカル・スタンバイ・データベースでは、SQL ApplyでNOLOGGING句を使用してスキップされていない表で実行された操作のREDOレコードが検出されると、次のエラーで停止します。 

ORA-16211 unsupported record found in the archived redo log

NOLOGGING句を指定した後のリカバリには、「ロジカル・スタンバイ・データベースでの表の追加または再作成」に説明されているように、プライマリ・データベースから1つ以上の表を再作成します。

ノート:

通常、NOLOGGING句の使用はお薦めしません。このため、プライマリ・データベース内の特定の表でNOLOGGING句を使用する操作が実行されることが事前にわかっている場合は、これらの表に関連付けられているSQL文をロジカル・スタンバイ・データベースに適用しないようにできます。これは、DBMS_LOGSTDBY.SKIPプロシージャを使用して行うことができます。

フィジカル・スタンバイ・データベースのリカバリ・ステップ

REDOがフィジカル・スタンバイ・データベースに適用されると、データファイルの一部がリカバリ不能とマークされます。フィジカル・スタンバイ・データベースにフェイルオーバーするか、読取り専用アクセスでスタンバイ・データベースをオープンし、UNRECOVERABLEのマークが付けられたブロックの範囲を読み取ろうとすると、次のようなエラー・メッセージが表示されます。 

ORA-01578: ORACLE data block corrupted (file # 1, block # 2521)
ORA-01110: data file 1: '/oracle/dbs/stdby/tbs_1.dbf'
ORA-26040: Data block was loaded using the NOLOGGING option

STANDBY NOLOGGING FOR LOAD PERFORMANCEモードを使用した場合も、フィジカル・スタンバイで実行された問合せがNOLOGGING操作による破損ブロックをレポートすることがあります。ただし、そのスタンバイでActive Data Guard構成の一部として管理リカバリが実行されている場合は、プライマリから置換ブロックが自動的にフェッチされます。(管理リカバリはALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT文を使用して開始されます。)管理リカバリは、そのようなブロックが最初に作成された直後にそのすべてをフェッチしようとし、それらの修正を成功するまで試行し続けます。管理リカバリが開始されるたびに、前のリカバリ・セッションで未処理だったブロックの修正が再開されます。この自動リカバリは、STANDBY NOLOGGING FOR LOAD PERFORMANCEモードを有効にして生成されたREDOが原因で発生した破損ブロックにのみ適用されます。従来のログに記録されない操作によって破損したブロックには、次の手順を使用する必要があります。このステップは、ログに記録されないすべてのブロックをリカバリする簡単な方法を示しています。(リカバリ不能な操作の後にバックアップが必要かどうかの決定　およびフィジカル・スタンバイ・データベースの一部分のリカバリなど、その他のアプローチについては後続の項を参照してください。)

  1. スタンバイでリカバリを停止します。

    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

  2. RMANをスタンバイに接続し、次のコマンドを発行して、ログに記録されないブロックをリカバリします。

    RMAN> RECOVER DATABASE NONLOGGED BLOCK;

    ログに記録されないブロックがスイッチオーバー後にのみ検出される場合、これらの2つのステップを使用できますが、プライマリ・データベースを(開かずに)単にマウントして、RMANをプライマリに接続する必要があります。

    RMANのRECOVERコマンドで、ログに記録されないブロックの一部をリカバリできないこともあります。これが起きる理由については、RMANコマンドが実行されたデータベースのアラート・ログに詳しく記載されています。最も一般的な理由は、プライマリで最近ブロックが変更されたが、まだ対応するデータファイルに書き込まれていないためです。つまり、スタンバイに送信されたブロックが古すぎて、スタンバイでリカバリ不能なブロックを置き換えることができないのです。 これを解決するには、ブロックをデータファイルに書き込んだ後で、再びRECOVERコマンドを発行します。

次に、RECOVERコマンドを実行して一部のブロックがリカバリ不能になった場合の、アラート・ログ・エントリの例を示します。 

Started Nonlogged Block Replacement recovery on file 7 (ospid 13005 rcvid 11319003446180375696)
Finished Nonlogged Block Replacement recovery on file 7. 5 blocks remain
  Statistics for replacement block source database (service=dg3tns)
  (Use of it stopped due to error 12942 received from it)
  Blocks requested 5, blocks received 0.

  Reason replacement blocks accepted or rejected               Blocks Last block
  -------------------------------------------------------- ---------- ----------
  Not received: Rejected by sender. Wrong state or SCN              5         21

この例では、スタンバイでコマンドが実行され、プライマリはブロックを送信せず、かわりに次のOracleエラーをレポートしました。

ORA-12942: database incarnation at source does not match

アラート・ログを調べたところ、プライマリでFLASHBACK DATABASEおよびOPEN RESETLOGSコマンドが実行されたが、スタンバイはフラッシュバックされていないことが判明しました。つまり、スタンバイは現在REDOの孤立したブランチにいるため、プライマリは正しいバージョンであることが確認されているデータ・ブロックを提供できなかったのです。

ノート:

Data Guard構成に複数のスタンバイがある場合、スタンバイで実行されるRMANのRECOVERコマンドは、プライマリからのみブロックを取得しようとします。RECOVERコマンドをプライマリで実行した場合、適切なブロックを取得する可能性が最も高い1つのスタンバイ(通常、プライマリと最も密接に同期しているスタンバイ)からのみブロックを取得しようとします。

リカバリ不能処理後にバックアップが必要かどうかの判断

プライマリ・データベースでリカバリ不能な操作を実行した場合、新しいバックアップ操作が必要かどうかを判別する必要があります。

これを行うには、次のステップを実行します。

  1. プライマリ・データベースでV$DATAFILEビューの問合せを行い、Oracleデータベースが最新の無効なREDOデータを生成したシステム変更番号(SCN)または時刻を特定します。
  2. プライマリ・データベースで次のSQL文を発行して、新たにバックアップを実行する必要があるかどうかを判断します。
    SQL> SELECT UNRECOVERABLE_CHANGE#,-
> TO_CHAR(UNRECOVERABLE_TIME, 'mm-dd-yyyy hh:mi:ss') -
> FROM V$DATAFILE;
  3. 前のステップの問合せで、データファイルが最後にバックアップされた時間よりも最近のデータファイルに対するリカバリ不能時間がレポートされる場合、問題のデータファイルの別のバックアップを作成します。

V$DATAFILEビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

フィジカル・スタンバイ・データベースの一部分のリカバリ・ステップ

RMANのRECOVER ... NONLOGGED BLOCKコマンドを使用して、データ・ファイルのセット、表領域のセット、または単に1つのプラガブル・データベース(PDB)およびマルチテナント・コンテナ・データベース(CDB)に属するブロックをリカバリできます。

この機能は、一部のデータ・ファイルに、ログに記録されないブロックを残すことが容認される場合に便利です(たとえば、現在削除されているオブジェクトに行をロードした結果として、ログに記録されないブロックが作成されたことがはっきりと分かっている場合など)。

V$NONLOGGED_BLOCKビューには通常、各データ・ファイルの既知の無効なブロックの範囲がリストされ、エントリはメディア・リカバリの一環として保持されます。ただし、情報が完全でないことがあります。通常、これはOracle Database 12cリリース1 (12.1)より前のリリースからアップグレードした後、またはデータ・ファイルのオペレーティング・システム・バックアップをリストアした後などです。次にメディア・リカバリを実行すると、失効エントリは削除されて新たに無効化されたブロックが記録されますが、前の無効なブロックはV$NONLOGGED_BLOCKにエントリがありません。 データ・ファイルにV$NONLOGGED_BLOCKエントリがない場合でも、V$DATAFILEビューのFIRST_NONLOGGED_SCN列を使用して、データ・ファイルに少なくとも1つの無効なブロックが存在することを確認できます。

RMANコマンドVALIDATE ... NONLOGGED BLOCKを使用して、V$NONLOGGED_BLOCKのエントリをデータ・ファイルと再び同期できます。それには、既存の範囲が完全かどうかを判断し、完全でない場合は、必要なデータ・ファイルをスキャンして無効なブロックを識別し、それらがV$NONLOGGED_BLOCKのエントリによって取得されるようにします。 VALIDATE ... NONLOGGED BLOCKコマンドには、単にデータ・ファイルのセット、表領域のセット、またはPDBやCDBを検証するための、RECOVER ... NONLOGGED BLOCKと同じオプションがあります。

ノート:

V$NONLOGGED_BLOCKビューのエントリは無効なブロックのスーパーセットであるため、無効なブロックに近い正常なブロックがいくつか含まれる可能性があります。 たとえば、ブロック100で始まるファイル7のエントリに、50のブロックが含まれる場合、これら50のブロックは一部または全部が無効であるか、いずれも無効ではありません。 VALIDATEコマンドを実行すると、無効なブロックがない範囲はなくなり、範囲の最初と最後のブロックも無効なブロックになります。 ただし、制御ファイルで保持できる範囲の合計数には制限があるため、同じファイルの範囲を結合しなければならないことがあり、それが通常のブロックが範囲に含められる原因となります。

オフライン・データ・ファイルのみを検証またはリカバリする場合は、RMANコマンドの実行時に、それらが属するデータベースを開くことができます。

OMFまたはOracle ASMを使用するスタンバイ・データベースの作成

スタンバイ・データベースを作成するときは、プライマリ・データベースでOracle Managed Files (OMF)またはOracle Automatic Storage Management (Oracle ASM)を使用する場合に実行する必要のある追加ステップがあります。

この項の説明は、すでにフィジカル・スタンバイ・データベースの作成方法を理解しており、RMAN、OMFおよびOracle ASM機能に習熟していることを前提としています。

スタンバイ・データベースを作成する前に、次の準備作業を実行します。

  1. プライマリ・データベースで強制ロギングを使用可能にします。

  2. プライマリ・データベースでアーカイブを使用可能にします。

  3. プライマリ・データベースで必要な初期化パラメータをすべて設定します。

  4. スタンバイ・データベース用に初期化パラメータ・ファイルを作成します。

  5. プライマリ・データベースがOMFを使用するよう構成されている場合、スタンバイ・データベースもOMFを使用するよう構成することをお薦めします。これを行うには、DB_CREATE_FILE_DESTおよびDB_CREATE_ONLINE_LOG_DEST_n初期化パラメータに適切な値を設定します。プライマリおよびスタンバイ・データベースの両方で同じディスク・グループ名が使用されている場合、メンテナンスや後のロールの推移が簡易化されます。

    ノート:

    スタンバイにOMFパラメータが設定されている場合は、そのスタンバイの新しいファイルはプライマリでの作成方法とは関係なく、常にOMFとして作成されます。したがって、DB_FILE_NAME_CONVERTおよびDB_CREATE_FILE_DESTパラメータの両方がスタンバイに設定されている場合は、DB_CREATE_FILE_DESTパラメータが優先されます。

  6. STANDBY_FILE_MANAGEMENT初期化パラメータにAUTOを設定します。

  7. スタンバイ・データベースに接続するために、必要に応じてOracle Netを構成します。

  8. REDO転送の認証を構成します。詳細は、「REDO転送の認証の構成」を参照してください。

  9. 制御ファイルをマウントせずにスタンバイ・データベース・インスタンスを起動します。

スタンバイ・データベースを作成するには、次の作業を実行します。

  1. スタンバイ・データベースでOracle ASMを使用する場合、スタンバイ・データベース・システムにOracle ASMインスタンスが存在していなければ、インスタンスを作成します。

  2. RMANのBACKUPコマンドを使用して、プライマリ・データベースのデータファイル、アーカイブ・ログ・ファイルおよびスタンバイ制御ファイルのコピーが含まれているバックアップ・セットを作成します。

  3. RMANのDUPLICATE FOR STANDBYコマンドを使用して、バックアップ・セットのデータファイル、アーカイブREDOログ・ファイルおよびスタンバイ制御ファイルをスタンバイ・データベースの格納場所にコピーします。

    DUPLICATE FOR STANDBYコマンドは、スタンバイ・インスタンスで実際のデータ移動を実行します。バックアップ・セットがテープ上にある場合、スタンバイ・インスタンスがバックアップ・セットを読み取れるように、メディア・マネージャを構成しておく必要があります。バックアップ・セットがディスク上にある場合は、ネットワーク・ファイル記憶域(NFS)でプライマリ・パス名を使用できるようにするか、スタンバイ・システムにコピーしてRMANのCATALOG BACKUPPIECEコマンドを使用し、バックアップ・ピースをカタログに追加してからリストアを行うことで、スタンバイ・インスタンスがバックアップ・ピースを読み取れるようにする必要があります。

これらのステップを完了した後、「フィジカル・スタンバイ・データベースが正しく実行されているかどうかの確認」のステップを実行してフィジカル・スタンバイ・データベースの構成を確認します。

ロジカル・スタンバイ・データベースを作成するには、「ロジカル・スタンバイ・データベースの作成」で説明されているスタンバイ・データベースの作成プロセスを実行しますが、次の点を変更します。

  1. ロジカル・スタンバイ・データベースの場合、DB_CREATE_FILE_DESTパラメータを設定しても、OMFファイル名を強制的に作成しません。ただし、このパラメータをプライマリ・データベースで設定する場合、スタンバイ・データベースでも設定する必要があります。
  2. プライマリ・システムでロジカル・スタンバイ制御ファイルを作成した後、このファイルをスタンバイ・システムにコピーするために、オペレーティング・システムのコマンドを使用しないでください。かわりにRMANのRESTORE CONTROLFILEコマンドを使用して、ロジカル・スタンバイ制御ファイルのコピーをスタンバイ・システムにリストアします。
  3. プライマリ・データベースでOMFファイルを使用する場合、スタンバイ・データベースに作成された新しいOMFファイルをスタンバイ・データベース制御ファイルが使用するよう、RMANを使用してスタンバイ・データベース制御ファイルを更新します。この操作を実行するには、次の例に示すように、スタンバイ・データベースにのみ接続します。
    > RMAN TARGET sys@lstdby

target database Password: password

RMAN> CATALOG START WITH '+stby_diskgroup';
RMAN> SWITCH DATABASE TO COPY;

これらのステップを完了した後、「ロジカル・スタンバイ・データベースのオープン」のステップを実行してロジカル・スタンバイ・データベースの起動、リカバリおよび検証を行います。

関連項目:

プライマリ・データベースでの書込みの欠落エラーからのリカバリ

Oracle Data Guard構成でのメディア・リカバリの実行中に、フィジカル・スタンバイ・データベースを使用してプライマリ・データベースで書込みの欠落によるデータ破損エラーを検出できます。

これは、プライマリ・データベースのREDOログに格納されているブロックのSCNをフィジカル・スタンバイ・データベースのブロックのSCNと比較して行います。プライマリ・データベースのブロックのSCNがスタンバイ・データベースのSCNよりも小さい場合は、プライマリ・データベースで書込みの欠落が発生しています。

そのような状況で、書込み欠落の検出(DB_LOST_WRITE_PROTECT初期化パラメータで設定)がプライマリとスタンバイ両方のレベルで有効な場合、スタンバイでリカバリを試行するとORA-752エラーになります。書込み欠落の検出が有効でない場合、リカバリを試行するとORA-600 [3020]エラーになります。ただし、ORA-600 [3020]エラーがすべて、プライマリにおける書込み欠落に起因するとはかぎりません。したがって、この項で説明するガイドラインに従う前にOracle Supportの担当者と協力し、ORA-600 [3020]エラーの根本原因が本当に、プライマリで発生した書込みの欠落なのかどうかを判断します。My Oracle Supportのノート1265884.1 (http://support.oracle.com)の『Resolving ORA-752 or ORA-600 [3020] During Standby Recovery』も参照してください。

ノート:

書込み欠落のエラーはプライマリによってブロックがキャッシュに読み取られた後、対応するREDOをスタンバイのブロックと比較した場合にのみ検出されるので、プライマリおよびスタンバイの両方で読取りや検証がまだ行われていない未検出ブロックが存在している可能性があります。古いブロックを読み取るまでに問合せや更新のためにスタンバイ上で使用したブロックのうち、現在適用しているREDOのSCNまでの全ブロックはスタンバイによる検証済なので、古いブロックが現行のデータベース操作に影響を及ぼすことはありません。

プライマリの書込みの欠落エラーがスタンバイで検出されると、失効したブロックごとに次のようなブロック・エラー・メッセージが1つ以上スタンバイ・データベースのアラート・ファイルに出力されます。

Tue Dec 12 19:09:48 2006
STANDBY REDO APPLICATION HAS DETECTED THAT THE PRIMARY DATABASE
LOST A DISK WRITE OF BLOCK 26, FILE 7
NO REDO AT OR AFTER SCN 389667 CAN BE USED FOR RECOVERY.
.
.
.

次に、アラート・ファイルは、ORA-00752エラーがスタンバイ・データベースに発生し、管理リカバリが取り消されたことを示します。 

Slave exiting with ORA-752 exception
Errors in file /oracle/log/diag/rdbms/dgstwrite2/stwrite2/trace/stwrite2_pr00_23532.trc:
ORA-00752: recovery detected a lost write of a data block
ORA-10567: Redo is inconsistent with data block (file# 7, block# 26)
ORA-10564: tablespace TBS_2
ORA-01110: data file 7: '/oracle/dbs/btbs_21.f'
ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 57503
.
.
.

次に、スタンバイ・データベースは、アラート・ファイルに出力されたSCN時点で、このエラーによるデータファイルの破損がない、一貫した状態にリカバリされます。

Recovery interrupted!
Recovered data files to a consistent state at change 389569

この最後のメッセージは、アラート・ファイルのかなり後の方に表示されることがあり、ブロック・エラー・メッセージより小さいSCNの場合もあります。また、プライマリ・データベースは、すでにデータファイルに破損があってもエラーが表示されずに動作している場合があります。

このようなエラーからリカバリするための推奨手順は、次のステップに示すように、フィジカル・スタンバイにフェイルオーバーします。

プライマリで書込みの欠落が検出された後のフィジカル・スタンバイへのフェイルオーバーのステップ

  1. プライマリ・データベースを停止します。ブロック・エラー・メッセージに出力されたSCN以降のデータがすべて消失します。

  2. スタンバイ・データベースで次のSQL文を発行してプライマリに変換します。

    SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;

Database altered.

Tue Dec 12 19:15:23 2006
alter database activate standby database
ALTER DATABASE ACTIVATE [PHYSICAL] STANDBY DATABASE (stwrite2)
RESETLOGS after incomplete recovery UNTIL CHANGE 389569
Resetting resetlogs activation ID 612657558 (0x24846996)
Online log /oracle/dbs/bt_log1.f: Thread 1 Group 1 was previously cleared
Online log /oracle/dbs/bt_log2.f: Thread 1 Group 2 was previously cleared
Standby became primary SCN: 389567
Tue Dec 12 19:15:23 2006
Setting recovery target incarnation to 3
Converting standby mount to primary mount.
ACTIVATE STANDBY: Complete - Database mounted as primary (stwrite2)
Completed: alter database activate standby database

  3. 新しいプライマリのバックアップを行います。データベースの完全なバックアップ・コピーがなければ、フェイルオーバー後の変更をリカバリすることができないので、バックアップをすぐに実行することは安全策として必要な作業です。フェイルオーバーを行うと元のプライマリ・データベースはOracle Data Guard構成に含まれなくなり、その他のすべてのスタンバイ・データベースが新しいプライマリ・データベースからREDOデータの受信と適用を行うようになります。

  4. 新規プライマリ・データベースをオープンします。

  5. オプションのステップとして、失敗したプライマリをフィジカル・スタンバイとして再作成します。これはステップ3で新しいプライマリで作成したデータベース・バックアップを使用して実行できます。(この場合は、フラッシュバック・データベースまたはOracle Data Guardブローカを使用して、元のプライマリ・データベースを回復することはできません。)新しいプライマリから作成したバックアップを使用して作成したフィジカル・スタンバイは、古いスタンバイと同じデータ・ファイルを保持することに注意してください。したがって、新しいスタンバイでは同じブロックを比較するため、古いスタンバイがアクティブ化される前に存在していた未検出の書込みの欠落は、新しいスタンバイによって検出されません。プライマリまたはスタンバイで発生した新しい書込みの欠落はすべて検出されます。

関連項目:

書込み欠落の検出有効化の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

DBCOMPプロシージャを使用した欠落書込みおよびその他の不一致の検出

PL/SQLプロシージャDBMS_DBCOMP.DBCOMPを使用して、欠落書込みの検出およびプライマリ・データベースとフィジカル・スタンバイ・データベースの間の不一致の検出も可能です。

DBMS_DBCOMP.DBCOMPプロシージャでは、プライマリ・データベースとフィジカル・スタンバイ・データベースの同じデータ・ブロックが比較されます。このプロシージャはいつでも実行できます。(DB_LOST_WRITE_PROTECT初期化パラメータを有効化する必要はありません。)

V$SESSION_LONGOPSビューを問い合せると、継続中のブロック比較操作の進捗状況を監視できます。

ノート:

ロジカル・スタンバイ・データベース、遠隔同期インスタンスおよびカスケード・スタンバイは、DBMS_DBCOMP.DBCOMPプロシージャのターゲット・データベースにはなれません。
DBMS_DBCOMP.DBCOMPプロシージャでは、1つのプライマリ・データベースと1つ以上のフィジカル・スタンバイ・データベースがあることを前提としています。データベースはブロック比較の前に少なくともマウントされている必要があります。

次の例の場合、一意の名前のdgmainを持ったプライマリ・データベースがあり、フィジカル・スタンバイ・データベースの名前がdgmainb、dgmainc、dgmaindなどであると仮定します。

例15-1 プライマリおよびすべてのスタンバイがマウントまたはオープンされており、DBCOMPがプライマリから実行される場合

この場合、DBCOMPプロシージャをプラマリ・データベースから実行すると、指定されたデータ・ファイルはプライマリとすべてのフィジカル・スタンバイ・データベースの間でブロック単位で比較されます。たとえば、次の問合せを実行するとします。 

SQL> exec sys.dbms_dbcomp.dbcomp(‘1’,’BlockCompare’,:retval);

生成される出力ファイルはBlockCompare_dgmainb_1およびBlockCompare_dgmainc_d_1です。

例15-2 プライマリおよびすべてのスタンバイがマウントまたはオープンされており、DBCOMPがスタンバイから実行される場合

この場合、DBCOMPプロシージャをスタンバイ・データベースの1つ(たとえばdgmainb)から実行すると、指定されたデータ・ファイルはプライマリと特定のスタンバイ・データベースの間でのみ比較されます。その他のスタンバイ・データベースは考慮されません。たとえば、次の問合せを実行するとします。 

SQL> exec sys.dbms_dbcomp.dbcomp(‘1’,’BlockCompare’,:retval);

生成される出力ファイルはBlockCompare_dgmain_1です。

例15-3 プライマリがマウントまたはオープンされているが、スタンバイはすべてがマウントまたはオープンされているとはかぎらず、DBCOMPがプライマリから実行される場合

この場合、 DBCOMPプロシージャをプラマリで実行すると、指定されたデータ・ファイルはプライマリ・データベースとマウントまたはオープンされたフィジカル・スタンバイ・データベースの間で比較されます。マウントもオープンもされていないスタンバイ・データベースの場合、処理はされません。

例15-4 プライマリがマウントまたはオープンされているが、スタンバイはすべてがマウントまたはオープンされているとはかぎらず、DBCOMPがスタンバイから実行される場合

この場合、指定されたデータ・ファイルはプライマリとDBCOMPプロシージャの実行元のスタンバイの間で比較されます。

例15-5 プライマリがマウントされていないが、複数のスタンバイがマウントまたはオープンされている場合

プライマリ・データベースはマウントもオープンもされていないため、 DBCOMPプロシージャは、比較するプライマリとフィジカル・スタンバイ・データベースの適切なペアを見つけることができません。ORAエラー・メッセージは返されませんが、次のようなメッセージが対応する出力ファイルに出力されます: Remote database is not in the primary role.

例15-6 プライマリがマウントまたはオープンされているが、マウントまたはオープンされているスタンバイがない場合

プライマリとフィジカル・スタンバイ・データベースの適切なペアが見つからないため、対応する出力ファイルにメッセージが出力されますが、ORAエラーは返されません。

関連トピック

RMANバックアップを使用した障害が発生したプライマリのスタンバイ・データベースへの変換

障害が発生したプライマリ・データベースを変換するには、プライマリでフラッシュバック・データベース機能を有効にし、必要に応じて次のいずれかの手順に従うことをお薦めします。

これらの項の手順では、障害が発生したプライマリをフィジカル・スタンバイまたはロジカル・スタンバイに変換する最も速い方法を説明しています。しかし、障害が発生したプライマリでフラッシュバック・データベースが無効になっている場合でも、次のトピックで説明するように、障害が発生したプライマリのローカル・バックアップを使用して、障害が発生したプライマリをフィジカル・スタンバイまたはロジカル・スタンバイに変換できます。

RMANバックアップを使用した、障害が発生したプライマリのフィジカル・スタンバイへの変換

このステップでは、RMANバックアップを使用して障害が発生したプライマリをフィジカル・スタンバイに変換する方法について説明します。

この手順には、古いプライマリのCOMPATIBLE初期化パラメータが11.0.0以上に設定されている必要があります。

  1. 新しいプライマリ・データベース上で次の問合せを発行し、古いスタンバイ・データベースが新しいプライマリ・データベースになったSCNを判別します。

    SQL> SELECT TO_CHAR(STANDBY_BECAME_PRIMARY_SCN) FROM V$DATABASE;

  2. スタンバイが新しいプライマリになったSCN(standby_became_primary_scn)に古いプライマリが到達する前に作成したバックアップを使用して、データベースをリストアします。次に、Point-in-Timeリカバリを実行して、古いプライマリをそれと同じ時点までリカバリします。

    次のRMANコマンドを発行します。

    RMAN> RUN
    {
      SET UNTIL SCN <standby_became_primary_scn + 1>;
      RESTORE DATABASE;
      RECOVER DATABASE;
     }

    ユーザー管理リカバリでは、先にデータベースを手動でリストアできます。通常、フェイルオーバー前の、数時間を要したバックアップは古くなっています。そのため、障害が発生したプライマリは次のコマンドを使用してリカバリできます。

    SQL> RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CHANGE -
>  <standby_became_primary_scn + 1>;

    フラッシュバック・データベースを使用する再インスタンス化とは異なり、この手順ではstandby_became_primary_scnに1を加算します。データファイルの場合、SCNまでフラッシュバックすることは、そのSCNに1を加算するまでリカバリすることと同義です。

  3. 古いプライマリ・データベースで次のステップを実行します。

    1. 古いプライマリ・データベースで次の文を発行します。

      SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

    2. データベースを停止して、再開します。

      SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;

  4. 次のコマンドを発行します。

    SQL> ALTER DATABASE OPEN READ ONLY;

    このステップの目的は、ディクショナリ・チェックを使用して制御ファイルをデータベースと同期させることです。このコマンドの後に、ディクショナリ・チェックで示されたアクションがないかアラート・ログをチェックします。通常、フェイルオーバー中に古いプライマリがデータファイルを追加または削除している途中でなければ、ユーザー・アクションは必要ありません。

  5. Oracle Active Data Guardオプション用にライセンスを購入しているときに、フィジカル・スタンバイ・データベースをアクティブ問合せモードで使用する場合は、このステップをスキップします。それ以外の場合は、スタンバイ・データベースをMOUNT状態にします。

    たとえば:

    SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;

  6. 新しいスタンバイ・データベースの作成前に、新しいプライマリ・データベースは、リモート宛先へのREDOの転送を停止しているはずです。REDO転送サービスを再開するには、新しいプライマリ・データベースで次のステップを実行します。

    1. 次の問合せを発行し、アーカイブ宛先の現在の状態を調べます。

      SQL> SELECT DEST_ID, DEST_NAME, STATUS, PROTECTION_MODE, DESTINATION, -
> ERROR,SRL FROM V$ARCHIVE_DEST_STATUS;
      2. 
                                 
    2. 
                                    
      必要に応じて、宛先を使用可能にします。
      SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_n=ENABLE;

      3. 
                                 
    3. 
                                    
      スタンバイ・データベースが新しいプライマリ・データベースからのREDOデータの受信を確実に開始するよう、ログ・スイッチを実行し、これが成功したことを確認します。 
      
                                    
      
                                       
      ノート:
      
                                       
      これは、新しいプライマリに続いて、古いプライマリが新しいスタンバイになるために重要なステップです。このステップが実行されないと、古いプライマリは誤ったデータベース・ブランチにリカバリされます。問題を修正する唯一の方法は、古いプライマリを再度変換することです。
      
                                    
      
                                    
      SQLプロンプトで次の文を入力します。
      SQL> ALTER SYSTEM SWITCH LOGFILE;
SQL> SELECT DEST_ID, DEST_NAME, STATUS, PROTECTION_MODE, DESTINATION, -
> ERROR,SRL FROM V$ARCHIVE_DEST_STATUS;

      新しいスタンバイ・データベースで、REDO転送サービスがREDOデータを別のデータベースに転送しないよう、LOG_ARCHIVE_DEST_n初期化パラメータも変更する必要があります。1つのサーバー・パラメータ・ファイル(SPFILE)でプライマリおよびスタンバイ・データベース・ロールの両方がVALID_FOR属性で設定されている場合、このステップを実行する必要はありません。これにより、Oracle Data Guard構成は、ロールの推移後も正しく動作します。
                                    
      
                                 
      4. 
                              
    
                           
    7. 
                           
  7. 
                              
    次のようにして、新しいフィジカル・スタンバイ・データベースでREDO Applyを開始します。
    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

    障害が発生したプライマリ・データベースがリストアされてスタンバイ・ロールで稼働し始めた後、オプションでスイッチオーバーを実行し、それぞれのデータベースを元の(障害発生前の)ロールに推移できます。詳細は、「フィジカル・スタンバイ・データベースへのスイッチオーバーの実行」を参照してください。
                              
    
                           
    8. 
                        

                     

                     
                  

               
RMANバックアップを使用した障害が発生したプライマリのロジカル・スタンバイへの変換

                  

                     
このステップでは、RMANバックアップを使用して障害が発生したプライマリをロジカル・スタンバイに変換する方法について説明します。 

                     

                        
    
                           
  1. 
                              
    新しいプライマリ・データベースで次の問合せを発行し、障害が発生したプライマリ・データベースをリカバリするSCNを判別します。
    SQL> SELECT APPLIED_SCN RECOVERY_SCN FROM V$LOGSTDBY_PROGRESS;

    また、新しいプライマリ・データベースで、次のようにして、アーカイブ・ログの処理に使用するSCNを判別します。
    
                              
      
                                 
    1. 
                                    
      すべてのスタンバイREDOログを必ずアーカイブしておきます。次の問合せを発行し、戻されるNONEの値を検索します。データベースのサイズおよびアーカイブする必要があるログの数によって、NONEのステータスが戻されるまでしばらく時間がかかることがあります。
                                    
      SQL> SELECT PENDING_ROLE_CHANGE_TASKS FROM V$DATABASE;

      2. 
                                 
    2. 
                                    
      NONEのステータスが戻されたら、次の問合せを実行し、このリカバリの一環としてアーカイブ・ログの処理のためのSCNを取得します。
                                    
      SQL> SELECT VALUE ARCHIVE_SCN FROM SYSTEM.LOGSTDBY$PARAMETERS -
> WHERE NAME='STANDBY_BECAME_PRIMARY_SCN';

      3. 
                              
    
                           
    2. 
                           
  2. 
                              
    フェイルオーバー操作以後に作成されたアーカイブ・ログをすべて、障害が発生したプライマリ・データベースから削除します。障害が発生したプライマリ・データベースがスタンバイから分離されていた場合は、現行のプライマリ・データベースと一貫性がない不一致のアーカイブ・ログが存在する可能性があります。これらの不一致のアーカイブ・ログを適用しないようにするには、バックアップおよび高速リカバリ領域から削除する必要があります。次のRMANコマンドを使用すると、関連アーカイブ・ログを高速リカバリ領域から削除できます。
    RMAN> DELETE FORCE ARCHIVELOG FROM SCN ARCHIVE_SCN;

    削除されると、これらの不一致のログおよび後続のトランザクションはリカバリできなくなります。
    
                              
    
                           
    3. 
                           
  3. 
                              
    新しいプライマリ・データベースで、次の問合せを発行し、バックアップからリカバリする前に、障害が発生したプライマリ・データベースにコピーする必要があるログ・ファイルの最小セットを判別します。
    SQL> SELECT file_name FROM DBA_LOGSTDBY_LOG WHERE next_change# > ARCHIVE_SCN;

    必要なスタンバイ・ログを取得し、バックアップ・セットを新しいスタンバイにコピーして新しい高速フラッシュ・リカバリ領域にリストアします。これらのログはスタンバイREDOログから得られるため、スタンバイの標準アーカイブの一部ではありません。RMANユーティリティでは、部分的なファイル名を使用して正しい場所からファイルを取得できます。
    
                              
    次に、RMANのBACKUPコマンドの使用例を示します。
                              
    RMAN> BACKUP AS COPY DEVICE TYPE DISK FORMAT '/tmp/test/%U'
> ARCHIVELOG LIKE '<partial file names from above>%';

    次に、RMANのRESTOREコマンドの使用例を示します。
                              
    RMAN> CATALOG START WITH '/tmp/test';
RMAN> RESTORE ARCHIVELOG FROM SEQUENCE 33 UNTIL SEQUENCE 35;

    4. 
                           
  4. 
                              
    元のプライマリの全データファイルのバックアップをリストアし、RECOVERY_SCN + 1までリカバリします。現行の制御ファイルを利用することをお薦めします。
                              
    
                              
      
                                 
    1. 
                                    
      データベースを制限モードで起動して、データベースのオープン後にGUARD ALLコマンドが発行されるまでローグ・トランザクションから保護します。
                                    
      
                                 
      2. 
                                 
    2. 
                                    
      バックアップを使用して障害が発生したプライマリ・データベースのデータファイルをリストアします。
      
                                 
      3. 
                                 
    3. 
                                    
      フラッシュバック・データベースが有効な場合は、無効にします(USING BACKUP CONTROLFILE句に必要)。
                                    
      
                                 
      4. 
                                 
    4. 
                                    
      SQL*Plusで、RECOVERY_SCN +1までPoint-in-Timeリカバリを実行します。
                                    
      
                                 
      5. 
                              
    
                              
    現行の制御ファイルを使用してもバックアップ制御ファイルを使用しても、USING BACKUP CONTROLFILE句を指定してリストアされるアーカイブ・ログを指すことができるようにする必要があります。指定しないと、リカバリ・プロセスでは、ステップ3で取得したログではなく、オンラインREDOログへのアクセスが試行されることがあります。ステップ3で取得した順序の入力を求められた場合は、次のようにリストアされるアーカイブ・ログのコピーのファイル名を指定します。
                              
    SQL> RECOVER DATABASE UNTIL CHANGE RECOVERY_SCN + 1 USING BACKUP CONTROLFILE;

    5. 
                           
  5. 
                              
    RESETLOGSオプションを指定してデータベースをオープンします。
    SQL> ALTER DATABASE OPEN RESETLOGS;

    6. 
                           
  6. 
                              
    Database Guardの有効化
    SQL> ALTER DATABASE GUARD ALL;

    7. 
                           
  7. 
                              
    新しいプライマリ・データベースへのデータベース・リンクを作成してSQL Applyを開始します。
    SQL> CREATE PUBLIC DATABASE LINK myLink -
> CONNECT TO SYSTEM IDENTIFIED BY password -
> USING 'service name of new primary database';

    SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY myLink;

    この時点で、制限セッション(ALTER SYSTEM DISABLE RESTRICTED SESSION)を無効にできます。つまり、データベースを再起動してステップ4cのフラッシュバックを再度有効にする必要がある場合は、RESTRICTED SESSIONをオフにして再起動します。
                              
    
                           
    8. 
                        

                     

                     
                  

               

            
フィジカル・スタンバイの再作成を伴わないプライマリの文字セットの変更

               

                  
Oracle Data Guardでは、構成内のフィジカル・スタンバイ・データベースを再作成することなく、プライマリ・データベースのデータベース文字セットと各国語文字セットの両方を変更できます。 

                  
プライマリ・データベースの文字セット変換の実行中に、中断を最小限に抑えて、フィジカル・スタンバイ・データベースを使用し続けることができます。

                  
文字セット移行プロセスは、考えられる問題の調査や問題を解決する方法の特定など、準備ステップで構成されます。これらの準備ステップの実行中、Oracle Data Guard構成は変わらず動作でき、フィジカル・スタンバイを維持するために何ら追加のステップは必要ありません。準備ステップの完了後、実際の変換が実行されます。これにはシステム・データ(メタデータ)およびユーザー・データの両方への変更が含まれる可能性があります。Oracle Data Guardに特有のいくつかの手順を、変換の一部として実行する必要があります。これらを実行する手順には、Database Migration Assistant for Unicode (DMU)やその他の適切な文字セットの変換ツールにより実行されるステップが組み入れられています。

                  
このプロセスに必要なステップの詳細は、http://support.oracle.comにあるMy Oracle Support ノート1124165.1を参照してください。 
                  

               

            
プライマリでのPDB PITRまたはPDBフラッシュバック後にスタンバイで必要なアクション

               

                  
プライマリでPDBのPoint-in-Timeリカバリ(PITR)またはPDBフラッシュバックを実行した後、スタンバイ上のPDBまたはフラッシュバックをリストアしてプライマリをスタンバイに継がせることができます。

                  

                     

                     
Oracle Databaseリリース19cでは、スタンバイがマウント・モードで、かつフラッシュバック・データベースが有効になっている場合、何も実行する必要はありません。一般的なケースでは、十分なフラッシュバック・データが存在する場合は、引き続きスタンバイがプライマリを継ぐように、スタンバイは自動的にフラッシュバックされます。

                     
                     
                     
他のすべての場合(スタンバイがオープンされている場合)は、「Active Data Guard環境でのPDB PITRまたはPDBフラッシュバック後のリカバリ」を参照してください。

                  

                  
               

               

                  

                     
関連トピック

                     
                  

               

            

            
Active Data Guard環境でのPDB PITRまたはPDBのフラッシュバック後のリカバリ 

               

                  
Active Data Guard環境では、PDBリカバリ分離により、スタンバイ上の特定のCDBのメディア・リカバリが、1つ以上のPDBと残りのCDBに一貫性がない場合に影響を受けることがなくなります。

                  

                     
PDBリカバリ分離について

                     
                     

                        
ノート:
PDBリカバリ分離は、Active Data Guard環境でのみ有効になります。
                     

                     
                     
                     
Active Data Guardメディア・リカバリでPDBにおいてホット・クローニング、Point-in-Timeリカバリまたはフラッシュバック・データベース操作が実行されたことが検出されると、次のステップが実行されます。

                     
                     
    
                        
  • 
                           
                           
    そのPDBが、無効として一時的にマークされ、CDBメディア・リカバリが続行されます。
    
                           
                        
    • 
                        
  • 
                           
                           
    別個のバックグラウンド・セッションでそのPDBが自動的にリカバリされます。これはPDBリカバリ分離と呼ばれます。
    
                           
                        
    • 
                        
  • 
                           
                           
    PDBリカバリ分離の完了後にそのPDBが有効化されます。
    
                           
                        
    • 
                        
  • 
                           
                           
    Active Data Guardメディア・リカバリ・セッションとPDBリカバリ分離がマージされます。
    
                           
                        
    • 
                     

                     
                     
PDBリカバリ分離を実行するには、CDBがオープンされている必要があります。PDBごとに1つずつの、複数のPDBリカバリ分離セッションをパラレルで実行できます。Active Data Guardメディア・リカバリを停止してから再起動すると、PDBリカバリ分離が自動的に再起動されます。

                     
                     
PDBリカバリ分離は自動プロセスですが、手動で停止および開始できます。PDBリカバリ分離を手動で停止する場合は、後でそれを再起動する必要があります。そうしないと、PDBリカバリ分離は無効なままになります。

                     
                     
PDBリカバリ分離を手動で停止するには:

                     
                     
    
                        
  • 
                           
                           
    RECOVER MANAGED STANDBY CANCEL句を指定してALTER PLUGGABLE DATABASEコマンドを使用します。
                           
    
                           
                           
    たとえば、PDB my_pdbのPDBリカバリ分離を停止するには、次のようにします。
                           
    
                           
    ALTER PLUGGABLE DATABASE my_pdb RECOVER MANAGED STANDBY DATABASE CANCEL;
    
                           
    そのPDBに接続している場合や現在のコンテナがそのPDBに設定されている場合は、ALTER DATABASEコマンドを使用することもできます。
                           
    
                           
                        
    • 
                     

                     
                     
PDBリカバリ分離が停止されている場合は、V$PDBS内またはV$CONTAINER内のRECOVERY_STATUS列の値がDISABLEDになります。
                     

                     
                     
PDBリカバリ分離を手動で開始するには:

                     
                  

                  
                  
    
                     
  • RECOVER MANAGED STANDBY句を指定してALTER PLUGGABLE DATABASEコマンドを使用します。
    たとえば、PDB my_pdbのPDBリカバリ分離を開始するには、次のようにします。
    ALTER PLUGGABLE DATABASE my_pdb RECOVER MANAGED STANDBY DATABASE;
    そのPDBに接続している場合や現在のコンテナがそのPDBに設定されている場合は、ALTER DATABASEコマンドを使用することもできます。
                           
    
                        
    
                        
    
                           
                           
    スタンバイでメディア・リカバリが実行されていないときにPDBリカバリ分離を開始した場合、リカバリは、現在のスタンバイ・データベース・チェックポイントSCNで停止します。PDBリカバリ分離が完了するまでは、スタンバイに対してメディア・リカバリを有効にできません。
    
                           
                           
    PDBリカバリ分離が停止されている場合は、V$PDBS内またはV$CONTAINER内のRECOVERY_STATUS列の値がDISABLED AUTOMATIC RECOVERになります。
                           
    
                           
                        
    
                     
    •