1. データベース・バックアップおよびリカバリ・ユーザーズ・ガイド
  2. データのバックアップおよびアーカイブ
  3. RMANバックアップの概要

8 RMANバックアップの概要

この章では、すべてのタイプのRMANバックアップを作成するために理解しておく必要がある一般的な概念について説明します。この章のトピックは、次のとおりです:

8.1 RMANの一貫性バックアップおよび非一貫性バックアップについて

RMANのBACKUPコマンドを使用して、一貫性バックアップおよび非一貫性バックアップを作成します。

RMANのBACKUPコマンドでは、次のタイプのファイルのバックアップがサポートされています。

  • データファイルおよび制御ファイル

  • サーバー・パラメータ・ファイル

  • アーカイブREDOログ

  • RMANバックアップ

データベースは、ネットワーク構成ファイル、パスワード・ファイル、Oracleホームの内容などの他のタイプのファイルに依存していますが、これらのファイルはRMANではバックアップできません。同様に、Oracle Databaseの一部の機能(外部表など)には、データファイル、制御ファイルおよびREDOログ以外のファイルが必要な場合があります。RMANでは、これらのファイルをバックアップできません。RMANでサポートされていないファイルを保護するために、Oracle Secure Backupなどの汎用のバックアップ・ソフトウェアを使用します。

RMANでBACKUPコマンドを実行すると、出力は常に1つ以上のバックアップ・セットまたは1つ以上のイメージ・コピーになります。バックアップ・セットはRecovery Managerに固有の独自の形式ですが、イメージ・コピーはファイルのビットごとのコピーです。デフォルトでは、Recovery Managerはバックアップ・セットを作成します。

関連項目:

8.1.1 RMANの一貫性バックアップについて

一貫性バックアップは、データベースが一貫性のある状態のときに実行します。BACKUPコマンドを使用して、データベースの一貫性バックアップを作成できます。

SHUTDOWN NORMAL、SHUTDOWN IMMEDIATEまたはSHUTDOWN TRANSACTIONALコマンドを使用して停止すると、データベースは一貫性のある状態になります。一貫性のある状態での停止では、すべてのREDOがデータファイルに適用されたことが保証されます。データベースをマウントし、この時点でバックアップを作成すると、後でデータベース・バックアップをリストアし、メディア・リカバリを実行せずにオープンすることができます。しかし、バックアップ作成後に発生したすべてのトランザクションは当然失われることになります。

8.1.2 RMANの非一貫性バックアップについて

一貫性のないデータベース・バックアップを非一貫性バックアップといいます。インスタンスでの障害の発生後またはSHUTDOWN ABORTコマンドの実行後に作成されたバックアップと同様に、データベースがオープンされているときに作成されたバックアップには一貫性がありません。

非一貫性バックアップからデータベースをリストアする場合、Oracle Databaseでは、データベースをオープンする前に、メディア・リカバリを実行し、バックアップ作成後に実行されたREDOログ内の変更を適用する必要があります。

注意:

データベースがNOARCHIVELOGモードの場合、RMANで非一貫性バックアップを作成することはできません。NOARCHIVELOGモードのデータベースに対してユーザー管理のバックアップ方法を使用する場合、このデータベースの非一貫性バックアップは作成しないでください。

ARCHIVELOGモードでデータベースを実行する場合、アーカイブREDOログおよびデータファイルをバックアップする場合は、非一貫性バックアップを堅実なバックアップおよびリカバリ計画の基礎とできます。非一貫性バックアップでは、データベースを完全に保護するバックアップを作成するためにデータベースを停止する必要がないため、優れた可用性が実現されます。

8.2 オンライン・バックアップおよびバックアップ・モードについて

RMANバックアップまたはユーザー管理バックアップを作成できます。

オンラインの表領域またはデータベースのユーザー管理のバックアップを実行すると、データベース・ライター(DBWR)によるファイルの更新と同時に、オペレーティング・システム・ユーティリティによってデータファイルのバックアップが作成される場合があります。ユーティリティは、更新途中の状態のブロックを読み取ることができるため、バックアップ・メディアにコピーされるブロックの前半は更新されていても、後半には古いデータが含まれていることがあります。このタイプの論理的な破損は、分裂ブロックと呼ばれます。つまり、SCNに関して一貫性のないブロックです。このバックアップをリストアし、ブロックをリカバリする必要がある場合は、ブロックを使用できないため、リカバリは失敗します。

サード・パーティのスナップショット・テクノロジでは、次のいずれかの方法を使用して、分裂ブロックが作成されるリスクを排除する必要があります。

  • そのスナップショット・テクノロジがOracleのオンライン・バックアップの要件に準拠していることを確認する

  • データベースまたはデータファイルをオフラインにする

  • サード・パーティのスナップショット・バックアップを使用する前に、データベースをバックアップ・モードにする

関連項目:

ユーザー管理ツールとは異なり、RMANでは、データ・ブロックの形式が認識されるため、追加のロギングまたはバックアップが必要ありません。RMANでは、分裂ブロックがバックアップされないことが保証されています。RMANによるバックアップ中、データベース・サーバー・セッションは各データ・ブロックを読み取り、ブロック・ヘッダーとフッターを比較することによって、分裂していないかどうかを確認します。ブロックが分裂している場合、セッションはそのブロックを再度読み取ります。同じ分裂が検出された場合、ブロックは永続的に破損しているとみなされます。また、RMANでは、ブロックが読み取られる順序が認識されているため、データファイルのヘッダーのチェックポイントをフリーズする必要がなく、このため、そのファイルに最適なチェックポイントを取得できます。

関連項目:

RMANを使用しない場合にオンラインの表領域をバックアップする方法については、オンラインの表領域およびデータファイルのユーザー管理バックアップの作成を参照してください。

8.3 バックアップ・セットについて

RMANでBACKUPコマンドを実行すると、1つ以上のバックアップ・セットまたはイメージ・コピーを作成できます。デフォルトでは、出力先がディスクの場合もメディア・マネージャの場合も、バックアップ・セットが作成されます。

注意:

通常、データファイルのバックアップ・セットはデータファイルのイメージ・コピーよりサイズが小さく、書込みにかかる時間が短くなります。

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

8.3.1 バックアップ・セットおよびバックアップ・ピースについて

RMANは、バックアップ・データをバックアップ・セット(RMANバックアップの最小単位)と呼ばれる論理構造に格納できます。

バックアップ・セットには、1つ以上のデータファイル、アーカイブREDOログ、制御ファイルまたはサーバー・パラメータ・ファイルのデータが含まれます。バックアップ・セットは、RMANによってテープ・ドライブやテープ・ライブラリなどのメディア・マネージャにバックアップを書き込むことができる唯一の形式です。

バックアップ・セットには、1つ以上のバイナリ・ファイルがRMAN固有の形式で含まれます。各ファイルは、バックアップ・ピースと呼ばれます。1つのバックアップ・セットに、複数のデータファイルを含めることができます。たとえば、1つのバックアップ・ピースで構成される1つのバックアップ・セットに、10個のデータファイルをバックアップできます。この場合、RMANでは、1つのバックアップ・ピースが出力として作成されます。バックアップ・セットには、このバックアップ・ピースのみが含まれます。

