20 RMANのリカバリの実行: 高度な例

先行の「障害の診断および対応」の章は、最も基本的なリカバリの例についての一般的な説明となっています。この章では、基本的な例ほど一般的ではないか、またはより複雑な例について説明します。

この章のトピックは、次のとおりです:

20.1 増分バックアップを使用したNOARCHIVELOGモードのデータベースのリカバリ

NOARCHIVELOGモードで実行されているデータベースのリストアは、ARCHIVELOGモードのデータベースのリストアと類似しています。主な違いは次のとおりです。

  • NOARCHIVELOGモードでのデータベースのリストアでは、一貫性バックアップのみを使用できます。

  • アーカイブREDOログが存在しないため、メディア・リカバリは実行できません。

増分バックアップを適用することによって、制限された変更のリカバリをNOARCHIVELOGモードで実行されているデータベースに実行できます。NOARCHIVELOGモードで実行されるデータベースのすべてのバックアップと同様に、増分バックアップは一貫性バックアップである必要があります。そのため、データベースのオープン時にデータベースのバックアップは作成できません。

NOARCHIVELOGデータベースをリカバリする場合は、RECOVERコマンドでNOREDOオプションを指定し、RMANがアーカイブREDOログの適用を試行しないように指定します。そうしない場合、RMANによってエラーが戻されます。

増分バックアップを使用して NOARCHIVELOG データベースをリカバリする手順

  1. ターゲット・データベースおよびリカバリ・カタログに接続した後、データベースをマウント状態にします。
    STARTUP FORCE MOUNT
    
  2. データベースをリストアおよびリカバリします。

    たとえば、次のコマンドで不完全リカバリを実行できます。

    RESTORE DATABASE 
      FROM TAG "consistent_whole_backup";
    RECOVER DATABASE NOREDO;
    
  3. RESETLOGSオプションを指定してデータベースをオープンします。

    たとえば、次のコマンドを入力します。

    ALTER DATABASE OPEN RESETLOGS;

20.2 サーバー・パラメータ・ファイルのリストア

サーバー・パラメータ・ファイルが消失した場合は、RMANを使用して、デフォルトの場所または選択した場所にそのファイルをリストアできます。制御ファイルが消失した場合とは異なり、サーバー・パラメータ・ファイルが消失した場合、インスタンスはすぐに停止しません。インスタンスは継続して実行できます。ただし、サーバー・パラメータ・ファイルをリストアした後、インスタンスを停止して再起動する必要があります。

サーバー・パラメータ・ファイルをリストアする場合は、次の考慮事項に注意してください。

  • インスタンスがサーバー・パラメータ・ファイルを使用してすでに起動されている場合、既存のサーバー・パラメータ・ファイルを上書きすることはできません。

  • リストア・コマンドでTO句を使用せずにクライアント側の初期化パラメータ・ファイルを使用してインスタンスを起動すると、RMANによってサーバー・パラメータ・ファイルがデフォルトの場所にリストアされます。デフォルトの場所はプラットフォーム固有です。たとえば、Linuxでは?/dbs/spfile.oraです。

  • リカバリ・カタログを使用すると、DBIDの記録および記憶を省略できるため、リカバリ手順が簡単になります。次の手順では、リカバリ・カタログを使用していないと想定しています。

自動バックアップからサーバー・パラメータ・ファイルをリストアする手順

  1. RMANを起動し、次のいずれかを実行します。
    • サーバー・パラメータ・ファイルが消失したときにデータベース・インスタンスが起動されていた場合は、ターゲット・データベースに接続します。

    • サーバー・パラメータ・ファイルが消失したときにデータベース・インスタンスが起動されておらず、リカバリ・カタログを使用していない場合は、SET DBIDコマンドを実行してターゲット・データベースのDBIDを設定します。DBIDを決定する方法については、「データベースのDBIDの確認」を参照してください。

  2. データベース・インスタンスを停止し、データベースをマウントせずに再起動します。

    サーバー・パラメータ・ファイルを使用できない場合、RMANでは仮のパラメータ・ファイルを使用してインスタンスが起動されます。たとえば、次のコマンドを入力します。

    STARTUP FORCE NOMOUNT;
    
  3. RUNコマンドを実行してサーバー・パラメータ・ファイルをリストアします。

    状況によっては、RUNコマンドで複数のコマンドを実行する必要がある場合もあります。次のことに注意してください。

    • テープからリストアする場合は、ALLOCATE CHANNELを使用してSBTチャネルを手動で割り当てます。ディスクからリストアする場合は、RMANによってデフォルトのディスク・チャネルが使用されます。

    • 自動バックアップがデフォルトの書式(%F)で生成されなかった場合は、SET CONTROLFILE AUTOBACKUP FOR DEVICE TYPEコマンドを使用して、自動バックアップの実行時に有効であった書式を指定します。

    • 最新の自動バックアップが今日作成されなかった場合は、SET UNTILを使用して検索を開始する日付を指定します。

    • RMANがリカバリ・カタログに接続されていない場合は、SET DBIDを使用してターゲット・データベースのDBIDを設定します。

    • サーバー・パラメータ・ファイルをデフォルト以外の場所にリストアするには、RESTORE SPFILEコマンドでTO句またはTO PFILE句を指定します。

    • RMANによって1日にn個を超える自動バックアップが生成されないことがわかっている場合は、RESTORE SPFILE FROM AUTOBACKUP ... MAXSEQパラメータにnを設定して、検索時間を短縮することができます。MAXSEQはデフォルトで255に設定されており、RESTOREMAXSEQから逆算して、その日最後のバックアップを検索します。現在の日付(または指定した日付)の自動バックアップが検出されない場合にリストア操作を終了するには、RESTOREコマンドでMAXDAYS 1を設定します。

    次の例では、テープ上の自動バックアップからサーバー・パラメータ・ファイルをリストアするRUNコマンドを示します。

    RUN 
    {
      ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS ...;
      SET UNTIL TIME 'SYSDATE-7';
      SET CONTROLFILE AUTOBACKUP FORMAT 
        FOR DEVICE TYPE sbt TO '/disk1/control_files/autobackup_%F';
      SET DBID 123456789;
      RESTORE SPFILE
        TO '/tmp/spfileTEMP.ora'
        FROM AUTOBACKUP MAXDAYS 10;
    }
    
  4. リストアしたファイルを使用してデータベース・インスタンスを再起動します。

    デフォルト以外の場所にあるサーバー・パラメータ・ファイルを使用してRMANを再起動する場合は、行SPFILE=new_locationを含む初期化パラメータ・ファイルを作成します。ここで、new_locationは、リストアされたサーバー・パラメータ・ファイルのパス名です。 次に、クライアント側の初期化パラメータ・ファイルを使用してインスタンスを再起動します。

    たとえば、次の1行を含む/tmp/init.oraファイルを作成します。

    SPFILE=/tmp/spfileTEMP.ora
    

    次のRMANコマンドを使用すると、リストアされたサーバー・パラメータ・ファイルを使用してインスタンスを再起動できます。

    STARTUP FORCE PFILE=/tmp/init.ora;

20.2.1 制御ファイルの自動バックアップからのサーバー・パラメータ・ファイルのリストア

制御ファイルの自動バックアップが構成されている場合は、自動バックアップが実行されるたびに、制御ファイルとともにサーバー・パラメータ・ファイルが常にバックアップされます。

制御ファイルの自動バックアップからサーバー・パラメータ・ファイルをリストアするには、まずデータベースのDBIDを設定し、次にRESTORE SPFILE FROM AUTOBACKUPコマンドを使用する必要があります。自動バックアップがデフォルト以外の書式である場合は、最初にSET CONTROLFILE AUTOBACKUP FORMATコマンドを使用して書式を指定します。

例20-1では、DBIDを設定し、デフォルト以外の場所にある制御ファイルの自動バックアップから、サーバー・パラメータをリストアします。

例20-1 制御ファイルの自動バックアップからのサーバー・パラメータ・ファイルのリストア

SET DBID 320066378;
RUN 
{
  SET CONTROLFILE AUTOBACKUP FORMAT 
    FOR DEVICE TYPE DISK TO 'autobackup_format';
  RESTORE SPFILE FROM AUTOBACKUP;
}

RMANでは、自動バックアップの書式およびDBIDを使用して、制御ファイルの自動バックアップが検索されます。制御ファイルの自動バックアップが検出されると、RMANによってサーバー・パラメータ・ファイルがバックアップからデフォルトの場所にリストアされます。

autobackup_formatの適切な値を判断する方法については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』CONFIGUREコマンド用のエントリ内のCONFIGURE CONTROLFILE AUTOBACKUP FORMATについての説明を参照してください。

関連項目:

DBIDを決定する方法の詳細は、「データベースのDBIDの確認」を参照してください。

20.2.2 RMANを使用した初期化パラメータ・ファイルの作成

