11g リリース1（11.1）
E05700-03
 目次 |
 索引 |
| Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド 11g リリース1（11.1） E05700-03 |
|
この章では、Recovery Managerを構成する場合の基本的なタスクについて説明します。この章の内容は、次のとおりです。
Recovery Managerには、バックアップに必要なほとんどのパラメータに対して、基本的なバックアップおよびリカバリを実行できる適切なデフォルトが備えられています。Recovery Managerベースのバックアップ計画を実装する場合、一般的な構成を理解すると、Recovery Managerを効果的に使用できます。
Recovery Managerの継続的な使用を簡単にするには、各ターゲット・データベースに多くの永続構成を設定します。これらの設定によって、Recovery Managerの動作の様々な点が制御されます。たとえば、バックアップの保存方針、バックアップのデフォルトの格納先、デフォルトのバックアップ・デバイス・タイプなどを構成できます。SHOWおよびCONFIGUREコマンドを使用すると、Recovery Manager構成の表示および変更を行うことができます。
この項では、Recovery Manager構成の概要およびCONFIGUREコマンドを使用してRecovery Managerのデフォルトの動作をバックアップとリカバリ環境用に変更する方法について説明します。また、使用可能な主な設定および一般的な設定値についても説明します。
|
注意: テープにバックアップする場合にRecovery Managerをメディア・マネージャとともに使用するように設定する方法については、「メディア・マネージャにバックアップするためのRecovery Managerの構成」を参照してください。 |
この項の内容は、次のとおりです。
SHOWコマンドを使用すると、ターゲット・データベース用に設定されたRecovery Managerの現在の値を表示できます。これらのコマンドが、現在デフォルト値に設定されているかどうかを表示することもできます。
SHOWコマンドを実行します。たとえば、例5-1に示すように、SHOW ALLを実行します（出力例も示します）。出力には、変更したパラメータおよびデフォルトに設定されたパラメータが含まれています。構成は、構成の再作成に必要な一連のRecovery Managerコマンドとして表示されます。出力をテキスト・ファイルに保存したり、このコマンド・ファイルを使用して同じまたは別のデータベースに構成を再作成することができます。
SHOW ALL;
RMAN configuration parameters for database with db_unique_name PROD1 are:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE SBT_TAPE TO '%F'; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 2 BACKUP TYPE TO COMPRESSED BACKUPSET;
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS 'ENV=(OB_DEVICE=tape1)';
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/disk1/oracle/dbs/snapcf_ev.f'; # default
SHOWコマンドは、特定の構成の名前を指定して使用することもできます。たとえば、次のように入力すると、保存方針およびデフォルトのデバイス・タイプを表示できます。
SHOW RETENTION POLICY; SHOW DEFAULT DEVICE TYPE;
CONFIGURE ... CLEARコマンドを使用して構成をデフォルト値に戻します。次に例を示します。
CONFIGURE BACKUP OPTIMIZATION CLEAR; CONFIGURE RETENTION POLICY CLEAR; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK CLEAR;
バックアップ先のデバイス・タイプが指定されていないバックアップは、構成済のデフォルト・デバイスに格納されます。Recovery Managerは、デフォルトのデバイス・タイプとしてディスクを使用するように事前構成されています。追加の構成は必要ありません。
デフォルトのデバイス・タイプをディスクからテープに変更したり、テープからディスクに戻す必要がある場合があります。表5-1に、デフォルトのデバイスを構成するコマンドを示します。
| コマンド | 説明 |
|---|---|
|
|
バックアップをデフォルトでディスクに格納するように指定します。 リカバリ領域が有効になっている場合、バックアップ場所はデフォルトでフラッシュ・リカバリ領域になります。リカバリ領域が有効になっていない場合、バックアップ場所はデフォルトでディスク上のオペレーティング・システム固有のディレクトリになります。 ディスクにバックアップする場合、データベース・ファイルの論理ブロック・サイズは、バックアップ先のデバイスの物理ブロック・サイズの倍数である必要があります。たとえば、ブロック・サイズが2KBのDISKタイプのデバイスは、論理ブロック・サイズが2KB、4KB、6KBなどのデータベース・ファイルのバックアップ先としてのみ使用できます。ほとんどのディスク・ドライブの物理ブロック・サイズは512バイトであるため、この制限が、ディスク・ドライブへのバックアップに影響を及ぼすことはほとんどありません。ただし、書込み可能なDVDまたは物理ブロック・サイズが大きいデバイスにバックアップする場合は、この制限の影響を受ける可能性があります。 |
|
|
バックアップをデフォルトでテープに格納するように指定します。 メディア・マネージャで使用するRecovery Managerの設定方法については、「メディア・マネージャにバックアップするためのRecovery Managerの構成」を参照してください。Recovery Managerがメディア・マネージャと通信できるようになった後、テープにバックアップが作成されるようにRecovery Managerを構成し、デフォルトのデバイス・タイプとしてSBTを指定します。 |
デフォルトのデバイスは、BACKUPコマンドのDEVICE TYPE句を使用して、常に上書きできます。
BACKUP DEVICE TYPE sbt DATABASE; BACKUP DEVICE TYPE DISK DATABASE;
SHOW ALLコマンドを実行して、現在構成されているデフォルトのデバイスを表示します。
TO DISKまたはTO sbtのいずれかを指定して、CONFIGURE DEFAULT DEVICE TYPEコマンドを実行します。BACKUPコマンドによって、バックアップ・セットまたはイメージ・コピーを作成できます。ディスクの場合、CONFIGURE DEVICE TYPE DISK BACKUP TYPE TOコマンドを使用すると、デフォルトのバックアップ・タイプとしてバックアップ・セットまたはイメージ・コピーを作成するようにRecovery Managerを構成できます。ディスクのデフォルトのバックアップ・タイプは、圧縮されていないバックアップ・セットです。
Recovery Managerはバイナリ圧縮を使用してバックアップ・セットを作成できます。BACKUP TYPE TO ... BACKUPSET句にCOMPRESSEDオプションを指定すると、デバイス・タイプに対してデフォルトで圧縮バックアップ・セットを使用するようにRecovery Managerを構成できます。圧縮を無効にするには、他の必要な設定を示す引数を指定してCONFIGURE DEVICE TYPEコマンドを使用しますが、COMPRESSEDキーワードは省略します。
次の例では、ディスク・バックアップのバックアップ・タイプをコピーおよびバックアップ・セットに構成しています。
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY; # image copies CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO BACKUPSET; # uncompressed
次の例では、バックアップ・セットの圧縮を構成しています。
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET; CONFIGURE DEVICE TYPE sbt BACKUP TYPE TO COMPRESSED BACKUPSET;
「Recovery Managerチャネル」で説明されているように、Recovery Managerチャネルとは、データベース・サーバー・セッションへの接続のことです。Recovery Managerは、ほぼすべてのRecovery Managerタスクの実行にチャネルを使用します。
ディスクまたはSBTチャネルのオプションを構成するには、CONFIGURE CHANNELコマンドを使用します。CONFIGURE CHANNELでは、ALLOCATE CHANNELコマンドで1回のみのオプションを指定する場合と同じオプションを使用します。デバイス・タイプに汎用チャネル設定を構成できます。汎用チャネル設定は、デバイスの構成済設定に基づいて作成されるチャネルで使用されるテンプレートです。
CONFIGURE CHANNELを使用してデバイスの汎用チャネル設定を指定する場合は、設定が競合していなくても、以前の設定は廃棄されることに注意してください。たとえば、構成済ディスク・チャネルのFORMATのみを指定する2つ目のCONFIGURE CHANNELコマンドを実行すると、ディスク・チャネルのMAXPIECESIZEがデフォルト値に戻ります。
CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 2G; CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT /tmp/%U;
デフォルトでは、Recovery Managerは、1つのディスク・チャネルをすべての操作に割り当てます。このチャネルに対して、バックアップ用の新しいデフォルトの場所などの他のオプションを指定する必要がある場合があります。例5-2では、ディスク・バックアップを/disk1ディレクトリに書き込むようにRecovery Managerを構成し、相対ファイル名にデフォルト以外の書式を指定します。
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/disk1/ora_df%t_s%s_s%p';
例5-2では、Recovery Managerは、書式指定子%tを4バイトのタイムスタンプに、%sをバックアップ・セット番号に、%pをバックアップ・ピース番号に自動的に置換します。
|
注意: ディスク・チャネルに明示的な書式を構成すると、Recovery Managerは、デフォルトではフラッシュ・リカバリ領域にバックアップを作成しません。この場合、フラッシュ・リカバリ領域のディスク領域管理機能は失われます。 |
次の例のように、ASMディスクの場所を指定することもできます。
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '+dgroup1';
コマンドの実行時にデバイス・タイプで使用できるチャネルの数によって、Recovery Managerが読取りまたは書込みをパラレルで行うかどうかが決まります。通常、コマンドの実行に使用するチャネルの数は、アクセスされるデバイスの数と一致する必要があります。したがって、テープ・バックアップの場合は、テープ・ドライブごとに1つのチャネルを割り当てます。ディスク・バックアップの場合は、物理ディスクごとに1つのチャネルを割り当てます。ただし、複数のチャネルを使用して、ディスク・サブシステム・アーキテクチャ用にバックアップを最適化できる場合は除きます。適切な数のチャネルが割り当てられない場合、I/O操作中のRecovery Managerのパフォーマンスが低下します。
CONFIGURE DEVICE TYPE sbtを使用すると、SBTデバイスに対してチャネルのパラレル化設定、バックアップ・セットのバイナリ圧縮などのオプションを構成できます。デバイス・タイプの構成は、チャネルの構成とは別に設定できます。
例5-3では、Recovery Managerで2つのテープ・ドライブをパラレルに使用してメディア・マネージャにバックアップできるようにSBTデバイスのパラレル化を変更します（出力例も示します）。構成済の各SBTチャネルでは、データの合計の約半分ずつがバックアップされます。
RMAN> CONFIGURE DEVICE TYPE sbt PARALLELISM 2;
old RMAN configuration parameters:
CONFIGURE DEVICE TYPE 'SBT_TAPE' BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 1;
new RMAN configuration parameters:
CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 2 BACKUP TYPE TO COMPRESSED BACKUPSET;
new RMAN configuration parameters are successfully stored
例5-4では、SBTデバイスのデフォルトのバックアップ・タイプを、圧縮されていないバックアップ・セットに変更します（出力例も示します）。
RMAN> CONFIGURE DEVICE TYPE sbt BACKUP TYPE TO BACKUPSET;
old RMAN configuration parameters:
CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 2 BACKUP TYPE TO COMPRESSED BACKUPSET;
new RMAN configuration parameters:
CONFIGURE DEVICE TYPE 'SBT_TAPE' BACKUP TYPE TO BACKUPSET PARALLELISM 2;
new RMAN configuration parameters are successfully stored
パラレル化およびバックアップ・タイプを設定するためにこの例で使用されているCONFIGURE DEVICE TYPEコマンドは、指定されていない設定値には影響を及ぼしません。例5-3では、パラレル化を変更しても、圧縮済バックアップ・セットのデフォルトのバックアップ・タイプは変更されていません。例5-4では、デフォルトのバックアップ・タイプを変更しても、パラレル化は変更されていません。
|
参照:
|
ジョブの実行中にチャネルを手動で割り当てると、構成済チャネルのすべての設定が無視されます。たとえば、デフォルトのデバイス・タイプがSBTに構成された状態で、次のコマンドを実行するとします。
RUN { ALLOCATE CHANNEL c1 DEVICE TYPE DISK; BACKUP TABLESPACE users; }
この場合、Recovery Managerは、RUNコマンド内で手動で割り当てられたディスク・チャネルのみを使用して、CONFIGURE DEVICE TYPE、CONFIGURE DEFAULT DEVICEまたはCONFIGURE CHANNEL設定を使用して設定されたすべてのデフォルトを上書きします。
|
参照:
|
「制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップ」で説明されているように、Recovery Managerは、制御ファイルおよびサーバー・パラメータ・ファイルを自動的にバックアップするように構成することができます。自動バックアップは、バックアップ・レコードが追加されるたびに実行されます。また、データベースがARCHIVELOGモードで実行されている場合も、自動バックアップは、制御ファイル内のデータベース構造メタデータが変更されるたびに実行されます。現行の制御ファイル、リカバリ・カタログおよびサーバー・パラメータ・ファイルが消失した場合でも、制御ファイルの自動バックアップを使用して、Recovery Managerはデータベースをリカバリできます。
自動バックアップのファイル名は標準書式に従っているため、Recovery Managerは、リポジトリにアクセスせずにこのファイルを検索し、サーバー・パラメータ・ファイルをリストアできます。リストアされたサーバー・パラメータ・ファイルを使用してインスタンスを起動すると、Recovery Managerは、自動バックアップから制御ファイルをリストアできます。制御ファイルをマウントすると、Recovery Managerリポジトリが使用可能になり、Recovery Managerは、データファイルをリストアし、アーカイブREDOログが検索できるようになります。
次のコマンドを実行すると、自動バックアップ機能を有効にできます。
CONFIGURE CONTROLFILE AUTOBACKUP ON;
次のコマンドを実行すると、自動バックアップ機能を無効にできます。
CONFIGURE CONTROLFILE AUTOBACKUP OFF;
デフォルトでは、すべての構成済デバイスの自動バックアップ・ファイルの書式はFORMAT句の置換変数%Fです。この変数の書式は、c-IIIIIIIIII-YYYYMMDD-QQに変換され、プレースホルダは次のように定義されます。
次のコマンドを使用すると、デフォルトの書式を変更できます。ここで、deviceSpecifierは有効なデバイス・タイプです。'string'には置換変数%F（他の置換変数は除く）が含まれている必要があります。また、'string'は指定したデバイスの有効なハンドルとなります。
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE deviceSpecifier TO 'string';
たとえば、次のコマンドを実行すると、制御ファイルの自動バックアップにデフォルト以外のファイル名を指定できます。ファイル名で、?はORACLE_HOMEを表します。
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '?/oradata/cf_%F';
次の例では、自動ストレージ管理ディスク・グループに書き込まれるように自動バックアップを構成します。
CONFIGURE CONTROLFILE AUTOBACKUP FOR DEVICE TYPE DISK TO '+dgroup1/%F';
デバイスに対する制御ファイルの自動バックアップの書式をクリアするには、次のコマンドを使用します。
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK CLEAR; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE sbt CLEAR;
データベースにフラッシュ・リカバリ領域が設定されている場合、ディスクに対する制御ファイルの自動バックアップ書式をクリアすると、制御ファイルの自動バックアップをフラッシュ・リカバリ領域に格納することができます。
RUNコマンド内またはRecovery Managerプロンプトのいずれかで指定できるSET CONTROLFILE AUTOBACKUP FORMATコマンドを指定すると、現行のセッションのみで構成済の自動バックアップ書式が上書きされます。優先順位は次のとおりです。
SET CONTROLFILE AUTOBACKUP FORMAT（RUNブロック内）
SET CONTROLFILE AUTOBACKUP FORMAT（Recovery Managerプロンプト）
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT
次の例では、2つの形式のSET CONTROLFILE AUTOBACKUP FORMATの相互作用を示します。
SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'controlfile_%F'; BACKUP AS COPY DATABASE; RUN { SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/tmp/%F.bck'; BACKUP AS BACKUPSET DEVICE TYPE DISK DATABASE; }
最初のSET CONTROLFILE AUTOBACKUP FORMATは、制御ファイルのすべての構成済自動バックアップ書式より優先され、Recovery Managerクライアントが終了するまで制御ファイルの自動バックアップの名前を制御します。RUNブロック内のSET CONTROFILE AUTOBACKUP FORMATでは、RUNブロックが有効なかぎり、RUNブロックの外にあるSET CONTROLFILE AUTOBACKUP FORMATは上書きされます。
ほとんどのプラットフォームでは、テープなどのシーケンシャル・メディアにバックアップしたり、これらのメディアからリストアしたりする場合には、Oracle Databaseとメディア・マネージャを統合する必要があります。テープに対してデータベース・システムとファイル・システムの両方のバックアップをサポートしているOracle Secure Backupをメディア・マネージャとして使用できます。特にOracle Secure Backupとともに使用するためにRecovery Managerを設定する方法の詳細は、『Oracle Secure Backup管理者ガイド』を参照してください。
Oracle Secure Backupを使用しない場合は、サード・パーティのメディア・マネージャを使用できます。この項では、サード・パーティのメディア・マネージャとともに使用するためにRecovery Managerを構成する一般的な手順について説明します。実際の手順は、インストールしたメディア管理製品およびデータベースを実行しているプラットフォームによって異なります。Oracle Secure Backup以外のメディア・マネージャとともにRecovery Managerを使用する場合は、製品固有のすべての情報をベンダーから入手する必要があります。
メディア・マネージャを構成する際、次の項を順に参照してください。
Recovery Managerをサード・パーティのメディア・マネージャとともに使用するには、メディア・マネージャをインストールし、Recovery Managerと通信できるようにする必要があります。詳細は、メディア管理ソフトウェアのベンダーのドキュメントを参照してください。
通常、まず、メディア管理ソフトウェアをターゲット・ホストまたは本番ネットワークにインストールして構成します。オペレーティング・システム・ファイルのRecovery Manager以外のバックアップをターゲット・データベース・ホスト上に作成できることを確認します。この手順に従って、メディア・マネージャとターゲット・ホストの基本的な統合が正常に完了したことを確認すると、後で行うトラブルシューティングが簡単になります。Recovery Managerを使用しないでメディア・マネージャにファイルをバックアップする方法については、メディア管理ソフトウェアのドキュメントを参照してください。
次に、サード・パーティのメディア管理モジュールを入手してインストールし、データベース・サーバーと統合します。このモジュールには、Oracle Databaseがメディア・マネージャへのアクセス時にロードおよび使用するメディア管理ライブラリが含まれています。このモジュールは通常、別ライセンスのサード・パーティ製品です。詳細は、メディア管理モジュールのベンダーに問い合せてください。
メディア・マネージャとともにRecovery Managerを使用する前に、メディア管理ライブラリの場所を指定します。Recovery Managerでメディア・マネージャとの通信に使用するチャネルの割当てまたは構成を行う場合は、ALLOCATE CHANNELまたはCONFIGURE CHANNELコマンドにSBT_LIBRARYパラメータを指定する必要があります。SBT_LIBRARYパラメータには、ライブラリへのパスを指定します。
次に、チャネルの構文の例を示します。ここで、pathnameは、ライブラリの絶対ファイル名です。
CONFIGURE CHANNEL DEVICE TYPE sbt PARMS 'SBT_LIBRARY=pathname';
Recovery Managerは、メディア・マネージャと通信するためのチャネルを割り当てる場合、SBT_LIBRARYパラメータで指定されたライブラリをロードします。
割当て済または事前構成済のチャネルでSBT_LIBRARYパラメータの値を指定しない場合、Recovery Managerは、プラットフォーム固有のデフォルトの場所を検索します。LinuxおよびUNIXでは、デフォルトのライブラリ・ファイル名は$ORACLE_HOME/lib/libobk.soです。拡張子名はプラットフォームに応じて異なり、.so、.sl（HP-UXの場合）、.a（AIXの場合）などが使用されます。Windowsでは、デフォルトのライブラリの場所は%ORACLE_HOME%¥bin¥orasbt.dllです。
メディア管理ソフトウェアのインストール後、Recovery Managerでバックアップを受け入れることができるように、ベンダーの要件に従ってソフトウェアを構成します。インストールしたメディア管理ソフトウェアのタイプによっては、メディア・プールの定義、ユーザーおよびクラスの構成などが必要になる場合があります。
Recovery Managerの適切な設定については、メディア管理ベンダーのドキュメントを参照してください。PARMSパラメータは、メディア・マネージャに指示を送信します。ALLOCATE CHANNELまたはCONFIGURE CHANNELコマンドにPARMS値が必要な場合、あるいはBACKUPまたはCONFIGUREコマンドにFORMAT文字列が推奨されている場合の詳細は、ベンダーのドキュメントを参照してください。
例5-5に、Oracle Secure BackupのPARMS設定を示します。このPARMS設定は、datafile_mfという一連のテープにバックアップを行うようにメディア・マネージャに指示します。PARMS設定は、常にベンダー固有です。
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS 'ENV=(OB_MEDIA_FAMILY=datafile_mf)';
データベース・サーバーでメディア管理ライブラリをロードできることを確認した後、Recovery Managerでメディア・マネージャにバックアップできるかどうかをテストします。
次の手順では、ALLOCATE CHANNELコマンドを使用して、Recovery Managerがメディア・マネージャと通信できるかどうかを確認する基本的なテストを実行します。
PARMSを指定してALLOCATE CHANNELコマンドを実行します。次のRUNコマンドは、ベンダー固有のPARMS設定の例を示しています。
RUN { ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS 'SBT_LIBRARY=/mydir/lib/libobk.so, ENV=(OB_DEVICE=drive1,OB_MEDIA_FAMILY=datafile_mf)'; }
エラー・メッセージが表示されない場合、データベースはメディア管理ライブラリを正常にロードしています。ORA-27211エラーが発生した場合、メディア管理ライブラリはロードされていません。
RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03009: failure of allocate command on c1 channel at 11/30/2007 13:57:18 ORA-19554: error allocating device, device type: SBT_TAPE, device name: ORA-27211: Failed to load Media Management Library Additional information: 25
この場合、メディア管理ソフトウェアの使用環境にメディア管理ライブラリが正常にインストールされているかどうかを確認し、SBT_LIBRARYパラメータの値（「メディア管理ライブラリの場所の確認」を参照）を再確認する必要があります。
SBT_LIBRARYパラメータに指定された場所またはデフォルトの場所でデータベースがメディア管理ライブラリを検出できない場合、Recovery ManagerはORA-27211エラーを発行して終了します。
チャネルの割当てに失敗すると、データベースは、常に自動診断リポジトリ・ホーム・ディレクトリのTRACEサブディレクトリにトレース・ファイルを書き込みます。出力例を次に示します。
SKGFQ OSD: Error in function sbtinit on line 2278 SKGFQ OSD: Look for SBT Trace messages in file /oracle/rdbms/log/sbtio.log SBT Initialize failed for /oracle/lib/libobk.so
メディア・マネージャでチャネルの割当てをテストした後、テスト・バックアップを作成し、リストアします。たとえば、例5-6の（メディア管理ベンダーで要求されているチャネル設定に置き換える）コマンドを使用すると、メディア・マネージャにバックアップを作成できるかどうかをテストできます。データベースでサーバー・パラメータ・ファイルが使用されていない場合は、かわりに、現行の制御ファイルをバックアップします。
RUN { ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS 'SBT_LIBRARY=/mydir/lib/libobk.so, ENV=(OB_DEVICE=drive1,OB_MEDIA_FAMILY=datafile_mf)'; BACKUP SPFILE; # If your database does not use a server parameter file, use: # BACKUP CURRENT CONTROLFILE; }
バックアップが正常に完了した後、サーバー・パラメータ・ファイルを初期化パラメータ・ファイルとしてリストアします。例5-7では、例5-6で作成したバックアップを一時ディレクトリにリストアします。
RUN { ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS 'SBT_LIBRARY=/mydir/lib/libobk.so, ENV=(OB_DEVICE=drive1,OB_MEDIA_FAMILY=datafile_mf)'; RESTORE SPFILE TO PFILE '/tmp/test_restore.f'; # If your database does not use a server parameter file, use: # RESTORE CURRENT CONTROLFILE; }
バックアップおよびリストア操作が正常に完了すると、Recovery Managerでメディア・マネージャを使用できます。バックアップの失敗には、次の状況が考えられます。
バックアップが中断した場合、通常はメディア・マネージャがテープのマウントを待機していることを示します。テープ・マウント要求モードのメディア・マネージャ・ジョブの有無を確認し、問題を修正します。「メディア・マネージャにバックアップするためのRecovery Managerの構成」の手順を正しく実行していることを確認します。
このエラーは、メディア管理ソフトウェアが正しく構成されていないことを示します。「メディア・マネージャにバックアップするためのRecovery Managerの構成」の手順を正しく実行していることを確認します。また、メディア管理ソフトウェアの要件に従って、PARMSおよびFORMAT文字列を正しく設定していることも確認します。
この項では、メディア・マネージャで使用するチャネルを構成する方法について説明します。構成済チャネルの概要およびその使用方法については、「高度なチャネル・オプションの構成」を参照してください。
バックアップ・ピース名は、BACKUPコマンド、CONFIGURE CHANNELコマンドまたはALLOCATE CHANNELコマンドに指定するFORMAT文字列によって決まります。メディア・マネージャでは、バックアップ・ピース名がバックアップ・ファイル名として認識されるため、メディア管理カタログ内で一意である必要があります。
FORMATパラメータ内の置換変数を使用すると、一意のバックアップ・ピース名を生成できます。たとえば、%dにはデータベース名を指定し、%tにはバックアップ・タイムスタンプを指定します。ほとんどの用途に対して%Uを使用できます。この場合、Recovery Managerは一意なファイル名を自動的に生成します。バックアップ・ピース名の例としては、12i1nk47_1_1があります。FORMATパラメータを指定しない場合、Recovery Managerは%U置換変数を含む一意のファイル名を自動的に生成します。
使用しているメディア・マネージャで、ファイルの名前およびサイズに制限がある場合があります。この場合、バックアップ・ピース名がメディア・マネージャの制限に従うように、バックアップ・ピース名の指定により詳細な制御を行う必要があります。たとえば、14文字のバックアップ・ピース名のみをサポートするメディア・マネージャ、特別なFORMAT文字列を必要とするメディア・マネージャなどが存在します。%U置換変数によって生成される一意の名前が14文字を超えないように注意してください。
一部のメディア・マネージャでは、バックアップまたはリストア可能なファイルの最大サイズが制限されている場合があります。Recovery Managerがこの制限を超えるバックアップ・セットを生成しないようにする必要があります。バックアップ・ピースのサイズを制限するには、CONFIGURE CHANNELおよびALLOCATE CHANNELコマンドに設定可能なパラメータMAXPIECESIZEを使用します。
|
参照:
|
メディア・マネージャをバックアップする最も簡単な方法は、SBTチャネルを構成する方法です。「バックアップ用のデフォルト・デバイスの構成: ディスクまたはSBT」で説明されているように、テープ・デバイスをデフォルトのバックアップ先として使用できます。
この構成では、「メディア・マネージャでのバックアップおよびリストア操作のテスト」でテストしたすべてのパラメータを入力します。次の例では、ベンダー固有のチャネル・パラメータを構成し、デフォルト・デバイスを設定します。
CONFIGURE CHANNEL DEVICE TYPE sbt PARMS 'ENV=(OB_RESOURCE_WAIT_TIME=1minute,OB_DEVICE=tape1)';
CONFIGURE DEFAULT DEVICE TYPE TO sbt;
複数のテープ・デバイスを使用する場合は、チャネルのパラレル化を指定する必要があります（「ディスクおよびSBTデバイス用のチャネルのパラレル化の構成」を参照）。次のように構成すると、2つのテープ・ドライブにパラレルにバックアップできます。
CONFIGURE DEVICE TYPE sbt PARALLELISM 2;
必要に応じて、次のコマンドを実行してチャネルの構成を確認します。
SHOW CHANNEL FOR DEVICE TYPE sbt;
次のコマンドを実行すると、サーバー・パラメータ・ファイルがテープにバックアップされます。
BACKUP SPFILE;
LIST BACKUP OF SPFILE;
「フラッシュ・リカバリ領域」で説明されているように、フラッシュ・リカバリ領域機能を使用すると、バックアップおよびリカバリに関連する様々なファイルの作成と管理をデータベースで実行可能なディスク領域を設定できます。フラッシュ・リカバリ領域を使用することをお薦めします。バックアップ計画を実装する場合の最初の手順の1つとして、フラッシュ・リカバリ領域を構成することを検討してください。
この項では、フラッシュ・リカバリ領域の機能の概要、この領域に格納されているファイルの識別方法、ファイル管理の規則および最も重要な構成オプションの概要について説明します。この項の内容は、次のとおりです。
フラッシュ・リカバリ領域には、制御ファイル、オンラインREDOログ、アーカイブREDOログ、フラッシュバック・ログおよびRecovery Managerバックアップを含めることができます。フラッシュ・リカバリ領域内のファイルは、永続的なファイルまたは一時的なファイルに分類されます。永続的なファイルとは、データベース・インスタンスで使用されるアクティブなファイルのことです。永続的でないすべてのファイルは一時的なファイルとなります。通常、Oracle Databaseでは、バックアップの保存方針に従って不要になった一時的なファイルまたはテープにバックアップされた一時的なファイルは最終的に削除されます。
表5-2に、リカバリ領域内のファイル、各ファイルの分類（永続的または一時的）およびデータベースの可用性への影響を示します。
| ファイル | タイプ | リカバリ領域にアクセスできない場合のデータベースの動作 |
|---|---|---|
|
現行の制御ファイルの多重コピー |
永続的 |
データベースでフラッシュ・リカバリ領域に格納されている制御ファイルの多重コピーに書き込むことができない場合は、インスタンスで障害が発生します。アクセス可能な多重コピーがリカバリ領域外にある場合でも障害が発生します。 参照: フラッシュ・リカバリ領域で制御ファイルを構成する方法については、「制御ファイルの場所の構成」を参照してください。 |
|
オンラインREDOログ・ファイル |
永続的 |
フラッシュ・リカバリ領域外のアクセス可能な場所にオンラインREDOログのミラー化されたコピーが存在している場合、インスタンスの可用性は影響を受けません。そうでない場合、インスタンスで障害が発生します。 参照: フラッシュ・リカバリ領域でオンラインREDOログ・ファイルを構成する方法については、「オンラインREDOログの場所の構成」を参照してください。 |
|
アーカイブREDOログ・ファイル |
一時的 |
フラッシュ・リカバリ領域外のアクセス可能な場所にログがアーカイブされる場合、インスタンスの可用性は影響を受けません。そうでない場合、データベースは、オンラインREDOログをアーカイブできないため最終的に停止します。 参照: フラッシュ・リカバリ領域でアーカイブREDOログ・ファイルを構成する方法については、「アーカイブREDOログの場所の構成」を参照してください。 |
|
外部のアーカイブREDOログ・ファイル |
一時的 |
注意: 外部のアーカイブREDOログ・ファイルは、LogMinerセッション用のロジカル・スタンバイ・データベースによって受信されます。外部のアーカイブREDOログのDBIDは、通常のアーカイブ・ログのDBIDとは異なっています。このため、外部のアーカイブREDOログ・ファイルは、ロジカル・スタンバイ・データベース上ではバックアップまたはリストアできません。 |
|
データファイルおよび制御ファイルのイメージ・コピー |
一時的 |
インスタンスの可用性は影響を受けません。 |
|
バックアップ・ピース |
一時的 |
インスタンスの可用性は影響を受けません。 |
|
フラッシュバック・ログ |
一時的 |
保証付きリストア・ポイントが定義されていない場合、インスタンスの可用性は影響を受けません。この場合、データベースによって、フラッシュバック・データベースが自動的に無効となり、アラート・ログにメッセージが書き込まれてデータベース処理が続行されます。保証付きリストア・ポイントが構成されている場合、インスタンスはフラッシュバック・ログとの相互依存関係が原因で失敗します。 フラッシュバック・ログは、データベースのPoint-in-Timeリカバリにかわる有効な機能を提供するOracle Flashback Database機能によって生成されます。これらのログは一時的なファイルであり、フラッシュ・リカバリ領域に格納する必要があります。他の一時的なファイルとは異なり、フラッシュバック・ログは他のメディアにバックアップできません。フラッシュ・リカバリ領域にフラッシュバック・ログを格納できる十分な領域がなく、リカバリ領域が他のバックアップ保存要件を満たしている場合、そのリカバリ領域では、フラッシュバック・ログを削除することができます。 参照: フラッシュバック・ロギングを有効にする方法については、「フラッシュバック・データベースの有効化」を参照してください。 |
Windowsプラットフォームを使用している場合は、Volume Shadow Copy Service（VSS）をOracle VSSライターとともに使用できます。この場合、フラッシュ・リカバリ領域によって、VSSスナップショットにすでにバックアップされているファイルの管理が自動化され、必要に応じてそれらのファイルが削除されます。
|
参照:
|
フラッシュ・リカバリ領域は、Oracle Managed Files（OMF）および自動ストレージ管理とともに使用できます。フラッシュ・リカバリ領域は、OMFの上に構築されるため、OMFを格納できるすべての場所に格納できます。リカバリ領域は、ASMで使用することもできます。
ASMストレージにフラッシュ・リカバリ領域を設定しない場合でも、Oracle Managed Filesを使用してASMディスク・グループでバックアップ・ファイルを管理することができます。新しいバックアップで領域が必要となった場合にリカバリ可能目標を達成するためにファイルを自動削除する必要がなくなるため、フラッシュ・リカバリ領域の主要なメリットのうちの1つ（ファイルの自動削除）が失われます。ただし、OMFの他の自動機能は動作します。
バックアップを格納する場合、フラッシュ・リカバリ領域を使用せずにASMでOMFを使用することはできますが、お薦めしません。ASM下のファイルは直接操作しにくいためです。
フラッシュ・リカバリ領域内の領域は、保存方針に従って保持する必要があるバックアップおよびアーカイブ・ログと、削除される可能性がある他のファイルの間でバランスが取られています。Oracle Databaseでは、他の目的のために領域の再利用が必要になるまで、対象のファイルはフラッシュ・リカバリ領域から削除されません。したがって、多くの場合、最近テープに移されたファイルはディスクでリカバリに使用できます。リカバリ領域は、テープに対するキャッシュとして使用できます。Oracle Databaseでは、フラッシュ・リカバリ領域が一杯になると、フラッシュ・リカバリ領域内の領域を再利用するために必要に応じて対象のファイルが自動的に削除されます。
リカバリ領域を有効にするには、表5-3に必須と示されている初期化パラメータを設定する必要があります。Oracle Real Application Clusters（Oracle RAC）データベースでは、すべてのインスタンスでこれらの初期化パラメータの値が同じである必要があります。この場所は、クラスタ・ファイル・システム、ASMまたは共有ディレクトリ上である必要があります。
| 初期化パラメータ | 必須 | 説明 |
|---|---|---|
|
|
該当 |
ディスク割当て制限を指定します。ディスク割当て制限は、このデータベースのリカバリ領域で使用されるデータの最大格納量をバイト単位で示したものです。このパラメータは、
|
|
|
該当 |
リカバリ領域の場所を指定します。ファイル・システム上のディレクトリまたはASMディスク・グループを指定することができますが、RAWディスクは指定できません。この場所は、ディスク割当て制限に対応できる十分な大きさである必要があります。 |
|
|
該当せず |
データベースをフラッシュバックできる時点の上限（分）を指定します。このパラメータは、フラッシュバック・データベースでのみ必要です。 このパラメータによって、リカバリ領域で保持されるフラッシュバック・ログ・データのサイズが間接的に決定されます。ただし、データベースによって生成されるフラッシュバック・ログのサイズは、データベース・ワークロードによって大幅に異なる可能性があります。一定期間に行われるデータベース更新によって影響を受けるブロックが増えると、この期間に生成されるフラッシュバック・ログ・データによって使用されるディスク領域も増えます。 |
フラッシュ・リカバリ領域は、大きいほど便利になります。フラッシュ・リカバリ領域は、表5-2に示されているファイルを格納できる十分なサイズにすることをお薦めします。リカバリ領域には、データベース内のすべてのデータファイルのコピー、および選択したバックアップ計画で使用される増分バックアップを格納できる必要があります。
前述のサイズの領域を保持することが難しい場合は、最も重要な表領域のバックアップ、およびテープにまだコピーされていないすべてのアーカイブ・ログを保持できるサイズの領域を作成することをお薦めします。最低限、フラッシュ・リカバリ領域は、テープにコピーされていないアーカイブREDOログを格納できるサイズにする必要があります。リカバリ領域にフラッシュバック・ログを格納できる十分な領域がなく、リカバリ領域が他のバックアップ保存要件を満たしている場合、そのリカバリ領域では、フラッシュバック・ログを削除して領域を確保することができます。
有効なフラッシュ・リカバリ領域のサイズを判断する方法は、次の状況によって異なります。
フラッシュバック・ロギングを有効にする場合、生成されるフラッシュバック・ログのサイズは、生成されるREDOログのサイズと同程度になります。たとえば、DB_FLASHBACK_RETENTION_TARGETを24時間に設定し、1日に20GBのREDOがデータベースで生成される場合は、目安として20〜30GBのディスク領域をフラッシュバック・ログに使用できるようにします。フラッシュバック・ロギングが有効になっている場合、同じ目安が保証付きリストア・ポイントに適用されます。たとえば、毎日20GBのREDOがデータベースで生成され、保証付きリストア・ポイントが1日保持される場合は、20GB〜30GBのディスク領域を割り当てます。
バックアップ保存方針がREDUNDANCY 1に設定されている場合にフラッシュ・リカバリ領域のサイズを決定し、増分更新バックアップを使用してOracle推奨の計画に従うとします。この例では、次の式を使用して、ディスク割当て制限を見積もります。nは、増分更新の間隔（日)です。yは、ロジカル・スタンバイ・データベースへの外部のアーカイブREDOログの適用の遅延です。
Disk Quota = Size of a copy of database + Size of an incremental backup + Size of (n+1) days of archived redo logs + Size of (y+1) days of foreign archived redo logs (for logical standby) + Size of control file + Size of an online redo log member * number of log groups + Size of flashback logs (based on DB_FLASHBACK_RETENTION_TARGET value)
フラッシュ・リカバリ領域は、データファイル、制御ファイル、オンラインREDOログなどのアクティブなデータベース・ファイルがデータベースによって保持されているデータベース領域とは別のディスクに配置します。データベース領域と同じディスクにフラッシュ・リカバリ領域を設定している場合、メディアで障害が発生すると、アクティブなデータベース・ファイルとバックアップの両方を失う可能性があります。
DB_RECOVERY_FILE_DESTは、DB_CREATE_FILE_DEST初期化パラメータまたはDB_CREATE_ONLINE_LOG_DEST_n初期化パラメータのいずれとも異なる値に設定することをお薦めします。DB_RECOVERY_FILE_DESTがこれらのパラメータと同じ場合は、データベースによってアラート・ログに警告が書き込まれます。
次のいずれかの条件を満たす場合、複数のデータベースでDB_RECOVERY_FILE_DESTに同じ値を指定できます。
DB_UNIQUE_NAME初期化パラメータが指定されている2つのデータベースで、DB_UNIQUE_NAMEの値が同じではない。
DB_UNIQUE_NAMEが指定されていないデータベースで、DB_NAMEに同じ値が指定されているデータベースがない。
このように、複数のデータベースで1つのフラッシュ・リカバリ領域を共有する場合、フラッシュ・リカバリ領域の場所は、すべてのデータベースのリカバリ・ファイルを保持できるサイズにする必要があります。データベースのDB_RECOVERY_FILE_DEST_SIZEの値を追加し、ミラー化または圧縮などのオーバーヘッドを見込みます。
表5-3は、フラッシュ・リカバリ領域を有効にするために設定する必要がある初期化パラメータを示しています。この項では、リカバリ領域の場所の指定方法およびその初期サイズの設定方法について説明します。
V$ARCHIVED_LOGを問い合せて、DB_FLASHBACK_RETENTION_TARGETに設定する時間にデータベースで生成されるREDOのサイズを決定します。
フラッシュバック・ロギングまたは保証付きリストア・ポイントを使用する場合は、手順1で取得したサイズの値が設定に組み込まれていることを確認します。次のいずれかの方法で、DB_RECOVERY_FILE_DEST_SIZE初期化パラメータを設定します。
DB_RECOVERY_FILE_DEST_SIZEパラメータを設定します。次に例を示します。
DB_RECOVERY_FILE_DEST_SIZE = 10G
ALTER SYSTEM SETを使用してリカバリ領域のサイズを指定します。次に例を示します。
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 10G SCOPE=BOTH SID='*';
次のいずれかの方法で、初期化パラメータを設定します。
DB_RECOVERY_FILE_DESTを設定します。次に例を示します。
DB_RECOVERY_FILE_DEST = '/u01/oradata/rcv_area'
ALTER SYSTEM SETを使用してDB_RECOVERY_FILE_DESTを指定します。次に例を示します。
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = '+disk1' SCOPE=BOTH SID='*';
フラッシュバック・ロギングを使用しない場合は、データベースをオープンし（クローズしている場合）、残りの手順は実行しないでください。
DB_FLASHBACK_RETENTION_TARGETで指定された期間、通常のワークロードでデータベースを実行します。これによって、データベースでフラッシュバック・ログの代表的なサンプルを生成できます。
V$FLASHBACK_DATABASE_LOGビューを次のように問い合せます。
SELECT ESTIMATED_FLASHBACK_SIZE FROM V$FLASHBACK_DATABASE_LOG;
フラッシュバック・データベースが有効になっているため、データベース・ワークロードに基づいて、現在のフラッシュバック保存目標を達成するために必要なディスク領域の見積りが結果として表示されます。
DB_FLASHBACK_RETENTION_TARGETで指定された期間に生成された実際のフラッシュバック・ログのサイズに基づいて、フラッシュバック・ログ領域要件を調整します。「フラッシュ・リカバリ領域の概要」で説明されているように、現行の制御ファイルおよびオンラインREDOログの多重コピーのみが永続的なファイルです。この項では、これらのファイルおよびアーカイブ・ログの場所の設定方法について説明します。
オンラインREDOログ・ファイルが作成される場所を決定する初期化パラメータは、DB_CREATE_ONLINE_LOG_DEST_n、DB_RECOVERY_FILE_DESTおよびDB_CREATE_FILE_DESTです。これらのパラメータの組合せによるオンラインREDOログの作成への影響の詳細は、『Oracle Database SQL言語リファレンス』のCREATE DATABASE文のLOGFILE句に関する事項を参照してください。
次のSQL文を使用すると、フラッシュ・リカバリ領域にオンラインREDOログを作成できます。
CREATE DATABASE
ALTER DATABASE ADD LOGFILE
ALTER DATABASE ADD STANDBY LOGFILE
ALTER DATABASE OPEN RESETLOGS
フラッシュ・リカバリ領域に作成されるオンライン・ログのデフォルトのサイズは100MBです。ログ・メンバーのファイル名は、データベースによって自動的に生成されます。
初期化パラメータCONTROL_FILES、DB_CREATE_ONLINE_LOG_DEST_n、DB_RECOVERY_FILE_DESTおよびDB_CREATE_FILE_DESTが相互に作用して、データベース制御ファイルが作成される場所が決まります。これらのパラメータの相互作用の詳細は、『Oracle Database SQL言語リファレンス』のCREATE CONTROLFILEのセマンティクスに関する事項を参照してください。
データベースによってOracle管理の制御ファイルが作成され、そのデータベースでサーバー・パラメータ・ファイルが使用されている場合は、そのサーバー・パラメータ・ファイルにCONTROL_FILES初期化パラメータが設定されます。このデータベースでクライアント側の初期化パラメータ・ファイルが使用されている場合は、初期化パラメータ・ファイルにCONTROL_FILES初期化パラメータを手動で設定する必要があります。
アーカイブ・ログはデータベースによって自動的に管理されるため、アーカイブの場所としてフラッシュ・リカバリ領域を使用することをお薦めします。フラッシュ・リカバリ領域内のアーカイブ・ログに対して生成されるファイル名はOracle管理ファイル用のファイル名であり、LOG_ARCHIVE_FORMATでは決定されません。どのアーカイブ・スキームを選択した場合も、常にアーカイブREDOログの複数のコピーを作成することをお薦めします。
次に、アーカイブREDOログ用の基本的なオプションを推奨順に示します。
DB_RECOVERY_FILE_DESTを指定し、LOG_ARCHIVE_DEST_nを指定しない場合は、LOG_ARCHIVE_DEST_10が暗黙的にリカバリ領域に設定されます。LOG_ARCHIVE_DEST_10を空の文字列に設定すると、この動作を無効にできます。
LOG_ARCHIVE_DEST_n初期化パラメータをフラッシュ・リカバリ領域外の場所に設定します。フラッシュ・リカバリ領域が構成されている場合は、LOG_ARCHIVE_DEST_nパラメータをLOCATION=USE_DB_RECOVERY_FILE_DESTに設定すると、フラッシュ・リカバリ領域をアーカイブ先として追加できます。
LOG_ARCHIVE_DEST_n初期化パラメータを設定します。
フラッシュ・リカバリ領域を使用する場合、LOG_ARCHIVE_DESTおよびLOG_ARCHIVE_DUPLEX_DEST初期化パラメータは使用できません。使用すると、インスタンスを起動できなくなります。かわりに、LOG_ARCHIVE_DEST_nパラメータを設定します。データベースでLOG_ARCHIVE_DEST_nが使用されている場合は、リカバリ領域を構成できます。
また、アーカイブを有効にしており、LOG_ARCHIVE_DEST、LOG_ARCHIVE_DEST_nまたはDB_RECOVERY_FILE_DESTのいずれの値も設定していない場合、REDOログはプラットフォーム固有のデフォルトの場所にアーカイブされることにも注意してください。たとえば、Solarisでのデフォルトの場所は?/dbsです。
この項では、フラッシュ・リカバリ領域でファイルを作成するためのRecovery Managerコマンドまたは暗黙的な処理（制御ファイルの自動バックアップなど）について説明します。また、コマンドによってフラッシュ・リカバリ領域または別の場所のいずれかにファイルを作成するかどうかを制御する方法について説明します。コマンドを次に示します。
BACKUPディスク・バックアップの目的でFORMAT句を指定していない場合は、Oracle Managed Filesの名前形式の名前が付いたバックアップ・ピースおよびイメージ・コピーがフラッシュ・リカバリ領域に作成されます。フラッシュ・リカバリ領域が有効になっていて、BACKUPまたはチャネルでFORMATを指定している場合、Recovery Managerは、リカバリ領域ではなくプラットフォーム固有の場所にバックアップを作成します。
Recovery Managerは、制御ファイルの自動バックアップをフラッシュ・リカバリ領域に作成できます。Recovery ManagerコマンドCONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK CLEARを使用すると、ディスク上での制御ファイルの自動バックアップ場所を指定したすべての構成済FORMATオプションをクリアできます。他の格納場所が構成されていない場合、Recovery Managerはフラッシュ・リカバリ領域に制御ファイルの自動バックアップを作成します。
RESTORE ARCHIVELOGLOG_ARCHIVE_DEST_nパラメータのいずれかをLOCATION=USE_DB_RECOVERY_FILE_DESTに明示的または暗黙的に設定します。SET ARCHIVELOG DESTINATIONを指定してこの動作を無効にしない場合、Recovery ManagerはアーカイブREDOログ・ファイルをフラッシュ・リカバリ領域にアーカイブします。
RECOVER DATABASEまたはRECOVER TABLESPACE、RECOVER ... BLOCK、およびFLASHBACK DATABASEこれらのコマンドを使用すると、コマンドからの要求に応じて、メディア・リカバリ中に使用されるアーカイブREDOログ・ファイルをバックアップからリストアできます。Recovery Managerは、これらの操作中に必要なすべてのREDOログ・ファイルをフラッシュ・リカバリ領域にリストアし、メディア・リカバリ中に適用した後で削除します。
リストアされたアーカイブ・ログをフラッシュ・リカバリ領域に格納するには、LOG_ARCHIVE_DEST_nパラメータのいずれかをLOCATION = USE_DB_RECOVERY_FILE_DESTに設定します。リストアされたログを他の場所に格納するためのSET ARCHIVELOG DESTINATIONは使用しないでください。
「バックアップの保存方針」で説明されているように、バックアップの保存方針では、データのリカバリ要件に従って保存する必要があるバックアップを指定します。保存方針は、リカバリ期間または冗長性のいずれに基づいていてもかまいません。保存方針を指定するには、CONFIGURE RETENTION POLICYコマンドを使用します。
CONFIGURE RETENTION POLICYコマンドのREDUNDANCYパラメータでは、Recovery Managerが保持する必要がある各データファイルおよび制御ファイルの全体またはレベル0のバックアップの数を指定します。つまり、特定のデータファイルまたは制御ファイルの全体またはレベル0のバックアップの数がREDUNDANCYの設定を超えると、Recovery Managerは余分なバックアップを不要とみなします。デフォルトの保存方針は、REDUNDANCY 1です。
作成するバックアップが増えるに従い、Recovery Managerは保存するバックアップおよび不要なバックアップを記録します。Recovery Managerは、不要でないバックアップのリカバリに必要なすべてのアーカイブ・ログおよび増分バックアップを保持します。
月曜日、火曜日、水曜日および木曜日にデータファイル7の全体バックアップを作成するとします。このデータファイルの全体バックアップは4つになります。REDUNDANCYが2の場合、月曜日と火曜日のバックアップは不要になります。金曜日にもう1つのバックアップを作成すると、データファイル7の水曜日のバックアップが不要となります。
REDUNDANCYが1であるという別の場合を想定します。月曜日の正午にレベル0のデータベース・バックアップを実行し、火曜日と水曜日の正午にレベル1の累積バックアップを、木曜日の正午にレベル0のバックアップを実行します。それぞれの日次バックアップの直後にDELETE OBSOLETEを実行します。水曜日にDELETEコマンドを実行しても、火曜日のレベル1のバックアップは冗長でないため、削除されません。火曜日のレベル1のバックアップは、火曜日の正午から水曜日の正午までの時点に月曜日のレベル0のバックアップをリカバリするために使用できます。ただし、木曜日のDELETEコマンドでは、以前のレベル0およびレベル1のバックアップが削除されます。
次の例のように、Recovery ManagerプロンプトでCONFIGURE RETENTION POLICYコマンドを実行します。
CONFIGURE RETENTION POLICY TO REDUNDANCY 3;
CONFIGUREコマンドのRECOVERY WINDOWパラメータでは、現時点と最初のリカバリ可能ポイント間の日数を指定します。Recovery Managerは、全体バックアップまたはレベル0の増分バックアップがリカバリ期間内にある場合はいずれのバックアップも不要とみなしません。また、Recovery Managerは、リカバリ期間内のランダムな時点までリカバリする必要があるすべてのアーカイブ・ログおよびレベル1増分バックアップを保持します。
Recovery ManagerプロンプトでCONFIGURE RETENTION POLICYコマンドを実行します。次の例では、先週の任意の時点までデータベースをリカバリできます。
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
Recovery Managerは、リカバリ期間によって不要とみなされたバックアップを自動的には削除しません。かわりに、REPORT OBSOLETEの出力やV$OBSOLETE_BACKUP_FILESのOBSOLETE列に、OBSOLETEとして表示します。DELETE OBSOLETEコマンドを実行すると、Recovery Managerは不要なファイルを削除します。
保存方針を無効にすると、Recovery Managerはすべてのバックアップを必要とみなします。保存方針を無効にするには、次のコマンドを実行します。
CONFIGURE RETENTION POLICY TO NONE;
保存方針をNONEに構成することは、保存方針を消去することとは異なります。保存方針を消去すると、デフォルトのREDUNDANCY 1の設定に戻りますが、NONEでは保存方針が完全に無効になります。
保存方針を無効にし、保存方針オプションをコマンドに渡さずにREPORT OBSOLETEまたはDELETE OBSOLETEを実行すると、不要なバックアップを判断する保存方針が存在しないため、Recovery Managerはエラーを発行します。
|
注意: フラッシュ・リカバリ領域を使用している場合は、保存方針が無効になっている状態でデータベースを実行しないでください。ファイルが不要とみなされないと、ファイルをフラッシュ・リカバリ領域から削除できるのは、そのファイルが他のディスクの場所またはテープなどの3次ストレージ・デバイスにバックアップされた場合のみになります。リカバリ領域内のすべての領域が使用され、データベースの通常の操作に影響を及ぼす可能性があります。詳細は、「Oracleによるフラッシュ・リカバリ領域でのディスク領域の管理方法」を参照してください。 |
バックアップの最適化を有効または無効にするには、CONFIGUREコマンドを実行します。バックアップを最適化すると、同じファイルまたは同じバージョンのファイルがすでにバックアップされている場合などの特定の状況においてファイルのバックアップがスキップされます。
バックアップの最適化が有効な場合、指定されたデバイス・タイプにすでにファイルがバックアップされていると、BACKUPコマンドで同一ファイルのバックアップがスキップされます。表5-4に、ファイルがすでにバックアップされているファイルと同一かどうかを判断する際の、Recovery Managerの基準を示します。
| ファイル・タイプ | 同一ファイルかどうかを判断する基準 |
|---|---|
|
データファイル |
すでにバックアップに含まれているデータファイルと同じDBID、チェックポイントSCN、作成SCN、および |
|
アーカイブ・ログ |
同じDBID、スレッド、順序番号、および |
|
バックアップ・セット |
同じDBID、バックアップ・セット・レコードIDおよびスタンプ。 |
ファイルが同一でありすでにバックアップされているとRecovery Managerが判断した場合、そのファイルはスキップ対象になります。ただし、Recovery Managerは、ファイルをスキップするかどうかについて、さらに詳細な確認を行う必要があります。これは、Recovery Managerが指定されたデバイス・タイプに十分なバックアップを保持しているかどうかを判断するアルゴリズムに、保存方針とバックアップ多重化機能の両方の要素があるためです。
Recovery Managerは、次の条件を満たしている場合にバックアップの最適化を使用します。
CONFIGURE BACKUP OPTIMIZATION ONコマンドを実行し、バックアップの最適化を有効にしている。
BACKUP DATABASE、ALLまたはLIKEオプションを指定したBACKUP ARCHIVELOG、BACKUP BACKUPSET ALL、BACKUP RECOVERY AREA、BACKUP RECOVERY FILESあるいはBACKUP DATAFILECOPYを実行する。
UNDOのバックアップの最適化では、Recovery Managerは、すでにコミットされたトランザクションについて、バックアップのリカバリに不要となったUNDOを除外します。バックアップの最適化を有効または無効にすることができますが、UNDOのバックアップの最適化は組込み動作です。
注意:
たとえば、バックアップの最適化を構成したと想定します。これらのコマンドは、データベース、すべてのアーカイブ・ログおよびすべてのバックアップ・セットをテープにバックアップします。
BACKUP DEVICE TYPE sbt DATABASE PLUS ARCHIVELOG; BACKUP DEVICE TYPE sbt BACKUPSET ALL;
バックアップされたすべてのファイルが最後のバックアップ以降に変更されていない場合、Recovery Managerはこれらのファイルを再度バックアップしません。また、Recovery Managerは、ファイルがすでにバックアップされているため、コマンドで指定されたすべてのファイルをスキップする場合、エラーを通知しません。
BACKUPコマンドにFORCEオプションを指定すると、いつでも最適化を無効にできます。たとえば、次のコマンドを実行します。
BACKUP DATABASE FORCE; BACKUP ARCHIVELOG ALL FORCE;
バックアップの最適化は、SBTデバイスへのバックアップ時に常に適用されるわけではありません。リカバリ期間および冗長性に基づく保存方針の通常のバックアップの最適化の動作の例外については、以降の項を参照してください。
バックアップの最適化が有効になっていて、リカバリ期間に基づくバックアップの保存方針が構成されているとします。この場合、SBTバックアップを実行すると、Recovery Managerは、最新のバックアップがリカバリ期間の前に作成されているデータファイルを常にバックアップします。たとえば、次の例を想定します。
2月21日に、表領域toolsをテープにバックアップするコマンドを発行します。この表領域は読取り専用であるため、1月3日のバックアップ以降も変更されていませんが、Recovery Managerはバックアップを実行します。これは、7日間のリカバリ期間内にこの表領域のバックアップが存在しないためです。
この動作によって、メディア・マネージャは古いテープを期限切れにすることができます。この動作が行われない場合、メディア・マネージャは、表領域toolsの1月3日のバックアップを無期限に保持し続けることになります。2月21日に表領域toolsのより新しいバックアップを作成することによって、メディア・マネージャは、1月3日のバックアップを含むテープを期限切れとして処理できます。
冗長性に基づく保存方針を構成するとします。この場合、Recovery Managerは、SBTへのオフラインまたは読取り専用のデータファイルのバックアップがr + 1個存在する場合にのみ、これらのファイルのバックアップをスキップします。ここで、rはCONFIGURE RETENTION POLICY TO REDUNDANCY rで設定された値です。
たとえば、バックアップの最適化を有効にして、次の保存方針を設定するとします。
CONFIGURE DEFAULT DEVICE TYPE TO sbt; CONFIGURE BACKUP OPTIMIZATION ON; CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
この例では、Recovery Managerは、3つの同一のファイルがすでにバックアップされている場合にのみ、バックアップをスキップします。ここで、これまでにバックアップしたことのない読取り/書込み表領域usersに対して、1週間の間に表5-5に示す処理を実行するとします。
火曜日、水曜日および木曜日のバックアップによって、オフライン表領域usersがバックアップされ、3つ（冗長性設定+ 1）のバックアップが存在する必要があるという条件を満たします。金曜日および土曜日のバックアップでは、バックアップの最適化のため、users表領域のバックアップは行われません。usersの火曜日のバックアップは、木曜日以降に不要となります。
日曜日にすべての不要なバックアップを削除すると、usersの火曜日のバックアップも削除されます。火曜日のバックアップは、保存方針設定によって不要となります。月曜日のデータベース全体のバックアップによって、users表領域がバックアップされ、3つ（冗長性設定+ 1）のバックアップが存在する必要があるという条件を満たします。この方法で、時間の経過とともにテープを再利用できます。
デフォルトでは、バックアップの最適化はOFFに構成されています。SHOW BACKUP OPTIMIZATIONコマンドを使用すると、バックアップの最適化の現行の設定を表示できます。
SHOW BACKUP OPTIMIZATIONコマンドを実行して、最適化が現在有効になっているかどうかを確認します。たとえば、次のコマンドを入力します。
SHOW BACKUP OPTIMIZATION;
SHOW BACKUP OPTIMIZATIONの出力例を次に示します。
RMAN configuration parameters for database with db_unique_name PROD1 are: CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE BACKUP OPTIMIZATION ON;
Recovery Managerを使用すると、アーカイブREDOログがディスクからの削除対象となる場合を制御する永続的な構成を作成できます。
CONFIGURE ARCHIVELOG DELETION POLICYコマンドを使用すると、アーカイブREDOログが削除対象になる場合を指定できます。この削除方針は、フラッシュ・リカバリ領域を含むすべてのアーカイブ先に適用されます。
アーカイブREDOログは、データベースによって自動的に削除されるか、またはユーザーが実行したRecovery Managerコマンドによって削除されます。フラッシュ・リカバリ領域内のログのみが、データベースによって自動的に削除されます。フラッシュ・リカバリ領域内のアーカイブREDOログ・ファイルの場合は、データベースによってできるかぎり保存され、追加のディスク領域が必要になると対象となるログが削除されます。フラッシュ・リカバリ領域の内部にあるか外部にあるかに関係なく、BACKUP ... DELETE INPUTまたはDELETE ARCHIVELOGを発行すると、すべての場所から対象のログを手動で削除できます。
デフォルトでは、アーカイブREDOログの削除方針はNONEに構成されています。この場合、Recovery Managerは、次の両方の条件を満たしている場合にリカバリ領域内のアーカイブREDOログ・ファイルを削除対象であるとみなします。
LOG_ARCHIVE_DEST_nで指定された必須のリモート転送先に転送されている。
バックアップ保存方針では、ログは保証付きリストア・ポイントで不要である場合およびOracle Flashback Databaseで不要である場合にのみ不要とみなされます。アーカイブREDOログは、ログがSYSDATE-'DB_FLASHBACK_RETENTION_TARGET'より後に作成された場合にフラッシュバック・データベースで必要とされます。
CONFIGURE ARCHIVELOG DELETION POLICY BACKED UP integer TIMES TO DEVICE TYPEコマンドを使用すると、アーカイブ・ログの削除方針を有効化できます。この構成では、指定した数のアーカイブ・ログのバックアップが指定したデバイス・タイプに存在する場合にのみアーカイブ・ログが削除対象になるように指定されます。
削除方針がBACKED UP integer TIMES句で構成されている場合、指定したデバイス・タイプ上にinteger個のバックアップがすでに存在していないかぎり、BACKUP ARCHIVELOGコマンドはログをコピーします。ログのinteger個のバックアップが存在している場合、BACKUP ARCHIVELOGコマンドはログをスキップします。これによって、アーカイブ・ログの削除方針は、デフォルトのBACKUP ARCHIVELOGコマンドのNOT BACKED UP integer TIMES句として機能します。BACKUPコマンドにFORCEオプションを指定すると、削除方針を無効にできます。
アーカイブ・ログの削除方針には、Data Guard環境固有のオプションもあります。たとえば、APPLIED ON STANDBY句を指定すると、Recovery Managerは、すべての必須のリモート転送先でログが適用された後、ログを削除します。たとえば、SHIPPED TO STANDBYを指定すると、Recovery Managerは、すべての必須のスタンバイ転送先にログが転送された後、ログを削除します。
この項では、アーカイブREDOログの削除方針の構成方法について説明します。デフォルトでは、削除方針はNONEに設定されています。
CONFIGURE ARCHIVELOG DELETION POLICYコマンドを実行します。次の例では、アーカイブREDOログが2回以上テープにバックアップされた場合、アーカイブREDOログがフラッシュ・リカバリ領域およびすべてのローカルのアーカイブ先からの削除の対象となるように指定しています。
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 2 TIMES TO SBT;
|
参照:
|
この項では、Oracle Flashback Databaseの環境を計画および構成する方法について説明します。この項では、リストア・ポイントの作成方法についても説明します。この項の内容は、次のとおりです。
Oracle Flashback Databaseおよびリストア・ポイントは、関連データ保護機能です。これらの機能は、データベースの不要な変更を無効にする場合にPoint-in-Timeリカバリのかわりに使用できるより効率的な機能です。フラッシュバック・データベースを使用すると、データベース全体の時間を巻き戻し、時間枠内でデータベース変更の結果を無効にできます。この機能は、データベースのPoint-in-Timeリカバリに類似しています。
リストア・ポイントには、フラッシュバック・データベースおよびその他のメディア・リカバリ操作に関連する機能が備えられています。特に、任意のSCNで作成された、保証付きリストア・ポイントによって、フラッシュバック・データベースを使用してデータベースをこのSCNに巻き戻すことができます。リストア・ポイントおよびフラッシュバック・データベースは、別々またはともに使用することができます。
Oracle Flashback Databaseには、Recovery ManagerコマンドFLASHBACK DATABASEまたはSQL文FLASHBACK DATABASEを使用してアクセスできます。いずれかのコマンドを使用して、論理データの破損やユーザー・エラーから、データベースを迅速にリカバリできます。
フラッシュバック・データベースは、従来のPoint-in-Timeリカバリと類似しています。フラッシュバック・データベースを使用すると、データベースを直前の状態に戻すことができます。ただし、フラッシュバック・データベースは、Point-in-Timeリカバリよりはるかに高速です。フラッシュバック・データベースでは、バックアップからデータファイルをリストアする必要がなく、アーカイブREDOログから変更をほとんど適用する必要がないためです。
データファイルが影響を受けていないかぎり、フラッシュバック・データベースを使用して、データベースに対する最も不要な変更を無効にすることができます。データベースを前のインカネーションの状態に戻すこともできます。つまり、ALTER DATABASE OPEN RESETLOGS文による影響を元に戻すことができます。FLASHBACK DATABASEコマンドを使用して、データベースの変更を無効にする方法については、「フラッシュバック・データベースを使用したデータベースの巻戻し」を参照してください。
フラッシュバック・データベースでは、独自のロギング・メカニズムによってフラッシュバック・ログが作成され、フラッシュ・リカバリ領域に格納されます。フラッシュバック・データベースは、フラッシュバック・ログが使用可能な場合にのみ使用できます。したがって、フラッシュバック・データベースを使用するには、フラッシュバック・ログが作成されるようにデータベースを事前に設定しておく必要があります。
フラッシュバック・データベースを有効にするには、フラッシュ・リカバリ領域を構成し、フラッシュバック保存目標を設定します。この保存目標によって、フラッシュバック・データベースを使用してデータベースを巻き戻す時点が指定されます。この目標時点以降、データベースでは、データファイル内の変更されたすべてのブロックのイメージがフラッシュバック・ログに定期的にコピーされます。
フラッシュバック・データベースを使用してデータベースを過去の目標時点に巻き戻すと、コマンドによって、目標時点以降に変更されたブロックが判別され、フラッシュバック・ログからリストアされます。データベースでは、目標時点の直前の各ブロックのバージョンがリストアされます。次に、データベースでは、REDOログを使用して、これらのブロックがフラッシュバック・ログに書き込まれた後に行われた変更が再適用されます。
ディスクまたはテープ上のREDOログは、フラッシュバック・ログに記録されている期間中、使用可能である必要があります。たとえば、フラッシュバック保存目標が1週間の場合は、過去1週間のすべての変更が含まれているオンラインREDOログおよびアーカイブREDOログに、アクセスできるようにしておく必要があります。実際、Point-in-Timeリカバリをサポートするには、通常、REDOログはフラッシュバック保存目標より長い期間必要とされることに注意してください。
FLASHBACK DATABASEコマンドをサポートするための十分なフラッシュバック・ログ・データが現在存在するSCNの範囲をフラッシュバック・データベース・ウィンドウと呼びます。フラッシュバック・データベース・ウィンドウは、使用可能なフラッシュバック・ログの最も古いSCNより前に延長することはできません。
フラッシュバック・ログは、フラッシュ・リカバリ領域外の場所にはバックアップできません。フラッシュバック・データベース・ウィンドウを満たすための十分なフラッシュバック・ログが保存される可能性を高くするために、フラッシュ・リカバリ領域を増加することができます（「フラッシュ・リカバリ領域の場所および初期サイズの設定」を参照）。
フラッシュ・リカバリ領域が、保存方針に必要なフラッシュバック・ログおよびアーカイブREDOログや他のバックアップなどのファイルを保持できるサイズでない場合、データベースでは、最も古いSCNからフラッシュバック・ログを削除して他のファイルに領域を確保することができます。この結果、フラッシュバック・データベース・ウィンドウは、フラッシュ・リカバリ領域のサイズ、保存する必要がある他のバックアップおよび必要なフラッシュバック・ロギング・データの量に応じてフラッシュバック保存目標より短くなる可能性があります。フラッシュバック保存目標は目標であり、フラッシュバック・データベースが使用可能になることを保証するものではありません。
フラッシュバック・データベース・ウィンドウの長さが十分でないためFLASHBACK DATABASEを使用できないときは、ほとんどの場合、同様の目的でデータベースのPoint-in-Timeリカバリ（DBPITR）を使用できます。フラッシュバック・データベースを使用して特定の時点に戻すか、またはフラッシュバック・ウィンドウのサイズを確保できるようにする場合は、保証付きリストア・ポイントが唯一の方法となります。
|
参照:
|
通常のリストア・ポイントでは、リストア・ポイント名がSCNまたは特定の時点に割り当てられます。これによって、リストア・ポイントはこのSCNのブックマークまたは別名として機能します。通常のリストア・ポイントは、無効にする必要がある操作を実行する前に作成できます。制御ファイルに、リストア・ポイント名およびSCNが格納されます。
フラッシュバック機能またはPoint-in-Timeリカバリを使用する必要がある場合は、時刻またはSCNのかわりに、リストア・ポイント名を使用します。次のコマンドでは、リストア・ポイントをこの方法で使用できます。
通常のリストア・ポイントでは、事前に手動でSCNを記録したり、問題が発生した後でフラッシュバック問合せなどの機能を使用して適切なSCNを判別する必要がありません。
通常のリストア・ポイントは軽量です。制御ファイルには、データベースのパフォーマンスに大きな影響を与えることなく、数千もの通常のリストア・ポイントの記録を保持できます。通常のリストア・ポイントは、手動で削除しない場合でも、最終的には制御ファイルからエージ・アウトされるため、継続的なメンテナンスは不要です。
通常のリストア・ポイントと同様に、保証付きリストア・ポイントは、リカバリ操作でSCNの別名として機能します。保証付きリストア・ポイントは、制御ファイルからエージ・アウトされず、明示的に削除する必要がある点が主な違いとなります。通常、保証付きリストア・ポイントは、通常のリストア・ポイントで動作するすべてのコマンドで、SCNの別名として使用できます。特に明記されていないかぎり、通常のリストア・ポイントの使用箇所および使用方法に関する情報は、保証付きリストア・ポイントにも適用されます。
保証付きリストア・ポイントによって、フラッシュバック・ログが無効になっている場合でも、フラッシュバック・データベースを使用してデータベースをリストア・ポイントSCNの状態に巻き戻すことができます。フラッシュバック・ロギングが有効になっている場合は、保証付きリストア・ポイントによって、最も古い保証付きリストア・ポイント以降の任意のSCNまで、フラッシュバック・データベースに必要なフラッシュバック・ログが保存されます。したがって、フラッシュバック・ロギングが有効になっている場合は、データベースを1つのSCNにのみ巻き戻すのではなく、連続したいずれかのSCNに巻き戻すことができます。
必要なログを格納できる十分なディスク領域がリカバリ領域にある場合は、保証付きリストア・ポイントを使用して、数日前または数週間前の良好な状態にデータベース全体を巻き戻すことができます。フラッシュバック・データベースの場合と同様に、ダイレクト・ロード・インサートなどのNOLOGGING操作の影響も、保証付きリストア・ポイントを使用して無効にすることができます。
実際、保証付きリストア・ポイントは、ストレージ・スナップショットにかわる有効な機能です。多くの場合、ストレージ・スナップショットは、大規模なデータベースの更新、アプリケーションのパッチの適用やアップグレードなどの危険を伴う操作の前に、データベースを保護するために使用します。操作のテスト用にスナップショットまたは複製データベースを作成するかわりに、プライマリ・データベースまたはフィジカル・スタンバイ・データベースに保証付きリストア・ポイントを作成できます。これによって、必要なフラッシュバック・ログが確実に保存される状態で、危険を伴う操作を実行できます。
フラッシュバック・データベースおよび保証付きリストア・ポイントのロギングでは、変更が適用される前のデータファイル・ブロックのイメージ取得する必要があります。FLASHBACK DATABASEコマンドでは、これらのイメージを使用して、データファイルを前の状態に戻すことができます。
通常のフラッシュバックのロギングと保証付きリストア・ポイントのロギングの主な違いは、ブロックをロギングするタイミング、およびフラッシュ・リカバリ領域で領域圧迫に応じてログを削除できるかどうかに関連しています。これらの違いは、ログに対する領域の使用状況およびデータベースのパフォーマンスに影響します。
リカバリ可能目標によって、フラッシュバック・データベースのロギングを有効にするかどうか、または保証付きリストア・ポイントを使用するかどうか、あるいはその両方を行うかどうかが部分的に決定されます。これらの機能を個別に使用した場合および同時に使用した場合のパフォーマンスおよび領域の使用状況への影響も、決定を行う場合の要因として考慮する必要があります。
次の規則によって、フラッシュ・リカバリ領域でのフラッシュバック・ログの作成、保存、上書きおよび削除が制御されます。
FLASHBACK DATABASEを使用するために、そのREDOログ・ファイルを使用する必要があるフラッシュバック・ログも削除されます。
保証付きリストア・ポイントを作成する場合は、フラッシュバック・データベースの完全なロギングを有効にしているかどうかに関係なく、フラッシュ・リカバリ領域で使用可能な領域を監視する必要があります。フラッシュ・リカバリ領域のディスク領域の使用状況を監視する方法については、「フラッシュ・リカバリ領域でのフラッシュバック・ログの領域の管理」を参照してください。
|
注意: 保存方針の要件および保証付きリストア・ポイントのため、フラッシュ・リカバリ領域からの削除対象となるファイルがない場合、データベースはディスクが一杯になった場合と同様に動作します。多くの場合、これによってデータベースは停止します。詳細は、「フラッシュ・リカバリ領域が一杯になった場合の対応」を参照してください。 |
フラッシュバック・データベースのロギングが無効になっているときに保証付きリストア・ポイントを作成するとします。この場合、保証付きリストア・ポイントの時点以降にデータファイル・ブロックが初めて変更されると、データベースによって、変更前のブロックのイメージがフラッシュバック・ログに格納されます。このため、フラッシュバック・ログには、保証付きリストア・ポイントが作成された時点で変更されているすべてのデータ・ブロックの内容が保持されます。同じブロックに対するこれ以降の変更では、そのブロックが最後に変更されてから別の保証付きリストア・ポイントが作成されないかぎり、その内容が再度ロギングされることはありません。
このロギング方法には、次の重要な効果があります。
FLASHBACK DATABASEを使用すると、ブロック・イメージによって、保証付きリストア・ポイントの時点でのデータファイルの内容を再作成できます。
保証付きリストア・ポイントが作成された時点にデータベースを戻すことが第一の目標であるとします。この場合は、通常、フラッシュバック・ロギングを無効にして、保証付きリストア・ポイントのみを使用する方がより効率的です。たとえば、週末にデータベース・ホストに対してアプリケーション・アップグレードを実行するとします。アップグレードの開始時に、保証付きリストア・ポイントを作成します。アップグレードに失敗した場合は、FLASHBACK DATABASEを使用して変更を無効にします。
フラッシュバック・データベースを有効にし、1つ以上の保証付きリストア・ポイントを定義すると、データベースで通常のフラッシュバック・ロギングが実行されます。この場合、現時点と現在定義されている最も古い保証付きリストア・ポイントの間の任意の時点にフラッシュバックするために必要なフラッシュバック・ログが、リカバリ領域に保存されます。フラッシュバック・ログは、保証を実現するために必要な場合、領域圧迫に応じて削除されることはありません。
フラッシュバック・ロギングでは、パフォーマンスのオーバーヘッドが発生します。また、データベースでのアクティビティのパターンに応じて、フラッシュ・リカバリ領域で著しい領域圧迫が発生する場合もあります。したがって、フラッシュ・リカバリ領域で使用される領域を監視する必要があります。
次に、フラッシュバック・データベースを有効にする前提条件を示します。
ARCHIVELOGモードで実行している必要があります。
保証付きリストア・ポイントを使用できるようにするには、データベースが次の前提条件を満たしている必要があります。
COMPATIBLE初期化パラメータを10.2以上に設定する必要があります。
ARCHIVELOGモードで実行されている必要があります。保証付きリストア・ポイントまでデータベースを巻き戻すには、FLASHBACK DATABASEコマンドで、リストア・ポイントの時点の前後から始まるアーカイブREDOログを使用する必要があります。
保証付きリストア・ポイントでは、フラッシュバック・ロギングに類似したメカニズムが使用されます。フラッシュバック・ロギングの場合と同様に、Oracle Databaseによって、必要なログがフラッシュ・リカバリ領域に格納されている必要があります。
Oracle Flashback Databaseのロギングを有効にするには、DB_FLASHBACK_RETENTION_TARGET初期化パラメータを設定し、ALTER DATABASE FLASHBACK ON文を発行します。
SHUTDOWN IMMEDIATE; STARTUP MOUNT;
DB_FLASHBACK_RETENTION_TARGETに、フラッシュバックの期間の長さを分単位で設定します。
ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET=4320; # 3 days
デフォルトでは、DB_FLASHBACK_RETENTION_TARGETは1日（1440分）に設定されます。
ALTER DATABASE FLASHBACK ON;
デフォルトでは、すべての永続表領域に対してフラッシュバック・ログが生成されます。必要に応じて、特定の表領域のフラッシュバック・ロギングを無効にして、オーバーヘッドを軽減できます。次に例を示します。
ALTER TABLESPACE tbs_3 FLASHBACK OFF;
表領域のフラッシュバック・ロギングは、次のコマンドを使用して、後で再度有効にできます。
ALTER TABLESPACE tbs_3 FLASHBACK ON;
表領域に対してOracle Flashback Databaseを無効にする場合は、FLASHBACK DATABASEを実行する前に、データファイルをオフラインにする必要があります。
次のコマンドを使用すると、データベース全体のフラッシュバック・ロギングを無効にできます。
ALTER DATABASE FLASHBACK OFF;
フィジカル・スタンバイ・データベースでフラッシュバック・データベースを有効にすると、スタンバイ・データベースをフラッシュバックできます。スタンバイ・データベースのフラッシュバック・データベースには、Data Guard環境で使用可能な多くのアプリケーションがあります。詳細は、『Oracle Data Guard概要および管理』を参照してください。
通常のリストア・ポイントまたは保証付きリストア・ポイントを作成するには、リストア・ポイントの名前を指定し、保証付きリストア・ポイントであるか通常のリストア・ポイント（デフォルト）であるかを指定して、SQL文CREATE RESTORE POINTを使用します。
CREATE RESTORE POINT文を実行します。次に、SQL*Plusで通常のリストア・ポイントを作成する方法の例を示します。
SQL> CREATE RESTORE POINT before_upgrade;
次に、保証付きリストア・ポイントの作成方法の例を示します。
SQL> CREATE RESTORE POINT before_upgrade GUARANTEE FLASHBACK DATABASE;
|
参照:
|
フラッシュバック・ログをメンテナンスすると、Oracle Databaseインスタンスで発生するオーバーヘッドが比較的制限されます。変更されたブロックがメモリーからフラッシュバック・ログに比較的低い頻度で定期的に書き込まれ、プロセスおよびI/Oオーバーヘッドが制限されます。
フラッシュバック・データベースが有効になっている大規模な本番データベースのパフォーマンスを向上させるには、次のガイドラインに従うことをお薦めします。
通常、データベースによってフラッシュ・リカバリ領域に作成されるファイル（フラッシュバック・ログなど）は、サイズが大きくなります。オペレーティング・システムのファイル・キャッシュは、通常、これらのファイルに対しては有効ではなく、実際には、このファイル・キャッシュによって、これらのファイルに対する読取り/書込みを行った場合のCPUオーバーヘッドが増加する場合があります。したがって、オペレーティング・システムのファイル・キャッシュが行われないASMなどのファイル・システムを使用することをお薦めします。
大規模な本番データベースでは、データベースでフラッシュバック・ログを効果的に書き込むために必要となるディスク・スループットをサポートするために、複数のディスク・スピンドルが必要な場合があります。
比較的小さなストライプ・サイズ（128KBなど）を使用します。この方法では、フラッシュバック・ログへのそれぞれの書込みを複数のスピンドルに分散することによって、パフォーマンスを向上できます。
LOG_BUFFERを8MB以上に設定します。この設定では、データベースによって、フラッシュバック・データベース・ログの書込みに最大メモリー（通常は16MB）が割り当てられます。
フラッシュバック・データベースのロギングで発生するオーバーヘッドは、データベース・ワークロードでの読取りと書込みの組合せによって異なります。ワークロードが書込み集中型の場合、フラッシュバック・データベースのロギングを有効にするとオーバーヘッドが増加します。問合せによってデータは変更されないため、フラッシュバック・データベースのロギング・アクティビティには影響しません。
Data Guard環境でRecovery Managerを使用する場合、CONFIGUREコマンドを使用すると、この環境での物理データベースの設定の登録および構成を行うことができます。Recovery Managerは、DB_UNIQUE_NAME初期化パラメータを使用して、データベースを別のデータベースと区別します。したがって、Data Guard環境でDB_UNIQUE_NAMEの一意性を維持することが重要です。
Data Guard環境内のデータベースに構成を作成または変更する場合、Recovery Managerはリカバリ・カタログに接続している必要があります。SET DBIDコマンドを使用して、Recovery ManagerセッションでDBIDを設定する場合は、Data Guard環境でRecovery ManagerがTARGETとしてデータベースに接続されていなくても、スタンバイ・データベースを構成できます。この場合は、作成されていないスタンバイ・データベースに構成を作成することもできます。
次の形式のCONFIGUREコマンドを使用できます。
CONFIGURE DB_UNIQUE_NAMEを使用すると、フィジカル・スタンバイ・データベースへの接続が定義され、新しいデータベースが暗黙的に登録されます。Recovery ManagerがTARGETとして初めてスタンバイ・データベースに接続する場合は、新しいスタンバイ・データベースも自動的に登録されます。
CONFIGURE FOR DB_UNIQUE_NAMEを使用すると、Data Guard環境でのデータベースの設定が構成されます。たとえば、環境内の指定したデータベースまたはすべてのデータベースに対して、チャネルやデフォルトのデバイスなどを構成できます。SHOW ALL FOR DB_UNIQUE_NAMEを使用すると、特定のスタンバイ・データベースの構成を表示でき、SHOW ALL FOR DB_UNIQUE_NAME ALLを使用すると、認識されるすべてのデータベースの構成を表示できます。
Data Guard環境には、Data Guardにのみ関連する多くの考慮事項があります。たとえば、アーカイブ・ログがスタンバイ・データベースに転送されたか、適用されたかに基づいて、アーカイブREDOログの削除方針を構成できます。
|
 Copyright © 2003, 2008, Oracle Corporation. All Rights Reserved. |
|