10gリリース2（10.2）
B19193-02
 目次 |
 索引 |
| Oracle Database バックアップおよびリカバリ基礎 10gリリース2（10.2） B19193-02 |
|
この章では、Recovery Managerを使用した最も一般的なバックアップ・タスクを実行する方法およびバックアップ計画を実装する方法について説明します。
この章では、次の項目について説明します。
ディスクのみのバックアップ計画およびディスクとテープを使用するバックアップ計画の詳細な例およびスクリプトは、付録A「Recovery Managerベースのディスクおよびテープのバックアップ計画の例」を参照してください。これらの計画は、データベースの更新アクティビティのレベル、バックアップに割り当てられるディスク領域およびデータベースのリカバリ可能性の要件によって分類されます。それぞれの計画に対して、初期設定、および毎日または毎週のバックアップに関するRecovery Managerコマンドが提供されています。増分更新バックアップやフラッシュ・リカバリ領域の使用など、Recovery Managerでサポートされる様々な形式のバックアップについてよく理解した後、独自のバックアップ計画を立案するために付録Aに示す例を参照してください。
この章で説明する多くのバックアップ方法は、Oracle Enterprise Managerで提供されるバックアップ計画にも使用されます（『Oracle Database 2日でデータベース管理者』を参照）。
リストア・ポイントおよびOracle Flashback Databaseでは、ここで示すバックアップ機能を補完する機能が提供されます。これらの機能を使用すると、不要な変更を後で元に戻すことができるように、データベースを事前に設定しておくことができます。バックアップおよびリカバリ計画にこれらを組み込むことをお薦めします。これらの機能の詳細は、第4章「Recovery Managerを使用したデータベースのバックアップ」を参照してください。
注意:
データベースの全体または一部をバックアップするには、Recovery Managerクライアント内からBACKUPコマンドを実行します。
Recovery Managerは、データベースの構成設定とチャネル、Recovery Managerリポジトリの以前のバックアップの記録、および制御ファイルのデータベース構造の記録を使用して、BACKUPコマンドに対応して実行する特定の手順の効率的なセットを決定し、その手順を実行します。
多くの場合、データベースがバックアップ計画に従って構成されていれば、次のような単純なコマンドを使用してデータベース全体のRecovery Managerバックアップを実行できます。
RMAN> BACKUP DATABASE;
Recovery ManagerのBACKUPコマンドでは、次のファイルのバックアップがサポートされています。
データベースの操作には、その他のファイル（ネットワーク構成ファイル、パスワード・ファイル、Oracleホームの内容など）も必要ですが、これらのファイルは、Recovery Managerではバックアップできません。同様に、Oracleの一部の機能（外部表など）には、情報を格納するために、データ・ファイル、制御ファイルおよびREDOログ以外のファイルが必要な場合があります。Recovery Managerでは、これらのファイルをバックアップできません。リストにないファイルについては、Recovery Manager以外の方法でバックアップします。
Recovery Managerバックアップは、イメージ・コピーまたはバックアップ・セットのいずれかの形式で格納できます。
イメージ・コピーとは、データベース・ファイルをビット単位で正確に複製したものであり、オペレーティング・システムのコマンドで作成されたコピーと同じです。（ただし、オペレーティング・システム・レベルのコマンドを使用して作成されたファイルのコピーとは異なり、Recovery Managerで作成されたイメージ・コピーは、Recovery Managerリポジトリに記録されます。）
イメージ・コピーのバックアップは、ディスク上に作成できます。Recovery Managerでは、データ・ファイル、データ・ファイルのコピー、制御ファイル、制御ファイルのコピー、アーカイブREDOログおよびバックアップ・ピースのイメージ・コピーが作成されます。Recovery Managerは、BACKUPコマンドでAS COPYオプションを使用した場合に、イメージ・コピーを作成します。
Recovery Managerでは、バックアップ・セットという論理構造にバックアップ情報を格納することもできます。バックアップ・セットには、データ・ファイル、アーカイブREDOログ、制御ファイルまたはSPFILEのデータが格納されます。（データ・ファイルおよびアーカイブ・ログを同じバックアップ・セットに格納することはできません。）既存のバックアップ・セットを別のバックアップ・セットにバックアップすることもできます。
バックアップ・セットは、Recovery Manager固有の形式のファイルであるバックアップ・ピースというファイルで構成されます。デフォルトでは、バックアップ・セットは、1つのバックアップ・ピースで構成されます。たとえば、10個のデータ・ファイルを、単一のバックアップ・ピースで構成される単一のバックアップ・セットにバックアップできます（つまり、1つのバックアップ・ピースが出力として作成され、バックアップ・ピースを含む単一のファイルで構成されるバックアップ・セット、およびバックアップ・ピースとそのバックアップ・ピースを含むバックアップ・セットが、Recovery Managerリポジトリに記録されます）。ファイルを複数のバックアップ・セットに分割することはできません。
バックアップ・セットの作成や、バックアップ・セットからのリカバリを実行できるのは、Recovery Managerのみです。複数のファイルが同じバックアップ・セットにバックアップされている場合、それらのファイルは同時に読み取られ、そのデータは多重化されます。
バックアップ・セットは、Recovery Managerがテープなどのメディア・マネージャ・デバイス上で実行できる唯一のバックアップ・タイプです。バックアップ・セットは、ディスク上に作成することもできます。Recovery Managerでは、デフォルトでディスクおよびテープの両方に、バックアップがバックアップ・セットとして作成されます。
データ・ファイルをバックアップ・セットにバックアップする場合、Recovery Managerでは、現在データが含まれていないデータ・ファイル・ブロックをいくつかスキップして、バックアップ・セットのサイズを小さくし、バックアップ・セットの作成に必要な時間を短縮することができます。この動作は、未使用ブロックの圧縮と呼ばれ、バックアップ・セットによるデータ・ファイルのバックアップは、通常、イメージ・コピーのバックアップより小さくなり、書込み時間も短縮されます。この動作は、Recovery Managerがバックアップ・ピースにデータ・ファイルを書き込む際の基本的な方法であり、無効にすることはできません。未使用ブロックをスキップする方法とタイミングについては、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
Recovery Managerは、バックアップ・セットのバイナリ圧縮もサポートします。この圧縮では、バックアップ・セットの内容はディスクに書き込まれる前に、データ・ファイルおよびアーカイブ・ログ・ファイルの圧縮用にチューニングされた圧縮アルゴリズムを使用して圧縮されます。バイナリ圧縮の使用方法については、「Recovery Managerによるバックアップでの圧縮バックアップ・セットの使用」を参照してください。
Recovery Managerによるデータ・ファイルのバックアップは、データ・ファイルの全体バックアップまたは増分バックアップのいずれかにすることができます。
データ・ファイルの全体バックアップは、ファイル内のすべての使用済データ・ブロックを含むバックアップです。データ・ファイルの全体バックアップをイメージ・コピーとして作成する場合は、ファイルの内容全体がそのまま再作成されます。（データ・ファイルをバックアップ・セットにバックアップする場合は、未使用ブロックをスキップすることができます。「バックアップ・セット」を参照してください。）
データ・ファイルの増分バックアップでは、特定の時点（通常は前回の増分バックアップの時点）以降に変更されたデータ・ファイル内のブロックのイメージが取得されます。増分バックアップは、常にバックアップ・セットとして格納されます。その結果、データ・ファイル内のすべてのブロックを変更しないかぎり、バックアップ・セットはデータ・ファイルの全体バックアップより小さくなります。Recovery Managerが作成できるのはデータ・ファイルの増分バックアップのみで、アーカイブREDOログ・ファイルなどのファイルの増分バックアップは作成できません。
メディア・リカバリ時には、Recovery Managerは増分バックアップのブロック・イメージを使用し、変更されたブロックを、そのブロックが作成されたときのSCNの内容に対して1回の手順で更新します。増分バックアップがない場合は、すべての変更をアーカイブREDOログから1つずつ適用する必要があります。したがって、増分バックアップを使用するリカバリは、変更をアーカイブREDOログから1つずつ適用するよりも短時間で行うことができます。また、増分バックアップではNOLOGGING操作によって行われ、REDOログには記録されないデータ・ブロックに対する変更も取得されます。このため、メディア・リカバリ時に増分バックアップが使用できる場合、Recovery Managerではアーカイブ・ログのかわりに増分バックアップが常に使用されます。
Recovery Managerコマンドに対して最小限の必須オプションのみを指定した場合（BACKUP DATABASEなど）、Recovery Managerによって、バックアップ先デバイス、バックアップ出力の場所、およびバックアップ用のタグが、構成済の環境とRecovery Managerの組込み済のデフォルト値に基づいて自動的に決定されます。ただし、BACKUPに引数を指定して、これらのデフォルト値と構成済の設定を上書きするこができます。この項では、一般的な次の項目を説明します。
BACKUPコマンドではDEVICE TYPE句を使用して、バックアップ先をディスクにするか、SBTデバイスにするかを指定します。次に例を示します。
BACKUP DATABASE DEVICE TYPE DISK;
DEVICE TYPE句を指定しないでBACKUPを使用すると、バックアップは構成済のデフォルトのデバイス（DISKまたはsbt）に格納されます。このデバイスは、CONFIGURE DEFAULT DEVICE TYPEを使用して設定されます。詳細は、「バックアップ用のデフォルト・デバイス・タイプの構成」を参照してください。
前述のとおり、Recovery Managerでは、バックアップをイメージ・コピーまたはバックアップ・セットとしてディスクに作成できます。デフォルトの出力タイプの設定については、「ディスク・バックアップ用のデフォルト・バックアップ・タイプの構成」を参照してください。このデフォルト値は、AS COPY句またはAS BACKUPSET句をBACKUPコマンドに指定して上書きできます。データをイメージ・コピーとしてディスクにバックアップするには、BACKUP AS COPYを使用します。
BACKUP AS COPY DEVICE TYPE DISK DATABASE;
データをバックアップ・セットにバックアップするには、BACKUP AS BACKUPSET句を使用します。バックアップ・セットは構成済のデフォルトのデバイスに作成したり、バックアップ・セットをディスクまたはテープに明示的に指定することもできます。次に例を示します。
BACKUP AS BACKUPSET DATABASE; BACKUP AS BACKUPSET DEVICE TYPE DISK DATABASE; BACKUP AS BACKUPSET DEVICE TYPE SBT DATABASE;
Recovery Managerでは、優先順位の順序で示されている次のルール・セットに基づいて、バックアップからの出力に一意のファイル名が生成されます。
BACKUPコマンドでFORMAT句を指定して、出力を特定の場所に指定できます。次に例を示します。
BACKUP DATABASE FORMAT="/tmp/backup_%U";
この場合のバックアップは、生成された一意のファイル名が付けられ/tmp/backups/に格納されます。%Uは必須で、ファイル名のこの位置で一意の文字列を生成するために使用されます。
また、次のようにFORMAT句を使用して、バックアップ先としてASMディスク・グループを指定することもできます。
RMAN> BACKUP DATABASE FORMAT '+dgroup1'; # sets an ASM disk group
この場合、%Uは必須ではありません。これは、ASMが必要に応じて一意のファイル名を生成するためです。
FORMAT設定がバックアップで使用される特定のチャネル用に構成されている場合、生成されるファイル名の制御はこの設定によって行われます。
FORMAT設定がバックアップで使用されるデバイス・タイプ用に構成されている場合、生成されるファイル名の制御はこの設定によって行われます。
Recovery Managerで作成されたすべてのバックアップには、将来Recovery Managerコマンドで使用可能なバックアップであることを示す方法として、タグと呼ばれる識別子が添付されます。
BACKUPコマンドを使用する場合、特定のコマンドを使用して、作成したバックアップに割り当てるタグを指定できます。特定の時間に作成したバックアップを識別するためにこのタグを使用できます。たとえば、2003_year_endのように使用します。また、長期にわたって作成される一連のバックアップに対し、1つのタグを繰り返して使用することもできます。たとえば、毎週作成する一連の増分バックアップに、weekly_incrementalなどのタグをラベル付けできます。
実際に、タグを使用して、増分バックアップ計画など、単一の計画の一部として作成された一連のバックアップであることを区別する場合があります。BACKUPコマンドの様々な形式を使用して、タグとバックアップを関連付けることができます。また、多くのRESTOREおよびRECOVERコマンドでは、タグを指定してRESTOREまたはRECOVER操作で使用するバックアップを制限できます。
タグを指定しないでBACKUPコマンドを使用すると、Recovery Managerによって一意のタグが生成され、このコマンドで作成されたバックップに割り当てられます。
バックアップのグループを識別するためにタグを指定するには、BACKUPコマンドのTAG句を使用します。次に例を示します。
RMAN> BACKUP DATABASE TAG = 'weekly_backup'; # gives the backup a tag identifier
BACKUPコマンドでTAG句を使用してタグをバックアップに割り当てていない場合は、Recovery Managerによって自動的にタグが生成され、バックアップに割り当てられます。
バックアップ・セットを作成するBACKUPコマンドを使用すると、AS COMPRESSED BACKUPSETオプションを指定することで、Recovery Managerでサポートされているバックアップ・セットのバイナリ圧縮を利用できます。その結果、バックアップ・セットは、Oracleデータベース・ファイルの効果的な圧縮用に最適化されたアルゴリズムを使用して圧縮されます。Recovery Managerの統合された圧縮を使用すると、リカバリ時に他の解凍手順は必要ありません。
Recovery Managerのバイナリ圧縮の使用での主なデメリットは、バックアップ時およびリストア時のパフォーマンスのオーバーヘッドです。圧縮バックアップ・セットを作成する際のパフォーマンスはCPUに依存します。複数のCPUを使用している場合は、複数のCPUでジョブを実行するために並列度を増やすことができるため、パフォーマンスを改善できます。
次の例では、データベース全体とアーカイブ・ログを、構成済のデフォルトのバックアップ先（ディスクまたはテープ）にバックアップし、圧縮バックアップ・セットを作成します。
BACKUP AS COMPRESSED BACKUPSET DATABASE PLUS ARCHIVELOG;
次の例では、バイナリ圧縮を使用して、複数のデータ・ファイルをデフォルトのデバイスにバックアップします。
BACKUP AS COMPRESSED BACKUPSET DATAFILE 1,2,4;
圧縮バックアップ・セットを作成すると、バックアップ時およびリストア時に非常に大きい余分なCPUオーバーヘッドが発生します。これによって、バックアップの処理速度が低下する場合があります。ただし、次のような状況では、パフォーマンスが低下しても有効な場合があります。
バックアップ・セットのバイナリ圧縮を使用する場合のパフォーマンスについては、『Oracle Databaseバックアップおよびリカバリ・リファレンス』にあるBACKUPコマンドのAS COMPRESSED BACKUPSETオプションの説明を参照してください。
この項では次の項目を取り上げます。
データベースの一貫性バックアップは、データベースに一貫性がある状態、つまりSHUTDOWN NORMAL、SHUTDOWN IMMEDIATEまたはSHUTDOWN TRANSACTIONALを使用して正常に停止された後で行われるバックアップです。正常に停止した時点で、REDOログのすべての変更はデータ・ファイルに適用されています。データベースをマウントし、この時点のバックアップを作成すると、将来、メディア・リカバリを実行しないで、このバックアップからデータベースをリストアしてオープンすることができます。
データベースが正常に停止されていないときに作成されたバックアップは、すべて非一貫性バックアップです。非一貫性バックアップからデータベースをリストアする場合、Oracleでは、データベースをオープンする前に、メディア・リカバリを実行し、REDOログ内の保留中の更新情報を適用する必要があります。
データベースがARCHIVELOGモードで実行されていて、アーカイブREDOログ・ファイルとデータ・ファイルがバックアップされているかぎり、非一貫性バックアップは、適切なバックアップおよびリカバリ計画の基礎となります。非一貫性バックアップには優れた可用性があるため、ほとんどのデータベースのバックアップ計画で重要な役割を果たします。たとえば、データベースをオープンさせたまま作成するバックアップは非一貫性バックアップです。
データベース全体のバックアップは、データベースをマウントまたはオープンして実行できます。データベース全体のバックアップを実行するには、Recovery ManagerプロンプトでBACKUP DATABASEコマンドを実行します。このコマンドの最も単純な形式ではパラメータは必要ありません。次に例を示します。
RMAN> BACKUP DATABASE;
次に、デフォルトの宛先にデータベース全体のバックアップを取るプロシージャの例を示します。
RMAN> BACKUP DATABASE; # uses automatic channels to make backup RMAN> SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT'; # switches logs and archives all logs
バックアップ直後にログをアーカイブすることで、このバックアップでアーカイブ・ログの完全なセットができます。これによって、このバックアップのリストア後にメディア・リカバリを実行できます。
BACKUP TABLESPACEコマンドを使用すると、個々の表領域をバックアップできます。このコマンドは、データベースがマウントまたはオープンされているときに使用できます。
表領域をバックアップする方法
Recovery Managerを起動した後、Recovery ManagerプロンプトでBACKUP TABLESPACEコマンドを実行します。次の例では、10MBを超えるバックアップ・セットがないことを指定するMAXSETSIZEパラメータを使用して、usersおよびtools表領域をテープにバックアップします。
BACKUP DEVICE TYPE sbt MAXSETSIZE = 10M TABLESPACE users, tools;
表領域名が、内部的にデータ・ファイルのリストに変換されます。
データ・ファイルおよびデータ・ファイルのコピーは、データベースがマウントまたはオープンされているときにバックアップできます。
Recovery Managerをターゲット・データベースに接続し、BACKUP DATAFILEコマンドを使用して、個々のデータ・ファイルをバックアップします。データ・ファイルは、名前または番号で指定できます。
次の例では、sbtチャネルを使用して、データ・ファイル1〜4および/tmp/system01.dbfに格納されているデータ・ファイルのコピーをテープにバックアップします。
BACKUP DEVICE TYPE sbt DATAFILE 1,2,3,4 DATAFILECOPY '/tmp/system01.dbf';
CONFIGURE CONTROLFILE AUTOBACKUPがONの場合、Recovery Managerは、現行の制御ファイルおよびSPFILEを別々の自動バックアップ・ピースに書き込みます。それ以外の場合、これらのファイルは、データ・ファイル1を含むバックアップ・セットに自動的に含められます。
BACKUP DATAFILECOPYコマンドを使用して、データ・ファイルのコピーをバックアップします。データ・ファイルのコピーは、ディスク上にのみ存在します。
データ・ファイルのコピーをバックアップする方法
ターゲット・データベースに接続し、Recovery ManagerプロンプトでBACKUP DATAFILECOPYコマンドを実行します。次の例では、データ・ファイル/tmp/system01.dbfをテープにバックアップします。
BACKUP DEVICE TYPE sbt DATAFILECOPY '/tmp/system01.dbf';
制御ファイルは、データベースがマウントまたはオープンされているときにバックアップできます。Recovery Managerは、スナップショット制御ファイルを使用して、読取り一貫性のバージョンを保証します。CONFIGURE CONTROLFILE AUTOBACKUPがON（デフォルトではOFF）の場合、Recovery Managerは、バックアップするたび、およびデータベースの構造を変更するたびに、制御ファイルおよびサーバー・パラメータ・ファイルを自動的にバックアップします。制御ファイルの自動バックアップには、以前のバックアップに関するメタデータが含まれます。このメタデータは、障害時リカバリに重要です。
自動バックアップ機能が設定されてない場合は、次のいずれかの方法で、制御ファイルを手動でバックアップする必要があります。
BACKUP CURRENT CONTROLFILEを実行する
BACKUPコマンドのINCLUDE CURRENT CONTROLFILEオプションを使用して、制御ファイルのバックアップをいずれかのバックアップに含める
1をバックアップする制御ファイルの手動バックアップは、制御ファイルの自動バックアップとは異なります。手動バックアップでは、現行のRecovery ManagerセッションでバックアップするRecovery Managerリポジトリのデータのみが制御ファイルのバックアップに含められ、手動でバックアップされた制御ファイルを自動的にリストアすることはできません。
現行の制御ファイルをバックアップに含めるには、バックアップ・オブジェクトを指定した後、INCLUDE CURRENT CONTROLFILEオプションを指定します。次の例では、デフォルトの構成済チャネルはsbtデバイスに設定されています。このコマンドによって、表領域usersがテープにバックアップされ、現行の制御ファイルがバックアップに含められます。
BACKUP DEVICE TYPE sbt TABLESPACE users INCLUDE CURRENT CONTROLFILE;
自動バックアップ機能が有効な場合、Recovery Managerは、BACKUP TABLESPACEコマンドが完了した後、制御ファイルの自動バックアップも作成します。これによって、制御ファイルの自動バックアップには、作成されたバックアップの記録も含まれます。
Recovery Managerを起動した後、BACKUP CURRENT CONTROLFILEコマンドを実行します。次の例では、現行の制御ファイルをデフォルトのディスク・デバイスにバックアップし、タグを割り当てます。
BACKUP CURRENT CONTROLFILE TAG = mondaypmbackup;
この例では、制御ファイルの自動バックアップ機能が有効な場合、Recovery Managerが2つの制御ファイルのバックアップを作成します。1つは明示的な制御ファイルのバックアップ（BACKUP CURRENT CONTROLFILE）で、もう1つは制御ファイルとサーバー・パラメータ・ファイルの自動バックアップです。
次の例では、BACKUP CONTROLFILECOPYコマンドを使用して、制御ファイルのバックアップを作成します。
制御ファイルのコピーをバックアップする方法
Recovery Managerを起動した後、Recovery ManagerプロンプトでBACKUP CONTROLFILECOPYコマンドを実行します。次の例では、制御ファイルのコピー'/tmp/control01.ctl'をディスクに作成した後、テープにバックアップします。
BACKUP AS COPY CURRENT CONTROLFILE FORMAT '/tmp/control01.ctl'; BACKUP DEVICE TYPE sbt CONTROLFILECOPY '/tmp/control01.ctl';
「Recovery Managerを使用した制御ファイルのバックアップ」で説明したとおり、Recovery Managerは、特定の状況下で、現行のサーバー・パラメータ・ファイルを自動的にバックアップします。BACKUP SPFILEコマンドは、パラメータ・ファイルを明示的にバックアップします。次に例を示します。
BACKUP DEVICE TYPE sbt SPFILE;
バックアップされるSPFILEは、インスタンスが使用中のファイルです。インスタンスがクライアント側の初期化パラメータ・ファイルを使用して起動されている場合、このコマンドを使用しても、Recovery Managerは何もバックアップしません。
アーカイブREDOログは、メディア・リカバリを正常に実行するために重要です。アーカイブREDOログのバックアップは、定期的に行います。 ログは、BACKUP ARCHIVELOGを使用してバックアップできます。または、データ・ファイルおよび制御ファイルのバックアップ時に、BACKUP ... PLUS ARCHIVELOGを指定してバックアップできます。
アーカイブREDOログをバックアップするには、Recovery ManagerプロンプトでBACKUP ARCHIVELOGコマンドを実行します。次の例では、構成済ディスクまたはsbtチャネルを使用して、すべてのアーカイブREDOログのログ順序番号ごとに1つのコピーをバックアップします。
BACKUP ARCHIVELOG ALL;
REDOログが複数の宛先にアーカイブされており、Recovery Managerを使用してアーカイブREDOログをバックアップする場合でも、Recovery Managerは、アーカイブREDOログ・ファイルの1つのコピーのみを選択して、バックアップ・セットに含めます。（同じログ順序番号を持つログは同一のものであるため、複数のコピーを含める必要はありません。）
また、次に示すように、アーカイブREDOログを、時間、SCNまたはログ順序番号で範囲指定することもできます。
BACKUP ARCHIVELOG FROM TIME 'SYSDATE-30' UNTIL TIME 'SYSDATE-7';
最新のログを含むアーカイブREDOログのバックアップを取る（つまり、UNTILまたはSEQUENCEオプションを指定せずにBACKUP ... ARCHIVELOGコマンドを実行する）場合、データベースがオープンされていると、Recovery Managerは、バックアップを開始する前に、現行のオンラインREDOログ・グループ、およびコマンド発行時に最新だったREDOログ・グループを含む、アーカイブされていないすべての最新オンラインREDOログを切り替えます。これによって、バックアップには、コマンドの実行前に生成されたすべてのREDOが確実に含められます。
BACKUP ARCHIVELOGコマンドにDELETE INPUTまたはDELETE ALL INPUT句を指定すると、バックアップ後にアーカイブ・ログを削除できるため、手動でアーカイブREDOログを削除する必要がなくなります。DELETE INPUTを指定すると、Recovery Managerは、バックアップ・セット用に選択されたアーカイブREDOログの特定のコピーのみを削除します。 DELETE ALL INPUTを指定すると、Recovery Managerは、バックアップされた各アーカイブREDOログ・ファイルをログのすべてのアーカイブ先から削除します。
たとえば、次のコマンドを実行して、/arc_dest1、/arc_dest2および/arc_dest3にアーカイブするとします。
BACKUP DEVICE TYPE sbt ARCHIVELOG ALL DELETE ALL INPUT;
この場合、Recovery Managerは、これらのディレクトリで各ログ順序番号の1つのコピーのみをバックアップした後、アーカイブ先からバックアップ済のログのすべてのコピーを削除します。DELETE ALL INPUTではなくDELETE INPUTを指定した場合、Recovery Managerは、バックアップ済の特定のアーカイブREDOログ・ファイルのみを削除します（たとえば、/arc_dest1のアーカイブREDOログ・ファイルがバックアップのソースとして使用されたファイルの場合、そのアーカイブ先のアーカイブREDOログ・ファイルのみ削除し、/arc_dest2および/arc_dest3の内容はそのまま残します）。
BACKUP ARCHIVELOG ALLまたはBACKUP ARCHIVELOG LIKE '...'を発行した場合、バックアップするアーカイブREDOログ・ファイルが存在しなくても、Recovery Managerはエラーを表示しません。
BACKUP ... PLUS ARCHIVELOG句を使用すると、アーカイブREDOログを他のファイルのバックアップに追加できます。 BACKUP ... PLUS ARCHIVELOGを追加すると、Recovery Managerは次の操作を実行します。
ALTER SYSTEM ARCHIVE LOG CURRENTコマンドを実行します。
BACKUP ARCHIVELOG ALLを実行します。バックアップの最適化が有効な場合、Recovery Managerは、特定のデバイスにバックアップ済のログをスキップします。
BACKUPコマンドに指定された残りのファイルをバックアップします。
ALTER SYSTEM ARCHIVE LOG CURRENTコマンドを実行します。
これによって、コマンドの実行時に取られたデータ・ファイルのバックアップを、一貫性のある状態にリカバリ可能であることが保証されます。
BACKUP ... PLUS ARCHIVELOGを使用してアーカイブREDOログをバックアップする方法
Recovery Managerを起動した後、Recovery ManagerプロンプトでBACKUP ... PLUS ARCHIVELOGコマンドを実行します。次の例では、データベースおよびすべてのアーカイブ・ログをバックアップします。
BACKUP DEVICE TYPE sbt DATABASE PLUS ARCHIVELOG;
Recovery Managerによる増分バックアップでは、以前の特定のバックアップ以降に変更されたデータ・ファイル・ブロックのみがバックアップされます。データベース、個々の表領域またはデータ・ファイルの増分バックアップを作成できます。
増分バックアップは、以前のバックアップ以降に変更されたデータ・ブロックのみバックアップすることを目的としています。
増分バックアップは、主に次の場合に作成します。
NOLOGGINGオプションを使用して作成されたオブジェクトへの変更をリカバリ可能にする場合。たとえば、ダイレクト・ロード・インサートではREDOログ・エントリは作成されないため、それらの変更はメディア・リカバリでは再作成できません。ただし、データ・ブロックは変更されるため、増分バックアップによって取得されます。
NOARCHIVELOGデータベースのバックアップ・サイズを削減する場合。データベース全体のバックアップを毎回作成するかわりに、増分バックアップを作成できます。全体バックアップと同様に、データベースがARCHIVELOGモードでオープンされている場合に増分バックアップを作成できます。データベースがNOARCHIVELOGモードの場合は、一貫性のある状態で停止した後にのみ、増分バックアップを作成できます。
ディスクに増分バックアップを作成した後、BACKUP AS BACKUPSETを使用して、作成されたバックアップ・セットをメディア・マネージャにバックアップする方法もあります。通常、増分バックアップは全体バックアップより小さく、テープに移動するまで格納に必要な領域を抑えることができます。また、ディスク上の増分バックアップをテープにバックアップすると、増分バックアップのすべてのブロックがテープにコピーされるため、テープ・ストリーミングを維持できる可能性が高くなります。Recovery Managerではデータ・ファイル内で変更されたブロックの特定に必要な時間があるため、遅延することはありません。
データ・ファイルの各データ・ブロックには、システム変更番号（SCN）が含まれます。これは、ブロックが最後に変更されたときのSCNです。増分バックアップ中、Recovery Managerは、入力ファイルの各データ・ブロックのSCNを読み取り、親増分バックアップのチェックポイントSCNと比較します。入力データ・ブロックのSCNが親のチェックポイントSCN以上である場合、Recovery Managerはそのブロックをコピーします。
ブロック・チェンジ・トラッキング機能を有効にすると、Recovery Managerは、チェンジ・トラッキング・ファイルを参照して、データ・ファイルの内容全体をスキャンしなくても、データ・ファイル内の変更されたブロックを識別できます。ブロック・チェンジ・トラッキング機能を有効にすると、パフォーマンスは向上しますが、増分バックアップの取り方や使用方法は変更されません。ブロック・チェンジ・トラッキングについては、「増分バックアップのパフォーマンスの改善: チェンジ・トラッキング」を参照してください。
増分バックアップは、レベル0またはレベル1のいずれかです。レベル0の増分バックアップは、データを含むすべてのブロックをコピーし、全体バックアップと同様に、データ・ファイルをバックアップ・セットにバックアップします。レベル0の増分バックアップは、後続の増分バックアップの基になります。レベル0の増分バックアップと全体バックアップの違いは、全体バックアップは増分計画には含まれないということです。
レベル1の増分バックアップは、次のいずれかです。
増分バックアップは、デフォルトでは差分バックアップです。
バックアップ・ファイルのサイズは、変更されたブロックの数と増分バックアップのレベルに依存します。
レベル1の差分バックアップでは、Recovery Managerは、レベルが0か1かにかかわらず、最新の累積または差分増分バックアップが行われてた後、変更されたすべてのブロックをバックアップします。Recovery Managerは、レベル1の最新のバックアップを判断し、そのバックアップ後に変更されたすべてのブロックをバックアップします。レベル1のバックアップが有効でない場合、Recovery Managerは、レベル0のバックアップ以降に変更されたすべてのブロックをコピーします。
次のコマンドを実行すると、データベースのレベル1の差分増分バックアップが実行されます。
RMAN> BACKUP INCREMENTAL LEVEL 1 DATABASE;
レベル0のバックアップが有効でない場合、互換性モードの設定によって動作が異なります。互換性が>=10.0.0の場合、Recovery Managerは、ファイル作成後に変更されたすべてのブロックをコピーし、その結果をレベル1のバックアップとして格納します。つまり、増分バックアップが取られたときのSCNは、ファイル固有のSCNになります。互換性が<10.0.0の場合、以前のリリースでの動作との一貫性が保持されるように、Recovery Managerは、バックアップ時点でのファイルの内容のレベル0のバックアップを生成します。
図4-1には、次のことが示されています。
レベル0の増分バックアップが実行され、このデータベースで使用されていたすべてのブロックがバックアップされます。
月曜日〜土曜日は、レベル1の差分増分バックアップが毎日実行され、レベル1または0の最新の増分バックアップが実行された後、変更されたすべてのブロックがバックアップされます。つまり、月曜日のバックアップでは、日曜日のレベル0のバックアップの後変更されたブロックがコピーされ、火曜日のバックアップでは、月曜日のレベル1のバックアップの後変更されたブロックがコピーされます。
レベル1の累積バックアップでは、Recovery Managerは、レベル0の最新の増分バックアップが行われた後、使用されたすべてのブロックをバックアップします。特定のレベルからの増分バックアップが1回のみ必要なため、累積増分バックアップによって、リストアに必要な作業が削減されます。ただし、同じレベルの以前のバックアップで行われた操作が重複するため、累積バックアップで必要な領域と時間は、累積バックアップと比べて多くなります。
次のコマンドを実行すると、データベースのレベル1の累積増分バックアップが実行されます。
BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE; # blocks changed since level 0図4-2 累積増分バックアップ
図4-2には、次のことが示されています。
レベル0の増分バックアップが実行され、このデータベースで使用されていたすべてのブロックがバックアップされます。
レベル1の累積増分バックアップで、レベル0の最新のバックアップが行われた後、変更されたすべてのブロックがコピーされます。レベル0の最新のバックアップは日曜日に作成されているため、月曜日〜土曜日に毎日行われるレベル1のバックアップでは、日曜日のバックアップの後、変更されたすべてのブロックがバックアップされます。
許容可能な平均リカバリ時間（MTTR）に従って、バックアップ方法を選択します。たとえば、全体バックアップまたはレベル0のバックアップを毎月実行する、レベル1の累積バックアップを毎週実行する、レベル1の差分バックアップを毎日実行する、という3レベルのバックアップを実装できます。この方法では、完全リカバリのために、毎日REDOを適用するだけで十分です。
全体バックアップまたはレベル0のバックアップの実行頻度を決定する場合、50%以上のデータが変更されるたびに、レベル0の新しいバックアップを実行することをお薦めします。データベースへの変更の割合を予測できる場合は、増分バックアップのサイズを調べて、レベル0の新しいバックアップの実行時期を判断します。次の問合せでは、50%以上のブロックがバックアップされたデータ・ファイルごとに、バックアップ・セットに書き込まれたブロックの数が表示されます。
SELECT FILE#, INCREMENTAL_LEVEL, COMPLETION_TIME, BLOCKS, DATAFILE_BLOCKS FROM V$BACKUP_DATAFILE WHERE INCREMENTAL_LEVEL > 0 AND BLOCKS / DATAFILE_BLOCKS > .5 ORDER BY COMPLETION_TIME;
差分バックアップまたは累積バックアップのブロック数と、レベル0のベース・バックアップを比較します。たとえば、レベル1の累積バックアップを作成する場合に、レベル1の最新のバックアップのサイズがレベル0のベース・バックアップの約半分であれば、レベル0の新しいバックアップを実行します。
Recovery Managerを起動した後、Recovery ManagerプロンプトでBACKUP INCREMENTALコマンドを実行します。次の例では、データベースのレベル0の増分バックアップを作成します。
BACKUP INCREMENTAL LEVEL 0 DATABASE;
次の例では、SYSTEM表領域およびデータ・ファイルtools01.dbfのレベル1の差分バックアップを作成します。このバックアップでは、レベル1またはレベル0の最新のバックアップの後、変更されたデータ・ブロックのみバックアップします。
BACKUP INCREMENTAL LEVEL 1 TABLESPACE SYSTEM DATAFILE 'ora_home/oradata/trgt/tools01.dbf';
次の例では、表領域usersのレベル1の累積バックアップを作成し、レベル0の最新のバックアップの後、変更されたすべてのブロックをバックアップします。
BACKUP INCREMENTAL LEVEL = 1 CUMULATIVE TABLESPACE users;
Oracleの増分更新バックアップ機能を使用すると、イメージ・コピーのバックアップと同じリカバリ機能が提供され、データ・ファイルのイメージ・コピーの全体バックアップを実行する際のオーバーヘッドを回避できます。
バックアップ計画の開始時に、Recovery Managerはデータ・ファイルのイメージ・コピーのバックアップを作成します。その後、（毎日など）定期的にレベル1の増分バックアップを取り、イメージ・コピーのバックアップに適用して、レベル1の増分バックアップが作成された時点にロールフォワードします。
データベースのリストアおよびリカバリ中に、Recovery Managerはこの増分更新コピーからリストアし、その後でREDOログから変更を適用できます。この結果は、最後に適用されたレベル1の増分バックアップのSCNで作成された全体バックアップからデータベースをリストアするのと同じです。
増分更新バックアップに基づくバックアップ計画によって、データベースのメディア・リカバリに必要な時間を最小限にできます。たとえば、スクリプトを実行してこの計画を毎日実装すると、リカバリ時に適用するREDOは、1日に1回で済みます。
増分更新バックアップ計画で使用する増分バックアップを作成するには、BACKUPコマンドのBACKUP... FOR RECOVER OF COPY WITH TAG形式を使用する必要があります。コマンドの動作方法は、この計画を実装するサンプル・スクリプトで最もよく理解できます。
定期的にこのスクリプトを実行することが、増分更新バックアップに基づく計画を実装するために必要なすべてのことです。
RUN { RECOVER COPY OF DATABASE WITH TAG 'incr_update'; BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_update' DATABASE; }
ただし、このスクリプトで使用する構文では、計画の動作が明確に理解できません。スクリプトと計画を理解するには、データ・ファイルのコピーまたは増分バックアップが存在しない場合の次の2つのコマンドの影響を理解する必要があります。
BACKUP INCREMENTAL LEVEL 1... FOR RECOVER OF COPY WITH TAG...コマンドでは、レベル1の増分バックアップが実際には作成されない場合があります。特定のデータ・ファイルのレベル0のイメージ・コピーのバックアップが存在しない場合、このコマンドを実行すると、レベル1のバックアップが作成されるかわりに、指定したタグを使用して、ディスク上にデータ・ファイルのイメージ・コピーのバックアップが作成されます。 したがって、スクリプトをはじめて実行すると、増分更新のサイクル開始に必要なデータ・ファイルのイメージ・コピーが作成されます。 2回目以降の実行では、データ・ファイルのレベル1の増分バックアップが作成されます。
RECOVER COPY OF DATABASE WITH TAG...コマンドを使用すると、Recovery Managerは、指定したタグを持つデータ・ファイルのコピーのセットにレベル1の使用可能なすべての増分バックアップを適用します。 増分バックアップまたはデータ・ファイルのコピーが存在しない場合、このコマンドでメッセージは表示されますが、エラーは生成されません。
データ・ファイルのコピーやレベル1の増分バックアップが存在しないため、スクリプトをはじめて実行したときは、何も処理が行われません。
2回目に実行したときは、データ・ファイルのコピーが存在（最初のBACKUPコマンドで作成されている）しますが、レベル1の増分バックアップが存在しないため、何も処理が行われません。
3回目以降の実行では、それまでの実行でデータ・ファイルのコピーとレベル1の増分バックアップが作成されているため、レベル1の増分バックアップはデータ・ファイルのコピーに適用され、データ・ファイルのコピーは、レベル1の増分バックアップのチェックポイントSCNの状態までリカバリされます。
この例について、次のことにも注意してください。
イメージ・コピーに適用するレベル1の増分バックアップは、そのイメージ・コピーのデータ・ファイルのチェックポイントSCNとレベル1の使用可能な増分バックアップに基づいて選択されます。（リカバリされるイメージ・コピーで使用されるタグは、そのレベルの増分バックアップの選択基準にはなりません。）
実際に、サンプル・スクリプトを1日に1回（可能であれば深夜）に実行するようにスケジュールするとします。通常、夜（つまり、最初の2日後の夜）、スクリプトの完了後に次のファイルのPoint-in-Timeリカバリが可能になります。
その後の24時間以内に、このバックアップからデータベースをリストアおよびリカバリ（完全リカバリまたはPoint-in-Timeリカバリのいずれか）する必要がある場合は、増分バックアップしたデータ・ファイルのコピーからデータ・ファイルをリストアした後、必要なSCNに到達するまで、レベル1の最新の増分バックアップおよびREDOログから変更を適用できます。REDOを適用するには、最大24時間かかります。これによって、Point-in-Timeリカバリにかかる時間が制限されます。
24時間を超える期間に高速リカバリの提供するために、基本的な例を拡張できます。 RECOVER COPY... WITH TAGを変更して、リカバリ可能期間を開始する過去のある時間に、データ・ファイルのコピーを不完全リカバリします。次に、7日間の保持方法の例を示します。
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; }
スクリプトは、次の処理を実行します。
RECOVER COPY... UNTIL TIME文は何も処理を実行しません。BACKUP INCREMENTAL... FOR RECOVER OF COPY文は、レベル0の増分コピーを作成します。
TIME 'SYSDATE - 7'がまだ未来であるため、RECOVER COPY... UNTIL TIME文は何も処理を実行しません。 BACKUP INCREMENTAL... FOR RECOVER OF COPY文は、前日のブロック変更を含むレベル1の差分増分バックアップを作成します。
RECOVER COPY... UNTIL TIME文は、7日目以前のレベル1の増分をデータベースのコピーに適用します。 BACKUP INCREMENTAL... FOR RECOVER OF COPY文は、前日の変更を含む増分バックアップを作成します。
基本的な例と同様に、増分バックアップからのブロック変更およびREDOログからの個々の変更を使用して、データ・ファイルのコピーのSCNと現在の間の任意の時点に高速リカバリが可能です。レベル1の増分が毎日あるため、1日を超えるREDOを適用する必要はありません。
Recovery Managerの増分バックアップ用のチェンジ・トラッキング機能を使用すると、チェンジ・トラッキング・ファイル内の各データ・ファイルで変更されたブロックを記録することにより、増分バックアップのパフォーマンスが改善されます。チェンジ・トラッキングが有効な場合、Recovery Managerは、チェンジ・トラッキング・ファイルを使用して、増分バックアップで変更されたブロックを識別します。これによって、データ・ファイル内のすべてのブロックをスキャンする必要がなくなります。
チェンジ・トラッキングを有効にした直後は、チェンジ・トラッキング・ファイルにブロックの状態が反映されていないため、レベル0の最初の増分バックアップでは、データ・ファイル全体をスキャンする必要があります。このレベル0の増分バックアップを親として使用するその後の増分バックアップでは、チェンジ・トラッキング・ファイルを使用します。
変更のないチェンジ・トラッキングを使用する場合は、通常、増分バックアップの実行に使用したコマンドおよびそのチェンジ・トラッキング・ファイル自体、初期構成をわずかにメンテナンスする必要があります。
チェンジ・トラッキングは、通常の動作時に、データベースに対するパフォーマンスのオーバーヘッドをわずかに発生させるため、デフォルトでは無効になっています。ただし、バックアップとバックアップの間で行われた変更がごく少量の場合などは、バックアップ時にデータベース全体のスキャンを実行しないことは大きな利点です。バックアップ計画に増分バックアップが含まれている場合は、チェンジ・トラッキングを有効にしてください。
データベース全体に対して、1つのチェンジ・トラッキング・ファイルが作成されます。 デフォルトでは、チェンジ・トラッキング・ファイルは、Oracleが管理するファイルとしてDB_CREATE_FILE_DESTに作成されます。ブロック・チェンジ・トラッキング・ファイルの名前を指定して、任意の場所に格納することもできます。
最新の増分バックアップ8つのうちのいずれかを親として使用して増分バックアップを取ることができるように、Oracleには十分なチェンジ・トラッキング情報が保存されています。
Recovery Managerでは、チェンジ・トラッキング・ファイル自体のバックアップおよびリカバリはサポートされていませんが、データベースの全体または一部をリストアまたはリカバリする必要がある場合、リカバリによって、自動的にチェンジ・トラッキングに対する処理が実行されます。リストアおよびリカバリ後、チェンジ・トラッキング・ファイルは内容が消去され、再度、ブロック変更の記録を開始します。リカバリの直後に実行される増分バックアップでは、チェンジ・トラッキング・データを使用できます。
データベースがオープンまたはマウントされている場合は、チェンジ・トラッキングを有効または無効にできます。チェンジ・トラッキングの設定を変更するには、SQL*Plusを使用して、管理者権限でターゲット・データベースに接続する必要があります。
データベース領域にチェンジ・トラッキング・ファイルを格納するには、ターゲット・データベースでDB_CREATE_FILE_DESTを設定する必要があります。その後、次のSQL文を発行して、チェンジ・トラッキングを有効にします。
SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;
また、次のSQL文を使用して、任意の場所にチェンジ・トラッキング・ファイルを作成することもできます。
SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '/mydir/rman_change_track.f' REUSE;
REUSEオプションは、指定した名前で既存のファイルを上書きすることを示します。
チェンジ・トラッキングを無効にするには、次のSQL文を使用します。
SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;
チェンジ・トラッキング・ファイルがデータベース領域に格納されていた場合は、チェンジ・トラッキングを無効にするときに削除されます。
SQL*PlusからV$BLOCK_CHANGE_TRACKING.STATUSを問い合せて、チェンジ・トラッキングが有効かどうかを判断できます。有効な場合は、V$BLOCK_CHANGE_TRACKING.FILENAMEを問い合せて、ファイル名を表示できます。
チェンジ・トラッキング・ファイルを移動する場合は、ALTER DATABASE RENAME FILEコマンドを実行して、新しい場所を参照するように制御ファイルを更新します。この項では、チェンジ・トラッキング・ファイルの内容を保持したまま、場所を移動する方法について説明します。
チェンジ・トラッキング・ファイルを移動する方法
SELECT filename FROM V$BLOCK_CHANGE_TRACKING;
SHUTDOWN IMMEDIATE
ALTER DATABASE RENAME FILE
'ora_home/dbs/change_trk.f' TO '/new_disk/change_trk.f';
ALTER DATABASE OPEN;
データベースを停止できない場合は、チェンジ・トラッキングを無効にした後、新しい場所で再度有効にする必要があります。次に例を示します。
ALTER DATABASE DISABLE BLOCK CHANGE TRACKING; ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE 'new_location';
この方法で移動すると、チェンジ・トラッキング・ファイルの内容が失われます。次回、レベル0の増分バックアップを完了するまで、Recovery Managerはファイル全体をスキャンする必要があります。
チェンジ・トラッキング・ファイルのサイズは、データベースのサイズおよび有効なREDOスレッドの数に比例します。データベースの更新頻度には関連しません。通常、ブロック・チェンジ・トラッキングに必要な領域は、追跡対象のデータ・ブロックのサイズの約1/30,000です。ただし、次の2つの要因によって、ファイルがこの見積りで示すサイズより大きくなる可能性があるため注意が必要です。
BACKUPコマンドのVALIDATEオプションを使用すると、データ・ファイルが適切な場所に存在するか、およびRecovery Managerでのデータ・ファイルのバックアップの作成を妨げる物理的または論理的な破損がないかを確認できます。 BACKUP... VALIDATEを実行すると、Recovery Managerは、実際のバックアップの場合と同じように、バックアップされるファイル全体を読み取ります。ただし、実際にはバックアップ・セットやイメージ・コピーを生成しません。
バックアップの検査によって破損ブロックが検出された後、Recovery Managerは、破損を示している行を反映して、V$DATABASE_BLOCK_CORRUPTIONビューを更新します。ブロック・メディア・リカバリを使用すると、破損を修復できます。詳細は、『Oracle Databaseバックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』を参照してください。破損ブロックを修復した後、このブロックを示している行はビューから削除されます。
たとえば、次のコマンドで、すべてのデータベース・ファイルおよびアーカイブ・ログがバックアップ可能かどうかを検査できます。
BACKUP VALIDATE DATABASE ARCHIVELOG ALL;
Recvery Managerクライアントは、実際にファイルをバックアップしたときと同じ出力を表示します。Recovery Managerで検査できないファイルがあると、エラー・メッセージが表示されます。たとえば、次のように表示されます。
RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of backup command at 08/29/2002 14:33:47 ORA-19625: error identifying file /oracle/oradata/trgt/arch/archive1_6.dbf ORA-27037: unable to obtain file status SVR4 Error: 2: No such file or directory Additional information: 3
MAXCORRUPTまたはPROXYパラメータにVALIDATEオプションを使用することはできません。
様々な方法で、Recovery Managerリポジトリから情報を取得できます。
LISTおよびREPORTコマンドでは、使用可能なバックアップと、データベースをリストアおよびリカバリするためにそれをどのように使用できるかという詳細な情報が提供されます。LISTについては、「Recovery Managerバックアップ、アーカイブ・ログおよびデータベース・インカネーションの表示」を、REPORTについては、「バックアップおよびデータベース・スキーマのレポート」を参照してください。
V$DATAFILE_HEADER、V$PROCESS、V$SESSIONなど、一部のV$ビューにはリカバリ・カタログ・ビューにはない情報が含まれています。V$ビューについては『Oracle Databaseリファレンス』を、RC_ビューについては『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
RESTOREコマンドではPREVIEW句がサポートされ、使用可能なバックアップ・セットを前提として、Recovery Managerがどのようにデータベースの全体または一部をリストアおよびリカバリできるかという詳細情報が提供されます。 RESTORE... PREVIEWについては、「リストア操作で使用するバックアップの確認: RESTORE PREVIEW」を参照してください。
Recovery Managerによる制御の外部でバックアップが操作されている場合（たとえば、いくつかのディスクベースのバックアップが削除されている場合や、テープ・バックアップが一時的に使用不可になっていたり、完全に消失している場合）、
注意:
CHANGE、CROSSCHECK、DELETEなどのコマンドを使用して、使用可能な実際のバックアップ・セットを反映するように、バックアップのRecovery Managerリポジトリ・レコードを更新します（第8章「Recovery Managerのメンテナンス作業」を参照）。これを行わないと、前述のコマンドおよびビューの出力には誤りが表示され、Recovery Managerは、リポジトリが更新されるまで、データベースをリストアおよびリカバリするためのバックアップを検出できない可能性があります。
LISTコマンドは、Recovery Managerリポジトリ内の情報を使用して、バックアップ、アーカイブ・ログおよびデータベース・インカネーションのリストを表示します。LISTの出力を使用して、他のRecovery Managerコマンドとともに使用する特定のバックアップを識別できます。
この項では次の項目を取り上げます。
LISTコマンドのBY BACKUPおよびBY FILEオプションを使用し、SUMMARYおよびVERBOSEオプションのいずれかを選択して、出力方法を制御できます。
LISTコマンドは、主に使用可能なバックアップを判断することを目的としています。たとえば、次のものを表示できます。
V$BACKUP_FILESにも、バックアップの表示情報が含まれます。
デフォルトでは、Recovery Managerは、バックアップごとにバックアップを表示します。つまり、各バックアップまたはプロキシ・コピーを連続して表示した後、そのバックアップが含まれるファイルを識別します。ファイルごとにバックアップを表示することもできます。
デフォルトでは、Recovery Managerは冗長モードでバックアップを表示します。冗長モードで出力されるバックアップが多すぎる場合は、サマリー・モードで表示することもできます。
バックアップごとにバックアップを表示するには、ターゲット・データベースとリカバリ・カタログ（使用している場合）に接続してから、LIST BACKUPコマンドを実行します。listObjList句を使用して、必要なオブジェクトを指定します。たとえば、次のように入力できます。
LIST BACKUP; # lists backup sets, image copies, and proxy copies LIST BACKUPSET; # lists only backup sets and proxy copies LIST COPY; # lists only disk copies
オプションで、EXPIREDを指定して、クロスチェックでは検索されなかったバックアップを識別します。
LIST EXPIRED BACKUP;
出力を調べます（LIST出力の様々な列ヘッダーについては、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照）。LIST BACKUPの出力例を、次に示します。
List ofCHANGE,CROSSCHECK, andDELETEBackup Sets
===================
BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
7 136M DISK 00:00:20 04-NOV-03
BP Key: 7 Status: AVAILABLE Compressed: NO Tag: TAG20031104T200759
Piece Name: /oracle/work/RDBMS/backupset/2003_11_04/o1_mf_annnn_TAG20031104T200759_ztjxx3k8_.bkp
List of Archived Logs in backup set 7
Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- --------- ---------- ---------
1 1 173832 21-OCT-03 174750 21-OCT-03
1 2 174750 21-OCT-03 174755 21-OCT-03
1 3 174755 21-OCT-03 174758 21-OCT-03
1 37 533321 01-NOV-03 575472 03-NOV-03
1 38 575472 03-NOV-03 617944 04-NOV-03
1 39 617944 04-NOV-03 631495 04-NOV-03
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
8 Full 2M DISK 00:00:01 04-NOV-03
BP Key: 8 Status: AVAILABLE Compressed: NO Tag: TAG20031104T200829
Piece Name: /ade/lashdown_rdbms/oracle/dbs/c-774627068-20031104-01
Controlfile Included: Ckp SCN: 631510 Ckp time: 04-NOV-03
SPFILE Included: Modification time: 21-OCT-03
LIST COPYの出力例を、次に示します。
List of Archived Log Copies
Key Thrd Seq S Low Time Name
------- ---- ------- - --------- ----
37 1 37 A 01-NOV-03 /oracle/work/RDBMS/archivelog/2003_11_03/o1_mf_1_37_ztd4hl5d_.arc
38 1 38 A 03-NOV-03 /oracle/work/RDBMS/archivelog/2003_11_04/o1_mf_1_38_zthvg168_.arc
39 1 39 A 04-NOV-03 /oracle/work/RDBMS/archivelog/2003_11_04/o1_mf_1_39_ztjxwxwy_.arc
listObjListまたはrecordSpec句（『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照）を使用して、必要なオブジェクトを指定します。オブジェクトを指定しないと、Recovery Managerは、すべてのデータベース・ファイルとアーカイブ・ログのコピーを表示します。デフォルトでは、Recovery Managerは冗長モードでオブジェクトを表示します。複数行で多数の情報を表示します。
ファイルごとにバックアップを表示するには、Recovery Managerクライアントからターゲット・データベースとリカバリ・カタログ（使用している場合）に接続してから、BY FILEオプションで表示するオブジェクトとオプションを指定して、LISTを実行します。たとえば、次のように入力します。
LIST BACKUP BY FILE; # shows backup sets, proxy copies, and image copies LIST COPY BY FILE; # shows only disk copies
EXPIREDオプションを指定して、クロスチェックでは検索されなかったバックアップを識別することもできます。
LIST EXPIRED BACKUP BY FILE;
出力を調べます（LIST出力の様々な列ヘッダーについては、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照）。出力例は次のとおりです。
List of Datafile Backups
========================
File Key TY LV S Ckp SCN Ckp Time #Pieces #Copies Compressed Tag
---- ------- - -- - ---------- --------- ------- ------- ---------- ---
1 5 B F A 631092 04-NOV-03 1 1 YES TAG20031104T195949
2 B F A 175337 21-OCT-03 1 1 NO TAG20031021T094513
2 5 B F A 631092 04-NOV-03 1 1 YES TAG20031104T195949
2 B F A 175337 21-OCT-03 1 1 NO TAG20031021T094513
... some rows omitted
List of Archived Log Backups
============================
Thrd Seq Low SCN Low Time BS Key S #Pieces #Copies Compressed Tag
---- ------- ---------- --------- ------- - ------- ------- ---------- ---
1 1 173832 21-OCT-03 7 A 1 1 NO TAG20031104T200759
1 A 1 1 NO TAG20031021T094505
1 2 174750 21-OCT-03 7 A 1 1 NO TAG20031104T200759
1 A 1 1 NO TAG20031021T094505
... some rows omitted
1 38 575472 03-NOV-03 7 A 1 1 NO TAG20031104T200759
1 39 617944 04-NOV-03 7 A 1 1 NO TAG20031104T200759
List of Controlfile Backups
===========================
CF Ckp SCN Ckp Time BS Key S #Pieces #Copies Compressed Tag
---------- --------- ------- - ------- ------- ---------- ---
631510 04-NOV-03 8 A 1 1 NO TAG20031104T200829
631205 04-NOV-03 6 A 1 1 NO TAG20031104T200432
175380 21-OCT-03 4 A 1 1 NO TAG20031021T094639
List of SPFILE Backups
======================
Modification Time BS Key S #Pieces #Copies Compressed Tag
----------------- ------- - ------- ------- ---------- ---
21-OCT-03 8 A 1 1 NO TAG20031104T200829
21-OCT-03 6 A 1 1 NO TAG20031104T200432
デフォルトでは、LIST出力で詳細な情報が表示されますが、要約された形式で表示されるように指定することもできます。listObjectListまたはrecordSpec句を使用して、必要なオブジェクトを指定します。オブジェクトを指定しないと、LIST BACKUPは、すべてのバックアップを表示します。
ターゲット・データベースとリカバリ・カタログ（使用している場合）に接続してから、必要なオブジェクトとオプションを指定して、LIST BACKUPを実行します。次に例を示します。
LIST BACKUP SUMMARY; # lists backup sets, proxy copies, and disk copies
EXPIREDキーワードを指定して、クロスチェックでは検索されなかったバックアップを識別することもできます。
LIST EXPIRED BACKUP SUMMARY;
出力例は次のとおりです。
List of Backups
===============
Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- ---
1 B A A SBT_TAPE 21-OCT-03 1 1 NO TAG20031021T094505
2 B F A SBT_TAPE 21-OCT-03 1 1 NO TAG20031021T094513
3 B A A SBT_TAPE 21-OCT-03 1 1 NO TAG20031021T094624
4 B F A SBT_TAPE 21-OCT-03 1 1 NO TAG20031021T094639
5 B F A DISK 04-NOV-03 1 1 YES TAG20031104T195949
6 B F A DISK 04-NOV-03 1 1 NO TAG20031104T200432
7 B A A DISK 04-NOV-03 1 1 NO TAG20031104T200759
8 B F A DISK 04-NOV-03 1 1 NO TAG20031104T200829
LIST出力の様々な列ヘッダーについては、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
様々な条件を指定して、LIST出力を制限できます。
ターゲット・データベースとリカバリ・カタログ（使用している場合）に接続してから、listObjListまたはrecordSpec句を指定して、LIST COPYまたはLIST BACKUPを実行します。 たとえば、次のいずれかのコマンドを実行します。
# lists backups of all files in database LIST BACKUP OF DATABASE; # lists copy of specified datafile LIST COPY OF DATAFILE 'ora_home/oradata/trgt/system01.dbf'; # lists specified backup set LIST BACKUPSET 213; # lists datafile copy LIST DATAFILECOPY '/tmp/tools01.dbf';
maintQualifierまたはRECOVERABLE句を指定して、検索を制限することもできます。次に例を示します。
# specify a backup set by tag LIST BACKUPSET TAG 'weekly_full_db_backup'; # specify a backup or copy by device type LIST COPY OF DATAFILE 'ora_home/oradata/trgt/system01.dbf' DEVICE TYPE sbt; # specify a backup by directory or path LIST BACKUP LIKE '/tmp/%'; # specify a backup or copy by a range of completion dates LIST COPY OF DATAFILE 2 COMPLETED BETWEEN '10-DEC-2002' AND '17-DEC-2002'; # specify logs backed up at least twice to tape LIST ARCHIVELOG ALL BACKED UP 2 TIMES TO DEVICE TYPE sbt;
出力は、LISTコマンドに指定してオプションによって異なります。たとえば、次のコマンドでは、データ・ファイル1のコピーが表示されます。
RMAN> list backup of datafile 1;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
2 Full 230M SBT_TAPE 00:00:49 21-OCT-03
BP Key: 2 Status: AVAILABLE Compressed: NO Tag: TAG20031021T094513
Handle: 02f4eatc_1_1 Media: /smrdir
List of Datafiles in backup set 2
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- --------- ----
1 Full 175337 21-OCT-03 /oracle/dbs/tbs_01.f
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
5 Full 233M DISK 00:04:30 04-NOV-03
BP Key: 5 Status: AVAILABLE Compressed: NO Tag: TAG20031104T195949
Piece Name: /oracle/work/RDBMS/backupset/2003_11_04/o1_mf_nnndf_TAG20031104T195949_ztjxfvgz_.bkp
List of Datafiles in backup set 5
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- --------- ----
1 Full 631092 04-NOV-03 /ade/lashdown_rdbms/oracle/dbs/tbs_01.f
データベースに対してOPEN RESETLOGS 操作を実行するたびに、新しいデータベース・インカネーションが作成されます。 データベース・インカネーションと、それによってRecovery Managerでのデータベース・リカバリが受ける影響については、『Oracle Databaseバックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』を参照してください。
増分バックアップの実行時、Recovery Managerは、前回のインカネーションまたは現行のインカネーションからのバックアップを、後続の増分バックアップの基礎として使用できます。リストアおよびリカバリの実行時、すべてのアーカイブ・ログが使用可能なかぎり、Recovery Managerは、現行のインカネーションからのバックアップを使用するのと同様に、リストアまたはリカバリ操作で前回のインカネーションからのバックアップを使用できます。
LIST INCARNATIONコマンドを使用して、データベース・インカネーションを表示します。
データベース・インカネーションを表示する方法
ターゲット・データベースとリカバリ・カタログ（使用している場合）に接続してから、LIST INCARNATIONを実行します。
RMAN> LIST INCARNATION;
リカバリ・カタログを使用している場合、および同じカタログに複数のターゲット・データベースを登録している場合は、OF DATABASEオプションを使用して、それらを区別することができます。
RMAN> LIST INCARNATION OF DATABASE prod3;
LIST出力の様々な列ヘッダーについては、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。出力例は次のとおりです。
RMAN> LIST INCARNATION OF DATABASE; List of Database Incarnations DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time ------- ------- -------- ---------------- ------ ---------- ---------- 1 1 RDBMS 774627068 PARENT 1 21-OCT-03 2 2 RDBMS 774627068 CURRENT 173832 21-OCT-03
この出力例では、RESETLOGSが、SCN 164378でデータベースtrgtに対して実行され、新しいインカネーションが作成されたことが示されています。インカネーションは、インカネーション・キー（Inc Key列）で区別されます。
Recovery ManagerのREPORTコマンドを使用すると、使用可能なバックアップおよびデータベースを分析して、次のような重要な質問に回答できます。
Recovery Managerリポジトリに使用可能なバックアップおよびデータベースの状態の正確なレコードが保持されている場合にのみ、
Recovery Managerリポジトリに記録されているいくつかのバックアップが削除されているか、またはストレージ・デバイスがオフラインになっているかメディアが使用できないためにバックアップが一時的に使用不可になっている場合、
注意:
REPORTで正しい結果が出力されます。たとえば、Recovery Managerの外部でディスクまたはテープからバックアップが削除されている場合、Recovery Managerによって生成されるレポートにはこれらの変更が自動的に反映されません。
CROSSCHECKコマンドを使用してすべてのバックアップの状態を更新するか、またはCHANGE、CATALOG、UNCATALOGおよびDELETEコマンドを使用して個々のバックアップの状態を直接設定できます。実際に使用可能なバックアップを反映するようにRecovery Managerリポジトリを更新する方法については、第8章「Recovery Managerのメンテナンス作業」を参照してください。
この項では次の項目を取り上げます。
レポートを使用すると、バックアップおよびリカバリ計画が実際にデータベースのリカバリ可能性の要件を満たしていることを確認できます。データベースがリカバリ可能であるかどうかを判断するために使用するREPORTには、主に次の2つの形式があります。
REPORT NEED BACKUP構成済の保存方針または指定した保存方針を満たすためにバックアップする必要があるデータベース・ファイルがレポートされます。
REPORT UNRECOVERABLEダイレクト・パス・インサートなどのNOLOGGING操作の影響を受けているためにバックアップを必要とするデータベース・ファイルがレポートされます。
|
注意:
|
REPORT NEED BACKUPコマンドを使用して、特定の保存方針に基づくバックアップが必要なデータベース・ファイルを判断します。
引数を指定せずにREPORT NEED BACKUPを実行すると、現行の保存方針でバックアップが必要なオブジェクトがレポートされます。REDUNDANCYが1に設定されている構成済の保存方針の出力は、次の例のようになります。
REPORT NEED BACKUP; RMAN retention policy will be applied to the command RMAN retention policy is set to redundancy 1 Report of files with less than 1 redundant backups File #bkps Name ---- ----- ----------------------------------------------------- 2 0 /oracle/oradata/trgt/undotbs01.dbf
次のいずれかの形式のコマンドを使用して、REPORT NEED BACKUPに様々な条件を指定できます。
REPORT NEED BACKUP RECOVERY WINDOW OFn DAYSバックアップがリカバリ期間ベースの保存方針を満たす必要があるオブジェクトが表示されます。
REPORT NEED BACKUP REDUNDANCYnバックアップが冗長性ベースの保存方針を満たす必要があるオブジェクトが表示されます。
REPORT NEED BACKUP DAYS = n リカバリ用にn日分より多いアーカイブREDOログを必要とするファイルが表示されます。
REPORT NEED BACKUP INCREMENTAL n リカバリ用にn個より多い増分バックアップの適用を必要とするファイルが表示されます。
REPORT NEED BACKUPを使用して、データベース全体の確認、指定された表領域のスキップ、または様々な保存方針に対する特定の表領域またはデータ・ファイルのみの確認を行うことができます。次に例を示します。
RMAN> REPORT NEED BACKUP RECOVERY WINDOW OF 2 DAYS DATABASE SKIP TABLESPACE TBS_2; RMAN> REPORT NEED BACKUP REDUNDANCY 2 DATAFILE 1; RMAN> REPORT NEED BACKUP TABLESPACE TBS_3; # uses configured retention policy RMAN> REPORT NEED BACKUP INCREMENTAL 2; # checks entire database
REPORT NEED BACKUPでテストするバックアップをディスクベースまたはテープベースのバックアップのみに制限できます。次に例を示します。
RMAN> REPORT NEED BACKUP RECOVERY WINDOW OF 2 DAYS DATABASE DEVICE TYPE SBT; RMAN> REPORT NEED BACKUP DEVICE TYPE DISK; RMAN> REPORT NEED BACKUP TABLESPACE TBS_3 DEVICE TYPE SBT;
ダイレクト・ロード・インサートなどのリカバリ不能な操作によってデータ・ファイルが変更されている場合、リカバリ不能な操作ではREDOが生成されないため、通常のメディア・リカバリを使用してファイルをリカバリすることはできません。このような操作の後に影響を受けるデータ・ファイルの全体バックアップまたは増分バックアップのいずれかを実行して、リカバリ不能な操作の影響を受けるデータ・ブロックをRecovery Managerを使用してリカバリできるようにする必要があります。
リカバリ不能な操作の影響を受けるデータ・ファイル、およびバックアップからデータ・ファイルをリストア可能にするために必要なバックアップのタイプを識別するには、REPORT UNRECOVERABLEコマンドを使用します。次に例を示します。
RMAN> REPORT UNRECOVERABLE; Report of files that need backup due to unrecoverable operations File Type of Backup Required Name ---- ----------------------- ----------------------------------- 1 full /oracle/oradata/trgt/system01.dbf
OBSOLETEキーワードを指定すると、不要な（指定した保存方針を満たす必要がない）バックアップ・セット、バックアップ・ピースおよびデータ・ファイルのコピーをレポートできます。他のオプションを指定せずにREPORT OBSOLETEを実行すると、現行の保存方針で不要とみなされるバックアップが表示されます。次に例を示します。
RMAN> REPORT OBSOLETE; Datafile Copy 44 08-FEB-05 /backup/ora_df549738566_s70_s1 Datafile Copy 45 08-FEB-05 /backup/ora_df549738567_s71_s1 Datafile Copy 46 08-FEB-05 /backup/ora_df549738568_s72_s1 Backup Set 26 08-FEB-05 Backup Piece 26 08-FEB-05 /backup/ora_df549738682_s76_s1 . . .
RECOVERY WINDOWおよびREDUNDANCYオプションを指定してREPORT OBSOLETEを使用することによって、様々なリカバリ期間ベースまたは冗長性ベースの保存方針に基づいて不要とみなされるバックアップを確認できます。次に例を示します。
REPORT OBSOLETE RECOVERY WINDOW OF 3 DAYS; REPORT OBSOLETE REDUNDANCY 1;
REPORTコマンドにデバイス・タイプを指定することによって、不要なファイルを確認する際にディスクまたはテープ上のバックアップのみが検索されるように指定できます。次に例を示します。
REPORT OBSOLETE RECOVERY WINDOW OF 3 DAYS DEVICE TYPE DISK; REPORT OBSOLETE REDUNDANCY 1;
不要なバックアップをレポートする方法
CROSSCHECKコマンドを発行してディスク上のバックアップの状態と比較してリポジトリのバックアップの状態を更新するか、またはCHANGE、CATALOG、UNCATALOGおよびDELETEコマンドを使用して個々のバックアップの状態を直接指定する場合があります。 最も簡単な例として、次のいずれかのコマンドを使用して、ディスクまたはテープ（あるいはその両方）上のすべてのバックアップをクロスチェックできます。
RMAN> CROSSCHECK BACKUP DEVICE TYPE DISK; RMAN> CROSSCHECK BACKUP DEVICE TYPE SBT; RMAN> CROSSCHECK BACKUP; # crosshecks all backups on all devices
実際に使用可能なバックアップ・セットが含まれるようにRecovery Managerリポジトリを更新する方法の詳細は、第8章「Recovery Managerのメンテナンス作業」を参照してください。
REPORT OBSOLETEを実行して、リカバリの必要がなくなったために不要となったバックアップを識別します。次に例を示します。
# lists backups that not needed to recover the database to within last week REPORT OBSOLETE RECOVERY WINDOW OF 7 DAYS; # lists backups not needed for redundancy-based retention policy, considering only backups stored on tape REPORT OBSOLETE REDUNDANCY = 2 DEVICE TYPE sbt;
|
参照:
|
REPORT SCHEMAコマンドを実行すると、データベース・ファイルに関する情報が表示されます。
ターゲット・データベースとリカバリ・カタログ（使用している場合）に接続してから、REPORT SCHEMAを実行します。次に例を示します。
RMAN> REPORT SCHEMA; List of Permanent Datafiles =========================== File Size(MB) Tablespace RB segs Datafile Name ---- -------- -------------------- ------- ------------------------ 1 450 SYSTEM *** /oracle/oradata/tbs_01.f 2 50 SYSAUX *** /oracle/oradata/tbs_ax1.f 3 2 SYSTEM *** /oracle/oradata/tbs_02.f 4 2 TBS_1 *** /oracle/oradata/tbs_11.f . . . 21 2 TBS_4 *** /oracle/oradata/tbs_43.f 22 2 TBS_5 *** /oracle/oradata/tbs_53.f List of Temporary Files ======================= File Size(MB) Tablespace Maxsize(MB) Tempfile Name ---- -------- -------------------- ----------- -------------------- 1 40 TEMP 32767 /oracle/oradata/tbs_tmp1.f
|
 Copyright © 2006 Oracle Corporation. All Rights Reserved. |
|