BACKUPコマンドにSECTION SIZEパラメータを指定すると、RMANによってマルチセクション・バックアップが作成されます。これは、複数のチャネルでパラレルに作成される単一の大規模なファイルのバックアップです。各チャネルによって、1つのバックアップ・ピースが作成されます。各バックアップ・ピースには、バックアップされるファイルのファイル・セクションが1つ含まれます。

マルチセクション・バックアップ以外のバックアップでは、RMANは、正常に完了したバックアップ・セットのみをリポジトリに記録します。部分バックアップ・セットのようなものはありません。これは、RMANメタデータに部分的なバックアップ・セットのレコードが含まれる可能性がある失敗したマルチセクション・バックアップとは異なります。後者の場合は、DELETEコマンドを使用して、部分的なバックアップ・セットを削除する必要があります。

注意:

RMANは、部分的なバックアップをリストアおよびリカバリの候補とみなしません。

関連項目:

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

8.3.2 バックアップ・セットのRMANブロック圧縮について

RMANでは、バックアップ・セットの作成時にブロック圧縮を使用できます。

次のタイプのブロック圧縮を使用できます。

  • 未使用ブロックの圧縮(ディスク・バックアップおよびOracle Secure Backupテープ・バックアップをサポート)

  • NULLブロックの圧縮(すべてのバックアップをサポート)

RMANブロック圧縮は、従来のバイナリ圧縮ではありません。むしろ、このバックアップには不要な特定のブロックをバックアップすることを防ぐためにRMANが使用する一連の方法です。

8.3.2.1 未使用ブロックの圧縮について

未使用ブロックの圧縮を使用すると、RMANでは、あるデータベース・オブジェクトに現在割り当てられていないデータベース・ブロックの読取りおよびバックアップがスキップされます。これは、それらのブロックが以前割り当てられていたかどうかにはかかわりません。

そのため、データベース表が削除されると、RMANは、新しいオブジェクトがその領域に作成されるまでその表が占有していた領域をバックアップしません。

未使用ブロックの圧縮は、次の条件が満たされている場合に自動的に実行されます。

  • COMPATIBLE初期化パラメータが10.2以上に設定されている。

  • 現在、データベースに定義されている保証付きリストア・ポイントがない。

  • データファイルがローカルで管理されている。

  • データファイルが、全体バックアップまたはレベル0の増分バックアップの一部としてバックアップ・セットにバックアップされている。

  • ディスクにバックアップ・セットが作成されているか、またはOracle Secure Backupがメディア・マネージャである。

8.3.2.2 NULLブロックの圧縮について

NULLブロックの圧縮を使用すると、RMANは、データが含まれたことのないブロックを出力から除外します。

NULLブロックの圧縮では、バックアップ・セット形式で作成されたレベル0または完全バックアップが使用されます。

8.3.3 RMANバックアップ・セットのバイナリ圧縮について

RMANでは、バックアップ・セットのバイナリ圧縮がサポートされています。バイナリ圧縮は、BACKUPコマンドでAS COMPRESSED BACKUPSETを指定した場合、またはCONFIGURE DEVICE TYPE [DISK | SBT] BACKUP TYPE TO COMPRESSED BACKUPSETコマンドを使用した場合(1回のみ)に有効になります。

バイナリ圧縮には2つのオプションがあります。

  • BASIC圧縮アルゴリズムを使用できます。この場合、Oracle Advanced Compressionオプションは必要ありません。この設定を使用すると、MEDIUMに相当する圧縮率を得られますが、CPU使用率は増加します。

  • Oracle Advanced Compressionオプションを有効にしている場合、「Oracle Advanced Compressionオプションについて」に示す圧縮レベルのいずれかを選択できます。

関連項目:

8.3.4 RMANのUNDOのバックアップの最適化について

UNDOのバックアップの最適化では、RMANは、トランザクションがコミットされているためバックアップのリカバリに不要となったUNDOを除外します。

UNDOのバックアップの最適化は、ディスク・バックアップおよびOracle Secure Backupテープ・バックアップに対して機能します。バックアップの最適化とは異なり、UNDOのバックアップの最適化は構成不可能です。

8.3.5 RMANバックアップ・セットの暗号化について

RMANでは、バックアップ・セットのバックアップの暗号化がサポートされています。キーストアベースの透過的暗号化またはパスワードベースの暗号化(あるいはその両方)を使用できます。

CONFIGURE ENCRYPTIONコマンドを使用すると、永続的な透過的暗号化を構成できます。パスワードベースの暗号化を指定するには、RMANセッション・レベルでSET ENCRYPTIONコマンドを使用します。

注意:

キーストアベースの暗号化は、パスワードが必要ないため、パスワードベースの暗号化より安全です。パスワードベースの暗号化は、バックアップをトランスポータブルにする必要があるため絶対に必要な場合にのみ使用してください。

RMANを使用してディスクに暗号化バックアップを作成するには、データベースでAdvanced Security Optionを使用している必要があります。Oracle Secure Backup SBTは、暗号化RMANバックアップをテープに直接作成するためにサポートされている唯一のインタフェースです。

関連項目:

8.3.6 RMANバックアップ・ピースのファイル名について

バックアップ・ピースの一意の名前をRMANに決定させることも、FORMAT句を使用して名前を指定することもできます。

FORMATパラメータを指定しない場合、RMANは、%U置換変数を含む一意のファイル名をデフォルトのバックアップ場所に自動的に生成します。

%UによってRMANで生成されるSBTバックアップ・ピース名の例は、次のとおりです。 

2i1nk47_1_1

ディスクの非Oracle Managed File(OMF)バックアップ・ピースの例は、次のとおりです。 

/backups/TEST/2i1nk47_1_1

FORMAT句では、一意のファイル名を生成するために%U以外の置換変数がサポートされています。たとえば、データベースの名前を生成するために%d、DBID用に%I、タイムスタンプ用に%tなどを使用できます。

最大4つのFORMATパラメータを指定できます。複数のFORMATパラメータを指定すると、複数のコピーを指定する場合にのみRMANで複数のFORMATパラメータを使用できます。BACKUP ... COPIES、SET BACKUP COPIESまたはCONFIGURE ... BACKUP COPIESコマンドを使用すると、複数のコピーを作成できます。

注意:

メディア・マネージャを使用する場合のFORMATの制限(名前のサイズ、ネーミング規則など)については、ベンダーのドキュメントを参照してください。

関連項目:

8.3.7 RMANバックアップ・ピースの数およびサイズについて

デフォルトでは、バックアップ・セットは、1つのバックアップ・ピースで構成されます。各バックアップ・ピースのサイズを制限するには、CONFIGURE CHANNELまたはALLOCATE CHANNELコマンドのMAXPIECESIZEオプションを指定します。

MAXPIECESIZEオプションによって、バックアップ・ピースのサイズが指定したバイト数に制限されます。バックアップ・セットの合計サイズが指定したバックアップ・ピースのサイズを超えた場合、RMANは、バックアップ・セットの内容を保持する複数の物理ピースを作成します。

