11g リリース1（11.1）
E05700-03
 目次 |
 索引 |
| Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド 11g リリース1（11.1） E05700-03 |
|
この章では、すべてのタイプのRecovery Managerバックアップを作成するために理解しておく必要がある一般的な概念について説明します。この章の内容は、次のとおりです。
バックアップを作成するRecovery Managerコマンドは、BACKUPです。Recovery ManagerのBACKUPコマンドでは、次のタイプのファイルのバックアップがサポートされています。
データベースは、ネットワーク構成ファイル、パスワード・ファイル、Oracleホームの内容などの他のタイプのファイルに依存していますが、これらのファイルはRecovery Managerではバックアップできません。同様に、Oracleの一部の機能（外部表など）には、データファイル、制御ファイルおよびREDOログ以外のファイルが必要な場合があります。Recovery Managerでは、これらのファイルをバックアップできません。リストにないファイルについては、Recovery Manager以外の方法でバックアップします。
Recovery ManagerでBACKUPコマンドを実行すると、出力は常に1つ以上のバックアップ・セットまたは1つ以上のイメージ・コピーになります。バックアップ・セットはRecovery Managerに固有の独自の形式ですが、 イメージ・コピーはファイルのビットごとのコピーです。デフォルトでは、Recovery Managerはバックアップ・セットを作成します。
BACKUPコマンドを使用すると、データベースの一貫性バックアップおよび非一貫性バックアップを作成できます。一貫性バックアップは、データベースが一貫性のある状態のときに実行します。SHUTDOWN NORMAL、SHUTDOWN IMMEDIATEまたはSHUTDOWN TRANSACTIONALコマンドを使用して停止すると、データベースは一貫性のある状態になります。一貫性のある状態での停止では、すべてのREDOがデータファイルに適用されたことが保証されます。データベースをマウントし、この時点でバックアップを作成すると、後でデータベース・バックアップをリストアし、メディア・リカバリを実行せずにオープンすることができます。
一貫性のないデータベース・バックアップを非一貫性バックアップといいます。インスタンスでの障害の発生後またはSHUTDOWN ABORTコマンドの実行後に作成されたバックアップと同様に、データベースがオープンされているときに作成されたバックアップには一貫性がありません。非一貫性バックアップからデータベースをリストアする場合、Oracleでは、データベースをオープンする前に、メディア・リカバリを実行し、REDOログ内の保留中の更新情報を適用する必要があります。
データベースがARCHIVELOGモードで実行され、アーカイブREDOログおよびデータファイルをバックアップするかぎり、非一貫性バックアップを適切なバックアップおよびリカバリ計画の基礎にすることができます。非一貫性バックアップでは、データベースを完全に保護するバックアップを作成するためにデータベースを停止する必要がないため、優れた可用性が実現されます。
オンラインの表領域またはデータベースのユーザー管理バックアップを実行すると、データベース・ライターによるファイルの更新と同時に、オペレーティング・システム・ユーティリティによってデータファイルのバックアップが作成される場合があります。ユーティリティは、更新途中の状態のブロックを読み取ることができるため、バックアップ・メディアにコピーされるブロックの前半は更新されていても、後半には古いデータが含まれていることがあります。このタイプの論理的な破損は、分裂ブロックと呼ばれます。つまり、SCNに関して一貫性のないブロックです。このバックアップを後でリストアし、ブロックをリカバリする必要がある場合は、ブロックを使用できないため、リカバリは失敗します。
ユーザー管理のオンライン・バックアップを実行する場合は、BEGIN BACKUP句を指定してALTER DATABASEまたはALTER TABLESPACE文を使用して、データファイルをバックアップ・モードにする必要があります。表領域がバックアップ・モードに設定されている場合、データベースは、ブロックを変更する前に、ブロック全体の変更前のイメージをREDOストリームに書き込みます。データベースは、ブロックに対する変更をオンラインREDOログに記録もします。また、バックアップ・モードでは、ファイルがバックアップ・モードから削除されるまで、データファイル・チェックポイントがフリーズされます。Oracle Databaseでは、サード・パーティのバックアップ・ツールでデータ・ブロックのコピーの前にファイル・ヘッダーがコピーされることを保証できないため、このようなセーフガードが実行されます。
ユーザー管理ツールとは異なり、Recovery Managerでは、データ・ブロックの形式が認識されるため、追加のロギングまたはバックアップが必要ありません。Recovery Managerでは、分裂ブロックがバックアップされないことが保証されています。Recovery Managerによるバックアップ中、データベース・サーバー・セッションは各データ・ブロックを読み取り、ブロック・ヘッダーとフッターを比較することによって、分裂していないかどうかを確認します。ブロックが分裂している場合、セッションはそのブロックを再度読み取ります。同じ分裂が検出された場合、ブロックは永続的に破損しているとみなされます。また、Recovery Managerでは、ブロックが読み取られる順序が認識されているため、データファイルのヘッダーのチェックポイントをフリーズする必要はありません。このため、そのファイルに最適なチェックポイントを取得できます。
|
参照:
Recovery Managerを使用しない場合にオンラインの表領域をバックアップする方法については、「オンラインの表領域およびデータファイルのユーザー管理バックアップの作成」を参照してください。 |
Recovery ManagerでBACKUPコマンドを実行すると、1つ以上のバックアップ・セットまたはイメージ・コピーを作成できます。デフォルトでは、出力先がディスクの場合もメディア・マネージャの場合も、バックアップ・セットが作成されます。
この項の内容は、次のとおりです。
Recovery Managerは、バックアップ・データをバックアップ・セット（Recovery Managerバックアップの最小単位）と呼ばれる論理構造に格納できます。バックアップ・セットには、1つ以上のデータファイル、アーカイブREDOログ、制御ファイルまたはサーバー・パラメータ・ファイルのデータが含まれます。バックアップ・セットの作成およびアクセスは、Recovery Managerによってのみ行われます。バックアップ・セットは、Recovery Managerによってテープ・ドライブやテープ・ライブラリなどのメディア・マネージャにバックアップを書き込むことができる唯一の形式です。
バックアップ・セットには、1つ以上のバイナリ・ファイルがRecovery Manager固有の形式で含まれます。このファイルは、バックアップ・ピースと呼ばれます。1つのバックアップ・セットに、複数のデータファイルを含めることができます。たとえば、1つのバックアップ・ピースで構成される1つのバックアップ・セットに、10個のデータファイルをバックアップできます。この場合、Recovery Managerでは、1つのバックアップ・ピースが出力として作成されます。バックアップ・セットには、このバックアップ・ピースのみが含まれます。
BACKUPコマンドにSECTION SIZEパラメータを指定すると、Recovery Managerによってマルチセクション・バックアップが作成されます。これは、複数のチャネルでパラレルに作成される単一の大規模なファイルのバックアップです。各チャネルによって、1つのバックアップ・ピースが作成されます。各バックアップ・ピースには、バックアップされるファイルのファイル・セクションが1つ含まれます。
マルチセクション・バックアップ以外のバックアップでは、Recovery Managerは、正常に完了したバックアップ・セットのみをリポジトリに記録します。部分バックアップ・セットのようなものはありません。これは、Recovery Managerメタデータに部分的なバックアップ・セットのレコードが含まれる可能性がある失敗したマルチセクション・バックアップとは異なります。後者の場合は、DELETEコマンドを使用して、部分的なバックアップ・セットを削除する必要があります。
Recovery Managerは、データファイルをバックアップ・セットにバックアップする際に、未使用ブロックの圧縮を使用してデータファイル・ブロックをスキップできます。Recovery Managerは、一度も使用されていないブロックを常にスキップします。『Oracle Databaseバックアップおよびリカバリ・リファレンス』BACKUP AS BACKUPSETエントリに示されている特定の条件では、現在使用されていないブロックもスキップします。このため、通常、データファイルのバックアップ・セットはデータファイルのコピーよりサイズが小さく、書込みにかかる時間が短くなります。未使用ブロックの圧縮は、Recovery Managerでバックアップ・ピースにデータファイルを書き込む方法の基本であり、無効にはできません。
Recovery Managerでは、バックアップ・セットのバイナリ圧縮もサポートされています。サポートされているアルゴリズムは、BZIP2（デフォルト）およびZLIBです。BZIP2アルゴリズムは最大の圧縮用に最適化され、ZLIBアルゴリズムはCPUの効率用に最適化されます。BZIP2は、ZLIBより多くのCPUリソースを消費しますが、通常はより圧縮されたバックアップを作成します。ZLIB圧縮の場合、Oracle Advanced Compressionオプションが必要なため、COMPATIBLE初期化パラメータを11.0.0以上に設定する必要があります。
Recovery Managerは、バックアップ・セットの内容を圧縮してからディスクに書き込みます。Recovery Manager圧縮を使用すると、リカバリ中に特別な解凍手順を実行する必要がありません。
UNDOのバックアップの最適化では、Recovery Managerは、トランザクションがすでにコミットされているためバックアップのリカバリに不要となったUNDOを除外します。バックアップの最適化を有効または無効にすることができますが、UNDOのバックアップの最適化は組込み動作です。
|
参照:
|
Recovery Managerでは、バックアップ・セットのバックアップの暗号化がサポートされています。ウォレットベースの透過的暗号化またはパスワードベースの暗号化（あるいはその両方）を使用できます。CONFIGURE ENCRYPTIONコマンドを使用すると、永続的な透過的暗号化を構成できます。パスワードベースの暗号化を指定するには、Recovery Managerセッション・レベルでSET ENCRYPTIONコマンドを使用します。
Recovery Managerを使用してディスクに暗号化バックアップを作成するには、データベースでAdvanced Security Optionを使用している必要があります。Oracle Secure Backup SBTは、暗号化Recovery Managerバックアップをテープに直接作成するためにサポートされている唯一のインタフェースです。Advanced Security Optionは、Oracle Secure Backup SBTに暗号化バックアップを作成する場合は必要ありません。
FORMAT句を使用して名前を指定することができます。FORMATパラメータを指定しない場合、Recovery Managerは、%U置換変数を含む一意のファイル名をデフォルトのバックアップ場所に自動的に生成します。%Uによって生成されるSBTバックアップ・ピース名の例は12i1nk47_1_1です。ディスク上のバックアップ・ピースの例は、次のとおりです。
/d1/orcva/TEST/backupset/2007_12_12/o1_mf_nnndf_TAG20071212T162825_2qyl99jm_.bkp
FORMAT句では、一意のファイル名を生成するために%U以外の置換変数がサポートされています。たとえば、データベースの名前を生成するために%d、DBID用に%I、タイムスタンプ用に%tなどを使用できます。
最大4つのFORMATパラメータを指定できます。複数のFORMATパラメータを指定すると、複数のコピーを指定する場合にのみRecovery Managerで複数のFORMATパラメータを使用できます。BACKUP ... COPIES、SET BACKUP COPIESまたはCONFIGURE ... BACKUP COPIESコマンドを使用すると、複数のコピーを作成できます。
|
参照:
|
デフォルトでは、バックアップ・セットは、1つのバックアップ・ピースで構成されます。各バックアップ・ピースのサイズを制限するには、CONFIGURE CHANNELまたはALLOCATE CHANNELコマンドのMAXPIECESIZEオプションを指定します。このオプションによって、バックアップ・ピースのサイズが指定したバイト数に制限されます。バックアップ・セットの合計サイズが指定したバックアップ・ピースのサイズを超えた場合、Recovery Managerは、バックアップ・セットの内容を保持する複数の物理ピースを作成します。
このオプションは、複数のテープにまたがるバックアップ・ピースを管理できないメディア・マネージャに使用できます。たとえば、最大容量が10GBのテープに、80GBのデータを保持するバックアップ・セットを作成する必要がある場合、メディア・マネージャで使用するテープに格納できる10GBのバックアップ・ピースを作成するように、Recovery Managerに指示する必要があります。この場合、バックアップ・セット・メディアは8つのテープから構成されます。SBT 2.0をサポートしているメディア・マネージャの場合、サポートするバックアップ・ピースの最大サイズを示す値をRecovery Managerに戻すことができるため、Recovery Managerはその値をバックアップ・アクティビティの計画に使用できます。
BACKUPコマンドにSECTION SIZEパラメータを指定すると、Recovery Managerによってマルチセクション・バックアップが作成されます。この場合、1つののバックアップ・セットに複数のバックアップ・ピースを含めることができます。各バックアップ・ピースにはファイル・セクションが含まれます。マルチセクション・バックアップの目的は、複数のチャネルで大規模なファイルをパラレルでバックアップできるようにすることです。
|
参照:
|
BACKUPコマンドのbackupSpec句を使用すると、バックアップするオブジェクトを指定できます。backupSpec句を1つ指定するごとに、1つ以上のバックアップ・セットが作成されます。
バックアップ・セットの合計数および合計サイズは、ほとんどの場合、Recovery Managerの内部アルゴリズムに基づいています。ただし、CONFIGUREまたはBACKUPコマンドのMAXSETSIZEパラメータを使用して、Recovery Managerの動作に影響を及ぼすことができます。このパラメータを使用してバックアップ・セットのサイズを制限することによって、セット内のファイル数を間接的に制限でき、場合によっては、Recovery Managerに追加のバックアップ・セットを作成させることができます。また、BACKUP ... FILESPERSETを指定して、各バックアップ・セット内のファイルの最大数を指定することもできます。
|
参照:
|
バックアップ・セットの作成時に、Recovery Managerは、ディスクから複数のファイルを同時に読み取って、同じバックアップ・セットにそれらのブロックを書き込むことができます。たとえば、Recovery Managerは、2つのデータファイルから同時に読取りを行って、それらのデータファイルのブロックを単一のバックアップ・ピースに組み合せることができます。複数のファイルからのブロックの組合せは、バックアップの多重化と呼ばれます。これに対して、イメージ・コピーは多重化されません。
|
注意: Recovery Managerによってデータファイルのマルチセクション・バックアップが作成された場合、そのデータファイルは他のすべてのデータファイルまたはファイル・セクションとは多重化されません。 |
図7-1に示すように、Recovery Managerは、1つのバックアップ・ピースのみを含むバックアップ・セットに3つのデータファイルをバックアップできます。このバックアップ・ピースには、3つの入力データファイルのデータ・ブロックが組み合されて格納されます。
Recovery Managerによる多重化は、複数の要因によって決定されます。たとえば、各バックアップ・セットに格納されるデータファイルの数は、BACKUPコマンドのFILESPERSETパラメータによって決定されます。Recovery Managerが同時に読み取ることができるデータファイルの数は、ALLOCATE CHANNELまたはCONFIGURE CHANNELのMAXOPENFILESパラメータによって定義されます。基本的な多重化アルゴリズムは、次のとおりです。
この数は、FILESPERSET設定および各チャネルによって読み込まれるファイル数の最小値です。FILESPERSETのデフォルトは64です。
これは、同時に読み取られ、同じバックアップ・ピースに書き込まれる入力ファイルの数です。多重化のレベルは、MAXOPENFILESおよび各バックアップ・セット内のファイル数の最小値です。MAXOPENFILESのデフォルトは8です。
1つのチャネルで12のデータファイルをバックアップするとします。各バックアップ・セット内のファイル数は4です。多重化のレベルは、この数と8の小さいほうになります。したがって、ブロックは、チャネルによって4つのデータファイルから各バックアップ・ピースに同時に書き込まれます。
次に、1つのチャネルで50のデータファイルをバックアップするとします。各バックアップ・セット内のファイル数は50です。多重化のレベルは、この数と8の小さいほうです。したがって、ブロックは、チャネルによって8つのデータファイルから各バックアップ・ピースに同時に書き込まれます。
Recovery Managerによるバックアップ・セットの多重化は、メディア・マネージャによる多重化とは異なります。メディア・マネージャによる多重化のタイプの1つとして、メディア・マネージャが、複数のRecovery Managerチャネルからの同時出力を単一のシーケンシャル・デバイスに書き込んだ場合に発生するものがあります。また、別のタイプとして、バックアップによって同じテープ上にデータベース・ファイルとデータベース以外のファイルが混在した場合に発生するものもあります。
|
参照:
|
プロキシ・コピーでは、Recovery Managerは、プロキシ・コピー機能をサポートしているメディア・マネージャに、データ送信の制御を移します。プロキシ・コピーはこの機能をサポートしているメディア・マネージャでのみ使用でき、タイプがDISKのチャネルでは使用できません。BACKUPコマンドのPROXYオプションを使用して、バックアップでプロキシ・コピーを実行することを指定します。
BACKUP PROXYコマンドでバックアップするファイルごとに、Recovery Managerは、プロキシ・コピーを実行できるかどうかをメディア・マネージャに問い合せて確認します。メディア・マネージャがファイルのプロキシ・コピーを実行できない場合、Recovery Managerは、PROXYオプションを使用しなかった場合と同様にファイルをバックアップします。（PROXY ONLYオプションを使用している場合に、プロキシ・コピーが実行できない場合は、Recovery Managerはバックアップを行いません。）
制御ファイルはプロキシ・コピーではバックアップされません。制御ファイルのバックアップ操作でPROXYオプションを指定した場合、このオプションは自動的に無視され、制御ファイルのバックアップが行われます。
イメージ・コピーは、1つのデータファイル、アーカイブREDOログ・ファイルまたは制御ファイルの正確なコピーです。イメージ・コピーはRecovery Manager固有の形式では格納されません。これらは、オペレーティング・システム・コマンドでファイルをコピーした場合と同じ形式で格納されます。イメージ・コピーは、Recovery Managerのリストアおよびリカバリ操作中に使用できます。また、Recovery Manager以外のリストアおよびリカバリ方法でもイメージ・コピーを使用できます。
イメージ・コピーを作成してRecovery Managerリポジトリに記録するには、Recovery ManagerのBACKUP AS COPYコマンドを実行します。また、ディスクのデフォルトのバックアップ・タイプをイメージ・コピーとして構成することもできます。コピーの作成には、データベース・サーバー・セッションが使用されます。このサーバー・セッションが、ファイル内のブロックの検証やRecovery Managerリポジトリへのイメージ・コピーの記録などの処理を実行します。
バックアップ・ピースと同様に、FORMAT変数は、イメージ・コピーの名前の指定にも使用されます。イメージ・コピーの場合、デフォルトの書式%U（「バックアップ・ピースのファイル名」を参照）の定義が異なっています。次に、%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が使用されます。
例7-1では、ファイル名の先頭に/maindisk/oradata/usersが付くデータファイルを、先頭に/backups/users_tsが付くファイル名に変更してコピーします。
BACKUP AS COPY TABLESPACE users DB_FILE_NAME_CONVERT ('/maindisk/oradata/users', '/backups/users_ts');
RESTOREコマンドを実行すると、デフォルトでは、イメージ・コピー・バックアップをコピーすることによって、データファイルまたは制御ファイルが元の場所にリストアされます。バックアップ・セットではなく、イメージ・コピーが選択されます。バックアップ・セットを使用すると、リストアするファイルを検索するためにバックアップ・セット全体が読み取られ、オーバーヘッドが増加するためです。
現行のデータファイルをリストアおよびリカバリする必要があり、ディスク上に使用可能なイメージ・コピーが存在する場合は、Recovery Managerでイメージ・コピーを元の場所にコピーする必要はありません。リストア対象のデータファイルのかわりに、イメージ・コピーを使用できます。このタスクの実行方法については、「コピーへの切替え後の完全リカバリの実行」を参照してください。
|
参照:
|
Recovery Managerでは、ディスク上にファイルのイメージ・コピーを作成するオペレーティング・システム固有のファイル・コピー・コマンドや、サード・パーティ・ユーティリティなど、Recovery Manager以外のメカニズムで作成したイメージ・コピーを使用できます。このタイプのコピーは、ユーザー管理バックアップまたはオペレーティング・システムのバックアップと呼ばれます。
CATALOGコマンドを実行すると、既存のイメージ・コピーを検査して、そのメタデータをRecovery Managerリポジトリに入力できます。ただし、CATALOGコマンドでは次の処理は行われません。
これらのファイルは、カタログへの追加後、Recovery Managerによって生成されたイメージ・コピーの場合と同様にRESTOREまたはSWITCHコマンドで使用できます。
ミラー化されたディスク・ボリューム上にデータファイルを格納しているサイトでは、ミラー化の解除によってイメージ・コピーの作成が可能になります。ミラー化を解除した後で、新しいユーザー管理コピーが存在することをRecovery Managerに通知して、そのコピーをバックアップの対象にします。CHANGE ... UNCATALOGコマンドの実行によってコピーが使用できなくなった場合は、Recovery Managerに通知する必要があります。
|
参照:
|
Recovery Managerでは、次の2つの方法を使用して、バックアップの同じコピーを複数作成できます。
BACKUP ... COPIESコマンドでバックアップを多重化します。この場合、Recovery Managerは各バックアップ・セットの複数のコピーを作成します。
BACKUP BACKUPSETまたはBACKUP COPY OFコマンドで、そのバックアップ・セットまたはイメージ・コピーをバックアップします。
データファイル、アーカイブREDOログ・ファイル、サーバー・パラメータ・ファイルおよび制御ファイルをバックアップ・ピースにバックアップする場合、Recovery Managerは、多重バックアップ・セットを作成して、1つのBACKUPコマンドで、異なるバックアップ先にバックアップ・セットの各バックアップ・ピースの同じコピーを最大4つ作成できます。イメージ・コピーを作成するバックアップ操作では、多重化はサポートされていません。
BACKUPコマンドの使用時に、CONFIGURE、SETまたはBACKUPコマンドでCOPIESパラメータを使用して、バックアップ・セットの多重化を指定できます。Recovery Managerでは、ディスクまたはテープにバックアップを多重化できますが、テープとディスクにバックアップを同時に多重化することはできません。テープへのバックアップ時に、コピーの数が、使用可能なテープ・デバイスの数を超えないようにしてください。
BACKUPコマンドのFORMATパラメータでは、多重バックアップの出力先を指定します。次の例では、データファイル7のバックアップのコピーを3つ作成します。
BACKUP DEVICE TYPE DISK COPIES 3 DATAFILE 7 FORMAT '/disk1/%U','?/oradata/%U','?/%U';
この場合、Recovery Managerは、各バックアップ・ピースの最初のコピーを/disk1に、2番目のコピーを?/oradataに、3番目のコピーをOracleホームに格納します。Recovery Managerは、それぞれ異なる一意のバックアップ・セット・キーを持つ3つのバックアップ・セットを作成するわけではありません。Recovery Managerは、一意のキーを持つ1つのバックアップ・セットを作成して、そのバックアップ・セット内の各バックアップ・ピースの同じコピーを3つ生成します。
|
参照:
|
BACKUPコマンドを使用すると、既存のバックアップ・セットおよびイメージ・コピーをバックアップできます。
Recovery ManagerのBACKUP BACKUPSETコマンドを使用すると、ディスク上に作成したバックアップ・セットをバックアップできます。このコマンドは、複数のメディア間でバックアップを実行する場合に有効です。
バックアップ・セットのいずれかのコピーが破損または欠落していることが検出された場合、Recovery Managerは、同じバックアップ・セットの他のコピーを検索します。この動作は、複数のアーカイブ先に存在するアーカイブREDOログをRecovery Managerがバックアップする際の動作に似ています。
例7-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
BACKUP BACKUPSETを使用して、バックアップ領域の割当てを管理することもできます。例7-3では、1週間以上前に作成されたバックアップ・セットをディスクからテープにバックアップして、それらをディスクから削除しています。
BACKUP DEVICE TYPE sbt BACKUPSET COMPLETED BEFORE 'SYSDATE-7' DELETE INPUT;
ここで使用しているDELETE INPUTは、DELETE ALL INPUTと同等であり、Recovery Managerは、バックアップ・セットのすべての既存のコピーを削除します。バックアップを4つの場所に多重化している場合、Recovery Managerは、バックアップ・セットのピースのコピーを4つともすべて削除します。
BACKUP COPY OFコマンドを使用すると、データベース・ファイルの既存のイメージ・コピーをバックアップ・セットまたはイメージ・コピーのいずれかとしてバックアップできます。このコマンドを使用する際は、コマンドで指定するすべてのデータファイルのイメージ・コピーがすでに存在している必要があります。1つのデータファイルに複数のコピーが存在する場合は、最新のコピーが使用されます。表領域またはデータベース全体を指定すると、データベースまたは表領域にデータファイルがあり、対応するイメージ・コピーのバックアップがない場合、Recovery Managerはエラーを発行します。
制御ファイルおよびサーバー・パラメータ・ファイルの最新のバックアップを作成しておくと、多くのリカバリ状況で非常に役立ちます。このようなバックアップの作成をサポートするために、データベースには、制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップ機能が備わっています。自動バックアップは、BACKUPコマンドで明示的に要求された現行の制御ファイルのバックアップとは関係なく行われます。
制御ファイルの自動バックアップによって、Recovery Managerは、現行の制御ファイル、リカバリ・カタログおよびサーバー・パラメータ・ファイルにアクセスできない場合でも、データベースをリカバリできます。自動バックアップの格納に使用されるパスは標準的な書式に準拠しているため、Recovery Managerは、その自動バックアップからサーバー・パラメータ・ファイルを検索してリストアできます。リストアされたサーバー・パラメータ・ファイルを使用してインスタンスを起動すると、Recovery Managerによって自動バックアップから制御ファイルがリストアされます。制御ファイルをマウントした後、マウントされた制御ファイル内のRecovery Managerリポジトリを使用して、データファイルをリストアします。
CONFIGURE CONTROLFILE AUTOBACKUPがONに設定されている場合、Recovery Managerは、正常なBACKUPコマンドの最後に、制御ファイルおよび現行のサーバー・パラメータ・ファイル（データベースの起動に使用された場合）を自動的にバックアップします。データベースがARCHIVELOGモードで実行されている場合、データベースの構造上の変更によって制御ファイルの内容が影響を受けると、Recovery Managerは、制御ファイルの自動バックアップを作成します。
自動バックアップは、バックアップ・ジョブ中に割り当てられた最初のチャネルによって作成され、独自のバックアップ・セットに格納されます。データベースの構造変更後の自動バックアップの場合は、構造変更に関連付けられたサーバー・プロセスによってバックアップが作成されます。
サーバー・パラメータ・ファイルがデータベースによって使用されている場合は、Recovery Managerによって、制御ファイルの自動バックアップと同じバックアップ・セットにバックアップされます。自動バックアップが完了すると、バックアップ・ピースの完全パスおよびデバイス・タイプを含むメッセージが、データベースによって自動診断リポジトリにあるアラート・ログに書き込まれます。
制御ファイルの自動バックアップのファイル名には、すべてのデバイス・タイプのデフォルトの書式%Fが使用されるため、Recovery Managerは、リポジトリを使用しなくても、ファイルの場所を判断してそのファイルをリストアできます。CONFIGURE CONTROLFILE AUTOBACKUP FORMATコマンドを使用すると、別の書式を指定できます。ただし、すべての自動バックアップの書式に%F変数を含める必要があります。デフォルトの書式を使用しない場合は、障害リカバリ中に、自動バックアップの生成に使用された書式を指定する必要があります。そうしない場合、Recovery Managerは自動バックアップをリストアできません。
|
参照:
|
デフォルトでは、Recovery Managerは全体バックアップを作成します。データファイルの全体バックアップには、バックアップするファイルのすべての割当て済ブロックが含まれます。データファイルの全体バックアップは、イメージ・コピーである場合があります。この場合は、すべてのデータ・ブロックがバックアップされます。また、バックアップ・セットに格納される場合もあります。この場合は、使用されていないデータファイル・ブロックはスキップされます。
全体バックアップは、Recovery Managerバックアップのデフォルト・タイプです。全体バックアップは、後続の増分バックアップには影響せず、増分バックアップ計画の一部とはみなされません。イメージ・コピーにはデータファイル内のすべてのデータ・ブロックが含まれるため、イメージ・コピーは常に全体バックアップとなります。バックアップ・セットにはデータファイル内のすべてのデータ・ブロックが含まれる可能性があるため、バックアップ・セットはデフォルトでは全体バックアップとなります。ただし、未使用ブロックの圧縮は、未使用のブロックは除外され、現在使用されていないブロックが除外される場合もあることを意味します（「バックアップ・セットの圧縮」を参照）。
全体バックアップに対し、増分バックアップでは、以前のバックアップ以降に変更されたデータ・ブロックのみがコピーされます。Recovery Managerを使用して、データファイル、表領域またはデータベース全体の増分バックアップを作成できます。全体バックアップを増分バックアップ計画に含めて、後続の増分バックアップの親として指定することはできません。
Recovery Managerでは、マルチレベル増分バックアップを作成できます。各増分レベルは、0または1の値で示されます。レベル0の増分バックアップは、後続の増分バックアップの基本となるバックアップであり、データが含まれるすべてのブロックをコピーします。レベル0のデータベース・バックアップは、バックアップ・セットまたはイメージ・コピーとして作成できます。
レベル0の増分バックアップと全体バックアップの違いは、全体バックアップは増分計画には含まれないという点のみです。したがって、全体バックアップは、レベルが0より大きい増分バックアップの親となります。
レベル1の増分バックアップは、次のいずれかのタイプです。
デフォルトでは、増分バックアップは、差分バックアップに設定されています。
バックアップ・ファイルのサイズは、変更されたブロック数、増分バックアップ・レベルおよび増分のタイプ（差分または累積）によって異なります。
レベル1の差分バックアップでは、Recovery Managerは、レベル1（累積または差分）またはレベル0の最新の増分バックアップ以降に変更されたすべてのブロックをバックアップします。たとえば、レベル1の差分バックアップでは、Recovery Managerはレベル1の最新のバックアップを確認して、そのバックアップ以降に変更されたすべてのブロックをバックアップします。レベル1のバックアップが使用できない場合、Recovery Managerは、レベル0の基本バックアップ以降に変更されたすべてのブロックをコピーします。
現行または親のインカネーションでレベル0のバックアップが使用できない場合の動作は、互換性モード設定によって異なります。互換性が10.0.0以上の場合、Recovery Managerは、ファイルの作成以降に変更されたすべてのブロックをコピーします。それ以外の場合、Recovery Managerは、以前のリリースと同様に、レベル0のバックアップを生成します。
図7-2に示す例では、毎週、次の処理が実行されます。
レベル0の増分バックアップによって、このデータベースでこれまでに使用されたすべてのブロックがバックアップされます。
月曜日から土曜日には、レベル1の差分増分バックアップによって、レベル1またはレベル0の最新の増分バックアップ以降に変更されたすべてのブロックが毎日バックアップされます。つまり、月曜日のバックアップでは、日曜日のレベル0のバックアップ以降に変更されたブロックがコピーされ、火曜日のバックアップでは、月曜日のレベル1のバックアップ以降に変更されたブロックがコピーされる、というように実行されます。
レベル1の累積バックアップでは、Recovery Managerは、現行または親のインカネーションでレベル0の最新の増分バックアップ以降に使用されたすべてのブロックをバックアップします。累積増分バックアップでは、特定のレベルの1つの増分バックアップのみが必要となるため、リストアに必要な作業が軽減されます。累積バックアップでは、同じレベルの以前のバックアップによって実行された作業が繰り返されるため、差分バックアップよりも多くの領域および時間が必要です。
図7-3に示す例では、毎週、次の処理が実行されます。
レベル0の増分バックアップによって、このデータベースでこれまでに使用されたすべてのブロックがバックアップされます。
レベル1の累積増分バックアップによって、レベル0の最新のバックアップ以降に変更されたすべてのブロックがコピーされます。レベル0の最新のバックアップは日曜日に作成されているため、月曜日から土曜日まで毎日行われるレベル1のバックアップでは、日曜日のバックアップ以降に変更されたすべてのブロックがバックアップされます。
増分バックアップのブロック・チェンジ・トラッキング機能を使用すると、各データファイル内の変更されたブロックをブロック・チェンジ・トラッキング・ファイルに記録することによって増分バックアップのパフォーマンスが向上します。このファイルは、データベース領域に格納される小さなビットマップ・ファイルです。REDOの生成時に、Recovery Managerは、変更されたブロックを追跡します。
ブロック・チェンジ・トラッキングを有効にした場合、Recovery Managerは、チェンジ・トラッキング・ファイルを使用して、増分バックアップ用の変更されたブロックを識別します。これによって、データファイル内のすべてのブロックをスキャンする必要がなくなります。レベル0の増分バックアップにはすべてのブロックが含まれるため、増分レベルが0（ゼロ）より大きい場合にのみ、Recovery Managerはブロック・チェンジ・トラッキングを使用します。
Recovery Managerで増分バックアップの作成に使用されるアルゴリズムを理解するには、次の概念を理解しておく必要があります。
すべてのデータファイルにデータファイル・チェックポイントSCNがあります。このSCNは、V$DATAFILE.CHECKPOINT_CHANGE#で参照できます。このSCNより小さいSCNを持つすべての変更がそのファイル内に存在することが保証されます。レベル0の増分バックアップがリストアされると、リストアされたデータファイルには、レベル0が作成されたときのチェックポイントSCNが含まれます。レベル1の増分バックアップがファイルに適用されると、そのファイルのチェックポイントSCNは、増分レベル1が作成されたときにファイルに含まれていたチェックポイントSCNに進みます。
このSCNは、レベル1の増分バックアップにのみ適用されます。バックアップには、SCNが増分開始SCN以上のすべてのブロックが含まれます。SCNが増分開始SCNより小さいブロックは、バックアップには含まれません。増分開始SCNは、多くの場合、レベル1のバックアップの親のチェックポイントSCNです。
データファイルの各データ・ブロックには、ブロックに対する最新の変更が行われた時点のSCNが記録されます。
Recovery Managerは、ファイルのレベル1の増分バックアップの作成時に、ファイルを読み取り、すべてのブロックのSCNを確認し、SCNがこのバックアップの増分開始SCN以上であるブロックをバックアップします。差分バックアップの場合、増分開始SCNは最新のレベル1のバックアップのチェックポイントSCNです。累積バックアップの場合、増分開始SCNは最新のレベル0のバックアップのチェックポイントSCNです。
ブロック・チェンジ・トラッキングが有効になっている場合、Recovery Managerは、ビットマップを使用して、増分開始SCNからチェックポイントSCNまでの範囲内で変更されていないブロックの読取りを回避します。Recovery Managerは、読み取るすべてのブロックを確認し、ブロック内のSCNを使用してバックアップに含めるブロックを決定します。
増分バックアップ・アルゴリズムによって、Recovery Managerは、リカバリ中、変更されたデータが含まれるすべてのブロックを適用できます。これには、NOLOGGINGオプションで作成されたオブジェクトに対する変更も含まれます。したがって、NOLOGGINGの変更を行う前に作成されたバックアップをリストアする場合、それらのバックアップをリカバリする方法は、増分バックアップのみとなります。
メディア・リカバリ中、Recovery Managerは、リストアされるファイルを確認し、増分バックアップを使用してそれらをリカバリできるかどうかを判断します。増分バックアップとアーカイブREDOログのいずれかを選択できる場合、Recovery Managerは常に増分バックアップを選択します。ブロック・レベルで変更を適用するほうが、REDOを適用するより高速なためです。
Recovery Managerでは、リカバリ中、増分バックアップをデータファイルに適用するためにデータファイルの基本増分バックアップをリストアする必要はありません。たとえば、データファイルのイメージ・コピーをリストアし、増分バックアップを使用してそれらをリカバリできます。
CONFIGURE RETENTION POLICYコマンドを使用すると、永続的かつ自動的なバックアップの保存方針を作成できます。バックアップの保存方針が有効な場合、Recovery Managerは、CONFIGUREコマンドで指定された基準に従って、データファイルまたは制御ファイルのバックアップを不要なバックアップ（リカバリに必要ではなくなった）とみなします。REPORT OBSOLETEコマンドを使用して不要なファイルを表示し、DELETE OBSOLETEコマンドを使用してそれらのファイルを削除できます。
長期にわたってバックアップを作成していると、古いバックアップは保存方針を満たすために必要ではなくなります。Recovery Managerは、不要になったファイルを識別できますが、自動的には削除しません。DELETE OBSOLETEコマンドを使用して、保存方針を満たすために必要ではなくなったファイルを削除する必要があります。
フラッシュ・リカバリ領域が構成されている場合、新しいファイル用にリカバリ領域がさらに必要になると、不要になったファイルまたはすでにテープにバックアップされたファイルがデータベースによって自動的に削除されます。ディスク割当て制限の規則は、保存方針の規則とは異なりますが、ディスク割当て制限を満たすために、保存方針に違反してファイルが削除されることはありません。詳細は、「フラッシュ・リカバリ領域が一杯になった場合の対応」を参照してください。
バックアップが不要になるのは、REPORT OBSOLETEまたはDELETE OBSOLETEで、ユーザー定義の保存方針に基づいて、バックアップがリカバリに必要ないと判断された場合です。バックアップが期限切れのバックアップとみなされるのは、Recovery Managerがクロスチェックを実行してファイルを検出できない場合のみです。したがって、不要とはファイルが必要ないことを意味し、期限切れとはファイルが検出されないことを意味します。
バックアップ保存方針は、全体またはレベル0のデータファイルおよび制御ファイルのバックアップにのみ適用されます。データファイルのコピーおよびプロキシ・コピーの場合、Recovery Managerがコピーまたはプロキシ・コピーを不要と判断すると、それらのコピーを削除できます。データファイルのバックアップ・セットの場合、バックアップ・セット内のすべてのデータファイルのバックアップが不要になると、Recovery Managerはそのバックアップ・セットを削除できます。
保存方針は、アーカイブREDOログおよびレベル1の増分バックアップに直接は影響しません。これらのファイルは、それらを必要とする全体バックアップが存在しなくなった場合に不要となります。保存方針は、データファイルおよび制御ファイルの全体バックアップまたはレベル0のバックアップのみでなく、アーカイブREDOログおよびレベル1の増分バックアップにも影響します。まず、Recovery Managerは不要なデータファイルおよび制御ファイルのバックアップを判断します。次に、Recovery Managerは、保持する必要がある最も古いデータファイルまたは制御ファイルのバックアップをリカバリする際に必要ないすべてのアーカイブ・ログおよびレベル1の増分バックアップを、不要とみなします。
保存方針を実装する場合、冗長性とリカバリ期間という相互に排他的な2つのオプションがあります。
リカバリ期間とは、現在の時点からリカバリ可能ポイントまでの期間です。リカバリ可能ポイントは、想定されるPoint-in-Timeリカバリの最も早い時点（メディア障害後にリカバリ可能な最も早い時点）です。たとえば、1週間のリカバリ期間を実装した場合、Recovery Managerは、データベースを最大7日前までリカバリできるように、全体バックアップおよび必要な増分バックアップとアーカイブ・ログを保持します。この保存方針は、次のように構成します。
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
このコマンドを実行すると、各データファイルに対して、リカバリ可能ポイントより前のバックアップが1つ保持されます。たとえば、リカバリ期間が7の場合、次の条件を満たす各データファイルのバックアップが常に1つ存在する必要があります。
SYSDATE - BACKUP CHECKPOINT TIME >= 7
この条件を満たす最新のバックアップよりも古いすべてのバックアップは不要となります。
図7-4に示す保存方針を設定するとします。保存方針の内容は、次のとおりです。
ARCHIVELOGモードで実行され、アーカイブ・ログは、保存方針で必要とされる間のみ、ディスク上に保存されます。
図7-4に示すように、現在の時点は1月23日、リカバリ可能ポイントは1月16日です。このため、リカバリには、1月14日のバックアップおよびログ順序500から850のアーカイブ・ログが必要です。500より前のログおよび1月1日のバックアップは、期間内の時点へのリカバリには必要ありません。
図7-5に、1週間後の同じ例を示します。
この例では、現在の時点は1月30日、リカバリ可能ポイントは1月23日です。最新（1月28日）のバックアップがリカバリ期間に存在していますが、この場合でも1月14日のバックアップは必要です。これは、1月28日のバックアップをリストアしても、期間の最初の時点（1月23日）にはリカバリできないためです。期間内のいずれの時点にもリカバリできるようにするために、1月14日のバックアップおよび順序500から1150のすべてのアーカイブ・ログを保存する必要があります。
リカバリ期間を使用すると、保持する必要があるバックアップの数が一定ではなく、バックアップ・スケジュールによって異なるため、ディスク領域の計画が複雑になる場合があります。これに対して、冗長性に基づく保存方針では、データファイルごとに保持する必要があるバックアップ数を指定します。たとえば、次のように入力して冗長性を2に構成できます。
CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
デフォルトの保存方針は、REDUNDANCY 1に構成されています。
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日前の間の時間にはリカバリできなくなります。
|
参照:
|
Recovery ManagerのステータスOBSOLETEは、常に保存方針に応じて決定されます。たとえば、Recovery Managerリポジトリ内のデータベースのバックアップがOBSOLETEとみなされる理由は、そのバックアップがリカバリ期間内の時点へのリカバリに必要ないか、または冗長であるためです。
フラッシュ・リカバリ領域を構成している場合、内部アルゴリズムを使用して、フラッシュ・リカバリ領域のファイルから、構成されている保存方針を満たす必要がなくなったファイルが選択されます。ステータスがOBSOLETEのバックアップは、ディスク割当て制限の規則によって削除対象となっています。ディスク割当て制限の規則に従ってフラッシュ・リカバリ領域から削除するファイルが決定される際に、保存方針が違反されることはありません。
フラッシュ・リカバリ領域のOBSOLETEステータスの規則と、ディスク割当て制限で削除対象とする規則には、1つの重要な違いがあります。1000から2000のアーカイブ・ログがディスク上に存在し、現行のリカバリ期間に必要であるとします。これらのログをテープにバックアップする場合、保存方針では、ディスク上のログは必要であるとみなされます。一方、フラッシュ・リカバリ領域のディスク割当て制限のアルゴリズムでは、ディスク上のログはテープにバックアップされているため、削除対象とみなされます。したがって、ディスク上のログはリポジトリではOBSOLETEステータスを持ちませんが、フラッシュ・リカバリ領域では削除対象になります。
|
 Copyright © 2003, 2008, Oracle Corporation. All Rights Reserved. |
|