ヘッダーをスキップ

Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド
11g リリース1(11.1)

E05700-03
目次
目次
索引
索引

戻る 次へ

8 データベースのバックアップ

この章では、最も基本的なバックアップ作業の実行方法およびRecovery Managerを使用したバックアップ計画の実装方法について説明します。この章の内容は、次のとおりです。

Recovery Managerバックアップの概要

この項では、Recovery Managerバックアップの概要について説明します。

Recovery Managerバックアップの目的

Recovery Managerバックアップの主要な目的は、データを保護することです。メディア障害が発生した場合は、バックアップをリストアして、消失した変更をリカバリできます。

また、バックアップを作成すると、「長期格納用のデータベース・バックアップの作成」の説明に従って長期アーカイブ用のデータを保存したり、第VII部「Recovery Managerを使用したデータの送信」の章の説明に従ってデータを送信することができます。

Recovery Managerバックアップの基本的な概念

第7章「Recovery Managerバックアップの概要」で説明されているように、Recovery Managerクライアント内からBACKUPコマンドを使用して、データベース全体または一部をバックアップできます。この章で説明する多くの方法は、Oracle Enterprise Managerで提供されるオラクル社推奨のバックアップ計画でも使用されます(『Oracle Database 2日でデータベース管理者』を参照)。

多くの場合、バックアップ計画に従ってデータベースを構成しておくと、Recovery Managerプロンプトで次のコマンドを入力してデータベースをバックアップできます。

RMAN> BACKUP DATABASE;

Recovery Managerは、構成された設定、以前のバックアップのレコードおよびデータベース構造の制御ファイル・レコードを使用して、効率的な一連のバックアップ手順を決定します。その後、それらの手順を実行します。

「Data Guard環境でのRecovery Managerによるファイル管理」で説明されているように、Data Guard環境の任意のデータベースでRecovery Managerバックアップを実行できます。バックアップにアクセスできるかぎり、環境内の任意のデータベースのすべてのバックアップを他のデータベースのリカバリに使用できます。データベース・ファイルのすべてのバックアップ(制御ファイルのバックアップを含む)をフィジカル・スタンバイ・データベースにオフロードすると、プライマリ・データベース上のリソースの消費を回避できます。

参照:

  • BACKUPコマンドについては、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

  • Recovery Managerでスタンバイ・データベースをバックアップする方法については、『Oracle Data Guard概要および管理』を参照してください。

 

バックアップ出力オプションの指定

BACKUP DATABASEなどのRecovery Managerコマンドに最低限必要なオプションのみを指定した場合、Recovery Managerは、構成された環境およびRecovery Managerの組込みデフォルトに基づいて、バックアップ先デバイス、バックアップの出力場所およびバックアップ・タグを自動的に決定します。

また、BACKUPに引数を指定して、これらのデフォルトを上書きすることもできます。次の項では、最も一般的なオプションについて説明します。

Recovery Managerバックアップ用のデバイス・タイプの指定

BACKUPコマンドでは、ディスクまたはテープ・デバイスのいずれにバックアップするかを指定するDEVICE TYPE句を使用します。次に、ディスクにバックアップする例を示します。

例8-1    デバイス・タイプDISKの指定

BACKUP DATABASE 
  DEVICE TYPE DISK;

DEVICE TYPE句を指定しないでBACKUPを実行すると、Recovery Managerは、構成されているデフォルトのデバイス(ディスクまたはSBT)にバックアップを格納します。デフォルトのデバイスは、「バックアップ用のデフォルト・デバイスの構成: ディスクまたはSBT」で説明されているCONFIGURE DEFAULT DEVICE TYPEコマンドを使用して設定します。

ディスクへのRecovery Managerバックアップ用のバックアップ・セットまたはバックアップ・コピーの指定

Recovery Managerは、イメージ・コピーまたはバックアップ・セットとしてバックアップをディスク上に作成できます。デフォルトのディスク・デバイスの構成方法については、「バックアップ用のデフォルト・タイプの構成: バックアップ・セットまたはコピー」を参照してください。このデフォルトは、AS COPY句またはAS BACKUPSET句を使用して上書きできます。イメージ・コピーとしてディスクにバックアップするには、BACKUP AS COPYを使用します。

例8-2    イメージ・コピーの作成

BACKUP AS COPY
  DEVICE TYPE DISK 
  DATABASE;

バックアップ・セットにデータをバックアップするには、AS BACKUPSET句を使用します。次の例に示すように、バックアップ・セットは、構成されているデフォルト・デバイスに作成したり、ディスクまたはテープに明示的に格納できます。

例8-3    バックアップ・セットの作成

BACKUP AS BACKUPSET 
  DATABASE;

BACKUP AS BACKUPSET 
  DEVICE TYPE DISK 
  DATABASE;

BACKUP AS BACKUPSET 
  DEVICE TYPE SBT 
  DATABASE;

Recovery Managerバックアップのフォーマットの指定

Recovery Managerには、BACKUPコマンドで生成されるファイルに名前を指定するための様々なオプションが用意されています。Recovery Managerは、優先順位に従って示されている次のルール・セットを使用して、出力ファイル形式を決定します。

  1. BACKUPコマンドにFORMATパラメータを指定した場合、生成されるファイル名はこの設定で制御されます。

    たとえば、次のコマンドに示すように、出力を特定の場所に格納することができます。

    BACKUP DATABASE 
      FORMAT "/disk1/backup_%U";  # specifies a location on the file system
    
    

    この場合、バックアップは、生成された一意のファイル名(/disk1/backup_という接頭辞付き)で格納されます。置換変数%Uが必要であることに注意してください。この置換変数は、ファイル名のその部分に一意の文字列を生成するために使用されます。

    また、次の例に示すように、FORMATパラメータを使用して、バックアップ先としてASMディスク・グループを指定することもできます。

    BACKUP DATABASE 
      FORMAT '+dgroup1';  # specifies an ASM disk group
    
    

    この場合、必要に応じて自動ストレージ管理で一意のファイル名が生成されるため、%Uは不要です。ただし、必要な場合は、%Uを指定できます。


    注意:

    フラッシュ・リカバリ領域が有効になっている場合にFORMATを指定すると、Recovery ManagerはFORMATの設定に従います。FORMAT句で場所を指定しなかった場合、Recovery Managerはプラットフォーム固有の場所にバックアップを作成します。 


  2. FORMAT設定がバックアップで使用される特定のチャネル用に構成されている場合、生成されるファイル名の制御はこの設定によって行われます。

  3. FORMAT設定がバックアップで使用されるデバイス・タイプ用に構成されている場合、生成されるファイル名の制御はこの設定によって行われます。

  4. ディスク・バックアップ中にフラッシュ・リカバリ領域が有効になっていて、FORMATが指定されていない場合は、自動生成された名前でフラッシュ・リカバリ領域にバックアップが作成されます。

  5. このリストの他のいずれの条件も当てはまらない場合は、バックアップのデフォルトの場所およびファイル名の書式はプラットフォーム固有になります。

    参照:

    FORMAT句については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。ご使用のプラットフォームのデフォルトのファイルの場所については、インストレーション・ガイドを参照してください。 

ディスク・バックアップの複数のフォーマットの指定

通常、テープにバックアップする場合には、デフォルトの%U変数によってテープ・バックアップに一意のファイル名が生成されるため、フォーマットを指定する必要はありません。ただし、ディスクへのバックアップで、パフォーマンスを向上するために複数のドライブにバックアップを分散させる必要がある場合には、フォーマットを指定できます。この場合、各ディスク・ドライブに1つのDISKチャネルを割り当て、ALLOCATE CHANNELコマンドでFORMAT文字列を指定して、それぞれのディスクにファイル名が生成されるようにします。たとえば、次のコマンドを発行します。

RUN
{ 
  ALLOCATE CHANNEL disk1 DEVICE TYPE DISK FORMAT '/disk1/%d_backups/%U';
  ALLOCATE CHANNEL disk2 DEVICE TYPE DISK FORMAT '/disk2/%d_backups/%U';
  ALLOCATE CHANNEL disk3 DEVICE TYPE DISK FORMAT '/disk3/%d_backups/%U';
  BACKUP AS COPY DATABASE; 
} 

チャネルを次のように構成すると、将来、デフォルトでこのようにバックアップを分散できるようになります。

CONFIGURE DEVICE TYPE DISK PARALLELISM 3;
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT '/disk1/%d_backups/%U';
CONFIGURE CHANNEL 2 DEVICE TYPE DISK FORMAT '/disk2/%d_backups/%U';
CONFIGURE CHANNEL 3 DEVICE TYPE DISK FORMAT '/disk3/%d_backups/%U';
BACKUP AS COPY DATABASE;

Recovery Managerバックアップのタグの指定

Recovery Managerは、バックアップを識別する方法として、作成するすべてのバックアップにタグと呼ばれる文字列を追加します。デフォルトのタグを受け入れるか、またはBACKUPコマンドのTAGパラメータで独自のタグを指定できます。

バックアップ・タグ