このオプションは、複数のテープにまたがるバックアップ・ピースを管理できないメディア・マネージャに使用できます。たとえば、最大容量が10GBのテープに、80GBのデータを保持するバックアップ・セットを作成する必要がある場合、メディア・マネージャで使用するテープに格納できる10GBのバックアップ・ピースを作成するように、RMANに指示する必要があります。この場合、バックアップ・セット・メディアは8つのテープから構成されます。SBT 2.0をサポートしているメディア・マネージャの場合、サポートするバックアップ・ピースの最大サイズを示す値をRMANに戻すことができるため、RMANはその値をバックアップ・アクティビティの計画に使用できます。

BACKUPコマンドにSECTION SIZEパラメータを指定すると、RMANによってマルチセクション・バックアップを作成できます。この場合、1つのバックアップ・セットに複数のバックアップ・ピースを含めることができます。各バックアップ・ピースにはファイル・セクションが含まれます。マルチセクション・バックアップの目的は、複数のチャネルで大規模なファイルをパラレルでバックアップできるようにすることです。

関連項目:

8.3.8 RMANバックアップ・セットの数およびサイズについて

BACKUPコマンドのbackupSpec句を使用すると、バックアップするオブジェクトを指定できます。backupSpec句を1つ指定するごとに、1つ以上のバックアップ・セットが作成されます。

バックアップ・セットの合計数および合計サイズは、主にRMANの内部アルゴリズムに基づいています。ただし、CONFIGUREまたはBACKUPコマンドのMAXSETSIZEパラメータを使用して、RMANの動作に影響を及ぼすことができます。このパラメータを使用してバックアップ・セットのサイズを制限することによって、セット内のファイル数を間接的に制限でき、場合によっては、RMANに追加のバックアップ・セットを作成させることができます。また、BACKUP ... FILESPERSETを指定して、各バックアップ・セット内のファイルの最大数を指定することもできます。

関連項目:

8.3.9 多重RMANバックアップ・セットについて

バックアップ・セットの作成時に、RMANは、ディスクから複数のファイルを同時に読み取って、同じバックアップ・セットにそれらのブロックを書き込むことができます。たとえば、RMANでは、2つのデータファイルから同時に読み取り、これらのデータファイルからのブロックを1つのバックアップ・ピースに結合できます。複数のファイルからのブロックの組合せは、バックアップの多重化と呼ばれます。

これに対して、イメージ・コピーは多重化されません。

注意:

RMANによってデータファイルのマルチセクション・バックアップが作成された場合、そのデータファイルは他のすべてのデータファイルまたはファイル・セクションとは多重化されません。

図8-1に示すように、RMANは、1つのバックアップ・ピースのみを含むバックアップ・セットに3つのデータファイルをバックアップできます。このバックアップ・ピースには、3つの入力データファイルのデータ・ブロックが組み合されて格納されます。

図8-1 データファイルの多重化

図8-1の説明が続きます
「図8-1 データファイルの多重化」の説明

RMANによる多重化は、複数の要因によって決定されます。たとえば、各バックアップ・セットに格納されるデータファイルの数は、BACKUPコマンドのFILESPERSETパラメータによって決定されます。RMANが同時に読み取ることができるデータファイルの数は、ALLOCATE CHANNELまたはCONFIGURE CHANNELのMAXOPENFILESパラメータによって定義されます。基本的な多重化アルゴリズムは、次のとおりです。

  • 各バックアップ・セット内のファイルの数

    この数は、FILESPERSET設定および各チャネルによって読み込まれるファイル数の最小値です。FILESPERSETのデフォルトは64です。

  • 多重化レベル

    これは、同時に読み取られ、同じバックアップ・ピースに書き込まれる入力ファイルの数です。多重化のレベルは、MAXOPENFILESおよび各バックアップ・セット内のファイル数の最小値です。MAXOPENFILESのデフォルトは8です。

FILEPERSETが4に設定されているときに、1つのチャネルを持つ12のデータファイルをバックアップするとします。多重化のレベルは、この数と8の小さい方になります。したがって、ブロックは、チャネルによって4つのデータファイルから各バックアップ・ピースに同時に書き込まれます。

1つのチャネルを持つ50のデータファイルをバックアップするとします。各バックアップ・セット内のファイル数は50です。多重化のレベルは、この数と8の小さい方になります。したがって、ブロックは、チャネルによって8つのデータファイルから各バックアップ・ピースに同時に書き込まれます。

RMANによるバックアップ・セットの多重化は、メディア・マネージャによる多重化とは異なります。メディア・マネージャによる多重化のタイプの1つとして、メディア・マネージャが、複数のRMANチャネルからの同時出力を単一のシーケンシャル・デバイスに書き込んだ場合に発生するものがあります。また、別のタイプとして、バックアップによって同じテープ上にデータベース・ファイルとデータベース以外のファイルが混在した場合に発生するものもあります。

注意:

RMANバックアップには、メディア・マネージャによる多重化を使用しないことをお薦めします。

関連項目:

8.3.10 RMANプロキシ・コピーについて

プロキシ・コピーでは、RMANは、プロキシ・コピー機能をサポートしているメディア・マネージャに、データ送信の制御を移します。プロキシ・コピーはこの機能をサポートしているメディア・マネージャでのみ使用でき、タイプがDISKのチャネルでは使用できません。BACKUPコマンドのPROXYオプションを使用して、バックアップでプロキシ・コピーを実行することを指定します。

BACKUP PROXYコマンドでバックアップするファイルごとに、RMANは、プロキシ・コピーを実行できるかどうかをメディア・マネージャに問い合せて確認します。メディア・マネージャがファイルのプロキシ・コピーを実行できない場合、RMANは、PROXYオプションを使用しなかった場合と同様にファイルをバックアップします。(PROXY ONLYオプションを使用している場合に、プロキシ・コピーが実行できない場合は、RMANはバックアップを行いません。)

制御ファイルはプロキシ・コピーではバックアップされません。制御ファイルのバックアップ操作でPROXYオプションを指定した場合、このオプションは自動的に無視され、制御ファイルのバックアップが行われます。

関連項目:

8.4 RMANイメージ・コピーについて

イメージ・コピーは、1つのデータファイル、アーカイブREDOログ・ファイルまたは制御ファイルの正確なコピーです。

イメージ・コピーはRMAN固有の形式では格納されません。これらは、オペレーティング・システム・コマンドでファイルをコピーした場合と同じ形式で格納されます。イメージ・コピーは、Recovery Managerのリストアおよびリカバリ操作中に使用できます。また、Recovery Manager以外のリストアおよびリカバリ方法でもイメージ・コピーを使用できます。

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

8.4.1 RMANで作成したイメージ・コピーについて

イメージ・コピーを作成してRMANリポジトリに記録するには、RMANのRMAN BACKUP AS COPYコマンドを実行します。

