G 古い構文を使用したロールの推移の実行

Oracle Database 12cリリース1 (12.1)より前は、フィジカル・スタンバイ・データベースへのスイッチオーバーおよびフェイルオーバーを実行するプロシージャは異なっていました。

これらのプロシージャは引き続きサポートされていますが、フィジカル・スタンバイ・データベースが関与するロールの推移で説明している新しいプロシージャを使用することをお薦めします。

Oracle Database 12cリリース1 (12.1)よりも前のリリースを使用している場合、古いプロシージャを使用する必要があります。

次の内容について説明します。

G.1 フィジカル・スタンバイが関与するロールの推移のSQL構文

Oracle Database 12cリリース1 (12.1)では、フィジカル・スタンバイ・データベースへのスイッチオーバーおよびフェイルオーバー操作の実行のために新しいSQL構文が導入されています。

Oracle Database 12cリリース1 (12.1)では、フィジカル・スタンバイ・データベースへのスイッチオーバーおよびフェイルオーバー操作の実行のために新しいSQL構文が導入されています。特別な指示がないかぎり、古いプロシージャ(この付録で説明)の構文と新しいプロシージャ(「ロールの推移」で説明)の構文を混在させないでください。

12cより前のフィジカル・スタンバイ・データベースに対するロールの推移の構文 12cのフィジカル・スタンバイ・データベースに対するロールの推移の構文

フィジカル・スタンバイ・データベースにスイッチオーバーするには、プライマリ・データベースで次の手順を実行します。

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;

フィジカル・スタンバイ・データベースで次の手順を実行します。

SQL>ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

フィジカル・スタンバイ・データベースにスイッチオーバーするには、次の手順を実行します。

SQL> ALTER DATABASE SWITCHOVER TO target_db_name [FORCE] [VERIFY];

フィジカル・スタンバイ・データベースにフェイルオーバーするには(古い構文を使用したフィジカル・スタンバイ・データベースへのフェイルオーバーの実行の手順6および手順8):

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;

AND

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

フィジカル・スタンバイ・データベースにフェイルオーバーするには、以前必要だった2つの文のかわりに次の文を使用します。

SQL> ALTER DATABASE FAILOVER TO target_db_name;

関連項目:

G.1.1 古い構文を使用する場合の新しい機能

Oracle Database12cリリース1 (12.1)から、アクティブなSQLセッションを強制終了するときにWITH SESSION SHUTDOWN句は不要になりました。

次の文を発行してアクティブなSQLセッションを自動的に強制終了できます。

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;

さらに、Oracle RACプライマリ・データベースからフィジカル・スタンバイ・データベースにスイッチオーバーを実行する場合、1つを残してすべてのプライマリ・データベース・インスタンスを停止する必要はなくなりました。スイッチオーバーの完了後、すべてのインスタンスは自動的に停止します。

G.2 フィジカル・スタンバイ・データベースが関与するロールの推移

Oracle Databaseリリース12cリリース1 (12.1)よりも前のリリースでは、フィジカル・スタンバイ・データベースへのスイッチオーバーおよびフェイルオーバーを実行するSQL構文が異なっていました。

次に示すのは、12.1より前のリリースを実行している場合に使用する必要のあるプロシージャです。

関連項目:

スイッチオーバーおよびフェイルオーバーの準備方法の詳細は「ロールの推移」を参照してください。

G.2.1 古い構文を使用したフィジカル・スタンバイ・データベースへのスイッチオーバーの実行

スイッチオーバーはプライマリ・データベースで開始され、ターゲット・スタンバイ・データベースで完了します。

