| Oracle® Databaseバックアップおよびリカバリ・ユーザーズ・ガイド 12c リリース1 (12.1) B71297-08 |
|
 前 |
 次 |
「バックアップ・セットの最大サイズの構成」の説明に従ってCONFIGUREコマンドを使用すると、バックアップ・セットのサイズを制御する永続的な設定を作成できます。この制御は、大規模なファイルをバックアップする場合に有効です。バックアップ・セットのサイズを永続的に構成しない場合は、 BACKUP ... MAXSETSIZEコマンドを使用して、バックアップ・セットのサイズを制限することができます。
BACKUPコマンドではなく、CONFIGUREコマンドを使用すると、個々のバックアップ・ピースのサイズに制限を設定できます。この制御は、ファイル・サイズに制限があるメディア・マネージャを使用する場合、または大規模なファイルをバックアップする必要がある場合に特に有効です。詳細は、「バックアップ・ピースの最大サイズの構成」を参照してください。
この項の内容は、次のとおりです。
BACKUPコマンドのMAXSETSIZEパラメータには、バイト(デフォルト)、KB、MBまたはGB単位でバックアップ・セットの最大サイズを指定します。したがって、バックアップ・セットのサイズを305MBに制限するには、MAXSETSIZE 305Mと指定します。RMANは、すべてのバックアップ・セットをこのサイズに制限します。
BACKUP ... MAXSETSIZEを使用して、データベースが複数のバックアップ・セットに分割されるように、バックアップ・セットのサイズを制限できます。バックアップの途中で障害が発生した場合は、再開可能バックアップ機能を使用して、前回バックアップされなかったファイルのみをバックアップできます。RMANバックアップを再起動する方法については、「RMANバックアップの再開」を参照してください。
場合によっては、MAXSETSIZEの値が小さすぎて、バックアップ中の最大のファイルを格納できない場合があります。MAXSETSIZEが小さすぎるかどうかを判断する場合、RMANは、圧縮後のファイル・サイズではなく元のデータファイルのサイズを使用します。RMANは、次のようなエラー・スタックを表示します。
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 11/03/13 14:40:33
RMAN-06182: archive log larger than MAXSETSIZE: thread 1 seq 1
/oracle/oradata/trgt/arch/archive1_1.dbf
関連項目:
CONFIGURE MAXSETSIZEコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
バックアップ・ピースのサイズがファイル・システムまたはメディア管理ソフトウェアの最大ファイル・サイズより大きい場合、問題が発生します。バックアップ・ピースのサイズを制限するには、CONFIGURE CHANNELコマンドまたはALLOCATE CHANNELコマンドのMAXSETSIZEパラメータを使用します。
バックアップ・セットのサイズを制限する手順
BACKUPコマンドにSECTION SIZEパラメータを指定すると、RMANによって、各バックアップ・ピースに1つのファイル・セクションのブロックが含まれているバックアップ・セットが作成されます。ファイル・セクションとは、ファイル内の連続するブロックの範囲のことです。このタイプのバックアップはマルチセクション・バックアップと呼ばれます。
注意:
SECTION SIZEは、MAXPIECESIZEとともに指定できません。
マルチセクション・バックアップの目的は、RMANチャネルが単一の大規模なファイルをパラレルでバックアップできるようにすることです。RMANは、複数のチャネルに作業を分割し、各チャネルでファイル内の1つのファイル・セクションをバックアップします。個別のセクションでファイルをバックアップすることによって、大規模データファイルのバックアップのパフォーマンスを向上させることができます。
マルチセクション・バックアップが正常に完了した場合は、バックアップ時に生成されたバックアップ・セットに、部分的なデータファイルは含まれません。マルチセクション・バックアップに失敗すると、RMANメタデータに部分的なバックアップ・セットのレコードが含まれる可能性があります。RMANは、部分的なバックアップをリストアおよびリカバリ対象とみなしません。DELETEコマンドを使用して、部分的なバックアップ・セットを削除する必要があります。
ファイルのサイズより大きいセクション・サイズを指定した場合、RMANはファイルのマルチセクション・バックアップを使用しません。小さなセクション・サイズを指定した結果、セクションの数が256を超えると、RMANは、正確に256になる値までセクション・サイズを増やします。
マルチセクション・バックアップを作成する手順
関連項目:
大規模なデータファイルのセクションを検証する方法については、「データファイルの検証のパラレル化」を参照してください。
「バックアップの最適化およびCONFIGUREコマンド」で説明されているように、CONFIGURE BACKUP OPTIMIZATIONコマンドを実行して、バックアップの最適化を有効にします。特定の条件が満たされた場合、RMANは、すでにバックアップされているファイルと同じファイルのバックアップをスキップします。
関連項目:
バックアップの最適化およびリカバリ期間に関連する例は、「リカバリ期間に基づく保存方針によるSBTバックアップのバックアップの最適化について」を参照してください
ファイルが同一で、スキップできる可能性があるかどうかを判断するためにCONFIGURE BACKUP OPTIMIZATIONで使用される条件の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
後続の例では、バックアップの最適化および保存方針を次の例のように構成していると想定しています。
例10-1 バックアップの最適化の構成
CONFIGURE DEFAULT DEVICE TYPE TO sbt; CONFIGURE BACKUP OPTIMIZATION ON; CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 4 DAYS;
RMANを例10-1のように構成して、次のコマンドを毎晩実行し、データベースをテープにバックアップします。
BACKUP DATABASE;
バックアップの最適化が構成されているため、リカバリ期間内に最新のバックアップが実行されている場合のみ、RMANは、オフラインおよび読取り専用のデータファイルのバックアップをスキップします。最新のバックアップがリカバリ期間より前に実行されている場合、RMANはバックアップをスキップしません。たとえば、最適化を行うと、読取り専用データファイルを含むバックアップ・セットがリカバリ期間内に1つ存在しているかぎり、このデータファイルの新しいバックアップを毎晩実行する必要がなくなります。
毎晩すべてのアーカイブ・ログをバックアップすると想定しています。ただし、各ログ順序番号の複数のコピーが作成されないようにします。RMANを例10-1のように構成して、次のコマンドをスクリプトで毎晩午前1時に実行します。
BACKUP DEVICE TYPE sbt ARCHIVELOG ALL;
RMANは、24時間以内に生成されたログ以外のすべてのログをスキップします。この方法で、各アーカイブ・ログの1つのみのコピーをテープ上に保持できます。
Oracle Secure Backupでは、メディア・ファミリは、共有のユーザー定義属性のセットが含まれている名前付きのボリューム・グループです。この例では、テープ上に存在しないログを1つのメディア・ファミリにバックアップし、同じログを別のメディア・ファミリにバックアップします。最後に、古いログを削除します。
RMANを例10-2に示すように構成して、毎晩同じ時刻に次のスクリプトを実行し、前日に生成されたログを2つの個別のメディア・ファミリにバックアップします。
例10-2 複数のメディア・ファミリへのアーカイブREDOログのバックアップ
# 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;
例10-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, to specify that the backup run by this
# channel goes 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;
次の表に、日次バックアップ・スクリプトおよび週次バックアップ・スクリプトの効果を示します。
表10-1 日次スクリプトおよび週次スクリプトの効果
| スクリプト | スクリプト実行後のテープの内容 | スクリプト実行後のディスクの内容 |
|---|---|---|
日次 |
バックアップされていないアーカイブ・ログは、この時点でメディア・ファミリ |
最後に |
週次 |
テープに2つより少ないバックアップがあるアーカイブ・ログは、この時点でメディア・ファミリ |
2回以上テープにバックアップされたすべてのアーカイブ・ログが削除されます。 |
週次バックアップの後に、second_copyメディア・ファミリのテープをオフサイトのストレージに送信できます。このテープ・バックアップは、プールfirst_copyのプライマリ・テープが損傷した場合にのみ使用します。セカンダリ・テープはオフサイトに存在するため、RMANでのリカバリには使用しません。そのため、このバックアップには使用不可能のマークを付けることができます。
CHANGE BACKUP OF ARCHIVELOG TAG SECOND_COPY UNAVAILABLE;
関連項目:
バックアップのステータスを変更する方法およびバックアップを削除する方法については、「RMANバックアップおよびリポジトリ・レコードのメンテナンス」を参照してください。
CHANGEコマンドおよびDELETEコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
デフォルトでは、BACKUPコマンドでデータファイルにアクセスできない場合、このコマンドは終了します。表10-2に示すようにパラメータを指定すると、コマンドの終了を回避できます。
表10-2 BACKUP ... SKIPのオプション
| 指定するパラメータ | RMANがスキップするデータファイル |
|---|---|
|
RMANが読み取れないデータファイル。 |
|
オフラインのデータファイル。一部のオフライン・データファイルは、ディスク上に残っているために読取りが可能です。ディスクから削除または移動されたデータファイルは読み取れないため、アクセス不可能になります。 |
|
読取り専用表領域のデータファイル。 |
次の例では、自動チャネルを使用してデータベースをバックアップし、バックアップ・ジョブを終了させる可能性のあるデータファイルをすべてスキップします。
例10-3 RMANバックアップ時のファイルのスキップ
BACKUP DATABASE SKIP INACCESSIBLE SKIP READONLY SKIP OFFLINE;
RMANは、バックアップ・セットの最大4つのコピーを同時に作成できます。これらのコピーは、それぞれが完全な複製です。多重バックアップ・セットのコピーは、バックアップ・セットに含まれる各バックアップ・ピースのコピーで、各コピーに一意のコピー番号が付けられます(0tcm8u2s_1_1、0tcm8u2s_1_2など)。バックアップ・セットを高速リカバリ領域に多重化することはできません。
BACKUP ... COPIESまたはCONFIGURE ... BACKUP COPIESを使用して、バックアップ・セットを多重化できます。RMANでは、ディスクまたはテープにバックアップを多重化できますが、テープとディスクにバックアップを同時に多重化することはできません。DISKチャネルの場合は、FORMATオプションで複数の値を指定して、異なる物理ディスクに複数のコピーを作成します。SBTチャネルの場合は、バージョン2のSBT APIをサポートするメディア・マネージャを使用すると、そのメディア・マネージャによって各コピーが自動的に個別のメディア(個別のテープなど)に書き込まれます。テープへのバックアップ時に、コピーの数が、使用可能なテープ・デバイスの数を超えないようにしてください。
多重化はバックアップ・セットにのみ適用され、イメージ・コピーには適用されません。イメージ・コピー・バックアップの作成時にBACKUP ... COPIESを指定すると、エラーが発生します。また、イメージ・コピー・バックアップにCONFIGURE ... BACKUP COPIESを設定しても、この設定は無視されます。
この項の内容は、次のとおりです。
関連項目:
RMANのバックアップ・コピーの概要は、「RMANを使用したバックアップの複数のコピーについて」を参照してください
「バックアップの多重化の構成」の説明に従ってCONFIGURE ... BACKUP COPIESコマンドを使用すると、指定したデバイス・タイプに作成する同じバックアップ・セットの数を指定できます。この設定は、制御ファイルの自動バックアップ(制御ファイルの自動バックアップでは常に1つのコピーが生成されるため)およびBACKUP BACKUPSETコマンドを使用してバックアップしたバックアップ・セットを除く、すべてのバックアップ・セットに適用されます。
CONFIGURE ... BACKUP COPIESを使用してバックアップを多重化する手順
関連項目:
CONFIGURE BACKUP COPIESコマンドについては「バックアップの多重化の構成」、基本的なバックアップ構成オプションについては「RMANバックアップの環境の構成について」を参照してください
多くのサイトでは、プライマリ・データベース上でメディア障害が発生したり、ユーザーが不適切な操作を行ってPoint-in-Timeリカバリが必要になった場合のために、データベースのバックアップがディスク上に格納されています。ディスク上のデータファイルのバックアップを使用すると、リカバリのリストア手順が簡単になり、リカバリの速度および信頼性が向上します。
注意:
オンラインREDOログのバックアップは(ミラーの分割または他のいずれの方法を使用しても)実行しないでください。オンラインREDOログのバックアップをリストアすると、順序番号が同じで内容が異なる2つのアーカイブ・ログが作成される場合があります。また、制御ファイルのバックアップを作成する場合は、ミラーの分割のかわりにBACKUP CONTROLFILEコマンドを使用することをお薦めします。
ディスク上にデータファイルのバックアップを作成する方法の1つは、ディスクのミラー化を使用する方法です。たとえば、オペレーティング・システムを使用して、データベースの各ファイルの3つのコピーを保持できます。この構成では、データベースのミラー化されたコピーを分割して、1つのバックアップとして使用できます。
RMANでは、自動的にミラーの分割は行われませんが、バックアップおよびリカバリで分割されたミラーを使用することができます。たとえば、RMANでは、データファイルの分割されたミラーをデータファイルのコピーとして処理し、このコピーをディスクまたはテープにバックアップできます。この項の手順では、ALTER SYSTEM SUSPEND/RESUME機能を使用してミラーの分割によるバックアップを作成する方法について説明します。
一部のミラー化技術では、ミラーを分割してバックアップとして使用する前に、Oracle DatabaseですべてのI/Oを一時停止する必要がありません。データベース・インスタンスでI/Oの一時停止が必要かどうかについては、ストレージ・マネージャ、ボリューム・マネージャまたはファイル・システムのドキュメントを参照してください。
SUSPEND/RESUMEを使用して表領域のミラーの分割によるバックアップを実行する手順
「バックアップの暗号化の構成」で説明されているように、バックアップの暗号化でRMANバックアップ・セットを保護できます。暗号化バックアップは、不正なユーザーが取得しても読み取ることができません。RMANバックアップの暗号化機能を使用するには、Enterprise Editionのデータベースが必要です。
この項の内容は、次のとおりです。
バックアップの暗号化は、次のコマンドで指定される暗号化設定に基づいて実行されます。
CONFIGURE ENCRYPTION
このコマンドを使用すると、透過的暗号化を永続的に構成できます。デュアル・モードまたはパスワード・モードの暗号化は永続的には構成できません。
SET ENCRYPTION
このコマンドを使用すると、デュアル・モードまたはパスワード・モードの暗号化をRMANセッション・レベルで構成できます。
注意:
キーストアベースの暗号化は、パスワードが必要ないため、パスワードベースの暗号化より安全です。パスワード・ベースの暗号化は、バックアップをトランスポータブルにする必要があるため、必要な場合のみ使用してください。
データベースでは、各暗号化バックアップに対して新しい暗号化キーが使用されます。バックアップ暗号化キーは、選択した暗号化モードに応じて、パスワードまたはデータベース・マスター・キー(あるいはその両方)を使用して暗号化されます。個々のバックアップ暗号化キーまたはパスワードは、クリアテキストでは格納されません。
1回のリストア操作で、異なるモードで暗号化されたバックアップを処理できます。RMANは、リストアするバックアップ・ピースごとに、それらが暗号化されているかどうかを確認します。透過的に暗号化されているバックアップは、Oracleキーストアがオープンしていて使用可能な場合、ユーザーの介入を必要としません。
パスワードの暗号化が検出された場合、RMANは、SET DECRYPTIONコマンドで入力したパスワードのリスト内の一致するキーを検索します。使用可能なキーが検出された場合、RMANはリストア操作を続行します。検出されなかった場合、RMANはOracleキーストア内のキーを検索します。RMANは、使用可能なキーが検出された場合はリストア操作を続行します。検出されなかった場合はバックアップ・ピースを復号化できないというエラーを通知します。
注意:
異なるパスワードを使用して作成されたバックアップのセットをRMANでリストアする場合は、必要なすべてのパスワードをSET DECRYPTIONに指定する必要があります。
RMANの暗号化はCPUに負荷のかかる操作であり、バックアップのパフォーマンスに影響を及ぼす可能性があります。暗号化の際の実際のCPU使用量は、ディスクおよびSBTの入力デバイスと出力デバイスにおけるデータの作成および消費が、CPUでのデータの暗号化より速いかどうかによって異なります。次に、CPUパフォーマンスを管理し、最大化するためのガイドラインを示します。
暗号化バックアップでは、暗号化されていないバックアップの場合より多くのCPUリソースが消費されるため、より多くのRMANチャネルを使用すると、ディスクへの暗号化バックアップのパフォーマンスを向上させることができます。システム内でCPUコアと同じ数のチャネルを使用することをお薦めします。たとえば、デュアルコア・プロセッサには、2つのチャネルを使用します。
ディスク・サブシステムとSBTサブシステムの両方が高速な場合は、CPU使用率が非常に高くなることが予想されます。必要に応じて、RMANのREADRATEパラメータを設定して、バックアップ・レートの低速化を検討できます。たとえば、ブロックの読取り上限を設定して、RMANで過度のディスク帯域幅が消費され、それによりオンライン・パフォーマンスが低下するのを防止できます。
関連項目:
パスワード暗号化バックアップをリストアする方法については、「データベースの完全リカバリの実行」を参照してください。
SETコマンドのENCRYPTIONおよびDECRYPTIONオプションの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
「RMANバックアップの暗号化モードの構成」の説明に従って、CONFIGUREコマンドで透過的暗号化を構成してある場合、暗号化バックアップの作成に必要な追加のコマンドはありません。通常どおりに、Recovery Managerバックアップを作成します。
再開可能バックアップ機能を使用すると、指定した日付以降にバックアップされていないファイルのみをバックアップできます。
この項の内容は、次のとおりです。
再開可能最小単位はデータファイルです。ただし、バックアップ・セットに1つのバックアップ・ピースが含まれ、このピースに複数のデータファイルからのブロックが含まれている場合、再開可能単位はバックアップ・ピースになります。イメージ・コピーの再開可能単位はデータファイルです。
再開可能バックアップのメリットは、バックアップによって複数のバックアップ・セットが生成される場合、正常に完了したバックアップ・セットを再実行する必要がないことです。ただし、データベース全体が1つのバックアップ・セットに書き込まれる場合、途中でバックアップが失敗すると、バックアップ全体を再開する必要があります。
ファイルの読取り時またはバックアップ・ピースやイメージ・コピーへの書込み時にI/Oエラーが検出された場合、RMANは実行中のバックアップ・ジョブを終了します。たとえば、バックアップを試みたデータファイルがディスク上に存在しなかった場合、バックアップは終了します。ただし、複数のチャネルが使用されていたり、バックアップの冗長コピーが作成されている場合、RMANはユーザーの介入なしにバックアップを続行できる可能性があります。
RMANは、指定した日付以降にバックアップされていないファイルのみをバックアップできます。バックアップが失敗した場合にこの機能を使用すると、失敗したバックアップで処理されなかったデータベースの部分をバックアップできます。
BACKUPコマンドでSINCE TIME句を指定して、バックアップを再開できます。SINCE TIMEに完了時刻より後の値が設定されている場合、RMANはそのファイルをバックアップします。SINCE TIMEパラメータを指定せずにBACKUP DATABASE NOT BACKED UPを使用した場合、RMANは、一度もバックアップされていないファイルのみをバックアップします。
関連項目:
BACKUP ... NOT BACKED UPの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
BACKUPコマンドのSINCE TIMEパラメータを使用すると、その日付を過ぎると新しいバックアップが必要になる日付を指定できます。SINCE TIMEに完了時刻より後の値が設定されている場合、RMANはそのファイルをバックアップします。SINCE TIMEパラメータを指定せずにBACKUP DATABASE NOT BACKED UPを使用した場合、RMANは、一度もバックアップされていないファイルのみをバックアップします。
指定した日付以降にバックアップされていないファイルのみをバックアップする手順
関連項目:
BACKUPコマンドを使用して完了していないバックアップを再開する方法の例については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
この項では、バックアップ期間を使用して、バックアップ・ジョブを完了できる期間の制限を設定する方法について説明します。
この項の内容は、次のとおりです。
バックアップ期間とは、バックアップを完了する必要がある時間の長さのことです。たとえば、データベースのバックアップを、システム上のユーザー・アクティビティが低下する時間帯(午前2時から6時など)に制限する場合があります。
RMANは、バックアップの日付が最も古いファイルを最初にバックアップします。デフォルトでは、RMANはファイルを可能なかぎり速くバックアップします。期間を指定しても、期間終了前にバックアップが完了するように通常より速くデータがバックアップされるわけではありません。
デフォルトでは、バックアップがDURATIONの時間内に完了しなかった場合、RMANはバックアップを中断し、エラーを通知します。BACKUPコマンドをRUNコマンド内で使用すると、RUNコマンドは終了します。バックアップ全体が完了しなかった場合でも、バックアップが完了したバックアップ・セットは保持され、リストア操作で使用できます。このため、実行可能な時間が終了して中断されたジョブを再試行すると、試行を繰り返すたびに、バックアップする必要があるファイルの処理が進行していきます。不完全なバックアップ・セットは廃棄されます。
BACKUPコマンドのDURATIONパラメータを使用して、特定のバックアップ・ジョブの実行を許可する期間を指定します。
バックアップ期間を指定する手順
関連項目:
BACKUPコマンドの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
PARTIALを指定すると、RMANは、バックアップ期間が終了してバックアップが中断された場合でも、エラーを通知しません。かわりに、バックアップされていないファイルを示すメッセージを表示します。BACKUPコマンドをRUNブロックで実行している場合、RUNブロック内の残りのコマンドは続行されます。
FILESPERSET 1を指定すると、RMANは各ファイルを独自のバックアップ・セットに格納します。バックアップ期間が終了してバックアップが中断されると、そのときバックアップ中であったファイルのバックアップのみが消失します。時間内に完了したすべてのバックアップ・セットは保存されるため、バックアップ期間の終了によって無効となる処理は最小限で済みます。
バックアップが部分的に完了した場合にRMANがエラーを通知しないようにする手順
DURATIONを使用すると、最高のパフォーマンスでバックアップを実行したり、割り当てられた時間内で可能なかぎり低速のバックアップを実行して、パフォーマンスへのバックアップ作業の影響を最小限に抑えることができます。最高のパフォーマンスでバックアップを実行するには、例10-4のように、DURATIONとともにMINIMIZE TIMEオプションを使用します。
例10-4 BACKUP DURATIONでのMINIMIZE TIMEの使用
BACKUP DURATION 4:00 PARTIAL MINIMIZE TIME DATABASE FILESPERSET 1;
使用可能なすべての時間を使用してバックアップを実行するには、例10-5のように、MINIMIZE LOADオプションを使用します。
例10-5 BACKUP DURATIONでのMINIMIZE LOADの使用
この例では、RMANは実行中のバックアップの進捗状況を監視し、現在のレートでバックアップの完了に必要な時間を定期的に見積もります。バックアップ期間の終了前にバックアップが終了すると判断した場合、RMANは、使用可能なすべての時間が使用されるように、バックアップのレートを低下させます。これによって、データベースでバックアップに関連するオーバーヘッドが減少します。
BACKUP DURATION 4:00 MINIMIZE LOAD DATABASE FILESPERSET 1;
DURATIONおよびMINIMIZE LOADをテープ・バックアップで使用する場合は、次の事項に注意してください。
テープへの効率的なバックアップには、テープ・ストリームが必要です。MINIMIZE LOADを使用すると、RMANがバックアップのレートを低下させ、テープ・ストリームが最適ではなくなる場合があります。
RMANは、バックアップ期間中、常にテープ・リソースを保持します。このため、バックアップ期間中は、テープ・リソースを他の目的に使用できません。
これらの点から、テープへのバックアップ時にはMINIMIZE LOADを使用しないことをお薦めします。
関連項目:
効率的なテープ処理の詳細は、「SBTへの書込みフェーズにおけるメディア・マネージャの構成要素」を参照してください。