また、ディスクのデフォルトのバックアップ・タイプをイメージ・コピーとして構成することもできます。コピーの作成には、データベース・サーバー・セッションが使用されます。このサーバー・セッションが、ファイル内のブロックの検証やRMANリポジトリへのイメージ・コピーの記録などの処理を実行します。

バックアップ・ピースの場合と同様に、FORMAT変数を使用してイメージ・コピーの名前を指定します。イメージ・コピーの場合は、デフォルトの書式%U(「RMANバックアップ・ピースのファイル名について」を参照)の定義が異なります。次に、%Uによって生成されるデータファイル2の名前の例を示します。 

/d1/oracle/work/orcva/RDBMS/datafile/o1_mf_sysaux_2qylngm3_.dbf

イメージ・コピーを作成する場合は、 BACKUPコマンドのDB_FILE_NAME_CONVERTパラメータで、出力コピーに名前を指定することもできます。このパラメータの動作は、DB_FILE_NAME_CONVERT初期化パラメータと同一です。ファイル名の接頭辞のペアを指定すると、出力ファイルの名前が変更されます。 ファイルがペアのいずれによっても変換されない場合、FORMAT仕様が使用されます。FORMATが指定されていない場合、デフォルトの書式%Uが使用されます。

例8-1 DB_FILE_NAME_CONVERTを使用したファイル名の指定

この例では、ファイル名の先頭に/maindisk/oradata/usersが付くデータファイルを、先頭に/backups/users_tsが付くファイル名に変更してコピーします。 

BACKUP AS COPY 
  DB_FILE_NAME_CONVERT ('/maindisk/oradata/users',
                        '/backups/users_ts')
  TABLESPACE users;

RESTOREコマンドを実行すると、デフォルトでは、イメージ・コピー・バックアップをコピーすることによって、データファイルまたは制御ファイルが元の場所にリストアされます。 イメージ・コピーが選択されるのは、バックアップ・セットを使用すると、リストアするファイルを検索するためにバックアップ・セット全体が読み取られ、オーバーヘッドが増加するためです。

現行のデータファイルをリストアおよびリカバリする必要があり、ディスク上に使用可能なイメージ・コピーが存在する場合は、RMANでイメージ・コピーを元の場所にコピーする必要はありません。リストア対象のデータファイルのかわりに、イメージ・コピーを使用できます。このタスクの実行方法については、「コピーへの切替え後の完全リカバリの実行」を参照してください。

関連項目:

8.4.2 ユーザー管理イメージ・コピーについて

RMANでは、ディスク上にファイルのイメージ・コピーを作成するオペレーティング・システム固有のファイル・コピー・コマンドや、サード・パーティ・ユーティリティなど、RMAN以外のメカニズムで作成したイメージ・コピーを使用できます。このタイプのコピーは、ユーザー管理バックアップまたはオペレーティング・システムのバックアップと呼ばれます。

CATALOGコマンドを使用して既存のイメージ・コピーを検査し、そのメタデータをRMANリポジトリに入力できます。ただし、CATALOGコマンドでは、次の処理は行われません。

  • 破損がないことを保証するためのデータファイルのコピー内のすべてのブロックの読取り

  • イメージ・コピーがバックアップ・モードで正常に作成されたことの保証

これらのファイルをカタログに追加した後、それらをRESTOREまたはSWITCHコマンドで使用できます。これは、RMANによって生成されるイメージ・コピーの場合と同様です。

ミラー化されたディスク・ボリューム上にデータファイルを格納しているサイトでは、ミラー化の解除によってイメージ・コピーの作成が可能になります。ミラー化を解除した後で、新しいユーザー管理コピーが存在することをRMANに通知して、そのコピーをバックアップの対象にします。CHANGE ... UNCATALOG コマンドを使用することによってコピーを今後利用できなくした場合は、RMANに通知する必要があります。

関連項目:

8.5 スパース・バックアップについて

RMANのBACKUPコマンドを使用して、スパース・データファイルのデータ・ブロック、スパース・データファイルが格納された表領域、スパース・プラガブル・データベース(PDB)、およびスパースPDBが格納されたマルチテナント・コンテナ・データベース(CDB)をバックアップできます。

スパース・データファイルは、基本データファイル・オブジェクトのシャドウとして作成される論理Oracleオブジェクトで、デルタ領域として知られる物理記憶領域に格納されます。例として、ベース・データベースDBから作成された、スパース・データベースDB0について考えます。スパース環境では、必ず、ベース・オブジェクトを読取り専用にする必要があります。ベース・データベースとは異なり、スパース・データベースは読取り/書込みが可能なデータベースです。この例のDBは、読取り専用のデータベースで、5つのデータファイルで構成されます。DB0は、これら5つの基本データファイルぞれぞれの論理バージョンを再作成し、各ファイル対して個別のデルタ記憶領域を割り当てます。スパース・データベースDB0がスパース・データファイルのいずれかのデータ・ブロックを更新すると、更新されたブロックだけが、変更されたデータファイルのデルタ領域に論理的に格納されます。DB0でスパース・バックアップの実行を選択した場合、この操作では、データベースのデルタ記憶領域とスパース・データファイルのデルタ領域のデータのみがコピーされます。スパース・バックアップは、バックアップ・セット形式(デフォルト)またはイメージ・コピー形式のいずれかにできます。RMANは、スパース・バックアップのスパース・データファイルをリストアし、次にそれらをアーカイブ・ログおよびREDOログからリカバリします。スパース・データファイルでは完全リカバリまたはPoint-in-Timeリカバリを実行できます。

スパース・バックアップおよびリカバリ操作を実行するには、データベースのCOMPATIBLE初期化パラメータが12.2以上に設定されている必要があります。

データベースのCOMPATIBLE初期化パラメータが12.2に設定されていて、全体バックアップまたはレベル0の増分バックアップを非スパース(標準)データファイルで行う場合、RMANは、指定されたデータファイルの従来の全体バックアップまたはレベル0の増分バックアップを実行します。これに対して、全体バックアップまたはレベル0の増分バックアップをスパース・データファイルで実行する場合、RMANは、その特定のデータファイルのデルタ記憶領域から、すべての最新の変更のみのバックアップを実行します。

COMPATIBLE初期化パラメータが12.2未満のデータベースでは、RMANは以前と同様にバックアップおよびリカバリ操作を実行し、データファイルがスパースであることの影響を受けません。

スパース・バックアップは、記憶領域の効率的な管理と、より高速なバックアップおよびリカバリを促進します。

注意:

スパース・データベースのベース(読取り専用)データファイルは、暗号化されていません。基本データファイルは、保護されたストレージに保存し、安全な通信を使用してアクセスするようにします。

関連項目:

RMANを使用したスパース・データベースのバックアップ

8.6 RMANを使用したバックアップの複数のコピーについて

RMANでは、バックアップの同じコピーを複数作成できます。

次のいずれかの方法を使用します。

  • BACKUP ... COPIESコマンドでバックアップを多重化しますが、この場合、RMANは各バックアップ・セットの複数のコピーを作成します。

    「多重バックアップ・セットについて」を参照してください。

  • ファイルをバックアップ・セットまたはイメージ・コピーとしてバックアップしてから、RMANのBACKUP BACKUPSETまたはBACKUP COPY OFコマンドで、そのバックアップ・セットまたはイメージ・コピーをバックアップします。

    「RMANバックアップのバックアップについて」を参照してください。