ユーザー指定のタグは、バックアップまたはコピーの様々な目的や使用方法を示す場合に有効です。タグは、バックアップ・セット、プロキシ・コピー、データファイル・コピーまたは制御ファイル・コピーに指定できます。たとえば、SWITCHコマンドで使用するデータファイルのコピーにはfor_switch_onlyRESTOREコマンドでのみ使用するファイルのコピーにはfor_restore_onlyというタグを指定することができます。

タグは一意である必要はないため、複数のバックアップ・セットまたはイメージ・コピーに同じタグ(weekly_backupなど)を付けることができます。特定のタグが含まれているバックアップからデータファイルをリストアするように指定するとします。要求したファイルの複数のバックアップにそのタグが含まれている場合、Recovery Managerは、RESTOREコマンドの制約内で、指定したタグが含まれている最新のバックアップをリストアします。

実際には、タグは、多くの場合、増分バックアップ計画などの1つの計画の一環として作成された一連のバックアップを区別する場合に使用されます。たとえば、BACKUP TAG weekly_incrementalなどのタグを付けて、週次増分バックアップを作成できます。BACKUPコマンドの様々な形式を使用して、タグとバックアップを関連付けることができます。また、多くのRESTOREおよびRECOVERコマンドでは、タグを指定してRESTOREまたはRECOVER操作で使用するバックアップを制限できます。

BACKUPコマンドのTAGパラメータを使用して明示的にタグを指定しない場合は、Recovery Managerによって、バックアップ(制御ファイルの自動バックアップ以外)のデフォルト・タグが暗黙的に作成されます。タグの形式は、TAGYYYYMMDDTHHMMSSです。ここで、YYYYは年、MMは月、DDは日、HHは時間(24時間形式)、MMは分、SSは秒です。たとえば、データファイル1のバックアップには、タグTAG20070208T133437が割り当てられる場合があります。日時は、バックアップを実行するインスタンスのタイムゾーンで、Recovery Managerがバックアップを開始した日時です。1つのBACKUPコマンドによって複数のバックアップ・セットが作成される場合、各バックアップ・ピースには同じデフォルト・タグが割り当てられます。

入力時に使用した大/小文字に関係なく、タグは大文字で格納されます。バックアップ・タグの最大長は30バイトです。オペレーティング・システムの環境変数または%T%Dなどの特殊な書式は、タグに使用できません。

参照:

BACKUP ...TAGのデフォルト形式については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。 

バックアップ・セットおよびイメージ・コピーのタグの指定

タグで使用する文字は、ターゲットのデータベース・ファイル・システムでファイル名として有効な文字に制限する必要があります。たとえば、自動ストレージ管理では、内部的に使用されるファイル名でのダッシュ(-)の使用はサポートされていません。このため、ASMディスク・グループでのバックアップの場合、ダッシュが含まれているタグ(weekly-incrなど)は無効なタグ名になります。

バックアップ・セットにタグを指定すると、そのタグは、指定したバックアップ・セットのコピーに含まれる各バックアップ・ピースの属性になります。多重バックアップ・セットを作成すると、バックアップ・セットの各コピーに同じタグが割り当てられます。例8-4では、タグMONDAYBKPが指定されたバックアップ・セットを1つ作成します。

例8-4    バックアップ・セットへのタグの適用

BACKUP AS BACKUPSET
  COPIES 1 
  DATAFILE 7
  TAG mondaybkp; 

イメージ・コピーにタグを指定すると、そのタグは各コピーに適用されます。例8-5では、表領域usersおよびtoolsのデータファイルのコピーに、タグMONDAYCPYを割り当てます。

例8-5    イメージ・コピーへのタグの適用

BACKUP AS COPY 
  TABLESPACE users, tools
  TAG mondaycpy;

FROM TAGを使用して特定のタグが含まれているイメージ・コピーをコピーした後、TAGを使用して出力コピーに別のタグを割り当てることができます。例8-6では、タグfull_cold_copyが含まれている、データベースのすべてのイメージ・コピーのコピーを新しく作成し、その新しいコピーにnew_full_cold_copyを割り当てます。

例8-6    出力コピーへのタグの割当て

BACKUP AS COPY
  COPY OF DATABASE
    FROM TAG full_cold_copy
  TAG new_full_cold_copy;

圧縮バックアップの作成

バックアップ・セットを作成するBACKUPコマンドを実行する場合は、Recovery Managerでサポートされている、バックアップ・セットのバイナリ圧縮を利用できます。BACKUPコマンドにAS COMPRESSED BACKUPSETオプションを指定します。作成されるバックアップ・セットは、Oracle Databaseファイルが効率的に圧縮されるように最適化されたアルゴリズムを使用して圧縮されます。リカバリ中に特別な解凍手順を実行する必要はありません。


注意:

バックアップ先がテープであり、テープ・デバイスで独自の圧縮が実行される場合、Recovery Managerによるバックアップ・セットの圧縮とメディア・マネージャ・ベンダーによる圧縮の両方は使用しないでください。ほとんどの場合、メディア・マネージャの圧縮を使用した方がよりよい結果を得ることができます。詳細は、第21章「Recovery Managerのパフォーマンスのチューニング」のRecovery Managerによるテープ・バックアップのパフォーマンス・チューニングに関する項を参照してください。 


例8-7では、データベース全体とアーカイブ・ログを、構成済のデフォルトのバックアップ先(ディスクまたはテープ)にバックアップし、圧縮バックアップ・セットを作成します。

例8-7    圧縮バックアップの作成

BACKUP 
  AS COMPRESSED BACKUPSET 
  DATABASE PLUS ARCHIVELOG;

バイナリ圧縮では、バックアップおよびリカバリ操作中に、パフォーマンスにある程度のオーバーヘッドが発生します。バイナリ圧縮はCPUリソースを消費するため、CPU使用率がすでに高い場合は、圧縮バックアップはスケジュールしないでください。ただし、次の状況では、パフォーマンスが低下する可能性があります。

Recovery Managerを使用したデータベース・ファイルのバックアップ

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

Recovery Managerを使用したデータベース全体のバックアップの作成

データベース全体のバックアップは、データベースをマウントまたはオープンして実行できます。データベース全体のバックアップを実行するには、Recovery ManagerプロンプトでBACKUP DATABASEコマンドを使用します。

データベース全体のバックアップから、指定した表領域を除外することができます。「データベース全体のバックアップから除外する表領域の構成」の説明に従って、常にスキップする各表領域に対してCONFIGURE EXCLUDEコマンドを実行すると、すべてのRecovery Managerセッションで永続的に表領域をスキップできます。BACKUP ... NOEXCLUDEを使用すると、構成済の設定を上書きできます。

データベースをバックアップする手順
  1. Recovery Managerを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

  2. データベースがマウントまたはオープンされていることを確認します。

  3. Recovery Managerプロンプトで、BACKUP DATABASEコマンドを発行します。

    次の例に示すように、このコマンドの最も簡単な形式にはオプションまたはパラメータは必要ありません。

    BACKUP DATABASE;
    
    

    次の例では、データベースをバックアップし、オンラインREDOログを切り替え、アーカイブ・ログをバックアップに格納します。

    BACKUP DATABASE PLUS ARCHIVELOG;
    
    

    バックアップの直後にログをアーカイブすることによって、バックアップ時間全体のアーカイブ・ログの完全なセットを取得します。これによって、このバックアップのリストア後にメディア・リカバリを実行できることが保証されます。

    参照:

     

Recovery Managerを使用した表領域およびデータファイルのバックアップ

BACKUP TABLESPACEコマンドでは1つ以上の表領域、BACKUP DATAFILEコマンドでは1つ以上のデータファイルをバックアップできます。表領域を指定すると、Recovery Managerは表領域の名前を一連のデータファイルに内部的に変換します。データベースは、マウントされている状態でもオープンされている状態でもかまいません。表領域は、読取り/書込みでも読取り専用でもかまいません。


注意:

以前のリリースと同様に、トランスポータブル表領域は、バックアップに対して読取り/書込みモードである必要はありません。 


バックアップにデータファイル1が含まれている場合、Recovery Managerは、制御ファイルおよびサーバー・パラメータ・ファイル(インスタンスがサーバー・パラメータ・ファイルで起動されている場合)を自動的にバックアップします。制御ファイルの自動バックアップが有効になっている場合、Recovery Managerは、現行の制御ファイルおよびサーバー・パラメータ・ファイルを別の自動バックアップ・ピースに書き込みます。そうでない場合、Recovery Managerは、データファイル1が含まれているバックアップ・セットにこれらのファイルを書き込みます。

表領域またはデータファイルをバックアップする手順
  1. Recovery Managerを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

  2. データベース・インスタンスが起動されていない場合は、データベースをマウントまたはオープンします。

  3. Recovery Managerプロンプトで、BACKUP TABLESPACEコマンドまたはBACKUP DATAFILEコマンドを実行します。

    次の例では、usersおよびtools表領域をテープにバックアップします。

    BACKUP
      DEVICE TYPE sbt
      TABLESPACE users, tools;
    
    

    次の例では、SBTチャネルを使用して、データファイル1から4および/tmp/system01.dbfに格納されているデータファイルのコピーをテープにバックアップします。

    BACKUP 
      DEVICE TYPE sbt 
      DATAFILE 1,2,3,4 
      DATAFILECOPY '/tmp/system01.dbf';
    

