11g リリース1（11.1）
E05700-03
 目次 |
 索引 |
| Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド 11g リリース1（11.1） E05700-03 |
|
この章では、Recovery Managerの高度なバックアップ手順について説明します。この章の内容は、次のとおりです。
「バックアップ・セットの最大サイズの構成」の説明に従ってCONFIGUREコマンドを使用すると、バックアップ・セットのサイズを制御する永続的な設定を作成できます。この制御は、大規模なファイルをバックアップする場合に有効です。バックアップ・セットのサイズを永続的に構成しない場合は、BACKUP ... MAXSETSIZEコマンドを使用して、バックアップ・セットのサイズを制限することができます。
BACKUPコマンドではなく、CONFIGUREコマンドを使用すると、個々のバックアップ・ピースのサイズに制限を設定できます。この制御は、ファイル・サイズに制限があるメディア・マネージャを使用する場合、または大規模なファイルをバックアップする必要がある場合に特に有効です。詳細は、「バックアップ・ピースの最大サイズの構成」を参照してください。
BACKUPコマンドのMAXSETSIZEパラメータには、バイト（デフォルト）、KB、MBまたはGB単位でバックアップ・セットの最大サイズを指定します。したがって、バックアップ・セットのサイズを305MBに制限するには、MAXSETSIZE 305Mと指定します。Recovery Managerは、すべてのバックアップ・セットをこのサイズに制限します。
BACKUP ... MAXSETSIZEを使用して、データベースが複数のバックアップ・セットに分割されるように、バックアップ・セットのサイズを制限できます。バックアップの途中で障害が発生した場合は、再開可能バックアップ機能を使用して、前回バックアップされなかったファイルのみをバックアップできます。Recovery Managerバックアップを再起動する方法については、「Recovery Managerバックアップの再開」を参照してください。
場合によっては、MAXSETSIZEの値が小さすぎて、バックアップ中の最大のファイルを格納できない場合があります。MAXSETSIZEが小さすぎるかどうかを判断する場合、Recovery Managerは、圧縮後のファイル・サイズではなく元のデータファイルのサイズを使用します。Recovery Managerは、次のようなエラー・スタックを表示します。
RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of backup command at 11/03/06 14:40:33 RMAN-06182: archive log larger than MAXSETSIZE: thread 1 seq 1 /oracle/oradata/trgt/arch/archive1_1.dbf
バックアップ・ピースのサイズがファイル・システムまたはメディア管理ソフトウェアの最大ファイル・サイズより大きい場合、問題が発生します。バックアップ・ピースのサイズを制限するには、CONFIGURE CHANNELコマンドまたはALLOCATE CHANNELコマンドのMAXSETSIZEパラメータを使用します。
MAXSETSIZEパラメータを指定してBACKUPコマンドを実行します。次の例では、各バックアップ・セットのサイズを100MBに制限して、アーカイブ・ログをテープにバックアップします。
BACKUP DEVICE TYPE sbt MAXSETSIZE 100M ARCHIVELOG ALL;
BACKUPコマンドにSECTION SIZEパラメータを指定すると、Recovery Managerによって、各バックアップ・ピースに1つのファイル・セクションのブロックが含まれているバックアップ・セットが作成されます。ファイル・セクションとは、ファイル内の連続するブロックの範囲のことです。このタイプのバックアップはマルチセクション・バックアップと呼ばれます。
マルチセクション・バックアップの目的は、Recovery Managerチャネルが単一の大規模なファイルをパラレルでバックアップできるようにすることです。Recovery Managerは、複数のチャネルに作業を分割し、各チャネルでファイル内の1つのファイル・セクションをバックアップします。個別のセクションでファイルをバックアップすることによって、大規模データファイルのバックアップのパフォーマンスを向上させることができます。
マルチセクション・バックアップが正常に完了した場合は、バックアップ時に生成されたバックアップ・セットに、部分的なデータファイルは含まれません。マルチセクション・バックアップに失敗すると、Recovery Managerメタデータに部分的なバックアップ・セットのレコードが含まれる可能性があります。Recovery Managerは、部分的なバックアップをリストアおよびリカバリ対象とみなしません。DELETEコマンドを使用して、部分的なバックアップ・セットを削除する必要があります。
ファイルのサイズより大きいセクション・サイズを指定した場合、Recovery Managerはファイルのマルチセクション・バックアップを使用しません。小さなセクション・サイズを指定した結果、セクションの数が256を超えると、Recovery Managerは、正確に256になる値までセクション・サイズを増やします。
SECTION SIZEパラメータを指定してBACKUPを実行します。たとえば、users表領域に900MBの単一のデータファイルが含まれているとします。また、SBTデバイス・セットのパラレル化設定が3に設定され、3つのSBTチャネルが構成されているとします。この表領域内のデータファイルは、次の例に示すようにファイル・セクションに分割できます。
BACKUP SECTION SIZE 300M TABLESPACE users;
この例では、3つのSBTチャネルのそれぞれによって、usersデータファイルの300MBのファイル・セクションがバックアップされます。
「バックアップの最適化の構成」で説明されているように、CONFIGURE BACKUP OPTIMIZATIONコマンドを実行すると、バックアップの最適化が有効になります。特定の条件が満たされた場合、Recovery Managerは、すでにバックアップされているファイルと同じファイルのバックアップをスキップします。
後続の例では、バックアップの最適化および保存方針を次の例のように構成していると想定しています。
CONFIGURE DEFAULT DEVICE TYPE TO sbt; CONFIGURE BACKUP OPTIMIZATION ON; CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 4 DAYS;
Recovery Managerを例9-1のように構成して、次のコマンドを毎晩実行し、データベースをテープにバックアップします。
BACKUP DATABASE;
バックアップの最適化が構成されているため、リカバリ期間内に最新のバックアップが実行されている場合のみ、Recovery Managerは、オフラインおよび読取り専用のデータファイルのバックアップをスキップします。最新のバックアップがリカバリ期間より前に実行されている場合、Recovery Managerはバックアップをスキップしません。たとえば、最適化を行うと、読取り専用データファイルを含むバックアップ・セットがリカバリ期間内に1つ存在しているかぎり、このデータファイルの新しいバックアップを毎晩実行する必要がなくなります。
|
参照:
|
毎晩すべてのアーカイブ・ログをバックアップすると想定しています。ただし、各ログ順序番号の複数のコピーが作成されないようにします。Recovery Managerを例9-1のように構成して、次のコマンドをスクリプトで毎晩午前1時に実行します。
BACKUP DEVICE TYPE sbt ARCHIVELOG ALL;
Recovery Managerは、24時間以内に生成されたログ以外のすべてのログをスキップします。この方法で、各アーカイブ・ログの1つのみのコピーをテープ上に保持できます。
Oracle Secure Backupでは、メディア・ファミリは、共有のユーザー定義属性のセットが含まれている名前付きのボリューム・グループです。この例では、テープ上に存在しないログを1つのメディア・ファミリにバックアップし、同じログを別のメディア・ファミリにバックアップします。最後に、古いログを削除します。
Recovery Managerを例9-2に示すように構成して、毎晩同じ時刻に次のスクリプトを実行し、前日に生成されたログを2つの個別のメディア・ファミリにバックアップします。
# The following command backs up just the logs that are not on tape. The # first copies are saved to the tapes from the media family "log_family1". RUN { ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS 'ENV=(OB_MEDIA_FAMILY=log_family1)'; BACKUP ARCHIVELOG ALL; } # Make one more copy of the archived logs and save them to tapes from a # different media family RUN { ALLOCATE CHANNEL c2 DEVICE TYPE sbt PARMS 'ENV=(OB_MEDIA_FAMILY=log_family2)'; BACKUP ARCHIVELOG NOT BACKED UP 2 TIMES; }
SBTに2回バックアップしたログをディスクから削除することが目標である場合は、アーカイブREDOログの削除方針を使用する方法が目標を達成する最も簡単な方法です。次のワンタイム構成では、テープに2つのアーカイブ・ログが存在する場合にアーカイブREDOログがディスクからの削除対象となるように指定されます。
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 2 TIMES TO DEVICE TYPE sbt;
例9-2のスクリプトを実行した後に、DELETE ARCHIVELOG ALLを実行すると、不要なログを削除できます。
アーカイブ・ログを毎日テープにバックアップするための、より高度な例を想定します。ただし、テープ破損を考慮して、週ごとにディスクからログを削除する前に、別々のテープに各ログ順序番号の複数のコピーが作成されるようにします。この例では、データベースでフラッシュ・リカバリ領域が使用されていないことを想定しています。
まず、ワンタイム構成を次のように実行します。
CONFIGURE BACKUP OPTIMIZATION ON; CONFIGURE DEVICE TYPE sbt PARALLELISM 1; CONFIGURE default DEVICE TYPE TO sbt; CONFIGURE CHANNEL DEVICE TYPE sbt PARMS 'ENV=(OB_MEDIA_FAMILY=first_copy);
最適化を有効にしているため、次のコマンドを毎晩実行して、まだバックアップされていないすべてのアーカイブ・ログをfirst_copyメディア・ファミリにバックアップできます。
BACKUP ARCHIVELOG ALL TAG first_copy;
毎週金曜日の夜に、すべてのアーカイブ・ログの追加のバックアップを別のメディア・ファミリに作成します。バックアップの終了時に、すでにテープ上に2つ以上のコピーが作成されているすべてのアーカイブ・ログを削除します。これを行うには、次のスクリプトを実行します。
RUN { # manually allocate a channel, in order to specify that the backup run by this # channel should go to both media families "first_copy" and "second_copy" ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS 'ENV=(OB_MEDIA_FAMILY=second_copy)'; ALLOCATE CHANNEL c2 DEVICE TYPE sbt PARMS 'ENV=(OB_MEDIA_FAMILY=first_copy)'; BACKUP CHANNEL c1 ARCHIVELOG UNTIL TIME 'SYSDATE' NOT BACKED UP 2 TIMES # back up only logs without 2 backups on tape TAG SECOND_COPY; BACKUP CHANNEL c2 ARCHIVELOG UNTIL TIME 'SYSDATE' NOT BACKED UP 2 TIMES # back up only logs without 2 backups on tape TAG FIRST_COPY; } # now delete from disk all logs that have been backed up to tape at least twice DELETE ARCHIVELOG ALL BACKED UP 2 TIMES TO DEVICE TYPE sbt;
次の表に、日次バックアップ・スクリプトおよび週次バックアップ・スクリプトの効果を示します。
週次バックアップの後に、second_copyメディア・ファミリのテープをオフサイトのストレージに送信できます。このテープ・バックアップは、プールfirst_copyのプライマリ・テープが損傷した場合にのみ使用します。セカンダリ・テープはオフサイトに存在するため、Recovery Managerでのリカバリには使用しません。そのため、このバックアップには使用不可能のマークを付けることができます。
CHANGE BACKUP OF ARCHIVELOG TAG SECOND_COPY UNAVAILABLE;
|
参照:
|
デフォルトでは、BACKUPコマンドでデータファイルにアクセスできない場合、このコマンドは終了します。表9-2に示すようにパラメータを指定すると、コマンドの終了を回避できます。
次の例では、自動チャネルを使用してデータベースをバックアップし、バックアップ・ジョブを終了させる可能性のあるデータファイルをすべてスキップします。
BACKUP DATABASE SKIP INACCESSIBLE SKIP READONLY SKIP OFFLINE;
Recovery Managerは、バックアップ・セットの最大4つのコピーを同時に作成できます。これらのコピーは、それぞれが完全な複製です。多重バックアップ・セットのコピーは、バックアップ・セットに含まれる各バックアップ・ピースのコピーで、各コピーに一意のコピー番号が付けられます（0tcm8u2s_1_1、0tcm8u2s_1_2など）。バックアップ・セットをフラッシュ・リカバリ領域に多重化することはできません。
BACKUP ... COPIESまたはCONFIGURE ... BACKUP COPIESを使用すると、バックアップ・セットを多重化できます。Recovery Managerでは、ディスクまたはテープにバックアップを多重化できますが、テープとディスクにバックアップを同時に多重化することはできません。DISKチャネルの場合は、FORMATオプションで複数の値を指定して、異なる物理ディスクに複数のコピーを作成します。SBTチャネルの場合は、バージョン2のSBT APIをサポートするメディア・マネージャを使用すると、そのメディア・マネージャによって各コピーが自動的に個別のメディア（個別のテープなど）に書き込まれます。テープへのバックアップ時に、コピーの数が、使用可能なテープ・デバイスの数を超えないようにしてください。
多重化はバックアップ・セットにのみ適用され、イメージ・コピーには適用されません。イメージ・コピー・バックアップの作成時にBACKUP ... COPIESを指定すると、エラーが発生します。また、イメージ・コピー・バックアップにCONFIGURE ... BACKUP COPIESを設定しても、この設定は無視されます。
「バックアップの多重化の構成」の説明に従ってCONFIGURE ... BACKUP COPIESコマンドを使用すると、指定したデバイス・タイプに作成する同じバックアップ・セットの数を指定できます。この設定は、制御ファイルの自動バックアップ（制御ファイルの自動バックアップでは常に1つのコピーが生成されるため）およびBACKUP BACKUPSETコマンドを使用してバックアップしたバックアップ・セットを除く、すべてのバックアップ・セットに適用されます。
デフォルトでは、各デバイス・タイプのCONFIGURE ... BACKUP COPIESが1に設定されています。次の例では、データファイルおよびアーカイブ・ログのテープへの多重化、およびデータファイル（アーカイブREDOログは含まない）のディスクへの多重化を構成しています。
CONFIGURE DEVICE TYPE sbt PARALLELISM 1; CONFIGURE DEFAULT DEVICE TYPE TO sbt; CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/disk1/%U', '/disk2/%U'; CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE sbt TO 2; CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE sbt TO 2; CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 2;
BACKUPコマンドを実行します。次のコマンドを実行すると、データベースおよびアーカイブ・ログがテープにバックアップされ、各データファイルおよびアーカイブ・ログのコピーが2つずつ作成されます。
BACKUP DATABASE PLUS ARCHIVELOG; # uses default sbt channel
ディスク・チャネル用のフォーマットが構成されているため、次のコマンドを実行すると、データベースがディスクにバックアップされ、生成されたバックアップ・セットの1つのコピーが/disk1ディレクトリに、もう1つのコピーが/disk2ディレクトリに格納されます。
BACKUP DEVICE TYPE DISK AS COPY DATABASE;
CONFIGURE CHANNNELにFORMAT句が構成されていない場合は、BACKUPコマンド自体にFORMATを指定できます。たとえば、次のコマンドを発行できます。
BACKUP DATABASE FORMAT '/disk1/%U', '/disk2/%U';
LIST BACKUPコマンドを発行して、バックアップ・セットおよびバックアップ・ピースのリストを表示します。たとえば、次のコマンドを入力します。
LIST BACKUP SUMMARY;
#Copies列には、多重化または複数のBACKUPコマンドによって生成されたバックアップ・セットの数が表示されます。
|
参照:
|
BACKUPコマンドのCOPIESオプションは、バックアップ・セットの多重化を制御する他のすべてのCOPIESまたはDUPLEXの設定より優先されます。
BACKUPコマンドのCOPIESオプションを指定して、コピーの数を指定します。たとえば、次のコマンドを実行して、デフォルトの場所であるDISKに各バックアップ・セットのコピーを3つずつ作成します。
BACKUP AS BACKUPSET DEVICE TYPE DISK COPIES 3 INCREMENTAL LEVEL 0 DATABASE;
BACKUPコマンドでCOPIESを指定しているため、CONFIGURE DATAFILE COPIESの設定に関係なく、各データファイルのバックアップ・セットが3つずつ作成されます。
LIST BACKUPコマンドを発行して、バックアップ・セットおよびバックアップ・ピースのリストを表示します（#Copies列には、多重化によって、またはBACKUPコマンドを複数回実行することによって生成されたコピーの数が表示されます）。たとえば、次のように入力します。
LIST BACKUP SUMMARY;
多くのサイトでは、プライマリ・データベース上でメディア障害が発生したり、ユーザーが不適切な操作を行ってPoint-in-Timeリカバリが必要になった場合のために、データベースのバックアップがディスク上に格納されています。ディスク上のデータファイルのバックアップを使用すると、リカバリのリストア手順が簡単になり、リカバリの速度および信頼性が向上します。
ディスク上にデータファイルのバックアップを作成する方法の1つは、ディスクのミラー化を使用する方法です。たとえば、オペレーティング・システムを使用して、データベースの各ファイルの3つのコピーを保持できます。この構成では、データベースのミラー化されたコピーを分割して、1つのバックアップとして使用できます。
Recovery Managerでは、自動的にミラーの分割は行われませんが、バックアップおよびリカバリで分割されたミラーを使用することができます。たとえば、Recovery Managerでは、データファイルの分割されたミラーをデータファイルのコピーとして処理できます。また、このコピーをディスクまたはテープにバックアップできます。この項の手順では、ALTER SYSTEM SUSPEND/RESUME機能を使用してミラーの分割によるバックアップを作成する方法について説明します。
一部のミラー化技術では、ミラーを分割してバックアップとして使用する前に、Oracle DatabaseですべてのI/Oを一時停止する必要がありません。データベース・インスタンスでI/Oの一時停止が必要かどうかについては、ストレージ・マネージャ、ボリューム・マネージャまたはファイル・システムのドキュメントを参照してください。
ALTER TABLESPACE ... BEGIN BACKUP文を使用して、バックアップする表領域をバックアップ・モードにします。（すべての表領域をバックアップ・モードにするには、ALTER DATABASE BEGIN BACKUPを使用します。）たとえば、表領域usersをバックアップ・モードにするには、Recovery Managerをターゲット・データベースに接続し、次のSQLコマンドを実行します。
SQL 'ALTER TABLESPACE users BEGIN BACKUP';
SQL 'ALTER SYSTEM SUSPEND';
SQL 'ALTER SYSTEM RESUME';
SQL 'ALTER TABLESPACE users END BACKUP';
ALTER DATABASE END BACKUPを使用して、すべての表領域のバックアップ・モードを終了することもできます。
CATALOGコマンドを使用して、ユーザー管理のミラー・コピーをデータファイルのコピーとしてカタログに追加します。たとえば、次のように入力します。
CATALOG DATAFILECOPY '/dk2/oradata/trgt/users01.dbf'; # catalog split mirror
BACKUP DATAFILECOPYコマンドを実行します。
BACKUP DATAFILECOPY '/dk2/oradata/trgt/users01.dbf';
CHANGE ... UNCATALOGコマンドを使用して、手順6でカタログに追加したデータファイルのコピーをカタログから削除します。たとえば、次のように入力します。
CHANGE DATAFILECOPY '/dk2/oradata/trgt/users01.dbf' UNCATALOG;
参照:
SUSPEND/RESUME機能の詳細は、『Oracle Database管理者ガイド』を参照してください。
「バックアップの暗号化の構成」で説明されているように、バックアップの暗号化でRecovery Managerバックアップ・セットを保護できます。暗号化バックアップは、不正なユーザーが取得しても読み取ることができません。Recovery Managerバックアップの暗号化機能を使用するには、Enterprise Editionのデータベースが必要です。
バックアップの暗号化は、次のコマンドで指定される暗号化設定に基づいて実行されます。
CONFIGURE ENCRYPTION このコマンドを使用すると、透過的暗号化を永続的に構成できます。デュアル・モードまたはパスワード・モードの暗号化は永続的には構成できません。
SET ENCRYPTIONこのコマンドを使用すると、デュアル・モードまたはパスワード・モードの暗号化をRecovery Managerセッション・レベルで構成できます。
データベースでは、各暗号化バックアップに対して新しい暗号化キーが使用されます。バックアップ暗号化キーは、選択した暗号化モードに応じて、パスワードまたはデータベース・マスター・キー（あるいはその両方）を使用して暗号化されます。個々のバックアップ暗号化キーまたはパスワードは、クリアテキストでは格納されません。
1回のリストア操作で、異なるモードで暗号化されたバックアップを処理できます。Recovery Managerは、リストアするバックアップ・ピースごとに、それらが暗号化されているかどうかを確認します。透過的に暗号化されているバックアップは、Oracleウォレットがオープンしていて使用可能な場合、ユーザーの介入を必要としません。
パスワードの暗号化が検出された場合、Recovery Managerは、SET DECRYPTIONコマンドで入力したパスワードのリスト内の一致するキーを検索します。使用可能なキーが検出された場合、Recovery Managerはリストア操作を続行します。検出されなかった場合、Recovery ManagerはOracleウォレット内のキーを検索します。Recovery Managerは、使用可能なキーが検出された場合はリストア操作を続行します。検出されなかった場合はバックアップ・ピースを復号化できないというエラーを通知します。
暗号化は、バックアップのパフォーマンスに悪影響を及ぼす場合があります。暗号化バックアップでは、暗号化されていないバックアップの場合より多くのCPUリソースが消費されるため、より多くのRecovery Managerチャネルを使用すると、ディスクへの暗号化バックアップのパフォーマンスを向上させることができます。
|
参照:
|
「Recovery Managerバックアップの暗号化モードの構成」の説明に従って、CONFIGUREコマンドで透過的暗号化を構成してある場合、暗号化バックアップの作成に必要な追加のコマンドはありません。通常どおりに、Recovery Managerバックアップを作成します。
SET ENCRYPTION BY PASSWORDコマンドを実行すると、Recovery Managerセッションで暗号化パスワードを設定できます。透過的暗号化が構成されている場合は、構成されている透過的暗号化ではなく、パスワードでバックアップを保護することを示すためにONLYキーワードを指定します。
SET ENCRYPTION ON IDENTIFIED BY password ONLYコマンドを実行します。次の例では、バックアップ内のすべての表領域の暗号化パスワード（passwordは実際に入力するパスワードのプレースホルダ）を設定し、暗号化がパスワードのみであることを示すためにONLYを指定しています。
SET ENCRYPTION IDENTIFIED BY password ONLY ON FOR ALL TABLESPACES;
たとえば、次のコマンドを入力します。
BACKUP DATABASE PLUS ARCHIVELOG;
Recovery ManagerプロンプトでSET ENCRYPTION BY PASSWORDコマンドを使用して、パスワード保護されたバックアップを作成します。透過的暗号化が構成されている場合は、パスワードおよび構成されている透過的暗号化でバックアップを保護することを示すためにONLYキーワードを省略します。
ONLYキーワードを省略して、SET ENCRYPTION BY PASSWORDコマンドを実行します。次の例では、バックアップ内のすべての表領域の暗号化パスワード（passwordは実際に入力するパスワードのプレースホルダ）を設定し、デュアル・モードの暗号化を示すためにONLYを省略しています。
SET ENCRYPTION IDENTIFIED BY password ON FOR ALL TABLESPACES;
たとえば、次のコマンドを入力します。
BACKUP DATABASE PLUS ARCHIVELOG;
再開可能バックアップ機能を使用すると、指定した日付以降にバックアップされていないファイルのみをバックアップできます。
再開可能最小単位はデータファイルです。ただし、バックアップ・セットに1つのバックアップ・ピースが含まれ、このピースに複数のデータファイルからのブロックが含まれている場合、再開可能単位はバックアップ・ピースになります。イメージ・コピーの再開可能単位はデータファイルです。
再開可能バックアップのメリットは、バックアップによって複数のバックアップ・セットが生成される場合、正常に完了したバックアップ・セットを再実行する必要がないことです。ただし、データベース全体が1つのバックアップ・セットに書き込まれる場合、途中でバックアップが失敗すると、バックアップ全体を再開する必要があります。
ファイルの読取り時またはバックアップ・ピースやイメージ・コピーへの書込み時にI/Oエラーが検出された場合、Recovery Managerは実行中のバックアップ・ジョブを終了します。たとえば、バックアップを試みたデータファイルがディスク上に存在しなかった場合、バックアップは終了します。ただし、複数のチャネルが使用されていたり、バックアップの冗長コピーが作成されている場合、Recovery Managerはユーザーの介入なしにバックアップを続行できる可能性があります。
Recovery Managerは、指定した日付以降にバックアップされていないファイルのみをバックアップできます。バックアップが失敗した場合にこの機能を使用すると、失敗したバックアップで処理されなかったデータベースの部分をバックアップできます。
BACKUPコマンドにSINCE TIME句を指定すると、バックアップを再開できます。SINCE TIMEに完了時刻より後の値が設定されている場合、Recovery Managerはそのファイルをバックアップします。SINCE TIMEパラメータを指定せずにBACKUP DATABASE NOT BACKED UPを使用した場合、Recovery Managerは、一度もバックアップされていないファイルのみをバックアップします。
BACKUPコマンドのSINCE TIMEパラメータを使用すると、その日付を過ぎると新しいバックアップが必要になる日付を指定できます。SINCE TIMEに完了時刻より後の値が設定されている場合、Recovery Managerはそのファイルをバックアップします。SINCE TIMEパラメータを指定せずにBACKUP DATABASE NOT BACKED UPを使用した場合、Recovery Managerは、一度もバックアップされていないファイルのみをバックアップします。
BACKUP ... NOT BACKED UP SINCE TIMEコマンドを実行します。SINCE TIMEパラメータに有効な日付を指定します。次の例では、デフォルトの構成済チャネルを使用して、過去2週間にバックアップされていないすべてのデータベース・ファイルおよびアーカイブREDOログをバックアップします。
BACKUP NOT BACKED UP SINCE TIME 'SYSDATE-14' DATABASE PLUS ARCHIVELOG;
この項では、バックアップ期間を使用して、バックアップ・ジョブを完了できる期間の制限を設定する方法について説明します。
バックアップ期間とは、バックアップを完了する必要がある時間の長さのことです。たとえば、データベースのバックアップを、システム上のユーザー・アクティビティが低下する時間帯（午前2時から6時など）に制限する場合があります。
Recovery Managerは、バックアップの日付が最も古いファイルを最初にバックアップします。デフォルトでは、Recovery Managerはファイルを可能なかぎり速くバックアップします。期間を指定しても、期間終了前にバックアップが完了するように通常より速くデータがバックアップされるわけではありません。
デフォルトでは、バックアップがDURATIONの時間内に完了しなかった場合、Recovery Managerはバックアップを中断し、エラーを通知します。BACKUPコマンドがRUNコマンド内に指定されている場合、RUNコマンドは終了します。バックアップ全体が完了しなかった場合でも、バックアップが完了したバックアップ・セットは保持され、リストア操作で使用できます。このため、実行可能な時間が終了して中断されたジョブを再試行すると、試行を繰り返すたびに、バックアップする必要があるファイルの処理が進行していきます。不完全なバックアップ・セットは廃棄されます。
BACKUPコマンドのDURATIONパラメータを使用すると、指定したバックアップ・ジョブを実行できる期間を指定できます。
BACKUP DURATIONコマンドを実行します。たとえば、次のコマンドを午前2時に実行して、午前6時までバックアップを実行するように指定できます。
BACKUP DURATION 4:00 TABLESPACE users;
PARTIALを指定すると、Recovery Managerは、バックアップ期間が終了してバックアップが中断された場合でも、エラーを通知しません。かわりに、バックアップできなかったファイルを示すメッセージを表示します。BACKUPコマンドをRUNブロックで実行している場合、RUNブロック内の残りのコマンドは続行されます。
FILESPERSET 1を指定すると、Recovery Managerは各ファイルを独自のバックアップ・セットに格納します。バックアップ期間が終了してバックアップが中断されると、そのときバックアップ中であったファイルのバックアップのみが消失します。時間内に完了したすべてのバックアップ・セットは保存されるため、バックアップ期間の終了によって無効となる処理は最小限で済みます。
PARTIALオプションを指定してBACKUP DURATIONコマンドを実行します。たとえば、次のコマンドを午前2時に実行して、午前6時までバックアップを実行し、各データファイルが個別のバックアップ・セットに格納されるように指定できます。
BACKUP DURATION 4:00 PARTIAL TABLESPACE users FILESPERSET 1;
DURATIONを使用すると、最高のパフォーマンスでバックアップを実行したり、割り当てられた時間内で可能なかぎり低速のバックアップを実行して、パフォーマンスへのバックアップ作業の影響を最小限に抑えることができます。最高のパフォーマンスでバックアップを実行するには、例9-4のように、DURATIONとともにMINIMIZE TIMEオプションを使用します。
BACKUP DURATION 4:00 PARTIAL MINIMIZE TIME DATABASE FILESPERSET 1;
使用可能なすべての時間を使用してバックアップを実行するには、例9-5のように、MINIMIZE LOADオプションを使用します。
BACKUP DURATION 4:00 PARTIAL MINIMIZE LOAD DATABASE FILESPERSET 1;
例9-5では、Recovery Managerはバックアップの進捗状況を監視し、現在のレートでバックアップの完了に必要な時間を定期的に見積もります。バックアップ期間の終了前にバックアップが終了すると判断した場合、Recovery Managerは、使用可能なすべての時間が使用されるように、バックアップのレートを低下させます。これによって、データベースでバックアップに関連するオーバーヘッドが減少します。
DURATIONおよびMINIMIZE LOADをテープ・バックアップで使用する場合は、次の事項に注意してください。
MINIMIZE LOADを使用すると、Recovery Managerがバックアップのレートを低下させ、テープ・ストリームが最適ではなくなる場合があります。
これらの点から、テープへのバックアップ時にはMINIMIZE LOADを使用しないことをお薦めします。
|
 Copyright © 2003, 2008, Oracle Corporation. All Rights Reserved. |
|