8.6.1 多重バックアップ・セットについて

データファイル、アーカイブREDOログ・ファイル、サーバー・パラメータ・ファイルおよび制御ファイルをバックアップ・ピースにバックアップする場合、RMANは、多重バックアップ・セットを作成して、1つのBACKUPコマンドで、異なるバックアップ先にバックアップ・セットの各バックアップ・ピースの同じコピーを最大4つ作成できます。イメージ・コピーを作成するバックアップ操作では、多重化はサポートされていません。

BACKUPコマンドの使用時に、CONFIGURE、SETまたは BACKUPコマンドでCOPIESパラメータを使用して、バックアップ・セットの多重化を指定できます。RMANでは、ディスクまたはテープにバックアップを多重化できますが、テープとディスクにバックアップを同時に多重化することはできません。テープへのバックアップ時に、コピーの数が、使用可能なテープ・デバイスの数を超えないようにしてください。

BACKUPコマンドのFORMATパラメータでは、多重バックアップの出力先を指定します。次の例では、データファイル7のバックアップのコピーを3つ作成します。 

BACKUP DEVICE TYPE DISK COPIES 3 DATAFILE 7 
  FORMAT '/disk1/%U','?/oradata/%U','?/%U';

この場合、RMANは、各バックアップ・ピースの最初のコピーを/disk1に、2番目のコピーを?/oradataに、3番目のコピーをOracleホームに格納します。RMANは、それぞれ異なる一意のバックアップ・セット・キーを持つ3つのバックアップ・セットを作成するわけではありません。RMANは、一意のキーを持つ1つのバックアップ・セットを作成して、そのバックアップ・セット内の各バックアップ・ピースの同じコピーを3つ生成します。

関連項目:

8.6.2 RMANバックアップのバックアップについて

BACKUPコマンドを使用すると、既存のバックアップ・セットおよびイメージ・コピーをバックアップできます。既存のバックアップをバックアップすると、RMANバックアップの同じコピーを複数作成できます。

次の各項では、バックアップのバックアップを作成する方法の詳細を説明します。

8.6.2.1 バックアップ・セットのバックアップ

RMANのBACKUP BACKUPSETコマンドを使用すると、ディスク上に作成したバックアップ・セットをバックアップできます。このコマンドは、複数のメディア間でバックアップを実行する場合に有効です。

バックアップ・セットのいずれかのコピーが破損または欠落していることが検出された場合、RMANは、同じバックアップ・セットの他のコピーを検索します。この動作は、複数のアーカイブ先に存在するアーカイブREDOログをRMANがバックアップする際の動作に似ています。

RMANを使用すると、暗号化されていないバックアップ・セットの暗号化されたバックアップを作成できます。暗号化されていないバックアップ・セットをバックアップする前に、SET ENCRYPTION FOR DATABASE ONコマンドを使用して暗号化を有効にします。SETコマンドは、現在のRMANセッションの暗号化を有効にする点に注意します。その後の操作で暗号化が必要ない場合は、データベースの暗号化を解除します。

例8-2 テープへのバックアップ・セットのバックアップ

この例は、本番バックアップ・スケジュールの一部として、週に1回BACKUPコマンドを実行する方法を示しています。この方法では、すべてのバックアップがディスクとテープの両方に作成されます。 

BACKUP DEVICE TYPE DISK AS BACKUPSET 
  DATABASE PLUS ARCHIVELOG; 
BACKUP 
  DEVICE TYPE sbt 
  BACKUPSET ALL; # copies backup sets on disk to tape

注意:

自動チャネルを使用したsbtへのバックアップでは、最初にCONFIGURE DEVICE TYPE sbtコマンドを実行する必要があります。

例8-3 領域割当ての管理

BACKUP BACKUPSETを使用して、バックアップ領域の割当てを管理することもできます。この例では、1週間以上前に作成されたバックアップ・セットをディスクからテープにバックアップして、それらをディスクから削除しています。 

BACKUP 
  DEVICE TYPE sbt 
  BACKUPSET COMPLETED BEFORE 'SYSDATE-7' 
  DELETE INPUT;

ここで使用しているDELETE INPUTは、DELETE ALL INPUTと同等であり、RMANは、バックアップ・セットのすべての既存のコピーを削除します。バックアップを4つの場所に多重化している場合、RMANは、バックアップ・セットのピースのコピーを4つともすべて削除します。

関連項目:

「RMANバックアップのバックアップ」

8.6.2.2 イメージ・コピーのバックアップ

BACKUP COPY OFコマンドを使用すると、データベース・ファイルの既存のイメージ・コピーをバックアップ・セットまたはイメージ・コピーのいずれかとしてバックアップできます。このコマンドを使用する際は、コマンドで指定するすべてのデータファイルのイメージ・コピーが存在している必要があります。1つのデータファイルに複数のコピーが存在する場合は、最新のコピーが使用されます。表領域またはデータベース全体を指定すると、データベースまたは表領域にデータファイルがあり、対応するイメージ・コピーのバックアップがない場合、RMANはエラーを発行します。

8.7 RMAN制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップについて

制御ファイルおよびサーバー・パラメータ・ファイルの最新のバックアップを作成しておくと、多くのリカバリ状況で非常に役立ちます。これらのファイルのバックアップを確実に作成するために、データベースには、制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップ機能が備わっています。

自動バックアップは、BACKUPコマンドで明示的に要求された現行の制御ファイルのバックアップとは関係なく行われます。制御ファイルの自動バックアップによって、RMANは、現行の制御ファイル、リカバリ・カタログおよびサーバー・パラメータ・ファイルにアクセスできない場合でも、データベースをリカバリできます。自動バックアップの格納に使用されるパスは標準的な書式に準拠しているため、RMANは、その自動バックアップからサーバー・パラメータ・ファイルを検索してリストアできます。リストアされたサーバー・パラメータ・ファイルを使用してインスタンスを起動すると、RMANによって自動バックアップから制御ファイルがリストアされます。制御ファイルをマウントした後、マウントされた制御ファイル内のRMANリポジトリを使用して、データファイルをリストアします。

制御ファイル自動バックアップをオンにすることをお薦めします。そうしない場合、RMANのデータベースのPoint-in-Timeリカバリ(DBPITR)およびPDBのPoint-in-Timeリカバリ(PITR)は、PITRでUNDOデータ・ファイルの追加や削除が必要な場合に効果的に動作しない可能性があります。

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

8.7.1 RMANが制御ファイルの自動バックアップを実行する場合

ターゲット・データベースの構成に応じて、RMANでは制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップを実行できます。

非CDBについては、CONFIGURE CONTROLFILE AUTOBACKUPがONの場合、RMANは、正常なBACKUPコマンド後に、制御ファイルおよび現行のサーバー・パラメータ・ファイル(データベースの起動に使用された場合)を自動的にバックアップします。COMPATIBLE初期化パラメータが12.0以上に設定されているCDBおよびスタンドアロン・データベースについては、デフォルトで制御ファイルの自動バックアップが有効になります。