Recovery Managerを使用した制御ファイルのバックアップ

制御ファイルは、データベースがマウントまたはオープンされているときにバックアップできます。Recovery Managerは、スナップショット制御ファイルを使用して、読取り一貫性のバージョンを保証します。CONFIGURE CONTROLFILE AUTOBACKUPコマンドがONに設定されている場合(デフォルトではOFF)、Recovery Managerは、すべてのバックアップ後およびデータベースの構造変更後に、制御ファイルおよびサーバー・パラメータ・ファイルを自動的にバックアップします。制御ファイルの自動バックアップには、以前のバックアップに関するメタデータが含まれます。このメタデータは、障害リカバリに重要です。


注意:

1つのData Guardデータベースで作成された制御ファイルのバックアップを、環境内の他のすべてのデータベースにリストアすることができます。プライマリ制御ファイルのバックアップとスタンバイ制御ファイルのバックアップには互換性があります。Recovery Managerを使用してスタンバイ・データベースにリストアする方法については、『Oracle Data Guard概要および管理』を参照してください。 


自動バックアップ機能が設定されていない場合は、次のいずれかの方法を使用して、手動で制御ファイルをバックアップする必要があります。

制御ファイルの手動バックアップの作成

制御ファイルの手動バックアップは、制御ファイルの自動バックアップとは異なります。Recovery Managerは、BACKUPコマンドで指定されたファイルをバックアップした後、制御ファイルの自動バックアップを作成します。このため、制御ファイルの手動バックアップとは異なり、自動バックアップには、完了直後のバックアップに関するメタデータが含まれます。また、Recovery Managerは、リカバリ・カタログを使用しないで自動バックアップを自動的にリストアすることもできます。

手動バックアップを作成するには、他のファイルをバックアップする際にINCLUDE CURRENT CONTROLFILEを指定するか、またはBACKUP CONTROLFILEを指定します。また、CONTROLFILECOPYパラメータを指定して、制御ファイルのコピーをディスクにバックアップすることもできます。

制御ファイルを手動でバックアップする手順
  1. Recovery Managerを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

  2. ターゲット・データベースがマウントまたはオープンされていることを確認します。

  3. 必要な制御ファイル句を指定してBACKUPコマンドを実行します。

    次の例では、表領域usersをテープにバックアップし、そのバックアップに現行の制御ファイルを含めます。

    BACKUP DEVICE TYPE sbt 
      TABLESPACE users 
      INCLUDE CURRENT CONTROLFILE;
    
    

    次の例では、現行の制御ファイルをデフォルトのディスク・デバイスにバックアップします。

    BACKUP AS COPY
      CURRENT CONTROLFILE 
      FORMAT '/tmp/control01.ctl';
    
    

    次の例では、前述の例で作成した制御ファイルのコピーをテープにバックアップします。

    BACKUP AS COPY 
      CURRENT CONTROLFILE 
      FORMAT '/tmp/control01.ctl';
    BACKUP DEVICE TYPE sbt 
      CONTROLFILECOPY '/tmp/control01.ctl';
    
    

    制御ファイルの自動バックアップ機能が有効になっている場合、Recovery Managerは、これらの例で制御ファイルのバックアップを2つ作成します。1つはBACKUPコマンドで指定したファイルの明示的なバックアップで、もう1つは制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップです。

    参照:

    CONFIGURE CONTROLFILE AUTOBACKUPコマンドについては、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。 

Recovery Managerを使用したサーバー・パラメータ・ファイルのバックアップ

「Recovery Managerを使用した制御ファイルのバックアップ」で説明したとおり、Recovery Managerは、特定の状況下で、現行のサーバー・パラメータ・ファイルを自動的にバックアップします。BACKUP SPFILEコマンドは、パラメータ・ファイルを明示的にバックアップします。バックアップされるサーバー・パラメータ・ファイルは、インスタンスで現在使用されているサーバー・パラメータ・ファイルです。

サーバー・パラメータ・ファイルをバックアップする方法
  1. Recovery Managerを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

  2. ターゲット・データベースがマウントまたはオープンされていることを確認します。

    サーバー・パラメータ・ファイルを使用して、データベースを起動している必要があります。インスタンスがクライアント側の初期化パラメータ・ファイルを使用して起動されている場合にBACKUP ... SPFILEを実行すると、Recovery Managerによってエラーが発行されます。

  3. BACKUP ... SPFILEコマンドを実行します。

    次の例では、サーバー・パラメータ・ファイルがテープにバックアップされます。

    BACKUP DEVICE TYPE sbt SPFILE;
    

NOARCHIVELOGモードでのデータベースのバックアップ

NOARCHIVELOGモードのデータベースの有効なバックアップは、クローズ状態の一貫性バックアップのみです。次のスクリプトを実行すると、データベースがデータベース全体の一貫性バックアップを行うための正しいモードになり、バックアップされます。次のスクリプトでは、制御ファイルの自動バックアップがデータベースに対して有効になっていると想定されています。

例8-8    NOARCHIVELOGモードでのデータベースのバックアップ

SHUTDOWN IMMEDIATE; 
# Start up the database in case it suffered instance failure or was 
# closed with SHUTDOWN ABORT before starting this script. 
STARTUP FORCE DBA; 
SHUTDOWN IMMEDIATE; 
STARTUP MOUNT;
# this example uses automatic channels to make the backup
BACKUP 
  INCREMENTAL LEVEL 0
  MAXSETSIZE 10M
  DATABASE
  TAG 'BACKUP_1';
# Now that the backup is complete, open the database. 
ALTER DATABASE OPEN; 

読取り専用表領域などの表領域はスキップできますが、バックアップからデータベースをリストアする必要がある場合、最新のバックアップ以降にオフラインまたは読取り専用になっていなかった表領域はスキップすると消失します。

Recovery Managerを使用したアーカイブREDOログのバックアップ

アーカイブREDOログは、メディア・リカバリを正常に実行するために重要です。アーカイブREDOログは、定期的にバックアップする必要があります。

アーカイブREDOログのバックアップ

Recovery Managerバックアップのいくつかの機能は、アーカイブREDOログ専用です。たとえば、BACKUP ... DELETEを使用すると、アーカイブREDOログをバックアップ・セットにバックアップした後、そのアーカイブREDOログの1つのコピーまたはすべてのコピーをディスクから削除できます。

アーカイブREDOログ・フェイルオーバー

REDOログが複数のアーカイブ先にアーカイブされている場合でも、Recovery Managerを使用してアーカイブREDOログをバックアップすると、Recovery ManagerはアーカイブREDOログ・ファイルのコピーを1つのみ選択してバックアップに含めます。同じログ順序番号を持つログは同一であるため、複数のログ・コピーを含める必要はありません。

アーカイブREDOログ・フェイルオーバー機能を使用すると、Recovery Managerは、一部のアーカイブ先でログが欠落している場合またはログに破損ブロックが存在する場合でも、バックアップを完了できます。特定のログ順序およびスレッドに対応する1つ以上のログが、フラッシュ・リカバリ領域またはいずれかのアーカイブ先で使用可能な場合、Recovery Managerはそのログのバックアップを試みます。バックアップ中にログ・ファイルで破損ブロックが検出された場合、Recovery Managerは、他の出力先で破損ブロックのないそのログのコピーを検索します。

たとえば、/arch1および/arch2の2つのアーカイブ先に、ログ121から124をアーカイブするとします。表8-1に、制御ファイル内のアーカイブREDOログ・レコードを示します。

表8-1    アーカイブREDOログ・レコードの例 
順序  /arch1でのファイル名  /arch2でのファイル名 

121 

/arch1/archive1_121.arc 

/arch2/archive1_121.arc 

122 

/arch1/archive1_122.arc 

/arch2/archive1_122.arc 

123 

/arch1/archive1_123.arc 

/arch2/archive1_123.arc 

124 

/arch1/archive1_124.arc 

/arch2/archive1_124.arc 

ここで、あるユーザーが、Recovery Managerを使用せずに/arch1ディレクトリからログ122および124を削除したとします。その後、次のバックアップを実行したとします。

BACKUP ARCHIVELOG
  FROM  SEQUENCE 121 
  UNTIL SEQUENCE 125;

フェイルオーバーによって、Recovery Managerは、/arch2のログ122および124を使用してバックアップを完了します。

オンラインREDOログ・スイッチ

Recovery Managerのもう1つの重要な機能は、自動オンラインREDOログ・スイッチです。最新のオンラインREDOログが含まれている、アーカイブREDOログのオープンされているデータベースのバックアップを作成するには、次のいずれかの句を指定してBACKUPコマンドを実行します。

Recovery Managerは、バックアップを開始する前に、現行のREDOログ・グループからの切替えを行い、コマンドの発行時に最新だったREDOログ・グループまでのアーカイブされていないすべてのオンラインREDOログをアーカイブします。この機能によって、コマンド開始前に生成されたすべてのREDOがバックアップに含まれるようになります。