サーバー・パラメータ・ファイルは、TO PFILE 'filename'句を使用してクライアント側の初期化パラメータ・ファイルとしてリストアすることもできます。指定するファイル名は、RMANクライアントが実行されているホストからアクセス可能なファイル・システム上にあることを示している必要があります。このファイルは、インスタンスが実行されているホストから直接アクセス可能である必要はありません。

次のRMANコマンドを実行すると、RMANクライアントが実行されているシステム上に/tmp/initTEMP.oraという名前の初期化パラメータ・ファイルが作成されます。

RESTORE SPFILE TO PFILE '/tmp/initTEMP.ora';

初期化パラメータ・ファイルを使用してインスタンスを再起動するには、次のコマンドを使用して、同じクライアント・ホスト上でRMANを再度実行します。

STARTUP FORCE PFILE='/tmp/initTEMP.ora';

20.3 バックアップ制御ファイルを使用したリカバリの実行

この項では、現行のすべての制御ファイルが消失したため、バックアップ制御ファイルをリストアする必要がある場合に行う操作について説明します。

この項では、次の項目について説明します。

20.3.1 バックアップ制御ファイルを使用したリカバリの実行

現行のすべての制御ファイルのコピーが消失したか、または破損した場合は、バックアップ制御ファイルをリストアおよびマウントする必要があります。リストアされたデータファイルがない場合でも、RECOVERコマンドを実行し、RESETLOGSオプションを指定してデータベースをオープンする必要があります。 ただし、現行の制御ファイルのいくつかのコピーを使用できる場合は、「現行の制御ファイルのサブセットが消失した場合の対応」の手順を実行し、リカバリおよびRESETLOGS操作の実行を回避できます。

RMANは、リカバリ時にRMANリポジトリに記録されていないオンライン・ログおよびアーカイブ・ログを自動的に検索し、検出したログをカタログに追加します。RMANは、現行のアーカイブ先で、現行のログ・フォーマットを持つすべての有効なアーカイブREDOログの検索を試行します。現行のフォーマットは、このインスタンス(またはOracle RAC構成のすべてのインスタンス)の起動に使用される初期化パラメータで指定されます。同様に、RMANは、制御ファイルに示されたファイル名を使用して、オンラインREDOログの検索を試行します。

リカバリ時にアーカイブ先またはフォーマットを変更したり、制御ファイルのバックアップの後に新しいオンライン・ログ・メンバーを追加すると、RMANで、必要なオンライン・ログまたはアーカイブ・ログを自動的にカタログに追加できなくなる場合があります。RMANでは、UNTIL時間を指定しなかった場合にオンラインREDOログを検出できないと、次のようなエラーが通知されます。

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 08/29/2013 14:23:09
RMAN-06054: media recovery requesting unknown log: thread 1 scn 86945

この場合、リカバリを続行するには、CATALOGコマンドを使用して必要なREDOログをリポジトリに手動で追加する必要があります。

関連項目:

20.3.1.1 RMANリストア時の制御ファイルの場所について

制御ファイルをリストアする場合、デフォルトのリストア先は、CONTROL_FILES初期化パラメータに定義されているすべての場所です。CONTROL_FILES初期化パラメータを設定しない場合、データベースは、CONTROL_FILESパラメータが設定されていないときに制御ファイルを作成する場合と同じ規則を使用して、リストアされた制御ファイルの格納先を決定します。これらの規則については、『Oracle Database SQL言語リファレンス』CREATE CONTROLFILE文についての説明を参照してください。

1つ以上の新しい場所に制御ファイルをリストアするには、CONTROL_FILES初期化パラメータを変更した後、引数を指定せずにRESTORE CONTROLFILEを実行して制御ファイルをデフォルトの場所にリストアする方法があります。たとえば、CONTROL_FILESに定義されている場所の一部がディスク障害によって使用できなくなった後に制御ファイルをリストアする場合は、CONTROL_FILESで障害ディスクへの参照を別のディスクへのパス名に置き換えた後、引数を指定せずにRESTORE CONTROLFILEを実行します。

RESTORE CONTROLFILE TO 'filename'という形式を使用して、CONTROL_FILESに定義されている以外の任意の場所に制御ファイルをリストアすることもできます。

RESTORE CONTROLFILE TO '/tmp/my_controlfile';

現在使用中の制御ファイルは上書きされないため、この操作は、NOMOUNTMOUNTまたはOPENの状態のデータベースで実行できます。'filename'という名前のすべての既存ファイルが上書きされます。制御ファイルを新しい場所にリストアした後、CONTROL_FILES初期化パラメータを更新して新しい場所を追加定義できます。

関連項目:

RESTORE CONTROLFILEの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

20.3.1.2 RMANのリカバリ・カタログを使用したリカバリおよび使用しないリカバリについて

RMANがリカバリ・カタログに接続している場合、バックアップ制御ファイルを使用したリカバリ手順は、現行の制御ファイルを使用したリカバリと同様になります。バックアップ制御ファイルで欠落しているRMANメタデータは、リカバリ・カタログで入手可能です。唯一の例外は、データベース名がカタログ内で一意でない場合です。この場合は、SET DBIDコマンドを使用してから制御ファイルをリストアする必要があります。

リカバリ・カタログを使用していない場合は、自動バックアップから制御ファイルをリストアする必要があります。自動バックアップから制御ファイルをリストアするには、データベースがNOMOUNT状態である必要があります。例20-2に示すように、まずデータベースのDBIDを設定し、次にRESTORE CONTROLFILE FROM AUTOBACKUPコマンドを使用する必要があります。

例20-2 DBIDの設定および自動バックアップからの制御ファイルのリストア

SET DBID 320066378;
RUN
{
  SET CONTROLFILE AUTOBACKUP FORMAT 
    FOR DEVICE TYPE DISK TO 'autobackup_format';
  RESTORE CONTROLFILE FROM AUTOBACKUP;
}

RMANでは、自動バックアップの書式およびDBIDを使用して、制御ファイルの自動バックアップを検索する場所が決定されます。制御ファイルの自動バックアップが検出されると、RMANによって、CONTROL_FILES初期化パラメータに示されているすべての制御ファイルの場所に制御ファイルがリストアされます。

関連項目:

20.3.1.3 高速リカバリ領域の使用時のRMANリカバリについて

制御ファイルをリストアするコマンドは、データベースで高速リカバリ領域が使用されているかどうかに関係なく同じです。データベースでリカバリ領域が使用されている場合、RMANは、すべてのディスクベースのバックアップおよび制御ファイルに記録されているイメージ・コピーをクロスチェックして、バックアップからリストアされた制御ファイルを更新します。RMANは、リカバリ領域内の記録されていないすべてのバックアップをカタログに追加します。この結果、リストアされた制御ファイルには、リカバリ領域内のすべてのバックアップ、およびバックアップの時点で制御ファイルに認識されたその他のバックアップの完全で正確なレコードが含まれます。

RMANは、制御ファイルをリストアした後、テープ・バックアップのクロスチェックを自動的には実行しません。テープ・バックアップを使用している場合は、制御ファイルをリストアおよびマウントできます。また、必要に応じてテープ上のバックアップをクロスチェックできます。次に例を示します。

CROSSCHECK BACKUP DEVICE TYPE sbt;

20.3.2 バックアップ制御ファイルを使用してリカバリ・カタログを使用しないリカバリの実行

この項では、制御ファイルのRMANバックアップを使用し、リカバリ・カタログは使用しないと想定しています。また、ターゲット・データベースの制御ファイルの自動バックアップ機能を有効にして、制御ファイルの自動バックアップをリストアできると想定しています。

自動バックアップでは標準的な書式が使用されるため、使用可能なバックアップを表示するリポジトリが存在しなくても、RMANは自動バックアップをリストアできます。自動バックアップはデフォルトの場所または新しい場所にリストアできます。RMANは、CONTROL_FILESで指定されたすべての場所に制御ファイルを自動的にレプリケートします。

注意:

(たとえば、メディア・マネージャによって、またはバックアップ・ピースがディスク上に存在するため)制御ファイルを含むバックアップ・ピースの名前がわかっている場合は、RESTORE CONTROLFILE FROM 'filename'コマンドを使用してバックアップ・ピースの名前を指定できます。データベースは、すべての自動バックアップの場所をアラート・ログに記録します。

リカバリ・カタログに接続していないため、RMANリポジトリには制御ファイルのバックアップの時点で使用可能なバックアップに関する情報のみが含まれます。他の使用可能なバックアップ・セットまたはイメージ・コピーの場所がわかっている場合は、CATALOGコマンドを使用して制御ファイルのRMANリポジトリに追加します。