データベースがARCHIVELOGモードで実行されている場合、データベースの構造上の変更によって制御ファイルの内容が影響を受けると、RMANは、制御ファイルの自動バックアップを作成します。

注意:

Oracle Database 11gリリース2以降では、スクリプトに含まれている複数の構造変更(表領域の追加、表領域またはデータファイルの状態の変更、新しいオンラインREDOログの追加、ファイルの名前変更など)が適用されている場合、RMANは、制御ファイルの自動バックアップを1つのみ実行します。

8.7.2 RMANによる制御ファイルの自動バックアップの実行方法

自動バックアップは、バックアップ・ジョブ中に割り当てられた最初のチャネルによって作成され、独自のバックアップ・セットに格納されます。データベースの構造変更後の自動バックアップの場合は、構造変更に関連付けられたサーバー・プロセスによってバックアップが作成されます。

サーバー・パラメータ・ファイルがデータベースによって使用されている場合は、Recovery Managerによって、制御ファイルの自動バックアップと同じバックアップ・セットにバックアップされます。自動バックアップが完了すると、バックアップ・ピースの完全パスおよびデバイス・タイプを含むメッセージが、データベースによって自動診断リポジトリ(ADR)にあるアラート・ログに書き込まれます。

注意:

制御ファイルの自動バックアップは多重化されません。

制御ファイルの自動バックアップのファイル名には、すべてのデバイス・タイプのデフォルトの書式%Fが使用されるため、RMANは、リポジトリを使用しなくても、ファイルの場所を判断してそのファイルをリストアできます。 CONFIGURE CONTROLFILE AUTOBACKUP FORMATコマンドを使用すると、別の書式を指定できます。ただし、すべての自動バックアップの書式に%F変数を含める必要があります。デフォルトの書式を使用しない場合は、障害リカバリ中に、自動バックアップの生成に使用された書式を指定する必要があります。そうしない場合、Recovery Managerは自動バックアップをリストアできません。

関連項目:

8.8 RMANの増分バックアップについて

増分バックアップでは、前回のバックアップ以降に変更されたデータファイル・ブロックのみがコピーされます。RMANを使用して、データファイル、表領域またはデータベース全体の増分バックアップを作成できます。

デフォルトでは、RMANは全体バックアップを作成します。データファイルの全体バックアップには、バックアップするファイルのすべての割当て済ブロックが含まれます。 データファイルの全体バックアップは、イメージ・コピーである場合があります。この場合は、すべてのデータ・ブロックがバックアップされます。また、バックアップ・セットに格納される場合もあります。この場合は、使用されていないデータファイル・ブロックはスキップされます。

全体バックアップは、後続の増分バックアップに影響を与えません。イメージ・コピーにはデータファイル内のすべてのデータ・ブロックが含まれるため、イメージ・コピーは常に全体バックアップとなります。 バックアップ・セットにはデータファイル内のすべてのデータ・ブロックが含まれる可能性があるため、バックアップ・セットはデフォルトでは全体バックアップとなります。ただし、未使用ブロックの圧縮は、未使用のブロックは除外され、現在使用されていないブロックが除外される場合もあることを意味します(「バックアップ・セットのRMANブロック圧縮について」を参照)。

全体バックアップを増分バックアップ計画に含めて、後続の増分バックアップの親として指定することはできません。

関連項目:

8.8.1 マルチレベル増分バックアップについて

RMANでは、マルチレベル増分バックアップを作成できます。各増分レベルは、0または1の値で示されます。

レベル0の増分バックアップは、後続の増分バックアップの基本となるバックアップであり、データが含まれるすべてのブロックをコピーします。レベル0の増分バックアップと全体バックアップの違いは、全体バックアップは増分計画には含まれないという点のみです。したがって、レベル0の増分バックアップは、レベルが0より大きい増分バックアップの親である全体バックアップです。

レベル1の増分バックアップは、次のいずれかのタイプです。

デフォルトでは、増分バックアップは、差分バックアップに設定されています。

レベル0の増分バックアップは、バックアップ・セットまたはイメージ・コピーのいずれかにできますが、レベル1の増分バックアップは、バックアップ・セットのみが可能です。

注意:

リカバリ時間がディスク領域より重要である場合は、差分バックアップより累積バックアップをお薦めします。これは、リカバリ中に適用する必要がある増分バックアップが少ないためです。

バックアップ・ファイルのサイズは、変更されたブロック数、増分バックアップ・レベルおよび増分バックアップのタイプ(差分または累積)によって異なります。

8.8.1.1 差分増分バックアップについて

レベル1の差分バックアップでは、RMANは、レベル1(累積または差分)またはレベル0の最新の増分バックアップ以降に変更されたすべてのブロックをバックアップします。

たとえば、レベル1の差分バックアップでは、RMANはレベル1の最新のバックアップを確認して、そのバックアップ以降に変更されたすべてのブロックをバックアップします。レベル1のバックアップが使用できない場合、RMANは、レベル0の基本バックアップ以降に変更されたすべてのブロックをコピーします。

現行または親のインカネーションでレベル0のバックアップが使用できない場合の動作は、互換性モード設定によって異なります。互換性が10.0.0以上の場合、RMANは、ファイルの作成以降に変更されたすべてのブロックをコピーします。それ以外の場合、RMANは、レベル0のバックアップを生成します。

図8-2 差分増分バックアップ

図8-2の説明が続きます
「図8-2 差分増分バックアップ」の説明

図8-2に示す例では、毎週、次のアクティビティが実行されます。

  • 日曜日

    レベル0の増分バックアップによって、このデータベースでこれまでに使用されたすべてのブロックがバックアップされます。

  • 月曜日から土曜日

    月曜日から土曜日には、レベル1の差分増分バックアップによって、レベル1またはレベル0の最新の増分バックアップ以降に変更されたすべてのブロックが毎日バックアップされます。つまり、月曜日のバックアップでは、日曜日のレベル0のバックアップ以降に変更されたブロックがコピーされ、火曜日のバックアップでは、月曜日のレベル1のバックアップ以降に変更されたブロックがコピーされる、というように実行されます。

8.8.1.2 累積増分バックアップについて

レベル1の累積バックアップでは、RMANは、現行または親のインカネーションでレベル0の最新の増分バックアップ以降に使用されたすべてのブロックをバックアップします。

累積増分バックアップでは、特定のレベルの1つの増分バックアップのみが必要となるため、リストア操作に必要な作業が軽減されます。累積バックアップでは、同じレベルの以前のバックアップによって実行された作業が繰り返されるため、差分バックアップよりも多くの領域および時間が必要です。

図8-3に示す例では、毎週、次のアクティビティが実行されます。

  • 日曜日

    レベル0の増分バックアップによって、このデータベースでこれまでに使用されたすべてのブロックがバックアップされます。

  • 月曜日から土曜日

    レベル1の累積増分バックアップによって、レベル0の最新のバックアップ以降に変更されたすべてのブロックがコピーされます。レベル0の最新のバックアップは日曜日に作成されているため、月曜日から土曜日まで毎日行われるレベル1のバックアップでは、日曜日のバックアップ以降に変更されたすべてのブロックがバックアップされます。