アーカイブREDOログをバックアップする最も効果的な方法の1つとして、BACKUP ... PLUS ARCHIVELOG句を使用する方法があります。これによって、Recovery Managerで次の操作が実行されます。

  1. ALTER SYSTEM ARCHIVE LOG CURRENT文を実行します。

  2. BACKUP ARCHIVELOG ALLを実行します。バックアップの最適化が有効になっている場合、Recovery Managerは、指定したデバイスにすでにバックアップされているログをスキップします。

  3. BACKUPコマンドに指定された残りのファイルをバックアップします。

  4. ALTER SYSTEM ARCHIVE LOG CURRENT文を実行します。

  5. バックアップ中に生成された残りのアーカイブ・ログをバックアップします。バックアップの最適化が有効になっていない場合、Recovery Managerは、ステップ1で生成されたログおよびバックアップ中に生成されたすべてのログをバックアップします。

前述のステップによって、コマンド実行中に作成されるデータファイルのバックアップを一貫性のある状態にリカバリできます。また、バックアップ終了時にオンラインREDOログがアーカイブされていない場合、そのバックアップでDUPLICATEを実行することはできません。

アーカイブREDOログ・ファイルのバックアップ

アーカイブ・ログをバックアップするには、BACKUP ARCHIVELOGコマンドを使用します。バックアップの最適化が有効になっている場合、Recovery Managerは、指定したデバイスにすでにバックアップされているアーカイブ・ログのバックアップをスキップします。

アーカイブREDOログ・ファイルをバックアップする手順
  1. Recovery Managerを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

  2. ターゲット・データベースがマウントまたはオープンされていることを確認します。

  3. BACKUP ARCHIVELOGまたはBACKUP ... PLUS ARCHIVELOGコマンドを実行します。

    次の例では、データベースおよびすべてのアーカイブREDOログをバックアップします。

    BACKUP DATABASE PLUS ARCHIVELOG;
    
    

    次の例では、構成済のディスクまたはSBTのチャネルを使用して、すべてのアーカイブREDOログの各ログ順序番号のコピーを1つバックアップします。

    BACKUP ARCHIVELOG ALL;
    
    

    また、アーカイブREDOログの範囲を、時間、SCN、またはログ順序番号で指定することもできます。次に例を示します。

    BACKUP ARCHIVELOG 
      FROM TIME  'SYSDATE-30'
      UNTIL TIME 'SYSDATE-7';
    

バックアップが必要なアーカイブREDOログのみのバックアップ

Recovery ManagerがアーカイブREDOログのバックアップを次の方法で自動的にスキップするように指定できます。

BACKUP ... NOT BACKED UP integer TIMESコマンドを指定すると、Recovery Managerは、指定したデバイスにinteger回以上バックアップされていないアーカイブ・ログ・ファイルのみをバックアップします。ファイルのバックアップの数を決定する場合、Recovery Managerは、現行のバックアップと同じデバイス・タイプに作成されているバックアップのみを考慮します。

BACKED UP句は、指定したメディアにアーカイブ・ログをバックアップする場合に有効です。たとえば、Recovery Managerがテープに各アーカイブREDOログのコピーを2つ保持し、追加のバックアップをスキップするように指定できます。

バックアップが必要なアーカイブREDOログをバックアップする手順
  1. Recovery Managerを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

  2. ターゲット・データベースがマウントまたはオープンされていることを確認します。

  3. バックアップに適切なチャネルが構成されていることを確認します。

  4. NOT BACKED UP句を指定してBACKUP ARCHIVELOGコマンドを実行します。

    BACKUP ARCHIVELOG ALL NOT BACKED UP 2 TIMES;
    

    参照:

    NOT BACKED UPの使用例については、「バックアップの最適化を使用したファイルのスキップ」を参照してください。 

バックアップ後のアーカイブREDOログの削除

BACKUP ARCHIVELOG ... DELETE INPUTコマンドは、アーカイブ・ログ・ファイルをバックアップした後、それらのファイルを削除します。このコマンドを使用すると、アーカイブREDOログを手動で削除する手順を実行する必要がなくなります。

DELETE INPUTを実行すると、Recovery Managerは、バックアップ・セットに選択されたアーカイブ・ログの特定のコピーのみを削除します。DELETE ALL INPUTを実行すると、Recovery Managerは、バックアップ済の各アーカイブREDOログ・ファイルを、ログのすべてのアーカイブ先から削除します。

「アーカイブREDOログの削除方針の構成」で説明されているように、BACKUP ... DELETE INPUTおよびDELETE ARCHIVELOGコマンドは、すべてのアーカイブ場所にあるログに関してアーカイブREDOログの削除方針に従います。たとえば、2回以上テープにバックアップされたログのみを削除するように指定した場合、BACKUP ... DELETEはこの方針に従います。

次の手順では、/arc_dest1/arc_dest2およびフラッシュ・リカバリ領域にアーカイブすることを想定しています。

バックアップ後にアーカイブREDOログを削除する手順
  1. Recovery Managerを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

  2. ターゲット・データベースがマウントまたはオープンされていることを確認します。

  3. DELETE INPUT句を指定してBACKUPコマンドを実行します。

    次のBACKUPコマンドを実行するとします。

    BACKUP DEVICE TYPE sbt 
      ARCHIVELOG ALL 
        DELETE ALL INPUT;
    
    

    この場合、Recovery Managerは、これらのアーカイブ場所にある各ログ順序番号のコピーを1つのみバックアップします。Recovery Managerは、フラッシュ・リカバリ領域内のログは削除しませんが、他のアーカイブ先内のバックアップ済のログのコピーはすべて削除します。削除対象となっているフラッシュ・リカバリ領域内のログは、領域が必要になった場合に自動的にデータベースによって削除されます。

    DELETE ALL INPUTではなくDELETE INPUTを指定すると、Recovery Managerは、バックアップ済の特定のアーカイブREDOログ・ファイルのみを削除します。たとえば、Recovery Managerは、/arc_dest1内のログがバックアップのソースとして使用された場合はそれらのファイルを削除しますが、/arc_dest2の内容はそのまま残します。

    参照:

    • スタンバイ・データベースでのアーカイブREDOログの管理については、『Oracle Data Guard概要および管理』を参照してください。

    • CONFIGURE ARCHIVELOG DELETION POLICYコマンドについては、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

    • DELETE ARCHIVELOGコマンドについては、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

    • 「Recovery ManagerバックアップおよびアーカイブREDOログの削除」

     

増分バックアップの作成および更新

「増分バックアップ」で説明されているように、増分バックアップでは、指定した以前のバックアップ以降に変更されたデータファイル・ブロックのみがコピーされます。増分バックアップは、累積増分バックアップまたは差分増分バックアップのいずれかです。

バックアップの内容は同じですが、BACKUP DATABASEBACKUP INCREMENTAL LEVEL 0 DATABASEは異なります。全体バックアップは増分計画の一部として使用できませんが、レベル0の増分バックアップは増分計画の基礎となります。Recovery Managerコマンドでは、全体バックアップをレベル0には変更できません。

Recovery Managerは、全体バックアップの場合と同様に、ARCHIVELOGモードでオープンまたはマウントされているデータベースの増分バックアップを作成できます。データベースがNOARCHIVELOGモードの場合、Recovery Managerは、一貫性のある状態でデータベースを停止した後でのみ、増分バックアップを作成できます。

増分バックアップの目的

増分バックアップを計画の一環として作成する主な理由は次のとおりです。

増分バックアップ計画の設計

許容可能なMTTR(平均リカバリ時間)に応じて、バックアップ計画を選択します。たとえば、3つのレベルのバックアップ・スキームを実装して、全体バックアップまたはレベル0のバックアップを月に1回、レベル1の累積バックアップを週に1回、レベル1の差分バックアップを毎日作成するように設定できます。この計画では、完全リカバリのために、1日分を超えるREDOを適用する必要はありません。

全体バックアップまたはレベル0のバックアップを実行する頻度の目安として、データの20%以上が変更された時点で、レベル0の新しいバックアップを実行するようにします。データベースへの変更率を予想できる場合は、増分バックアップのサイズを監視して、レベル0の新しいバックアップが必要な時点を判断できます。次のSQL問合せを実行すると、ブロックの20%以上がバックアップされている各データファイルの、レベル1の増分バックアップに書き込まれたブロックの数が表示されます。

SELECT   FILE#, INCREMENTAL_LEVEL, COMPLETION_TIME, 
         BLOCKS, DATAFILE_BLOCKS 
FROM     V$BACKUP_DATAFILE 
WHERE    INCREMENTAL_LEVEL > 0 
AND      BLOCKS / DATAFILE_BLOCKS > .2
ORDER BY COMPLETION_TIME;

レベル1のバックアップのブロック数を、レベル0のバックアップと比較します。たとえば、レベル1の累積バックアップのみを作成する場合は、レベル1の最新のバックアップのサイズがレベル0のバックアップの約半分であれば、レベル0の新しいバックアップを作成します。