NOCATALOGモードで制御ファイルの自動バックアップを使用してデータベースをリカバリする手順

  1. RMANを起動し、ターゲット・データベースに接続します。

  2. データベースをマウントせずにターゲット・データベース・インスタンスを起動します。次に例を示します。

    STARTUP NOMOUNT;
    
  3. SET DBIDコマンドを使用して、ターゲット・データベースのデータベース識別子を設定します。

    ターゲット・データベースに接続するたびに、DBIDが表示されます。保存されたRMANのログ・ファイルを調べるか、カタログを問い合せるか、または制御ファイルの自動バックアップのファイル名を検索することによって取得することもできます。たとえば、次のコマンドを実行します。

    SET DBID 676549873;
    
  4. 自動バックアップの制御ファイルをリストアしてリカバリを実行するためのRMANコマンド・ファイルを記述します。

    このコマンド・ファイルには、次の手順が含まれています。

    1. 必要に応じて、最新のバックアップのタイムスタンプを指定します。RMANは、リストアする制御ファイルの自動バックアップの検索時に、このタイムスタンプを使用できます。

    2. 制御ファイルの自動バックアップの作成時に制御ファイルの自動バックアップの異なる書式が有効になっていたことがわかっている場合は、制御ファイルのリストアにデフォルト以外の書式を指定します。

    3. SBTチャネルによって制御ファイルの自動バックアップが作成された場合は、1つ以上のSBTチャネルを割り当てます。使用可能なリカバリ・カタログがないため、事前構成されたチャネルは使用できません。

    4. 必要に応じて、RMANが検索できる過去の最大日数および最初の日付の検索に使用する最初の順序番号を設定して、制御ファイルの自動バックアップをリストアします。

    5. 残りのリストア・プロセスに有効な構成済のチャネルに関する情報が制御ファイルに含まれていることがわかっている場合は、RMANを終了し、手順4.cで行ったチャネルの手動割当てを解除できます。

      RMANクライアントを再起動してデータベースをマウントする場合は、これらの構成済のチャネルを使用できます。制御ファイルに含まれている構成済のチャネルを使用しない場合は、データベースをマウントできます。

    6. この手順は、オンラインREDOログが使用可能かどうかによって異なります。ログが使用可能かどうかに関係なく、バックアップ制御ファイルを使用してリカバリを行った後は、常にOPEN RESETLOGSオプションが必要となります。

      オンラインREDOログが使用可能な場合、RMANはこれらのログを検出および適用できます。完全なリストアおよびリカバリを実行します(「データベースの完全リカバリの実行」を参照)。

      オンラインREDOログを使用できない場合は、DBPITRを実行します(「データベースのPoint-in-Timeリカバリの実行」を参照)。オンラインREDOログの最初のSCNより前の時点までリカバリする場合の目標時点、SCNまたはログ順序番号を指定するには、UNTIL句を使用する必要があります(この句を使用しない場合、RMANはRMAN-6054エラーを発行します)。

      バックアップ制御ファイルを使用してDBPITRを実行する場合、RESETLOGSを使用してデータベースをオープンする前に、SQL*Plusを使用してデータベースを読取り専用でオープンし、必要に応じて問合せを実行して、論理的な破損の影響が無効にされたことを確認できます。結果が期待どおりだった場合、RESETLOGSを使用して、データベースをオープンできます。

      注意:

      ログ順序の指定時に、最後に作成されたアーカイブREDOログの順序がnの場合は、RMANがnを適用してから停止するように、UNTIL SEQUENCE n+1を指定します。

    次の例では、オンラインREDOログ・ファイルが消失しており、最新のアーカイブREDOログの順序番号は13243です。この例は、制御ファイルの自動バックアップをリストアし、最新のログを使用してリカバリする方法を示しています。

    RUN 
    {
      # Optionally, set upper limit for eligible time stamps of control file 
      # backups
      # SET UNTIL TIME '09/10/2013 13:45:00';
      # Specify a nondefault autobackup format only if required
      # SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK 
      #   TO '?/oradata/%F.bck';
      ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS '...'; # allocate manually
      RESTORE CONTROLFILE FROM AUTOBACKUP
        MAXSEQ 100           # start at sequence 100 and count down
        MAXDAYS 180;         # start at UNTIL TIME and search back 6 months
      ALTER DATABASE MOUNT;
    }
    # Now use automatic channels configured in restored control file
    RESTORE DATABASE UNTIL SEQUENCE 13244;
    RECOVER DATABASE UNTIL SEQUENCE 13244;
    
  5. リカバリに成功した場合は、データベースをオープンし、オンライン・ログをリセットします。

    ALTER DATABASE OPEN RESETLOGS;

20.4 障害リカバリの実行

障害リカバリには、ターゲット・データベース全体、リカバリ・カタログ・データベース、すべての現行の制御ファイル、すべてのオンラインREDOログ・ファイルおよびすべてのパラメータ・ファイルが消失した後のターゲット・データベースのリストアおよびリカバリが含まれます。

この項では、次の項目について説明します。

20.4.1 障害リカバリの前提条件

障害リカバリを実行するには、次のものが必要です。

  • すべてのデータファイルのバックアップ

  • リストアする最も古いバックアップの作成時刻の後に生成されたすべてのアーカイブREDOログ

  • 1つ以上の制御ファイルの自動バックアップ

  • データベースのDBIDのレコード

20.4.2 障害発生後のデータベースのリカバリ

障害リカバリの手順は、NOCATALOGモードでバックアップ制御ファイルを使用してデータベースをリカバリする手順と類似しています。新しいホストにデータベースをリストアする場合は、「新しいホストへのデータベースのリストア」で説明されている考慮事項を参照してください。

この例では、データベースが実行されていたLinuxサーバーに修復不可能な破損が発生していると想定しています。データベースをOracle Secure Backupにバックアップしてあるため、そのテープを使用できます。この例では、次のことを想定しています。

  • Oracle Databaseが新しいホストにインストールされています。

  • 古いホストと同じディレクトリ構造を持つ新しいLinuxホストにデータベースをリストアします。

  • 1つのテープ・ドライブを使用します(このテープ・ドライブには、すべてのデータファイルのバックアップ、ログ1124までのアーカイブREDOログおよび制御ファイルとサーバー・パラメータ・ファイルの自動バックアップが含まれています)。

  • データベースでリカバリ・カタログは使用しません。

新しいホストにデータベースをリカバリする手順

  1. 「障害リカバリの前提条件」で説明している前提条件を満たしていることを確認します。

  2. 可能な場合は、tnsnames.oralistener.ora、パスワード・ファイルなどの関連するすべてのネットワーク・ファイルをリストアまたは再生成します。

  3. RMANを起動し、ターゲット・データベース・インスタンスに接続します。

    この時点では、初期化パラメータ・ファイルは存在しません。ORACLE_SIDおよびORACLE_HOMEを設定すると、オペレーティング・システム認証を使用してSYSDBAまたはSYSBACKUPとして接続できます。

  4. SET DBIDコマンドを使用してターゲット・データベースのDBIDを指定します(「サーバー・パラメータ・ファイルのリストア」を参照)。

    たとえば、次のコマンドを入力します。

    SET DBID 676549873;
    
  5. STARTUP NOMOUNTコマンドを実行します。

    サーバー・パラメータ・ファイルを使用できない場合、RMANは仮のサーバー・パラメータ・ファイルを使用してインスタンスの起動を試行します。

  6. チャネルをメディア・マネージャに割り当て、自動バックアップからサーバー・パラメータ・ファイルをリストアします。

    たとえば、Oracle Secure Backupからサーバー・パラメータ・ファイルをリストアする場合は、次のコマンドを入力します。

    RUN
    {
      ALLOCATE CHANNEL c1 DEVICE TYPE sbt;
      RESTORE SPFILE FROM AUTOBACKUP;
    }
    
  7. リストアしたサーバー・パラメータ・ファイルを使用してインスタンスを再起動します。

    STARTUP FORCE NOMOUNT;
    
  8. リストアおよびリカバリ操作を実行するためのコマンド・ファイルを記述し、そのコマンド・ファイルを実行します。このコマンド・ファイルでは、次の手順を実行する必要があります。

    1. チャネルをメディア・マネージャに割り当てます。

    2. 制御ファイルの自動バックアップをリストアします(「バックアップ制御ファイルを使用してリカバリ・カタログを使用しないリカバリの実行」を参照)。

    3. リストアした制御ファイルをマウントします。

    4. CATALOGコマンドを使用して、リポジトリに記録されていないバックアップをカタログに追加します。

    5. データファイルを元の場所にリストアします。 ボリューム名が変更されている場合は、リストア操作の前にSET NEWNAMEコマンドを実行し、リストア操作の後にSWITCHを実行して、制御ファイルをデータファイルの新しい場所に更新します。次に例を示します。

    6. データファイルをリカバリします。指定したログ順序番号に達すると、RMANによってリカバリが停止されます。

    RMAN> RUN
    {
      # Manually allocate a channel to the media manager
      ALLOCATE CHANNEL t1 DEVICE TYPE sbt;
      # Restore autobackup of the control file. This example assumes that you have 
      # accepted the default format for the autobackup name.
      RESTORE CONTROLFILE FROM AUTOBACKUP;
      #  The set until command is used in case the database
      #  structure has changed in the most recent backups, and you want to
      #  recover to that point in time. In this way RMAN restores the database
      #  to the same structure that the database had at the specified time.
      ALTER DATABASE MOUNT;
      SET UNTIL SEQUENCE 1124 THREAD 1;
      RESTORE DATABASE;
      RECOVER DATABASE;
    }
    

    次のRUNコマンドの例は、リストアしたデータファイルに新しいファイル名を使用することを除き、前述の例と同様です。

    RMAN> RUN
    {
      #  If you must restore the files to new locations,
      #  use SET NEWNAME commands:
      SET NEWNAME FOR DATAFILE 1 TO '/dev/vgd_1_0/rlvt5_500M_1';
      SET NEWNAME FOR DATAFILE 2 TO '/dev/vgd_1_0/rlvt5_500M_2';
      SET NEWNAME FOR DATAFILE 3 TO '/dev/vgd_1_0/rlvt5_500M_3';
      ALLOCATE CHANNEL t1 DEVICE TYPE sbt;
      RESTORE CONTROLFILE FROM AUTOBACKUP;
      ALTER DATABASE MOUNT;
      SET UNTIL SEQUENCE 124 THREAD 1;
      RESTORE DATABASE;
      SWITCH DATAFILE ALL; # Update control file with new location of data files.
      RECOVER DATABASE;
    }
    
  9. リカバリに成功した場合は、データベースをオープンし、オンライン・ログをリセットします。

    ALTER DATABASE OPEN RESETLOGS;