関連項目:

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

図8-3 累積増分バックアップ

図8-3の説明が続きます
「図8-3 累積増分バックアップ」の説明

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

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

ブロック・チェンジ・トラッキング・ファイルは、データベース領域に格納される小さなバイナリ・ファイルです。REDOの生成時に、RMANは、変更されたブロックを追跡します。

ブロック・チェンジ・トラッキングを有効にした場合、RMANは、チェンジ・トラッキング・ファイルを使用して、増分バックアップ用の変更されたブロックを識別します。レベル0の増分バックアップにはすべてのブロックが含まれるため、増分レベルが0(ゼロ)より大きい場合にのみ、Recovery Managerはブロック・チェンジ・トラッキングを使用します。

関連項目:

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

8.8.3 増分バックアップのアルゴリズムについて

RMANで増分バックアップの作成に使用されるアルゴリズムを理解するには、次の概念を理解しておく必要があります。

  • チェックポイントSCN

    すべてのデータファイルにデータファイル・チェックポイントSCNがあり、このSCNは、V$DATAFILE.CHECKPOINT_CHANGE#で参照できます。このSCNより小さいSCNを持つすべての変更がそのファイル内に存在することが保証されます。レベル0の増分バックアップがリストアされると、リストアされたデータファイルには、レベル0が作成されたときのチェックポイントSCNが含まれます。 レベル1の増分バックアップがファイルに適用されると、そのファイルのチェックポイントSCNは、レベル1の増分バックアップが作成されたときにファイルに含まれていたチェックポイントSCNに進みます。

  • 増分開始SCN

    このSCNは、レベル1の増分バックアップにのみ適用されます。バックアップには、SCNが増分開始SCN以上のすべてのブロックが含まれます。SCNが増分開始SCNより小さいブロックは、バックアップには含まれません。増分開始SCNは、多くの場合、レベル1のバックアップの親のチェックポイントSCNです。

  • ブロックSCN

    データファイルの各データ・ブロックには、ブロックに対する最新の変更が行われた時点のSCNが記録されます。

RMANは、ファイルのレベル1の増分バックアップの作成時に、ファイルを読み取り、すべてのブロックのSCNを確認し、SCNがこのバックアップの増分開始SCN以上であるブロックをバックアップします。差分バックアップの場合、増分開始SCNは最新のレベル1のバックアップのチェックポイントSCNです。累積バックアップの場合、増分開始SCNは最新のレベル0のバックアップのチェックポイントSCNです。

ブロック・チェンジ・トラッキングが有効になっている場合、RMANは、ビットマップを使用して、増分開始SCNからチェックポイントSCNまでの範囲内で変更されていないブロックの読取りを回避します。RMANは、読み取るすべてのブロックを確認し、ブロック内のSCNを使用してバックアップに含めるブロックを決定します。

増分バックアップ・アルゴリズムによって、RMANは、リカバリ中、変更されたデータが含まれるすべてのブロックを適用できます。これには、NOLOGGINGオプションで作成されたオブジェクトに対する変更も含まれます。したがって、NOLOGGINGの変更を行う前に作成されたバックアップをリストアする場合、これらの変更をリカバリする方法は、増分バックアップのみとなります。

8.8.4 増分バックアップを使用したリカバリについて

メディア・リカバリ中、RMANは、リストアされるファイルを確認し、増分バックアップを使用してそれらをリカバリできるかどうかを判断します。増分バックアップとアーカイブREDOログのいずれかを選択できる場合、Recovery Managerは常に増分バックアップを選択します。ブロック・レベルで変更を適用する方が、REDOを適用するより高速なためです。

RMANでは、リカバリ中、増分バックアップをデータファイルに適用するためにデータファイルの基本増分バックアップをリストアする必要はありません。たとえば、データファイルのイメージ・コピーをリストアし、増分バックアップを使用してそれらをリカバリできます。

関連項目:

増分バックアップおよびアーカイブREDOログの選択について

8.8.5 リカバリ・アプライアンスの永久増分バックアップ計画について

永久増分バックアップ計画では、Zero Data Loss Recovery Appliance (リカバリ・アプライアンス)にバックアップする場合に全体バックアップを繰り返し作成する必要がなくなります。リカバリ・アプライアンスは他のRMANバックアップ計画もサポートしていますが、継続的なバックアップ用として推奨される方法は永久増分バックアップ計画です。

永久増分バックアップ計画を使用する場合、1つの初期レベル0の全体バックアップのみと後続レベル1の増分バックアップを作成する必要があります。初期バックアップと後続増分は、イメージ・コピーではなくRMANバックアップ・セットである必要があります。

リカバリ・アプライアンスの永久増分バックアップ計画は、従来のRMAN設定の増分更新バックアップ計画とは異なります。RMANの場合、増分更新バックアップでは、初期イメージ・コピーが使用された後、最終的には全体バックアップにマージされる増分バックアップが使用されます。したがって、少なくとも1つの完全なイメージ・コピー、複数の増分バックアップ、および複数のアーカイブREDOログが常に存在します。

関連項目:

8.9 バックアップの保存方針について

CONFIGURE RETENTION POLICYコマンドを使用して、永続的かつ自動のバックアップの保存方針を作成できます。

バックアップの保存方針が有効な場合、RMANは、CONFIGUREコマンドで指定された条件に従って、データファイルまたは制御ファイルのバックアップを不要なバックアップ(つまり、今後リカバリに不要)とみなします。REPORT OBSOLETEコマンドを使用して不要なファイルを表示したり、DELETE OBSOLETEコマンドを使用して不要なファイルを削除できます。

長期にわたってバックアップを作成していると、古いバックアップは保存方針を満たすために必要ではなくなります。RMANは、不要になったファイルを識別できますが、自動的には削除しません。DELETE OBSOLETEコマンドを使用して、保存方針を満たすために必要ではなくなったファイルを削除する必要があります。

高速リカバリ領域が構成されている場合、新しいファイル用にリカバリ領域がさらに必要になると、不要になったファイルまたはテープにバックアップされたファイルがデータベースによって自動的に削除されます。ディスク割当て制限の規則は、保存方針の規則とは異なりますが、ディスク割当て制限を満たすために、保存方針に違反してファイルが削除されることはありません。「高速リカバリ領域が一杯になった場合の対応」を参照してください。

バックアップが不要になるのは、REPORT OBSOLETEまたはDELETE OBSOLETEで、ユーザー定義の保存方針に基づいて、バックアップがリカバリに必要ないと判断された場合です。バックアップが期限切れのバックアップとみなされるのは、RMANがクロスチェックを実行してファイルを検出できない場合のみです。したがって、不要とはファイルが必要ないことを意味し、期限切れとはファイルが検出されないことを意味します。