このトピックでは、フィジカル・スタンバイ・データベースへのスイッチオーバーを実行する方法について説明します。

  1. プライマリ・データベースがスタンバイ・ロールに切替え可能であることを確認します。

    プライマリ・データベースでV$DATABASEビューのSWITCHOVER_STATUS列を問い合せます。次に例を示します。

    SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
    
    SWITCHOVER_STATUS 
     ----------------- 
     TO STANDBY 
     1 row selected 
    

    TO STANDBYまたはSESSIONS ACTIVEは、プライマリ・データベースをスタンバイ・ロールに切替え可能であることを示します。これらのいずれの値も戻されない場合、REDO転送が正しく構成されていないか、正しく機能していないため、スイッチオーバーは不可能です。REDO転送の構成および監視の詳細は、「REDO転送サービス」を参照してください。

  2. プライマリ・データベースで次のSQL文を発行してスタンバイ・ロールに切り替えます。
    SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;
    

    この文では、プライマリ・データベースをフィジカル・スタンバイ・データベースに変換します。現行の制御ファイルは、スイッチオーバーの前にカレントSQLセッション・トレース・ファイルにバックアップされます。これによって、必要に応じて現行の制御ファイルを再作成できるようになります。

  3. 元のプライマリ・データベースをマウントします。例:
    SQL> STARTUP MOUNT;
    

    スイッチオーバー・プロセスのこの時点では、元のプライマリ・データベースがフィジカル・スタンバイ・データベースです。

  4. ターゲット・スタンバイ・データベースでV$DATABASEビューのSWITCHOVER_STATUS列を問い合せて、スイッチオーバー・ターゲットをプライマリ・ロールに切り替える準備ができていることを確認します。次に例を示します。
    SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
    
    SWITCHOVER_STATUS 
    ----------------- 
    TO PRIMARY 
    1 row selected
    

    TO PRIMARYまたはSESSIONS ACTIVEは、スタンバイ・データベースでプライマリ・ロールに切り替える準備が完了していることを示します。これらのいずれの値も戻されない場合、REDO applyがアクティブで、REDO転送が正しく構成されて機能していることを確認します。値TO PRIMARYまたはSESSIONS ACTIVEが戻されるまで、この列の問合せを続行します。

  5. ターゲット・フィジカル・スタンバイ・データベースで次のSQL文を発行して、プライマリ・ロールに切り替えます。
    SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;

    注意:

    手順4で実行した問合せでTO PRIMARYの値が戻された場合、WITH SESSION SHUTDOWN句をスイッチオーバー文から省略できます。

  6. 新しいプライマリ・データベースをオープンします。
    SQL> ALTER DATABASE OPEN;
  7. 新しいフィジカル・スタンバイ・データベースでREDO Applyを開始します。
    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE -
    > DISCONNECT FROM SESSION;
  8. Oracle Data Guard構成のその他のフィジカル・スタンバイ・データベースのいずれかでREDO Applyが停止している場合は、これを再開します。
    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE -
    > DISCONNECT FROM SESSION;

G.2.2 古い構文を使用したフィジカル・スタンバイ・データベースへのフェイルオーバーの実行