20.5 新しいホストへのデータベースのリストア

障害リカバリ手順のテスト実行を行うか、またはデータベースを新しいホストに永続的に移動する場合は、この項で説明する手順を実行します。この手順では、RESTOREコマンドおよびRECOVERコマンドを使用します。

この項の手順を実行すると、リストアされるデータベースのDBIDは、元のデータベースのDBIDと同じになります。この方法で作成したテスト・データベースは、ソース・データベースと同じリカバリ・カタログに登録しないでください。2つのデータベースのDBIDが同じであるため、テスト・データベースのメタデータが、ソース・データベースをリストアおよびリカバリするRMANの機能に影響を与える可能性があります。

新しいホストで継続して使用するためにターゲット・データベースのコピーを作成する場合は、この手順ではなく、RMANのDUPLICATEコマンドを実行します。DUPLICATEコマンドを実行すると、作成されるデータベースに対して新しいDBIDが割り当てられるため、このデータベースを元のデータベースと同じリカバリ・カタログに追加できます。

関連項目:

データベースの複製方法については、「RMANデータベースの複製の概要」を参照してください。

この項では、次の項目について説明します。

20.5.1 新しいホストへのデータベースのリストアの準備

新しいホストへのデータベースのリストアを準備するには、次の手順を実行します。

  • ソース・データベースのDBIDを記録します。データベースのDBIDが不明な場合は、DBIDの確認方法について「データベースのDBIDの確認」を参照してください。

  • 新しいホスト上でソース・データベースの初期化パラメータ・ファイルをアクセス可能にします。オペレーティング・システム・ユーティリティを使用して、古いホストから新しいホストにこのファイルをコピーします。

  • テスト・リストア操作のみを実行する場合は、RMANがリカバリ・カタログに接続されていないことを確認してください。接続されている場合は、RMANによって、リストアされたデータファイルに関するメタデータがリカバリ・カタログに記録されます。このメタデータは、プライマリ・データベースを将来リストアおよびリカバリする場合の障害となります。

    リストアする必要があるすべてのバックアップのRMANリポジトリ・データを格納するには制御ファイルのサイズが十分ではないため、リカバリ・カタログを使用する必要がある場合は、Oracle Data Pumpを使用してカタログをエクスポートし、別のスキーマまたはデータベースにインポートします。その後、コピーしたリカバリ・カタログをテスト・リストアに使用します。これを行わない場合、リカバリ・カタログでは、リストアされたデータベースが現行のターゲット・データベースとみなされます。

  • リストア操作に使用されるバックアップがリストア・ホスト上でアクセス可能であることを確認します。たとえば、メディア・マネージャを使用してバックアップを作成した場合は、テープ・デバイスが新しいホストに接続されていることを確認します。ディスクのコピーを使用している場合は、次の項の手順を実行します。

  • 本番データベースの試行リストアを実行する場合は、テスト環境でデータベースをリストアする前に、次の操作のいずれかを実行します。

    • 本番データベースが使用しているリカバリ領域とは物理的に異なる高速リカバリ領域をテスト・データベースで使用する場合は、テスト・データベース・インスタンスのDB_RECOVERY_FILE_DESTを新しい場所に設定します。

    • 本番データベースで使用されるリカバリ領域と物理的に同じ高速リカバリ領域をテスト・データベースで使用する場合は、テスト・データベース・インスタンスのDB_UNIQUE_NAMEを、本番データベースとは異なる名前に設定します。

    前述の操作をどちらも実行しないと、RMANでは、本番データベースをリストアしていると判断し、高速リカバリ領域の フラッシュバック・ログを使用不可能とみなして削除します。

20.5.2 新しいホストへのディスク・バックアップのリストア

ディスク上のデータファイルのコピーまたはバックアップ・セットを使用して新しいホストにデータベースを移動するには、新しいホストにそのファイルを手動で転送する必要があります。次の例では、RMANでリカバリ・カタログが使用されていると想定しています。