バックアップ保存方針は、全体またはレベル0のデータファイルおよび制御ファイルのバックアップにのみ適用されます。データファイルのコピーおよびプロキシ・コピーの場合、RMANがコピーまたはプロキシ・コピーを不要と判断すると、それらのコピーを削除できます。データファイルのバックアップ・セットの場合、バックアップ・セット内のすべてのデータファイルのバックアップが不要になると、RMANはそのバックアップ・セットを削除できます。

保存方針は、不要なアーカイブREDOログおよびレベル1の増分バックアップの削除またはレンダリングには関係しません。これらのファイルは、それらを必要とする全体バックアップが存在しなくなった場合に不要となります。保存方針は、データファイルおよび制御ファイルの全体バックアップまたはレベル0のバックアップのみでなく、アーカイブREDOログおよびレベル1の増分バックアップにも影響します。まず、RMANは不要なデータファイルおよび制御ファイルのバックアップを判断します。次に、RMANは、保持する必要がある最も古いデータファイルまたは制御ファイルのバックアップをリカバリする際に必要ないすべてのアーカイブ・ログおよびレベル1の増分バックアップを、不要とみなします。

注意:

RMANを使用せずに(メディア・マネージャのテープの保存方針などによって)バックアップを削除すると、RMANは自動保存方針を実装できません。テープ上のすべてのRMANバックアップがメディア・マネージャのカタログから削除されるまで、メディア・マネージャがそのテープを期限切れにしないように設定することをお薦めします。

保存方針を実装する場合、冗長性とリカバリ期間という相互に排他的な2つのオプションがあります。

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

8.9.1 リカバリ期間について

リカバリ期間とは、現在の時点からリカバリ可能ポイントまでの期間です。リカバリ可能ポイントは、想定されるPoint-in-Timeリカバリの最も早い時点(メディア障害後にリカバリ可能な最も早い時点)です。

たとえば、1週間のリカバリ期間を実装した場合、RMANは、データベースを最大7日前までリカバリできるように、全体バックアップおよび必要な増分バックアップとアーカイブ・ログを保持します。この保存方針は、次のように構成します。

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;

このコマンドを実行すると、各データファイルに対して、リカバリ可能ポイントより前のバックアップが1つ保持されます。たとえば、リカバリ期間が7の場合、次の条件を満たす各データファイルのバックアップが常に1つ存在する必要があります。 

SYSDATE - BACKUP CHECKPOINT TIME >= 7

この条件を満たす最新のバックアップよりも古いすべてのバックアップは不要となります。

図8-4に示す保存方針を設定するとします。保存方針の内容は、次のとおりです。

  • リカバリ期間は7日です。

  • データベースのバックアップは2週間ごとにスケジュールされ、次の日付に実行されます。

    • 1月1日

    • 1月15日

    • 1月29日

    • 2月12日

  • データベースはARCHIVELOGモードで実行され、アーカイブ・ログは、保存方針で必要とされる間のみ、ディスク上に保存されます。

図8-4 リカバリ期間1

図8-4の説明が続きます
「図8-4 リカバリ期間1」の説明

図8-4に示すように、現在の時点は1月23日、リカバリ可能ポイントは1月16日です。このため、リカバリには、1月15日のバックアップおよびログ順序500から850のアーカイブ・ログが必要です。500より前のログおよび1月1日のバックアップは、期間内の時点へのリカバリには必要ありません。

図8-5に、1週間後の同じ例を示します。

図8-5 リカバリ期間2

図8-5の説明が続きます
「図8-5 リカバリ期間2」の説明

この例では、現在の時点は1月30日、リカバリ可能ポイントは1月23日です。最新(1月29日)のバックアップがリカバリ期間に存在していますが、この場合でも1月15日のバックアップは不要ではありません。これは、1月29日のバックアップをリストアしても、期間の最初の時点(1月23日)にはリカバリできないためです。期間内のいずれの時点にもリカバリできるようにするために、1月15日のバックアップおよび順序500から1150のすべてのアーカイブ・ログを保存する必要があります。

関連項目:

リカバリ期間に基づく保存方針の構成

8.9.2 バックアップ冗長性について

リカバリ期間を使用すると、保持する必要があるバックアップの数が一定ではなく、バックアップ・スケジュールによって異なるため、ディスク領域の計画が複雑になる場合があります。これに対して、冗長性に基づく保存方針では、データファイルごとに保持する必要があるバックアップ数を指定します。

たとえば、次のように入力して冗長性を2に構成できます。

CONFIGURE RETENTION POLICY TO REDUNDANCY 2;

デフォルトの保存方針は、REDUNDANCY 1に構成されています。

関連項目:

冗長性に基づく保存方針の構成

8.9.3 不要なバックアップのバッチ削除について

REPORT OBSOLETEコマンドを実行すると、保存方針に従って、現在不要なバックアップを確認できます。

関連コマンドDELETE OBSOLETEを実行すると、保存方針に従って、不要なすべてのファイルを削除できます。DELETE OBSOLETEを定期的に実行して、不要なバックアップの格納によって消費される領域を最小限に抑えることができます。たとえば、週に1回実行するスクリプトでDELETE OBSOLETEを実行できます。

また、REPORTまたはDELETEコマンドでREDUNDANCYまたはRECOVERY WINDOWオプションを指定して、構成されている保存方針を無効にすることもできます。構成したリカバリ期間より短いリカバリ期間でDELETE OBSOLETEを使用すると、リカバリ可能な期間が事実上短縮されます。たとえば、構成した期間が14日にもかかわらず、DELETE OBSOLETE RECOVERY WINDOW OF 7 DAYSを実行した場合は、7日から14日前の間の時間にはリカバリできなくなります。

関連項目:

8.9.4 バックアップ保存方針および高速リカバリ領域の削除規則について

高速リカバリ領域を構成している場合、内部アルゴリズムを使用して、高速リカバリ領域のファイルから、構成されている保存方針を満たす必要がなくなったファイルが選択されます。

ディスク割当て制限の規則に従って高速リカバリ領域から削除するファイルが決定される際に、保存方針が違反されることはありません。ステータスがOBSOLETEのバックアップは、ディスク割当て制限の規則によって削除対象となっています。

RMANのステータスOBSOLETEは、常に保存方針に応じて決定されます。たとえば、RMANリポジトリ内のデータベースのバックアップがOBSOLETEとみなされる理由は、そのバックアップがリカバリ期間内の時点へのリカバリに必要ないか、または冗長であるためです。

高速リカバリ領域のOBSOLETEステータスの規則と、ディスク割当て制限で削除対象とする規則には、1つの重要な違いがあります。1000から2000のアーカイブ・ログがディスク上に存在し、現行のリカバリ期間に必要であるとします。これらのログをテープにバックアップする場合、保存方針では、ディスク上のログは必要であるとみなされます。一方、高速リカバリ領域のディスク割当て制限のアルゴリズムでは、ディスク上のログはテープにバックアップされているため、削除対象とみなされます。したがって、ディスク上のログはリポジトリではOBSOLETEステータスを持ちませんが、高速リカバリ領域では削除対象になります。

関連項目:

高速リカバリ領域の規則の削除