ディスク領域を節約する効果的な方法の1つとして、増分バックアップをディスクに作成してから、BACKUP AS BACKUPSETでバックアップをテープにオフロードする方法があります。通常、増分バックアップは全体バックアップより小さいため、テープに移動されるまでの格納に必要な領域は制限されます。ディスク上の増分バックアップをテープにバックアップすると、増分バックアップのすべてのブロックがテープにコピーされるため、テープがストリーム化する可能性があります。Recovery Managerでデータファイル内の変更されたブロックの特定にかかる時間のため、遅延が発生する可能性はありません。

もう1つの方法としては、「増分更新バックアップ」で説明されている増分更新バックアップを使用する方法があります。この方法では、各データファイルのイメージ・コピーを作成した後、レベル1の増分バックアップを作成および適用して、定期的にこのコピーをロールフォワードします。これによって、データファイルの完全なイメージ・コピーを繰り返し作成することによって発生するオーバーヘッドが回避され、すべてのメリットを活用できるようになります。

Data Guard環境では、増分バックアップをフィジカル・スタンバイ・データベースにオフロードできます。スタンバイ・データベースの増分バックアップとプライマリ・データベースの増分バックアップには互換性があります。つまり、スタンバイ・データベースの増分バックアップをプライマリ・データベースに適用したり、プライマリ・データベースの増分バックアップをスタンバイ・データベースに適用することができます。また、スタンバイ・データベースでは、Data Guard環境の他のデータベースでブロック・チェンジ・トラッキングが有効になっているかどうかに関係なく、ブロック・チェンジ・トラッキングを有効にできます。これによって、Recovery Managerは、スタンバイ・データベースの増分バックアップを自動的に最適化します。

参照:

Recovery Managerでスタンバイ・データベースをバックアップする方法については、『Oracle Data Guard概要および管理』を参照してください。 

増分バックアップの作成

Recovery Managerを起動した後、Recovery ManagerプロンプトでBACKUP INCREMENTALコマンドを実行します。デフォルトでは、増分バックアップは差分バックアップです。

増分バックアップを作成する手順
  1. Recovery Managerを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

  2. ターゲット・データベースがマウントまたはオープンされていることを確認します。

  3. 必要なオプションを指定してBACKUP INCREMENTALコマンドを実行します。

    増分レベルを指定するには、LEVELパラメータを使用します。次の例では、データベースのレベル0の増分バックアップを作成します。

    BACKUP
      INCREMENTAL LEVEL 0
      DATABASE;
    
    

    次の例では、SYSTEMおよびtools表領域の差分増分バックアップをレベル1で作成します。レベル1またはレベル0の最新のバックアップ以降に変更されたデータ・ブロックのみがバックアップされます。

    BACKUP
      INCREMENTAL LEVEL 1
      TABLESPACE SYSTEM, tools;
    
    

    次の例では、users表領域の累積増分バックアップをレベル1で作成し、最新のレベル0のバックアップ以降に変更されたすべてのブロックをバックアップします。

    BACKUP
      INCREMENTAL LEVEL 1 CUMULATIVE
      TABLESPACE users;
    

VSSスナップショットの増分バックアップの作成

Volume Shadow Copy Service(VSS)をOracle VSSライターとともに使用すると、Oracle Database内のファイルのシャドウ・コピーまたはスナップショットを作成できます。Oracle VSSライターでVSSスナップショットを作成するには、Recovery Managerではなく、サード・パーティのバックアップ・プログラムを使用する必要があります。この場合、フラッシュ・リカバリ領域によって、VSSスナップショットにすでにバックアップされているファイルの管理が自動化され、必要に応じてそれらのファイルが削除されます。

Recovery ManagerでBACKUP INCREMENTAL LEVEL 1 ... FROM SCNコマンドを使用すると、フラッシュ・リカバリ領域に増分バックアップを作成できます。つまり、このコマンドを使用すると、VSSシャドウ・コピーのレベル1の増分バックアップを作成できます。Recovery Managerでは、リカバリ中に増分バックアップを透過的に適用できます。

参照:

Recovery Managerを使用したVSSバックアップの作成方法については、Oracle Databaseのプラットフォーム・ガイドを参照してください。 

増分更新バックアップ

バックアップを増分更新することによって、データファイルの完全なイメージ・コピー・バックアップを作成する場合に発生するオーバーヘッドを回避できます。また、データベースのメディア・リカバリにかかる時間を最小限に抑えることもできます。たとえば、日次バックアップ・スクリプトを実行する場合、メディア・リカバリのために、1日分を超えるREDOを適用する必要はありません。

データファイルのバックアップを増分更新する手順
  1. データファイルの完全なイメージ・コピー・バックアップを作成します。

  2. 定期的(毎日など)に、データファイルのレベル1の増分バックアップを作成して、イメージ・コピー・バックアップに適用します。

この方法では、レベル1の増分が作成された時点にバックアップがロールフォワードされます。Recovery Managerは、この増分更新バックアップをリストアし、REDOログから変更を適用できます。この場合、最後に適用されたレベル1の増分バックアップのSCNで作成されたデータファイルのバックアップをリストアする場合と同じ結果になります。


注意:

RECOVER COPYコマンドを毎日実行すると、イメージ・コピーは継続的に更新されるため、1日を超えるリカバリ期間を満たすことができません。増分更新バックアップ機能は、高速のメディア・リカバリを実現するための最適な方法です。 


増分更新バックアップ: 基本例

増分更新バックアップ計画で使用する増分バックアップを作成するには、BACKUP ... FOR RECOVER OF COPY WITH TAG形式のBACKUPコマンドを使用します。このコマンドについては、増分更新バックアップ計画を実装するサンプル・スクリプトのコンテキストを参照してください。

増分更新バックアップに基づいた計画を実装するには、例8-9のスクリプトを定期的に実行することのみが必要となります。

例8-9    基本的な増分更新スクリプト

RUN
{
  RECOVER COPY OF DATABASE 
    WITH TAG 'incr_update';
  BACKUP 
    INCREMENTAL LEVEL 1
    FOR RECOVER OF COPY WITH TAG 'incr_update'
    DATABASE;
}

このスクリプトおよび計画を理解するには、データファイルのコピーまたは増分バックアップが存在しない場合の、使用されている2つのコマンドの影響について理解する必要があります。次の2つの点に注意してください。

次の表に、スクリプトの影響を示します。列には、スクリプトを最初に実行した場合の影響、スクリプトを2回目に実行した場合の影響、スクリプトを3回目およびそれ以降に実行した場合の影響が示されています。

表8-2    スクリプトを複数回実行した場合の影響 
コマンド  1回目  2回目  3回目以降 

RECOVER 

増分バックアップまたはデータファイルのコピーが存在しないため、コマンドによってメッセージが生成されます(エラーは生成されません)。つまり、コマンドによる影響はありません。 

データファイルのコピーは存在しますが、そのコピーのリカバリに使用するレベル1の増分バックアップは存在しません。つまり、RECOVERコマンドによる影響はありません。 

前回の実行によって、データファイルのコピーおよびレベル1の増分バックアップが存在しています。レベル1の増分バックアップがデータファイルのコピーに適用され、そのコピーがレベル1の増分バックアップのチェックポイントSCNまで戻されます。 

BACKUP 

レベル0のイメージ・コピー・バックアップが存在しないため、指定したタグが含まれている、データファイルのイメージ・コピー・バックアップがコマンドによってディスクに作成されます。つまり、スクリプトによって、増分更新のサイクルを開始するために必要なイメージ・コピーが作成されます。

注意: スクリプトによってDEVICE TYPE sbtが設定される場合は、最初の実行によって、テープ上ではなくディスク上にコピーが作成されます。後続の実行では、テープ上にレベル1の増分バックアップが作成されます。 

コマンドによって、前日のブロック変更が含まれているレベル1の増分バックアップが作成されます。 

コマンドによって、前日のブロック変更が含まれているレベル1の増分バックアップが作成されます。 

例8-9の動作については、次の点にも注意してください。

実際には、例8-9のスクリプトは、毎日日が変わった後(可能なかぎり午前0時)に実行されるようにスケジュールします。スクリプトの3回目の実行後は、次のファイルをPoint-in-Timeリカバリで使用できるようになります。

スクリプトを実行した後の24時間のいずれかの時点で、データベースのリストアおよびリカバリが必要になった場合は、増分更新されたデータファイルのコピーからデータファイルをリストアできます。これによって、必要なSCNに達するまで、レベル1の最新の増分バックアップおよびREDOログから変更を適用できます。最大24時間分の適用するREDOがあるため、Point-in-Timeリカバリにかかる時間は制限されます。

参照:

Oracle Enterprise ManagerでのOracle推奨バックアップ計画の使用方法については、『Oracle Database 2日でデータベース管理者』を参照してください。 

増分更新バックアップ: 高度な例

例8-9の基本スクリプトを拡張すると、24時間を超える期間を高速でリカバリできます。例8-10に、RECOVERコマンドでリカバリ可能期間の開始時間を指定して、7日間保持する方法を示します。

例8-10    高度な増分更新スクリプト

RUN
{
  RECOVER COPY OF DATABASE 
    WITH TAG 'incr_update' 
    UNTIL TIME 'SYSDATE - 7';
  BACKUP
    INCREMENTAL LEVEL 1 
    FOR RECOVER OF COPY WITH TAG 'incr_update'
    DATABASE;
}