バックアップ・ファイルを新しいホストにリストアする方法

  1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログに接続します。

  2. LISTコマンドを実行して、データファイルのバックアップおよび制御ファイルの自動バックアップのリストを表示します。

    たとえば、次のコマンドを入力してデータファイルのコピーを表示します。

    LIST COPY;
    

    たとえば、次のコマンドを入力して制御ファイルのバックアップを表示します。

    LIST BACKUP OF CONTROLFILE;
    

    自動バックアップ・ピースの名前には、%F置換変数を使用する必要があります。したがって、自動バックアップ・ピースの名前には、文字列c-IIIIIIIIII-YYYYMMDD-QQが含まれます。ここで、IIIIIIIIIIはDBIDを表し、YYYYMMDDはバックアップが生成された日のグレゴリオ暦でのタイムスタンプ、QQは16進数の順序です。

  3. オペレーティング・システム・ユーティリティを使用して、バックアップを新しいホストにコピーします。

    次のコマンドを入力して、すべてのデータファイルのコピーを新しいホストの?/oradata/trgtディレクトリにコピーします。

    % cp -r /disk1/*dbf /net/new_host/oracle/oradata/trgt
    

    次のコマンドを入力して、自動バックアップのバックアップ・ピースを新しいホストの/tmpディレクトリにコピーします。

    % cp -r /disk1/auto_bkp_loc/c-1618370911-20130208-00 /net/new_host/tmp
    

    「制御ファイルの自動バックアップからのサーバー・パラメータ・ファイルのリストア」で説明されているように、デフォルト以外の場所から自動バックアップをリストアする場合は、SET CONTROLFILE AUTOBACKUP FORMATコマンドを使用する必要があります。

20.5.3 新しいホストへのデータベースのリストアのテスト

次の例では、データベースを新しいホストにリストアすることができるかどうかをテストします。この例では、ネットワークで接続された2台のLinuxホストhostahostbを使用します。trgtaという名前のターゲット・データベースがhosta上に存在し、リカバリ・カタログcatdbに登録されています。データベースtrgtaが起動され、hosta上で実行されている間に、hostb上でtrgtaのリストアおよびリカバリをテストします。

ここで、hostbのディレクトリ構造はhostaのディレクトリ構造と異なっていると想定します。ターゲット・データベースは/net/hosta/dev3/oracle/dbsに存在していますが、このデータベースを/net/hostb/oracle/oradata/testにリストアします。データファイル、制御ファイル、アーカイブREDOログおよびサーバー・パラメータ・ファイルのテープ・バックアップが、両方のホストからアクセス可能なメディア・マネージャ上にあります。TRGTAデータベースのORACLE_SIDは、TRGTAであり、リストアされたデータベースでも変更しません。

注意:

テストの目的でデータベースをリストアする場合は、RMANをテスト・データベースおよびリカバリ・カタログに接続しないでください。

新しいホストにデータベースをリストアする手順

  1. ターゲット・データベースのバックアップが新しいホスト上でアクセス可能であることを確認します。

    障害リカバリをテストするには、ターゲット・データベースのリカバリ可能なバックアップが必要です。障害リカバリ計画を作成する場合は、データファイル、制御ファイルおよびサーバー・パラメータ・ファイルのバックアップがhostb上にリストア可能であることを確認します。そのため、hostbをメディア・マネージャのクライアントにして、hosta上に作成されたバックアップ・セットを読み取ることができるように、メディア管理ソフトウェアを構成する必要があります。この問題に対するサポートについては、メディア管理ベンダーに問い合せてください。

  2. hostb上でORACLE_SIDを構成します。

    この例では、RMANクライアントをhostb上で起動し、オペレーティング・システムを介して自分を認証すると想定しています。ただし、ローカルで、またはネット・サービス名を介して、hostbに接続する必要があります。

    管理者権限を使用してhostbにログインした後、自分がDBAグループに含まれるように/etc/groupファイルを編集します。

    dba:*:614:<your_user_name>
    

    hostb上で、環境変数ORACLE_SIDhosta上で使用した値と同じ値に設定します。

    % setenv ORACLE_SID trgta
    
  3. hostb上でRMANを起動し、リカバリ・カタログに接続せずにターゲット・データベースに接続します。

    たとえば、次のコマンドを入力します。

    % rman NOCATALOG
    RMAN> CONNECT TARGET /
    
  4. DBIDを設定し、データベースをマウントせずにデータベース・インスタンスを起動します。

    たとえば、SET DBIDを実行してDBIDを設定し、次にSTARTUP NOMOUNTを実行します。

    SET DBID 1340752057;
    STARTUP NOMOUNT
    

    サーバー・パラメータ・ファイルがリストアされていないため、RMANがサーバー・パラメータ・ファイルの検出に失敗しますが、仮のファイルを使用してインスタンスが起動されます。出力例を次に示します。

    startup failed: ORA-01078: failure in processing system parameters
    LRM-00109: could not open parameter file '/net/hostb/oracle/dbs/inittrgta.ora'
    
    trying to start the Oracle instance without parameter files ...
    Oracle instance started
    
  5. サーバー・パラメータ・ファイルをリストアおよび編集します。

    バックアップの実行時に制御ファイルの自動バックアップ機能を有効にしたため、バックアップにサーバー・パラメータ・ファイルが含まれます。デフォルト以外の書式の自動バックアップをリストアする場合は、SET CONTROLFILE AUTOBACKUP FORMATコマンドを使用して書式を指定します。

    メディア・マネージャにチャネルを割り当て、サーバー・パラメータ・ファイルをクライアント側のパラメータ・ファイルとしてリストアし、SETコマンドを使用して自動バックアップの場所を指定します(この例では、自動バックアップは/tmpにあります)。

    RUN
    {
      ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS '...';
      SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/tmp/%F';
      RESTORE SPFILE 
        TO PFILE '?/oradata/test/inittrgta.ora' 
        FROM AUTOBACKUP;
      SHUTDOWN ABORT;
    }
    
  6. リストアされた初期化パラメータ・ファイルを編集します。

    末尾が_DESTなどの場所固有のすべてのパラメータを変更し、新しいディレクトリ構造を反映します。たとえば、次のパラメータを編集します。

      - IFILE
      - LOG_ARCHIVE_DEST_1
      - CONTROL_FILES
    
  7. 編集した初期化パラメータ・ファイルを使用してインスタンスを再起動します。

    たとえば、次のコマンドを入力します。

    STARTUP FORCE NOMOUNT PFILE='?/oradata/test/inittrgta.ora';
    
  8. 自動バックアップから制御ファイルをリストアし、データベースをマウントします。

    たとえば、次のコマンドを入力します。

    RUN 
    {
      ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS '...';
      RESTORE CONTROLFILE FROM AUTOBACKUP;
      ALTER DATABASE MOUNT;
    }
    

    CONTROL_FILES初期化パラメータで指定した場所に制御ファイルがリストアされます。

  9. 新しいファイル名またはCATALOG START WITH (すべてのファイルが共通の接頭辞を持つディレクトリに含まれ、CATALOG START WITHコマンドで簡単に指定できることがわかっている場合)を使用して、「新しいホストへのディスク・バックアップのリストア」でコピーしたデータファイルのコピーをカタログに追加します。たとえば、次のコマンドを実行します。

    CATALOG START WITH '/oracle/oradata/trgt/';
    

    ファイルを個別に指定する場合は、CATALOGコマンドを次のように実行します。

    CATALOG DATAFILECOPY
      '/oracle/oradata/trgt/system01.dbf', '/oracle/oradata/trgt/undotbs01.dbf', 
      '/oracle/oradata/trgt/cwmlite01.dbf', '/oracle/oradata/trgt/drsys01.dbf',
      '/oracle/oradata/trgt/example01.dbf', '/oracle/oradata/trgt/indx01.dbf', 
      '/oracle/oradata/trgt/tools01.dbf', '/oracle/oradata/trgt/users01.dbf';
    
  10. 新しいデータベース上でSQL*Plusセッションを開始し、制御ファイルに記録されたデータベースのファイル名を問い合せます。

    制御ファイルはtrgtaデータベースからリストアされているため、記録されたファイル名では元のhostaのファイル名が使用されます。V$ビューを問い合せると、この情報を取得できます。SQL*Plusで次の問合せを実行します。

    COLUMN NAME FORMAT a60
    SPOOL  LOG '/tmp/db_filenames.out'
    SELECT FILE# AS "File/Grp#", NAME 
    FROM   V$DATAFILE
    UNION
    SELECT GROUP#,MEMBER 
    FROM   V$LOGFILE;
    SPOOL OFF
    EXIT
    
  11. RMANのリストア・スクリプトおよびリカバリ・スクリプトを記述します。このスクリプトには、次の手順が含まれている必要があります。

    1. ソース・ホスト上のパスとは異なるパスにリストアされた宛先ホスト上の各データファイルに対して、SET NEWNAMEコマンドを使用して宛先ホスト上に新しいパスを指定します。宛先システム上のファイル・システムがソース・ホスト上のパスと同じパスを持つように設定されている場合は、ソース・ホスト上のパスと同じパスにリストアされるファイルに対してSET NEWNAMEを使用しないでください。

    2. ソース・ホスト上の場所とは異なる場所に作成される各オンラインREDOログに対して、SQLのALTER DATABASE RENAME FILEコマンドを使用して宛先ホスト上にパス名を指定します。宛先システム上のファイル・システムがソース・ホスト上のパスと同じパスを持つように設定されている場合は、ソース・ホスト上のパスと同じパスにリストアされるファイルに対してALTER DATABASE RENAME FILEを使用しないでください。

    3. SET UNTIL操作を実行して、リカバリをアーカイブREDOログの最後までに制限します。SET UNTILコマンドが指定されていない場合、エラーが発生してリカバリが停止します。

    4. データベースをリストアおよびリカバリします。

    5. SWITCH DATAFILE ALLコマンドを実行して、新しいパス名をデータファイルの正式な新しい名前として制御ファイルに認識させます。

    次のコードに、リストアおよびリカバリ操作を実行できるRMANスクリプトreco_test.rmanを示します。

    RUN
    {
      # allocate a channel to the tape device
      ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS '...';
    
      # rename the data files and online redo logs
      SET NEWNAME FOR DATAFILE 1 TO '?/oradata/test/system01.dbf';
      SET NEWNAME FOR DATAFILE 2 TO '?/oradata/test/undotbs01.dbf';
      SET NEWNAME FOR DATAFILE 3 TO '?/oradata/test/cwmlite01.dbf';
      SET NEWNAME FOR DATAFILE 4 TO '?/oradata/test/drsys01.dbf';
      SET NEWNAME FOR DATAFILE 5 TO '?/oradata/test/example01.dbf';
      SET NEWNAME FOR DATAFILE 6 TO '?/oradata/test/indx01.dbf';
      SET NEWNAME FOR DATAFILE 7 TO '?/oradata/test/tools01.dbf';
      SET NEWNAME FOR DATAFILE 8 TO '?/oradata/test/users01.dbf';
      ALTER DATABASE RENAME FILE '/dev3/oracle/dbs/redo01.log'
          TO '?/oradata/test/redo01.log';
      ALTER DATABASE RENAME FILE '/dev3/oracle/dbs/redo02.log'
          TO '?/oradata/test/redo02.log';
    
      # Do a SET UNTIL to prevent recovery of the online logs
      SET UNTIL SCN 123456;
      # restore the database and switch the data file names
      RESTORE DATABASE;
      SWITCH DATAFILE ALL;
    
      # recover the database
      RECOVER DATABASE;
    }
    EXIT
    
  12. 前述の手順で作成したスクリプトを実行します。

    たとえば、RMANを起動してターゲット・データベースに接続し、@コマンドを実行します。

    % rman TARGET / NOCATALOG
    RMAN> @reco_test.rman
    
  13. RESETLOGSオプションを指定して、リストアしたデータベースをオープンします。

    RMANプロンプトで、RESETLOGSオプションを指定してデータベースをオープンします。

    ALTER DATABASE OPEN RESETLOGS;

    注意:

    次の手順でデータベースを再オープンする場合は、リカバリ・カタログに接続しないでください。そうしなかった場合は、作成される新しいデータベース・インカネーションがリカバリ・カタログに自動的に登録され、本番データベースのファイル名が、スクリプトに指定されている新しいファイル名に置換されます。

  14. 必要に応じて、含まれているすべてのファイルとともにテスト・データベースを削除します。

    注意:

    ASMディスク・グループを使用した場合、テスト・データベースのファイルを安全に削除する方法はDROP DATABASEコマンドのみです。非ASMストレージにリストアした場合は、オペレーティング・システムのコマンドを使用してデータベースを削除することもできます。

    DROP DATABASEコマンドを使用して、データベースに関連付けられているすべてのファイルを自動的に削除します。次の例では、データベース・ファイルを削除します。

    STARTUP FORCE NOMOUNT PFILE='?/oradata/test/inittrgta.ora';
    DROP DATABASE;
    

    リカバリ・カタログへの接続時にリストアおよびリカバリ操作を実行しなかったため、リカバリ・カタログには、リストアしたファイルまたはテスト中に実行した手順のレコードは含まれません。同様に、trgtaデータベースの制御ファイルは、テストによる影響を受けません。

20.6 古いバージョンのRMANを使用して作成されたバックアップのリストア

Oracle Database 9iリリース2 (9.2.0.8)までの古いバージョンのRMANを使用して作成されたバックアップをリストアできます。

バックアップが作成されたOracle Databaseバージョンと、リストアされたデータベースを実行するOracleソフトウェア・バージョンとの間で、サポートされているアップグレード・パスが存在する必要があります。

この例では、ソース・データベースはOracle Database 11gリリース2データベースで、サーバー・パラメータ・ファイル(spfile)を使用するように構成されています。データベースはARCHIVELOGモードで実行され、高速リカバリ領域を使用します。制御ファイルの自動バックアップも構成されます。アーカイブREDOログを含む、ソース・データベースのRMANバックアップを作成します。

これらのバックアップがリストアされる宛先ホストには、Oracle Database 12cリリース1がインストールされています。

現行のターゲット・データベース・バージョンより古いRMANバージョンを使用して作成されたRMANバックアップをリストアするには、次の手順を実行します。

  1. バックアップが作成されたデータベース・バージョンからデータベースをリストアするOracleサーバー・バージョンへの、サポートされているアップグレード・パスが存在することを確認します。

    たとえば、RMANバックアップがOracle Database 11gリリース2 (11.2.0.3)で作成され、リストアされたデータベースをOracle Database 12cリリース1 (12.1)で実行する場合、リリース11.2.0.3からリリース12.1.へのサポートされているアップグレード・パスが存在することを確認する必要があります。

    関連項目:

    データベース・アップグレード・パスの詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください

  2. ソース・データベース・バックアップが、リストアする必要がある宛先ホストで使用可能であることを確認します。
    オペレーティング・システム・ユーティリティを使用してバックアップを宛先ホストにコピーしたり、宛先ホストにアクセス可能な共有の場所にバックアップを格納することもできます。
  3. 宛先データベースを停止します。
  4. 宛先ホスト上で、ORACLE_SIDを、ソース・データベースで使用された値と同じ値に設定します。
    %  setenv ORACLE_SID db112
  5. 宛先ホスト上でRMANを起動し、オペレーティング・システム認証を使用しリカバリ・カタログを使用せずにターゲット・データベースに接続します。
    % rman target / NOCATALOG
  6. DBIDをソース・データベースと同じ値に設定します。

    次のコマンドでは、DBIDを699892390に設定します。これは、バックアップがリストアされるソース・データベースのDBIDです。

    RMAN> set DBID 699892390;
  7. ターゲット・データベースをNOMOUNTモードで起動します。
    RMAN> startup nomount;

    RMANは、まだリストアされていないサーバー・パラメータ・ファイルの検出に失敗します。しかし、インスタンスは仮のファイルを使用して起動され、次の出力が表示されます。

    startup failed: ORA-01078: failure in processing system parameters
    LRM-00109: could not open parameter file '/oracle/dbs/inittrgta.ora'
    trying to start the Oracle instance without parameter files ...
    Oracle instance started
  8. ソース・データベースの自動バックアップからサーバー・パラメータ・ファイルをリストアします。

    制御ファイルの自動バックアップがソース・データベースで有効になっていたため、サーバー・パラメータ・ファイルはバックアップに含まれます。デフォルト以外の書式の自動バックアップをリストアするには、SET CONTROLFILE AUTOBACKUP FORMATコマンドを使用して書式を指定します。

    次の例では、自動バックアップの書式を設定し、ソース・データベースのspfileをpfile /dev3/oracle/network/init_db112.oraにリストアし、ターゲット・データベースを停止します。

    run
    {
        set controlfile autobackup format for device type disk to '/scratch/fra/cf/%F.bck';
        restore spfile to pfile '/dev3/oracle/network/init_db112.ora' from autobackup recovery area '/scratch /fra/cf' db_name 'DB112';
        shutdown abort;
    }
  9. リストアされた初期化パラメータ・ファイルを編集し、必要な初期化パラメータを変更します。

    これにCOMPATIBLEパラメータが含まれるのは、ターゲット・データベースの互換性要件がソース・データベースで設定された互換性要件と異なり、パラメータがターゲット・データベースのリリースで非推奨となっている場合です。また、末尾が_DESTなどの場所固有のすべてのパラメータを更新し、新しいディレクトリ構造を反映します。

    この例では、/dev3/oracle/network/init_db112.oraにあるpfileを編集する必要があります。

  10. 編集した初期化パラメータ・ファイルを使用してインスタンスを再起動します。

    次のコマンドは、編集されたパラメータ・ファイルを使用して、データベース・インスタンスをNOMOUNTモードで起動します。

    RMAN> startup force nomount pfile='/dev3/oracle/network/init_db112.ora';
  11. 自動バックアップから制御ファイルをリストアし、データベースをマウントします。

    次の例では、制御ファイルの自動バックアップの書式を設定し、自動バックアップから制御ファイルをリストアし、データベースをマウントします。

    run
    {
        set controlfile autobackup format for device type disk to '/scratch/fra/cf/%F.bck';
        restore controlfile from autobackup recovery area '/scratch/fra/cf' db_name 'DB112'; 
        alter database mount;
    }

    制御ファイルは、編集された初期化パラメータ・ファイル内のCONTROL_FILES初期化パラメータで指定された場所にリストアされます。

  12. 宛先ホストで使用可能になったソース・データベースのデータファイルのコピーをカタログに追加します。

    すべてのファイルが共通の接頭辞を持つディレクトリにある場合、CATALOG START WITHコマンドを使用します。ファイル名を個別に指定する場合、CATALOG DATAFILECOPYコマンドを使用します。

    次の例では、すべてのデータファイルのコピーが単一のフォルダ/scratch/fra/DB112/backupsetに格納されているため、CATALOG START WITHコマンドを使用します。

    RMAN> catalog start with '/scratch/fra/DB112/backupset';
  13. ソース・データベースをリストアおよびリカバリします。

    データファイルが、ソース・データベース上のデータファイルとは異なるパスにリストアされる場合、SET NEWNAMEコマンドを使用して、宛先ホスト上に新しいパスを指定する必要があります。オンラインREDOログが、ソース・データベース上のオンラインREDOログとは異なる場所に作成される場合、ALTER DATABASE RENAME FILEコマンドを使用して、宛先データベース上の各REDOログ・ファイルの場所を指定します。

    この例では、SET NEWNAME FOR DATABASEコマンドを使用して、リストアされたすべてのデータファイルの新しい場所を指定します。各オンラインREDOログ・ファイルの新しい場所は、ALTER DATABASE RENAME FILEコマンドを使用して指定されます。リカバリは、SCNがコマンドで指定されるまで実行されます。

    run
    {
        set newname for database to '/ade/b/1885631999/oracle/dbs/%U.f';
        alter database rename file '/dev1/oracle/dbs/redo01.log' to '/dev3/oracle/dbs/redo1.log';
        alter database rename file '/dev1/oracle/dbs/redo02.log' to '/dev3/oracle/dbs/redo2.log';
        set until scn 1092435;
        restore database;
        switch datafile all;
        recover database;
    }
  14. RESETLOGSおよびUPGRADEオプションを指定して、リストアされたデータベースをオープンします。
    RMAN> alter database open resetlogs upgrade;
    Statement processed
    RMAN-06900: WARNING: unable to generate V$RMAN_STATUS or V$RMAN_OUTPUT row
    RMAN-06901: WARNING: disabling update of the V$RMAN_STATUS and V$RMAN_OUTPUT rows
    ORACLE error from target database: 
    ORA-04023: Object SYS.STANDARD could not be validated or authorized

    エラーは、アップグレード・プロセスの一部として再検証する必要があるデータベース・パッケージによって発生します。

  15. RMANを終了します。
  16. データベースのアップグレードに必要な手順を実行して、ターゲット・データベースを目的のOracleリリースにアップグレードします。

    関連項目:

    データベースのアップグレードの詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください

20.7 ネットワークを介したファイルのリストアおよびリカバリ

RMANでは、必要なファイルが含まれるフィジカル・スタンバイ・データベースへネットワークを介して接続し、ファイルのリストアまたはリカバリを可能にします。データベース全体、データ・ファイル、制御ファイル、サーバー・パラメータ・ファイルまたは表領域をリストアできます。プライマリ・データベースおよびスタンバイ・データベースを同期化する必要がある場合、ネットワークを介したファイルのリストアは、非常に有用です。

ネットワークを介してファイルをリストアまたはリカバリする場合、バックアップ・セットが使用されます。そのため、マルチセクション・バックアップ、暗号化および圧縮を使用して、バックアップとリストアのパフォーマンスを向上させることができます。

ネットワークを介したファイルのリストアおよびリカバリは、Oracle Database 12cリリース1 (12.1)からサポートされています。

この項の内容は次のとおりです。

20.7.1 ネットワークを介したファイルのリストアについて

RMANは、RESTOREコマンドのFROM SERVICE句を使用し、フィジカル・スタンバイ・データベースからネットワークを介してデータベース・ファイルをリストアします。FROM SERVICE句では、ファイルをリストアする必要があるフィジカル・スタンバイ・データベースのサービス名を指定します。リストア操作では、リストアする必要があるファイルのバックアップ・セットがRMANによってフィジカル・スタンバイ・データベース上に作成され、これらのバックアップ・セットがネットワークを介してターゲット・データベースに転送されます。

マルチセクション・リストア操作を実行するには、RESTOREコマンドでSECTION SIZE句を使用します。フィジカル・スタンバイ・データベース上に作成されたバックアップ・セットを暗号化するには、RESTOREコマンドの前に、SET ENCRYPTIONコマンドで、使用される暗号化アルゴリズムを指定します。

フィジカル・スタンバイ・データベースから、圧縮されたバックアップ・セットとしてファイルを転送するには、RESTOREコマンドでUSING COMPRESSED BACKUPSET句を使用します。デフォルトでは、RMANの構成で設定されているアルゴリズムを使用して、バックアップ・セットが圧縮されます。RESTORE文の前にSET COMPRESSION ALGORITHMコマンドを使用することで、異なるアルゴリズム設定でデフォルトをオーバーライドできます。

20.7.2 ネットワークを介したファイルのリカバリについて

RMANでは、プライマリ・データベースからネットワークを介して増分バックアップをフェッチし、この増分バックアップをフィジカル・スタンバイ・データベースに適用することによって、リカバリを実行できます。RMANはTARGETとしてフィジカル・スタンバイ・データベースに接続されます。リカバリ・プロセスは、データファイル内の使用済データ・ブロックのみをリストアすることによって最適化されます。FROM SERVICE句を使用して、増分バックアップをフェッチする必要があるプライマリ・データベースのサービス名を指定します。

リカバリ・プロセスでマルチセクション・バックアップ・セットを使用するには、RECOVERコマンドでSECTION SIZE句を指定します。プライマリ・データベースから暗号化バックアップ・セットとして必要なファイルを転送するには、RESTOREコマンドの前に、SET ENCRYPTIONコマンドで、バックアップ・セットの作成に使用される暗号化アルゴリズムを指定します。

ネットワークを介したファイルのリカバリに使用されるバックアップ・セットを圧縮するには、USING COMPRESSED BACKUPSETを使用します。RMANでは、プライマリ・データベース上にバックアップ・セットを作成する際にこれらを圧縮し、その後ターゲット・データベースに転送します。

20.7.3 ネットワークを介したファイルのリストアおよびリカバリの例

フィジカル・スタンバイ・データベースにネットワークを介して接続し、ファイルをリカバリすることは、次の場合に有用です。

  • フィジカル・スタンバイ・データベースをロールフォワードしてプライマリ・データベースと同期化する必要がある場合。

    プライマリ・データベースで最新の変更の増分バックアップを作成した後、その増分バックアップを使用してフィジカル・スタンバイ・データベースをリストアできます。

  • プライマリ・データベースで失われたデータファイル、制御ファイルまたは表領域を、フィジカル・スタンバイ・データベース上の対応するファイルを使用してリストアする必要がある場合。プライマリ・データベースを使用してフィジカル・スタンバイ・データベース上のファイルをリストアすることもできます。

20.7.4 ネットワークを介したデータファイルのリストア

この例では、プライマリ・データベースのDB_UNIQUE_NAMEMAINで、フィジカル・スタンバイ・データベースのDB_UNIQUE_NAMESTANDBYです。プライマリ・データベースのデータファイルsales.dbfが失われました。このデータファイルをフィジカル・スタンバイ・データベースからリストアする必要があります。フィジカル・スタンバイ・データベースのサービス名はstandby_tnsです。RESTOREコマンドにFROM SERVICE句を使用すると、フィジカル・スタンバイ・データベースのデータファイルを使用してプライマリ・データベースの失われたデータファイルをリストアできます。プライマリ・データベースとフィジカル・スタンバイ・データベースのパスワード・ファイルは、同じです。

次の手順を使用して、プライマリ・データベースのデータファイルsales.dbfをフィジカル・スタンバイ・データベースのデータファイルを使用してリストアします。

  1. SYSBACKUP権限を持つユーザーとしてプライマリ・データベースに接続します。
    %RMAN
    RMAN> CONNECT TARGET "sbu@main AS SYSBACKUP";
    

    sbuユーザーのパスワードを要求された場合は入力します。

  2. バックアップ・セットが、AES128暗号化アルゴリズムを使用して暗号化される必要があることを指定します。
    RMAN> SET ENCRYPTION ALGORITHM 'AES128';
    
  3. フィジカル・スタンバイ・データベースのtnsnames.oraファイルに、プライマリ・データベースと対応するエントリが含まれていることを確認します。さらに、プライマリ・データベースとフィジカル・スタンバイ・データベース上のパスワード・ファイルが同じことであることも確認します。
  4. フィジカル・スタンバイ・データベースのデータファイルを使用して、プライマリ・データベースのデータファイルをリストアします。次のコマンドは、リストア操作を実行するためのマルチセクション・バックアップ・セットを作成します。
    RESTORE DATAFILE '/oradata/datafiles/sales.dbf'
    FROM SERVICE standby_tns
    SECTION SIZE 120M;
    

20.7.5 RECOVERコマンドを使用したフィジカル・スタンバイ・データベースのロールフォワード

RECOVER ... FROM SERVICEコマンドを使用すると、フィジカル・スタンバイ・データベース上のデータファイルを、プライマリ・データベース上のデータファイルと同期化できます。RMANでは、プライマリ・データベースへの変更を含む増分バックアップを作成し、ネットワークを介して増分バックアップをフィジカル・スタンバイ・データベースに転送します。その後、この増分バックアップがフィジカル・スタンバイ・データベースに適用されます。プライマリ・データベース上のデータファイルへのすべての変更(スタンバイ・データファイル・ヘッダがSCNで始まる)が、この増分バックアップに含まれます。

RECOVER ... FROM SERVICEコマンドを使用すると、スタンバイ・データファイルを更新し、プライマリと同じPoint-in-Timeにロールフォワードできます。ただし、スタンバイ制御ファイルには、スタンバイ・データファイルのSCN値より小さい古いSCN値が含まれたままになります。したがって、フィジカル・スタンバイ・データベースの同期を完了するには、スタンバイ制御ファイルを更新し、更新されたスタンバイ制御ファイルのデータファイル名、オンラインREDOログ・ファイル名、スタンバイREDOログ・ファイル名を更新する必要があります。

ネットワーク・リソースに制約がある場合は、BACKUP INCREMENTALコマンドを使用してプライマリ・データベース上に増分バックアップを作成し、この増分バックアップを使用してフィジカル・スタンバイ・データベースをロールフォワードできます。

「プライマリ・データベースで行われた変更を使用してフィジカル・スタンバイ・データベースを更新する手順」では、FROM SERVICE句を使用してフィジカル・スタンバイをリフレッシュする手順について説明します。

関連項目:

BACKUP INCREMENTALコマンドを使用したフィジカル・スタンバイ・データベースのロールフォワードの詳細は、『Oracle Data Guard概要および管理』を参照してください。

20.7.5.1 プライマリ・データベースで行われた変更を使用してフィジカル・スタンバイ・データベースをリフレッシュする手順

プライマリ・データベースのDB_UNIQUE_NAMEMAINで、そのネット・サービス名はprimary_dbであるとします。スタンバイ・データベースのDB_UNIQUE_NAMEは、STANDBYで、そのネット・サービス名はstandby_dbだとします。

次の手順を使用して、プライマリ・データベースで行われた変更を使用してフィジカル・スタンバイ・データベースを更新します。

  1. 次の前提条件が満たされていることを確認してください。

    • Oracle Net接続性が、フィジカル・スタンバイ・データベースとプライマリ・データベースとの間で確立されている。

      これは、フィジカル・スタンバイ・データベースのtnsnames.oraファイルに、プライマリ・データベースに対応するエントリを加えることによって行うことができます。

      関連項目:

      Oracle Netの接続確立の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

    • プライマリ・データベースとフィジカル・スタンバイ・データベースのパスワード・ファイルが同じである。

    • プライマリ・データベースおよびフィジカル・スタンバイ・データベースの初期化パラメータファイルの、COMPATIBLEパラメータが12.0に設定されている。

  2. RMANを起動して、ターゲットとしてフィジカル・スタンバイ・データベースに接続します。リカバリ・カタログにも接続することをお薦めします。

    次のコマンドでTARGETとしてフィジカル・スタンバイ・データベースに接続し、CATALOGとしてリカバリ・カタログに接続します。フィジカル・スタンバイ・データベースへの接続は、sbuユーザーを使用して確立されます。このユーザーにはSYSBACKUP権限が与えられています。フィジカル・スタンバイ・データベースのネット・サービス名はstandby_dbで、リカバリ・カタログのネット・サービス名はcatdbです。

    CONNECT TARGET "sbu@standby_db AS SYSBACKUP";
    CONNECT CATALOG rman@catdb;
    
  3. 次のコマンドを使用して、フィジカル・スタンバイ・データベースのデータファイル名および一時ファイル名を取得します。

    REPORT SCHEMA;
    

    また、このコマンドによってリカバリ・カタログが暗黙的に再同期化され、そこにスタンバイ・データベースのすべてのファイル名が含まれていることが確認されます。

  4. フィジカル・スタンバイ・データベースのオンラインREDOログ・ファイル名およびスタンバイREDOログ・ファイル名をメモします。後の手順でこれらの名前が必要になる場合があります。

    次のコマンドでは、REDOログ・ファイル名およびグループ識別子が表示されます。

    SELECT type, group#, member FROM v$logfile;
    
  5. フィジカル・スタンバイ・データベース上の管理リカバリ・プロセスを停止します。

    次のコマンドで、リカバリ・プロセスを停止します。

    ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
    

    Data Guard Brokerを使用する場合、次のコマンドを使用して、管理リカバリ・プロセスを停止します。

    DGMGRL > edit database standby_db set state='APPLY-OFF';
  6. フィジカル・スタンバイ・データベースの現行のSCNをメモします。これは、後の手順で、新しいデータファイルがプライマリ・データベースに追加されたかどうかを確認する際に必要です。

    次のコマンドを使用して、V$DATABASEビューを問い合せて、現行のSCNを取得します。

    SELECT CURRENT_SCN FROM V$DATABASE;
  7. フィジカル・スタンバイ・データベースをNOMOUNTモードに設定します。

    次の手順を使用して、スタンバイをNOMOUNTモードに設定します。

    SHUTDOWN IMMEDIATE;
    STARTUP NOMOUNT;
    
  8. プライマリ・データベース上の制御ファイルを使用して、スタンバイ制御ファイルをリストアします。

    次のコマンドでは、プライマリ・データベース制御ファイルを使用して、フィジカル・スタンバイ・データベース上の制御ファイルがリストアされます。

    RESTORE STANDBY CONTROLFILE FROM SERVICE primary_db;
    

    この手順を実行すると、スタンバイ制御ファイル内のファイル名が、プライマリ・データベースで使用されているファイル名になります。

  9. 次のコマンドを使用して、スタンバイ・データベースをマウントします。

    ALTER DATABASE MOUNT;
    
  10. スタンバイ制御ファイル内のデータファイル名および一時ファイル名を更新します。

    • リカバリ・カタログに接続したら、次のコマンドを使用してファイル名を更新します。

      RECOVER DATABASE NOREDO;
      
    • リカバリ・カタログに接続したら、CATALOGコマンドおよびSWITCHコマンドを使用してすべてのデータファイル名を更新します。

      CATALOG START WITH '/disk2/datafiles/';
      SWITCH DATABASE TO COPY;
      

      ここで、/disk2/datafiles/は、フィジカル・スタンバイ・データベース上のデータファイルの場所です。すべてのデータファイルを、この場所に格納する必要があります。

      データファイルが異なる場所にある場合は、ALTER DATABASE RENAME FILEコマンドを使用してデータファイルの名前を変更します。

  11. プライマリ・データベース上のデータファイルの増分バックアップを使用して、フィジカル・スタンバイ・データベース上のデータファイルを更新します。

    次のコマンドでは、プライマリ・データベース上にマルチセクション増分バックアップが作成され、これを使用してスタンバイ・データファイルが更新されます。primary_dbは、スタンバイ・データベースを更新するために使用される、プライマリ・データベースのネット・サービス名です。NOREDO句で、アーカイブREDOログ・ファイルがリカバリ中に適用されないように指定します。

    RECOVER DATABASE
    FROM SERVICE primary_db
    NOREDO
    SECTION SIZE 120M;
    
  12. 手順6で戻された現行のSCNを使用して、スタンバイ・データベースの最後のリフレッシュ以降に新しいデータファイルがプライマリ・データベースに追加されたかどうかを確認します。追加された場合、プライマリ・データベースからこれらのデータファイルをスタンバイでリストアする必要があります。

    次の例では、手順6で戻されたCURRENT_SCNが35806であると想定し、このSCNによって表されるタイムスタンプ後にプライマリで作成されたデータファイルを表示します。

    SELECT file# FROM V$DATAFILE WHERE creation_change# >= 35806;
  13. 手順12でファイルが戻されない場合は、手順14に進みます。手順12で1つ以上のファイルが戻された場合は、プライマリ・データベースからこれらのデータファイルをリストアします。

    • リカバリ・カタログに接続されていない場合、次のコマンドを使用して、スタンバイの最後のリフレッシュ後にプライマリに追加されたデータファイル(データファイル15および17がプライマリに追加された)をリストアします。

      RUN
      {
      SET NEWNAME FOR DATABASE TO '/oracle/database';
      RESTORE DATAFILE 15, 17 FROM SERVICE primary_db;
      }
    • リカバリ・カタログに接続されている場合、次のコマンドを使用して、スタンバイの最後のリフレッシュ後にプライマリに追加されたデータファイル(データファイル15および17がプライマリに追加された)をリストアします。

      RESTORE DATAFILE 15, 17 FROM SERVICE primary_db;
      
  14. 次の方法で、スタンバイ制御ファイル内のオンラインREDOログとスタンバイREDOログの名前を更新します。

    • ALTER DATABASE CLEARコマンドを使用して、スタンバイ・データベースのすべてのREDOログ・グループのログ・ファイルを消去します。RMANで、すべてのスタンバイREDOログおよびオンラインREDOログ・ファイルを再作成します。

      注意:

      スタンバイ・データベースに、プライマリ・データベースのオンラインREDOログ・ファイルおよびスタンバイREDOログ・ファイルへのアクセス権がない場合のみ、ログ・ファイルを消去することをお薦めします。スタンバイ・データベースに、プライマリ・データベースのREDOログ・ファイルへのアクセス権があり、プライマリ・データベースのREDOログ・ファイル名がOMF名である場合は、ALTER DATABASEコマンドでプライマリ・データベース上のログ・ファイルを削除します。

      手順4で問い合せたV$LOGFILEビューのGROUP#列に、消去する必要があるログ・グループのREDOログ・グループ識別子が示されます。個別にALTER DATABASE CLEARコマンドを使用して、各REDOログ・グループを消去します。

      次のコマンドで、識別子2を持つREDOログ・グループを消去します。

      ALTER DATABASE CLEAR LOGFILE GROUP 2;
      

      すべてのREDOログ・グループを消去したあと、古いログ・ファイルを削除します。

    • ALTER DATABASE RENAME FILEコマンドを使用して、REDOログ・ファイルの名前を変更します。個別のコマンドを使用して、手順4で示された各ログ・ファイルの名前を変更します。

      ログ・ファイルを名前を変更するには、STANDBY_FILE_MANAGEMENT初期化パラメータをMANUALに設定する必要があります。プライマリ・データベースとフィジカル・スタンバイ・データベースで、オンラインREDOログ・ファイルとスタンバイREDOログ・ファイルの数が同じ場合、ログ・ファイルの名前を変更することをお薦めします。

      関連項目:

      ALTER DATABASEコマンド構文については、『Oracle Database SQL言語リファレンス』を参照してください。

  15. プライマリ・データベース上で、次のコマンドを使用してアーカイブREDOログ・ファイルを切り替えます。

    ALTER SYSTEM ARCHIVE LOG CURRENT;
    
  16. (Active Data Guardの場合のみ)次の手順を実行して、REDOデータをリカバリし、フィジカル・スタンバイ・データベースを読取り専用モードでオープンします。

    ALTER DATABASE RECOVER MANAGED STANDBY DATABASE UNTIL CONSISTENT;
    ALTER DATABASE OPEN READ ONLY;
  17. フィジカル・スタンバイ・データベース上の管理リカバリ・プロセスを開始します。

    次のコマンドでは、管理リカバリ・プロセスを開始します。

    ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

    Data Guard Brokerを使用する場合、次のコマンドを使用して、管理リカバリ・プロセスを開始します。

    DGMGRL> edit database standby_db set state='APPLY-ON';