この手順では、フィジカル・スタンバイ・データベースへのフェイルオーバーを実行する方法について説明します。

  1. 可能な場合は、プライマリ・データベースをマウントして、未送信のアーカイブされた現行のREDOをプライマリ・データベースからスタンバイ・データベースにフラッシュします。この操作が正常に終了した場合、プライマリ・データベースがデータ消失ゼロのデータ保護モードで実行されていなくても、データの消失がないようにフェイルオーバーすることができます。

    ターゲット・スタンバイ・データベースでREDO Applyがアクティブであることを確認します。

    プライマリ・データベースをマウントします。オープンはしないでください。プライマリ・データベースをマウントできない場合は、手順2に進みます。

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

    SQL> ALTER SYSTEM FLUSH REDO TO target_db_name;
    

    target_db_nameには、プライマリ・データベースからフラッシュされたREDOを受信するスタンバイ・データベースのDB_UNIQUE_NAMEを指定します。

    この文は、未送信のREDOをすべて、プライマリ・データベースからスタンバイ・データベースにフラッシュし、このREDOがスタンバイ・データベースに適用されるまで待機します。

    この文がエラーなしに終了した場合は、手順5に進みます。この文でエラーが出た場合、または完了するまで待てないため、この文を停止しなければならない場合は、手順2に進みます。

  2. スタンバイ・データベースが、プライマリ・データベースREDOスレッドそれぞれについて、最新のアーカイブREDOログ・ファイルを持っていることを確認します。

    それには、ターゲット・スタンバイ・データベースでV$ARCHIVED_LOGビューを問い合せ、個々のREDOスレッドについて、最も大きなログ順序番号を取得します。

    次に例を示します。

    SQL> SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#) -
    > OVER (PARTITION BY thread#) AS LAST from V$ARCHIVED_LOG;
    
        THREAD       LAST
    ---------- ----------
             1        100
    

    可能であれば、各プライマリ・データベースREDOスレッドに対する最新のアーカイブREDOログ・ファイルがスタンバイ・データベースになければ、これをコピーし、登録します。これは、REDOスレッドごとに実行する必要があります。

    次に例を示します。

    SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';
  3. ターゲット・スタンバイ・データベースでV$ARCHIVE_GAPビューを問い合せ、ターゲット・スタンバイ・データベースにREDOギャップがあるかどうか判別します。

    次に例を示します。

    SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
    
    THREAD#    LOW_SEQUENCE# HIGH_SEQUENCE#
    ---------- ------------- --------------
             1            90             92
    

    この例では、スレッド1の順序番号90、91および92のアーカイブREDOログ・ファイルがギャップです。

    可能であれば、欠落しているすべてのアーカイブREDOログ・ファイルを、プライマリ・データベースからターゲット・スタンバイ・データベースにコピーして登録します。これは、REDOスレッドごとに実行する必要があります。

    次に例を示します。

    SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';
  4. すべてのギャップが解決されるまで手順3を繰り返します。(手順3で実行する問合せでは、順序番号が最も大きいギャップに関する情報のみが表示されるため、ギャップを解決した後、行が戻されなくなるまで問合せを繰り返す必要があります。)

    手順2から手順4を実行した後、アーカイブREDOログ・ファイルのすべてのギャップを解決できない場合(障害の発生したプライマリ・データベースのホスト・システムへのアクセス権がない場合など)、フェイルオーバー時にデータが消失する可能性があります。

  5. ターゲット・スタンバイ・データベースに次のSQL文を発行して、Redo Applyを停止します。
    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
  6. 受信したすべてのREDOデータの適用を終了します。
    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
    

    この文がエラーなしに終了した場合は、手順7に進みます。

    エラーが発生した場合、受信されたREDOデータに適用されていないものがあります。エラーの原因を解決し、文を再発行してから次の手順に進みます。

    手順3および手順4で解決されなかったREDOギャップがある場合、REDOギャップがあることを知らせるエラーが表示されます。

    エラー状態を解決できない場合でも、ターゲット・スタンバイ・データベースで次のSQL文を発行してフェイルオーバーを実行できます(一部のデータが消失する可能性があります)。

    SQL> ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE;
    

    ACTIVATE文が完了した後、手順9に進みます。

  7. ターゲット・スタンバイ・データベースがプライマリ・データベースになる準備が完了していることを確認します。

    それには、ターゲット・スタンバイ・データベースでV$DATABASEビューのSWITCHOVER_STATUS列を問い合せます。次に例を示します。

    SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
    
    SWITCHOVER_STATUS
    -----------------
    TO PRIMARY
    1 row selected
    

    TO PRIMARYまたはSESSIONS ACTIVEは、スタンバイ・データベースでプライマリ・ロールに切り替える準備ができていることを示します。これらのいずれの値も戻されない場合、REDO Applyがアクティブで、TO PRIMARYまたはSESSIONS ACTIVEのいずれかが戻されるまでこのビューを問い合せ続けることを確認します。

  8. ターゲット・フィジカル・スタンバイ・データベースで次のSQL文を発行して、フィジカル・スタンバイをプライマリ・ロールに切り替えます。
    SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;

    注意:

    前の手順で実行されたSWITCHOVER_STATUS列の問合せでTO PRIMARYが戻された場合、WITH SESSION SHUTDOWN句をスイッチオーバー文から省略できます。

  9. 新しいプライマリ・データベースをオープンします。
    SQL> ALTER DATABASE OPEN;
  10. 新しいプライマリ・データベースをただちにバックアップすることをお薦めします。
  11. Oracle Data Guard構成のその他のフィジカル・スタンバイ・データベースのいずれかでREDO Applyが停止している場合は、これを再開します。
    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE -
    > DISCONNECT FROM SESSION;
  12. 必要に応じて、障害の発生したプライマリ・データベースをリストアします。

    フェイルオーバーの完了後、元のプライマリ・データベースは「フラッシュバック・データベースを使用した障害が発生したプライマリのスタンバイ・データベースへの変換」または「RMANバックアップを使用した障害が発生したプライマリのスタンバイ・データベースへの変換」で説明する方法に従って、新しいプライマリ・データベースのフィジカル・スタンバイ・データベースに変換できます。あるいは、「フィジカル・スタンバイ・データベースの作成手順」で説明した方法に従って、新しいプライマリ・データベースのバックアップからフィジカル・スタンバイ・データベースとして再作成できます。

    元のプライマリ・データベースをスタンバイ・ロールで実行したら、スイッチオーバーを実行してプライマリ・ロールにリストアできます。

G.3 フィジカル・スタンバイ・データベースへのスイッチオーバーのトラブルシューティング

フィジカル・スタンバイ・データベースへのスイッチオーバー時に発生する可能性がある問題の一部を次に示します。

注意:

次のトラブルシューティングの各項は、Oracle Database 12cリリース1 (12.1)よりも前のリリースで使用可能なプロシージャを使用した、フィジカル・スタンバイ・データベースへのスイッチオーバーおよびフェイルオーバーを実行する場合にのみ該当します。

G.3.1 REDOデータが転送されていないためスイッチオーバーできない

スイッチオーバーが正常に完了しない場合は、V$ARCHIVED_LOGビューのSEQUENCE#列の問合せを行い、元のプライマリ・データベースから転送された最新のREDOデータが、スタンバイ・データベースに適用されていることを確認してください。

最後のREDOデータがスタンバイ・データベースに転送されていない場合は、そのREDOデータが含まれるアーカイブREDOログ・ファイルを元のプライマリ・データベースから古いスタンバイ・データベースに手動でコピーし、SQL ALTER DATABASE REGISTER LOGFILE file_specification文を使用して登録します。次に適用サービスを開始すると、アーカイブREDOログ・ファイルが自動的に適用されます。V$DATABASEビューのSWITCHOVER_STATUS列を問い合せます。SWITCHOVER_STATUS列からTO PRIMARYまたはSESSIONS ACTIVEが戻されると、プライマリ・ロールへのスイッチオーバーが可能になります。

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

SWITCHOVER_STATUS 
----------------- 
TO PRIMARY 
1 row selected 

V$DATABASEビューのSWITCHOVER_STATUS列に対するその他の有効な値の詳細は、「Oracle Data Guardに関連するビュー」を参照してください。

スイッチオーバーを続行するには、「古い構文を使用したフィジカル・スタンバイ・データベースへのスイッチオーバーの実行」の指示に従い、ターゲット・スタンバイ・データベースをプライマリ・ロールへのスイッチを再試行します。

G.3.2 ORA-01102エラーによりスイッチオーバーできない

ORA-01102エラーが表示された場合に考えられる原因の一部と解決策を次に示します。

スタンバイ・データベースとプライマリ・データベースが同じサイトに存在するとします。ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY文およびALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY文の両方が正常に実行された後、フィジカル・スタンバイ・データベースとプライマリ・データベースを停止し、再起動します。

注意:

フィジカル・スタンバイ・データベースが起動後に読取り専用モードでオープンされていない場合、停止して再起動する必要はありません。

ただし、2番目のデータベースの起動は、ORA-01102「データベースを排他モードでマウントすることができません。」エラーで失敗します。

スタンバイ・データベース(元のプライマリ・データベース)で使用される初期化パラメータ・ファイルにDB_UNIQUE_NAMEパラメータを設定していないと、スイッチオーバー中にこの現象が発生することがあります。スタンバイ・データベースのDB_UNIQUE_NAMEパラメータが設定されていない場合、スタンバイ・データベースとプライマリ・データベースの両方が同じマウント・ロックを使用するため、2つ目のデータベースの起動時にORA-01102エラーが発生します。

処置: DB_UNIQUE_NAME=unique_database_nameをスタンバイ・データベースが使用する初期化パラメータ・ファイルに追加して、スタンバイ・データベースとプライマリ・データベースを停止し、再起動します。

G.3.3 スイッチオーバー後にREDOデータが適用されない

スイッチオーバー後にアーカイブREDOログ・ファイルが新しいスタンバイ・データベースに適用されない場合は、スイッチオーバー後に一部の環境パラメータまたは初期化パラメータが正しく設定されていなかったことが原因と考えられます。

処置:

  • 新しいプライマリ・サイトのtnsnames.oraファイルおよび新しいスタンバイ・サイトのlistener.oraファイルを調べます。スタンバイ・サイトにはリスナーのエントリ、プライマリ・サイトにはそれに対応するサービス名が必要です。

  • リスナーがまだ起動されていない場合は、スタンバイ・サイトで起動します。

  • プライマリ・サイトからスタンバイ・サイトにREDOデータを正しく転送するための、LOG_ARCHIVE_DEST_n初期化パラメータが設定されているかどうかを調べます。たとえば、プライマリ・サイトでV$ARCHIVE_DEST固定ビューを次のように問い合せます。

    SQL> SELECT DEST_ID, STATUS, DESTINATION FROM V$ARCHIVE_DEST;
    

    スタンバイ・サイトに対応するエントリが見つからない場合、LOG_ARCHIVE_DEST_n初期化パラメータおよびLOG_ARCHIVE_DEST_STATE_n初期化パラメータを設定する必要があります。

  • スタンバイ・サイトにSTANDBY_ARCHIVE_DEST初期化パラメータおよびLOG_ARCHIVE_FORMAT初期化パラメータを正しく設定し、アーカイブREDOログ・ファイルが適切な場所に適用されるようにします。(STANDBY_ARCHIVE_DESTパラメータは非推奨であり、下位互換性のためにのみサポートされています。)

  • スタンバイ・サイトで DB_FILE_NAME_CONVERT初期化パラメータおよび LOG_FILE_NAME_CONVERT初期化パラメータを設定します。プライマリ・サイトで作成された新しいデータファイルがスタンバイ・サイトに自動的に追加されるようにするには、STANDBY_FILE_MANAGEMENT初期化パラメータをAUTOに設定します。

G.3.4 失敗したスイッチオーバーをロールバックして最初からやりなおす

フィジカル・スタンバイ・データベースでエラーが発生し、スイッチオーバーを続行できない場合は、新しいフィジカル・スタンバイ・データベースをプライマリ・ロールに戻すことができます。

次の手順を実行します。

  1. 新しいスタンバイ・データベース(古いプライマリ)を停止し、マウントします。
  2. 新しいスタンバイ・データベースでREDO Applyを開始します。
  3. 新しいスタンバイ・データベースがいつでもプライマリ・ロールに戻せることを確認します。スタンバイ・データベースでV$DATABASEビューのSWITCHOVER_STATUS列を問い合せます。次に例を示します。
    SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
     
    SWITCHOVER_STATUS 
    ----------------- 
    TO_PRIMARY 
    1 row selected
    

    TO PRIMARYまたはSESSIONS ACTIVEは、スタンバイ・データベースでプライマリ・ロールに切り替える準備が完了していることを示します。値TO PRIMARYまたはSESSIONS ACTIVEが戻されるまで、この列の問合せを続行します。

  4. 次の文を発行して、新しいスタンバイ・データベースを変換してプライマリ・ロールに戻します。
    SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;
    

    この文が正常に実行されると、データベースはプライマリ・データベース・ロールで実行されるため、それ以降の手順を実行する必要はありません。

    この文が正常に実行されなかった場合は、手順5に進んでください。

  5. プライマリからフィジカル・スタンバイにロールを変更するスイッチオーバーを開始したときに、トレース・ファイルがログ・ディレクトリに書き込まれています。このトレース・ファイルには、元のプライマリ制御ファイルを再作成するために必要なSQL文が含まれています。トレース・ファイルの位置を特定し、SQL文を一時ファイルに抽出します。SQL*Plusから一時ファイルを実行します。これによって、新しいスタンバイ・データベースはプライマリ・ロールに戻されます。
  6. 元のフィジカル・スタンバイ・データベースを停止します。
  7. 新しいスタンバイ制御ファイルを作成します。このファイルは、プライマリ・データベースとフィジカル・スタンバイ・データベースの再同期化に必要です。フィジカル・スタンバイ制御ファイルを元のフィジカル・スタンバイ・システムにコピーします。フィジカル・スタンバイ制御ファイルの作成方法は、「スタンバイ・データベース用の制御ファイルの作成」を参照してください。
  8. 元のフィジカル・スタンバイ・インスタンスを再起動します。

    この手順が正常終了し、アーカイブ・ギャップ管理が使用可能になると、FALプロセスが起動し、欠落したアーカイブREDOログ・ファイルをフィジカル・スタンバイ・データベースに再アーカイブします。プライマリ・データベース上でログ・スイッチを強制実行し、プライマリ・データベースとフィジカル・スタンバイ・データベースの両方のアラート・ログを調べて、アーカイブREDOログ・ファイルの順序番号が正しいことを確認します。

    アーカイブ・ギャップ管理の詳細は「手動によるギャップの解決」を、トレース・ファイルの場所については「アーカイブ・トレースの設定」を参照してください。

  9. スイッチオーバーを再度実行します。

    この時点で、Oracle Data Guard構成は初期状態にロールバックされています。最初に失敗したスイッチオーバーの問題をすべて解決した後、スイッチオーバー操作を再度実行できます。