次の表に、スクリプトの影響を示します。列には、スクリプトを最初に実行した場合の影響、スクリプトを2から7回目に実行した場合の影響、スクリプトをそれ以降に実行した場合の影響が示されています。

表8-3    スクリプトを複数回実行した場合の影響 
  1回目  2から7回目  8回目以降 

RECOVERコマンド 

リカバリするバックアップが存在しないため、何も実行されません。 

UNTIL TIME SYSDATE-7は将来のある時点を指定しているため、何も実行されません。 

7日前に作成されたレベル1の増分バックアップが既存のデータベース・コピーに適用されます。 

BACKUPコマンド 

レベル0のコピーが存在しないため、レベル0の増分コピーが作成されます。 

前日のブロック変更が含まれているレベル1の増分バックアップが作成されます。 

前日以降の変更が含まれている増分バックアップが作成されます。 

例8-9の基本スクリプトと同様に、データファイルのコピーのSCNと現在の間の任意の時点に高速でリカバリできます。Recovery Managerは、増分バックアップのブロック変更およびREDOログの個々の変更の両方を使用できます。レベル1の日次増分バックアップがあるため、1日分を超えるREDOを適用する必要はありません。

参照:

RECOVERコマンドについては、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。 

ブロック・チェンジ・トラッキングを使用した、増分バックアップのパフォーマンスの向上

増分バックアップのブロック・チェンジ・トラッキング機能を使用すると、データファイルごとに変更されたブロックを記録することによってバックアップのパフォーマンスが向上します。

ブロック・チェンジ・トラッキング

プライマリ・データベースまたはスタンバイ・データベースでブロック・チェンジ・トラッキングが有効になっている場合、Recovery Managerは、ブロック・チェンジ・トラッキング・ファイルを使用して、増分バックアップ用に変更されたブロックを識別します。この小さなビットマップ・ファイルを読み取り、変更されたブロックを確認することによって、バックアップしているデータファイルのすべてのブロックのスキャンを回避します。

ブロック・チェンジ・トラッキングは、デフォルトでは無効になっています。ただし、バックアップ中にデータファイル全体をスキャンする必要がなくなるというメリットは無視できません。バックアップを実行してから次のバックアップを実行するまでの間に変更されたデータ・ブロックが小量の場合は特にです。バックアップ計画に増分バックアップが含まれている場合は、ブロック・チェンジ・トラッキングを有効にすることをお薦めします。ブロック・チェンジ・トラッキングによって、増分バックアップの実行に使用されるコマンドが変更されることはありません。通常、初期構成後にチェンジ・トラッキング・ファイル自体にメンテナンスを行う必要はほとんどありません。

ブロック・チェンジ・トラッキング・ファイルの領域管理

チェンジ・トラッキング・ファイルには、バックアップ間のデータファイルの変更をマークするビットマップが保持されます。データベースでは、各バックアップの前にビットマップの切替えが実行されます。Oracle Databaseでは、最新の8つのバックアップに対応するブロック・チェンジ・データを保持するためにチェンジ・トラッキング・ファイルの領域が自動的に管理されます。最大8つのビットマップに達すると、最新のビットマップは現行の変更を追跡するビットマップによって上書きされます。

最初のレベル0の増分バックアップでは、データベース全体がスキャンされます。それ以降の増分バックアップでは、ブロック・チェンジ・トラッキング・ファイルを使用して、最後のバックアップ以降に変更されたとマークされているブロックのみがスキャンされます。増分バックアップは、ブロック・チェンジ・トラッキング・ファイル内の最も古いビットマップの開始後に作成された親ビットマップに基づいている場合にのみ最適化できます。

増分バックアップ計画を作成する場合は、ビットマップ数の制限(8)を考慮してください。たとえば、レベル0のデータベース・バックアップを作成した後で7つの差分増分バックアップを作成すると、ブロック・チェンジ・トラッキング・ファイルには8つのビットマップが含まれます。次にレベル1の累積増分バックアップを作成すると、レベル0の親バックアップに対応するビットマップが現行の変更を追跡するビットマップで上書きされるため、Recovery Managerはバックアップを最適化できません。

ブロック・チェンジ・トラッキング・ファイルの場所

データベース全体に対して、1つのブロック・チェンジ・トラッキング・ファイルが作成されます。デフォルトでは、チェンジ・トラッキング・ファイルは、DB_CREATE_FILE_DEST初期化パラメータで指定された出力先にOracle管理ファイルとして作成されます。また、ブロック・チェンジ・トラッキング・ファイルは、選択した場所に格納することによってその名前を指定することもできます。ブロック・チェンジ・トラッキング・ファイルにRAWデバイス(ファイル・システムを持たないディスク)を使用できますが、デバイスは十分に大きい必要があります。


注意:

Oracle RAC環境では、チェンジ・トラッキング・ファイルは、クラスタ内のすべてのノードからアクセスできる共有ストレージに格納する必要があります。 


Recovery Managerでは、チェンジ・トラッキング・ファイルのバックアップおよびリカバリはサポートされていません。データベースは、チェンジ・トラッキング・ファイルが無効であると判断した場合、チェンジ・トラッキング・ファイルを再設定します。データベース全体またはサブセットをリストアおよびリカバリする場合、データベースは、ブロック・チェンジ・トラッキング・ファイルを消去し、変更の追跡を再度開始します。レベル0の増分バックアックを作成した後の次の増分バックアップでは、チェンジ・トラッキング・データを使用できます。

ブロック・チェンジ・トラッキング・ファイルのサイズ

ブロック・チェンジ・トラッキング・ファイルのサイズは、データベースのサイズおよびREDOの有効になっているスレッドの数に比例します。ブロック・チェンジ・トラッキング・ファイルのサイズは、データベースの変更に応じて増減します。このサイズは、データベースの更新頻度とは関係ありません。

通常、ブロック・チェンジ・トラッキングに必要な領域は、追跡するデータ・ブロックのサイズの約1/30,000です。この見積りが示すサイズよりファイルが大きくなる場合の要因を次に示します。

ブロック・チェンジ・トラッキングの有効化および無効化

ブロック・チェンジ・トラッキングは、データベースがオープンまたはマウントされている場合に有効にできます。この項では、ブロック・チェンジ・トラッキングをOracle管理ファイルとしてデータベース領域に作成することを想定しています。データベース領域とは、データファイル、制御ファイル、オンラインREDOログ・ファイルなどのアクティブなデータベース・ファイルをデータベースが保持する場所です。データベースおよびフラッシュ・リカバリ領域については、「フラッシュ・リカバリ領域の概要」を参照してください。

ブロック・チェンジ・トラッキングを有効にする手順
  1. SQL*Plusを起動し、管理者権限でターゲット・データベースに接続します。

  2. DB_CREATE_FILE_DEST初期化パラメータが設定されていることを確認します。

    SHOW PARAMETER DB_CREATE_FILE_DEST
    
    

    このパラメータが設定されていない状態でデータベースがオープンされている場合は、次の形式のALTER SYSTEM文を使用してこのパラメータを設定できます。

    ALTER SYSTEM SET 
      DB_CREATE_FILE_DEST = '/disk1/bct/'
      SCOPE=BOTH SID='*';
    
    
  3. ブロック・チェンジ・トラッキングを有効にします。

    次のALTER DATABASE文を実行します。

    ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;
    
    

    また、次の形式のSQL文を使用して、自分で選択した場所にチェンジ・トラッキング・ファイルを作成することもできます。

    ALTER DATABASE ENABLE BLOCK CHANGE TRACKING 
      USING FILE '/mydir/rman_change_track.f' REUSE;
    
    

    REUSEオプションは、Oracle Databaseに、指定した名前を持つ既存のブロック・チェンジ・トラッキング・ファイルを上書きするように指示します。

ブロック・チェンジ・トラッキングの無効化

この項では、ブロック・チェンジ・トラッキング機能が現在有効になっていると想定しています。ブロック・チェンジ・トラッキングを無効にすると、データベースはオペレーティング・システムからブロック・チェンジ・トラッキング・ファイルを削除します。

ブロック・チェンジ・トラッキングを無効にする手順
  1. SQL*Plusを起動し、管理者権限でターゲット・データベースに接続します。

  2. ターゲット・データベースがマウントまたはオープンされていることを確認します。

  3. ブロック・チェンジ・トラッキングを無効にします。

    次のALTER DATABASE文を実行します。

    ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;
    

チェンジ・トラッキングが有効かどうかの確認

V$BLOCK_CHANGE_TRACKINGビューを問い合せて、チェンジ・トラッキングが有効になっているかどうかを確認できます。有効になっている場合は、ブロック・チェンジ・トラッキング・ファイルのファイル名も確認できます。

チェンジ・トラッキングが有効かどうかを確認する方法

ブロック・チェンジ・トラッキング・ファイルの場所の変更

チェンジ・トラッキング・ファイルを移動するには、ALTER DATABASE RENAME FILE文を使用します。データベースはマウントされている必要があります。この文は、新しい場所を参照するように制御ファイルを更新し、チェンジ・トラッキング・ファイルの内容を保持します。データベースを停止できない場合は、ブロック・チェンジ・トラッキングを無効にしてから有効にすることができます。この場合、既存のブロック・チェンジ・トラッキング・ファイルの内容は消失します。

チェンジ・トラッキング・ファイルの場所を変更する手順
  1. SQL*Plusを起動し、ターゲット・データベースに接続します。

  2. 必要に応じて、チェンジ・トラッキング・ファイルの現在の名前を確認します。

    SQL> SELECT FILENAME FROM V$BLOCK_CHANGE_TRACKING;
    
    
  3. 可能な場合は、データベースを停止します。たとえば、次のように入力します。

    SQL> SHUTDOWN IMMEDIATE
    
    

    データベースを停止する場合は、次の手順にスキップします。データベースを停止しない場合は、次のSQL文を実行し、残りの手順をすべてスキップします。

    SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;
    SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE 'new_location';
    
    

    この場合、ブロック・チェンジ・トラッキング・ファイルの内容は消失します。次回レベル0の増分バックアップを完了するまで、Recovery Managerはファイル全体をスキャンする必要があります。

  4. ホスト・オペレーティング・システムのコマンドを使用して、チェンジ・トラッキング・ファイルを新しい場所に移動します。

  5. データベースをマウントして、より多くの領域がある場所にチェンジ・トラッキング・ファイルを移動します。たとえば、次のように入力します。

    ALTER DATABASE RENAME FILE
       '/disk1/bct/RDBMS/changetracking/o1_mf_2f71np5j_.chg' TO 
       '/disk2/bct/RDBMS/changetracking/o1_mf_2f71np5j_.chg';
    
    

    この文は、内容を保持した状態でチェンジ・トラッキング・ファイルの場所を変更します。

  6. データベースをオープンします。

    SQL> ALTER DATABASE OPEN;
    

    参照:

    ALTER DATABASE文およびALTER SYSTEM文については、『Oracle Database SQL言語リファレンス』を参照してください。 

長期格納用のデータベース・バックアップの作成

この項では、長期格納用のバックアップを作成する場合の基本的な概念およびタスクについて説明します。

アーカイブ・バックアップの目的

BACKUP ... KEEPを使用すると、バックアップの保存方針から除外される包括的なバックアップを作成できます。データベースのリストアおよびリカバリに必要なすべてのファイルが単一のディスクまたはテープにバックアップされるため、このバックアップは包括的になります。また、KEEPオプションは、保存方針からのバックアップの除外を永続的または指定した期間行うように指定します。BACKUP ... KEEPで作成されるバックアップの一般名はアーカイブ・バックアップです。

「データの保持」で説明されているように、バックアップおよびリカバリ計画の目的の1つは、データを保存することです。BACKUP ... KEEPを使用すると、保存方針に指定された期間より長くデータベースのバックアップを保持できます。たとえば、規定の要件を満たすために毎年元旦にデータベースをバックアップして、メディアをオフサイトに格納することができます。アーカイブ・バックアップを作成して数年後に、このバックアップをリストアおよびリカバリしてバックアップ時のデータの状態を問い合せることができます。

アーカイブ・バックアップのもう1つの目的は、テストのためにリストアするバックアップを作成し、後で削除することです。たとえば、データベースをバックアップしてテスト環境でリストアした後、テスト・データベースが操作可能になったらアーカイブ・バックアップを破棄することができます。また、これと関連して、別のユーザーまたはホストへの転送完了後に削除可能な自己完結型のバックアップを作成するという目的もあります。たとえば、別のユーザーが、レポートまたはテスト用にデータベースのコピーを必要とする場合があります。

アーカイブ・バックアップの基本的な概念

BACKUPコマンドでKEEPオプションを使用すると、バックアップを保存方針から除外できます。また、CHANGEコマンドでKEEPおよびNOKEEPオプションを使用すると、既存のバックアップのステータスを変更できます。KEEP属性を使用したバックアップは、他のすべてのバックアップと同様にリカバリできる有効なバックアップです。

KEEP UNTIL TIME句を使用してアーカイブ・バックアップの終了日を指定したり、FOREVERでバックアップを永続的に保持するように指定できます。UNTILを指定した場合、構成されている保存方針に関係なく、UNTILで指定した時間が経過すると、バックアップはRecovery Managerによって不要とマークされます。たとえば、KEEP UNTIL TIME '01-JAN-08'と指定すると、1月1日の深夜0時を1秒経過した後にバックアップが不要とマークされます。UNTIL TIMEを午後9時に指定すると、午後9時1分にバックアップが不要とマークされます。

BACKUPコマンドにKEEPを指定すると、Recovery Managerは複数のバックアップ・セットを生成します。BACKUP ... KEEPコマンドには次の特性があります。

長期格納用のアーカイブ・バックアップの作成

この項では、アーカイブを目的としたデータベース・バックアップの作成方法について説明します。通常、アーカイブ・バックアップはテープに作成します。データ保護を目的としたバックアップは、アクセス可能な状態のままで再利用されるテープのセットに格納されることが多いため、アーカイブ・バックアップ用にテープのセットを取っておくことをお薦めします。この特別なテープのセットにアーカイブ・バックアップを書き込んだ後、オフサイトの保管場所に格納することができます。

この項では、アーカイブ・バックアップを作成する場合の標準的な方法について説明します。手順を変更すると、動的に更新できるストアド・スクリプトまたはシェル・スクリプトを作成できます。このスクリプトの実行時に、リストア・ポイントの名前、バックアップ形式などを動的に設定できます。

参照:

 

アーカイブ・バックアップの作成

次の例では、QUARTERLYというバックアップのタグを使用して長期用のアーカイブ・バックアップを作成し、長期格納用に確保されているOracle Secure Backupの専用のテープ・ファミリに割り当てます。この例では、次の点に注意してください。

長期用のアーカイブ・バックアップを作成する手順
  1. Recovery Managerを起動し、ターゲット・データベースおよびリカバリ・カタログに接続します。

    ターゲット・データベースは、オープンされている状態でもマウントされている状態でもかまいません。リカバリ・カタログは、KEEP FOREVERには必要ですが、その他のKEEPオプションには必要ありません。

  2. BACKUP ... KEEPを実行して、バックアップを作成します。

    次の例では、データファイルおよびアーカイブ・ログのバックアップを生成し、通常のリストア・ポイントを作成します。指定したリストア・ポイントは、存在していない必要があることに注意してください。

    ログのバックアップには、このバックアップを一貫性のある状態にリストアするためのアーカイブ・ログのみが含まれています。この新しいバックアップを一貫性のある状態するために必要な、現行のオンライン・ログにあるREDOをアーカイブするために、データベースでオンラインREDOログの切替えが実行されます。制御ファイルの自動バックアップにはリストア・ポイントのコピーが含まれているため、制御ファイルをリストアするとすぐにこのコピーを参照できます。

    RUN
    {
      ALLOCATE CHANNEL c1 
        DEVICE TYPE sbt
        PARMS 'ENV=(OB_MEDIA_FAMILY=archival_backup)';
      BACKUP DATABASE
        TAG quarterly
        KEEP FOREVER
        RESTORE POINT FY06Q4;
    }
    
    

    次の例では、バックアップを永続的にではなく、365日間保存します。1年が経過すると、バックアップ保存方針に関係なく、バックアップは不要とマークされます。

    RUN
    {
      ALLOCATE CHANNEL c1 DEVICE TYPE sbt
        PARMS 'ENV=(OB_MEDIA_FAMILY=archival_backup)';
      BACKUP DATABASE
        TAG quarterly
        KEEP UNTIL TIME 'SYSDATE+365'
        RESTORE POINT FY06Q4;
    }
    

    参照:

    リストア・ポイントについては、「リストア・ポイントおよびフラッシュバック・データベース」を参照してください。 

一時的なアーカイブ・バックアップの作成

アーカイブ・バックアップの目的の1つは、テスト・データベースを作成することです。テスト・データベースの作成方法は、「長期格納用のアーカイブ・バックアップの作成」で説明されている方法と基本的に同じです。異なる点は、バックアップを、作成後すぐに削除することです。

BACKUP ... KEEP UNTILパラメータを使用すると、バックアップの一時的なステータスを指定できます。バックアップを作成後、そのバックアップを同じ日に新しいホストにリストアするとします。この場合、KEEP UNTIL TIME SYSDATE+1を指定して、1日間のみこのバックアップの保存方針を上書きするようにRecovery Managerに指示できます。1日が経過すると、構成されているバックアップ保存方針に関係なく、バックアップは不要とマークされます。

例8-11のコマンドは、タグTESTDBが含まれているアーカイブ・バックアップを一時ディスクに作成します。この例では、バックアップをリカバリする時点のラベルとなる通常のリストア・ポイントを作成します。バックアップ中にデータベースがオープンしている場合、Recovery ManagerはアーカイブREDOログのみをバックアップします。アーカイブ・ログは、オフライン・バックアップでは必要ないためバックアップされません。

例8-11    一時的なアーカイブ・バックアップの作成

BACKUP DATABASE
  FORMAT '/disk1/oraclebck/%U' 
  TAG TESTDB 
  KEEP UNTIL TIME 'SYSDATE+1' 
  RESTORE POINT TESTDB06;

アーカイブ・バックアップをリストアする場合は、DUPLICATEコマンドを使用する方法をお薦めします。詳細は、「DUPLICATEを使用したアーカイブ・バックアップのリストア」を参照してください。

Recovery Managerバックアップのバックアップ

この項では、バックアップ・セットおよびイメージ・コピーのバックアップ方法について説明します。

バックアップのバックアップ

BACKUP BACKUPSETコマンドを使用すると、他のバックアップ・ジョブによって作成されたバックアップ・セットをバックアップできます。また、BACKUP RECOVERY AREAを使用すると、現行および以前のすべてのフラッシュ・リカバリ領域に作成されたリカバリ・ファイルをバックアップすることもできます。リカバリ・ファイルとは、全体および増分バックアップ・セット、制御ファイルの自動バックアップ、データファイルのコピーおよびアーカイブREDOログのことです。BACKUP RECOVERY AREAでは、SBTバックアップのみがサポートされています。

これらのコマンドは、特に次の場合に有効です。

また、BACKUP COPY OFコマンドを使用すると、データファイル、制御ファイルおよびアーカイブREDOログのイメージ・コピーをバックアップすることもできます。このコマンドでは、バックアップ・セットまたはイメージ・コピーのいずれかを出力できるため、イメージ・コピーからバックアップ・セットを生成できます。ディスク上にイメージ・コピーとして作成されたデータベースのバックアップをテープにバックアップするには、この形式のバックアップを使用します。

バックアップ・セットの複数のコピー

BACKUP BACKUPSETを実行すると、バックアップ・セットにバックアップ・ピースの追加コピーが作成されますが、新しいバックアップ・セットは作成されません。つまり、BACKUP BACKUPSETは、BACKUPDUPLEXまたはMAXCOPIESオプションを使用する場合と類似しています(「バックアップ・セットの多重化」を参照)。他の形式のBACKUPコマンドによって生成されたバックアップ・セットのコピーが個別のバックアップ・セットにならないのと同様に、BACKUP BACKUPSETによって作成されたバックアップ・セットの追加コピーも新しいバックアップ・セットにはなりません。

バックアップをバックアップする場合のバックアップの保存方針の影響

冗長性に基づいたバックアップ保存方針では、バックアップ・セットはバックアップの1つのインスタンスとみなされます。これは、バックアップ・セットを構成するバックアップ・ピースの複数のコピーが存在する場合(バックアップ・セットがディスクからテープにバックアップされている場合など)でも該当します。

リカバリ期間に基づく保存方針では、バックアップ・セットのすべてのコピーが不要とみなされるか、またはすべてが不要でないとみなされます。これは、LISTおよびREPORTコマンドの出力を参照すると最も簡単に理解できます。

バックアップをバックアップする場合のバックアップの保存方針の影響を表示する手順
  1. データファイルをバックアップします。

    この例では、データファイル5をバックアップします。

    BACKUP AS BACKUPSET DATAFILE 5;
    
    
  2. 前の手順で作成したデータファイルのバックアップに対してLISTコマンドを実行します。

    たとえば、次のコマンドを実行します(出力例も示します)。

    LIST BACKUP OF DATAFILE 5 SUMMARY;
     
    List of Backups
    ===============
    Key     TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
    ------- -- -- - ----------- --------------- ------- ------- ---------- ---
    18      B  F  A DISK        04-AUG-07       1       1       NO         
    TAG20070804T160 134
    
    
  3. 前の手順のバックアップ・セット・キーを使用して、バックアップ・セットをバックアップします。

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

    BACKUP BACKUPSET 18;
    
    
  4. 手順2で実行したLISTコマンドを再度実行します。

    たとえば、次のコマンドを実行します(出力例も示します)。

    LIST BACKUP OF DATAFILE 5 SUMMARY;
     
    List of Backups
    ===============
    Key     TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
    ------- -- -- - ----------- --------------- ------- ------- ---------- ---
    18      B  F  A DISK        04-AUG-07       1       2       NO         
    TAG20070804T160 134
    
    

    この出力に表示されているバックアップ・セットは1つのみですが、これでバックアップ・セットのコピーは2つ存在しています。

  5. レポートを生成して、冗長性に基づくバックアップの保存方針でのこれらのコピーの影響を確認します。

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

    REPORT OBSOLETE REDUNDANCY 1;
     
    

    バックアップ・セットの両方のコピーのset_stampset_countの値が同じであるため、いずれのコピーも不要とはみなされません。

  6. レポートを生成して、リカバリ期間に基づくバックアップの保存方針でのこれらのコピーの影響を確認します。

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

    REPORT OBSOLETE RECOVERY WINDOW 1 DAY;
     
    

    現在の時点と他のバックアップの可用性に関して、バックアップ・セットのいずれのコピーも不要であるとはみなされず、またこのバックアップ・セットのCHECKPOINT_CHANGE#に基づくとはみなされません。

    参照:

     

Recovery Managerを使用したバックアップ・セットのバックアップ

この項では、BACKUP BACKUPSETコマンドを使用して、バックアップ・セットをディスクからテープにコピーする方法について説明します。この手順では、デフォルト・デバイスとしてSBTデバイスがすでに構成されていることを想定しています。

ディスクからテープにバックアップ・セットをバックアップする手順
  1. 使用可能なバックアップ・セットのサブセットをバックアップする場合は、LIST BACKUPSETコマンドを実行してそれらの主キーを取得します。

    次の例では、バックアップ・セットをサマリー形式で表示します。

    RMAN> LIST BACKUPSET SUMMARY;
    
    List of Backups
    ===============
    Key TY LV S Device Type Completion Time #Pieces #Copies Comp Tag
    --- -- -- - ----------- --------------- ------- ------- ---- ---
    1   B  F  A DISK        28-MAY-07       1       1       NO   TAG20070528T132432
    2   B  F  A DISK        29-MAY-07       1       1       NO   TAG20070529T132433
    3   B  F  A DISK        30-MAY-07       1       1       NO   TAG20070530T132434
    
    

    次の例では、バックアップ・セット3を詳細形式で表示します。

    RMAN> LIST BACKUPSET 3;
    
    List of Backup Sets
    ===================
    
    BS Key  Type LV Size       Device Type Elapsed Time Completion Time
    ------- ---- -- ---------- ----------- ------------ ---------------
    3       Full    8.33M      DISK        00:00:01     30-MAY-07
            BP Key: 3   Status: AVAILABLE  Compressed: NO  Tag: TAG20070530T132434
            Piece Name: /disk1/oracle/dbs/c-35764265-20070530-02
      Control File Included: Ckp SCN: 397221       Ckp time: 30-MAY-07
      SPFILE Included: Modification time: 30-MAY-07
      SPFILE db_unique_name: PROD
    
    
  2. BACKUP BACKUPSETコマンドを実行します。

    次の例では、ディスクのすべてのバックアップ・セットをテープにバックアップし、入力のディスク・バックアップを削除します。

    BACKUP BACKUPSET ALL
      DELETE INPUT;
    
    

    次の例では、主キー1および2を含むバックアップ・セットのみをテープにバックアップし、入力ディスクのバックアップを削除します。

    BACKUP BACKUPSET 1,2
      DELETE INPUT;
    
    
  3. 必要に応じて、LISTコマンドを実行して、バックアップ・セットおよびバックアップ・ピースのリストを表示します。

    BACKUP BACKUPSETによって作成されたバックアップ・ピースのコピーを含むすべてのコピーが出力に含まれます。

Recovery Managerを使用したイメージ・コピーのバックアップ

この項では、BACKUPコマンドを使用してイメージ・コピーをテープにバックアップする方法について説明します。デフォルト・デバイスとしてSBTデバイスが構成されていることを想定しています。

データファイルの複数のコピーを含むイメージ・コピーをバックアップする場合は、バックアップにタグを指定すると、入力イメージ・コピーの識別が簡単になります。データファイルのすべてのイメージ・コピーにタグが指定されます。イメージ・コピーが新しいイメージ・コピーとしてバックアップされると、デフォルトで、そのイメージ・コピーのタグが継承されます。

ディスクからテープにイメージ・コピーをバックアップする手順
  1. BACKUP ... COPY OFまたはBACKUP DATAFILECOPYコマンドを発行します。

    次の例では、タグDBCopyが含まれているデータファイルのコピーをバックアップします。

    BACKUP DATAFILE COPY FROM TAG monDBCopy;
    
    

    次の例では、データベースの最新イメージ・コピーをテープにバックアップし、QUARTERLY_BACKUPというタグを割り当て、入力のディスク・バックアップを削除します。

    BACKUP DEVICE TYPE sbt
      TAG "quarterly_backup"
      COPY OF DATABASE 
      DELETE INPUT;
    
    
  2. 必要に応じて、LISTコマンドを実行して、バックアップ・セットのリストを表示します。BACKUP BACKUPSETによって作成されたバックアップ・ピースのコピーを含むすべてのコピーが出力に含まれます。


戻る 次へ
Oracle
Copyright © 2003, 2008, Oracle Corporation.

All Rights Reserved.
目次
目次
索引
索引