ヘッダーをスキップ

Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド
11g リリース1(11.1)

E05700-03
目次
目次
索引
索引

戻る 次へ

6 Recovery Manager環境の構成: 高度なトピック

この章では、設定および構成作業を実行する方法について説明します。この章の内容は、次のとおりです。

高度なチャネル・オプションの構成

「チャネルの構成」ではチャネルの構成の基本が説明されていますが、この項では、より高度なチャネルのトピックについて説明します。この項の内容は、次のとおりです。

チャネル制御オプション

チャネルを手動で割り当てる場合も自動チャネル割当てを使用する場合も、チャネル・コマンドおよびオプションを使用して、チャネルの動作を制御できます。表6-1に、チャネルの動作を制御する方法の概要を示します。特に明記されていないかぎり、CONFIGURE CHANNELALLOCATE CHANNELコマンドの両方ですべてのチャネル・パラメータがサポートされています。

表6-1    チャネル制御オプション 
チャネル制御のタイプ  コマンド 

I/O帯域幅消費に対する制限 

バックアップの制限メカニズムとして機能するRATEチャネル・パラメータを使用できます。 

バックアップ・セットおよびバックアップ・ピースに対する制限 

MAXPIECESIZEチャネル・パラメータを使用して、バックアップ・ピースのサイズに制限を設定できます。また、BACKUPおよびCONFIGUREコマンドでMAXSETSIZEパラメータを使用して、バックアップ・セットのサイズの制限を設定することもできます。 

ベンダー固有の手順 

PARMSチャネル・パラメータを使用して、メディア・マネージャに関するベンダー固有の情報を指定できます。SENDコマンドを使用して、ベンダー固有のコマンドをメディア・マネージャに送信することもできます。 

バックアップおよびリストア操作でのチャネルのパラレル化 

チャネルは、CONFIGURE DEVICE TYPE ... PARALLELISMを使用して永続的にパラレル化するか、または複数のALLOCATE CHANNELコマンドを使用してジョブ・レベルでパラレル化することができます。 

データベース・インスタンスの接続設定 

CONNECTチャネル・パラメータを使用して、操作を実行するインスタンスを指定できます。 

参照:

ALLOCATE CHANNEL構文については『Oracle Databaseバックアップおよびリカバリ・リファレンス』、CONFIGURE構文については『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。 

固有のチャネル・パラメータの構成

特定のタイプのすべてのチャネルに適用されるパラメータの構成に加えて、特定のチャネルに適用されるパラメータを構成することもできます。特定のチャネルを構成するには、CONFIGURE CHANNEL nnは255未満の正の整数)コマンドを実行します。

チャネルに番号を手動で割り当てる場合、各チャネルに1つ以上のチャネル・オプション(MAXPIECESIZEFORMATなど)を指定する必要があります。固有の番号を割り当てたチャネルをバックアップで使用すると、構成済の汎用チャネル設定ではなく、そのチャネルの構成設定が使用されます。

各チャネルに設定されたパラメータを個別に制御する必要がある場合は、固有のチャネルを番号ごとに構成します。この方法は、次のような場合に実行する必要があります。

固有のチャネルの構成の例

次の例では、ディスク・バックアップを2つのディスクに送信します。ディスク・チャネルを次のように構成します。

CONFIGURE DEFAULT DEVICE TYPE TO disk;        # backup goes to disk
CONFIGURE DEVICE TYPE disk PARALLELISM 2;     # two channels used in in parallel
CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT '/disk1/%U' # 1st channel to disk1 
CONFIGURE CHANNEL 2 DEVICE TYPE DISK FORMAT '/disk2/%U' # 2nd channel to disk2
BACKUP DATABASE; # backup - first channel goes to disk1 and second to disk2

2つのテープ・ドライブがあり、各テープ・ドライブで異なるテープ・メディア・ファミリのテープを使用するという別の場合を想定します。デフォルトの出力デバイスおよびデフォルトのテープ・チャネルを次の例のように構成して、データベース・バックアップをパラレル化します。

例6-1    テープ・デバイスのチャネルのパラレル化の構成

CONFIGURE DEFAULT DEVICE TYPE TO sbt;    # backup goes to sbt
CONFIGURE DEVICE TYPE sbt PARALLELISM 2; # two sbt channels allocated by default
# Configure channel 1 to pool named first_pool
CONFIGURE CHANNEL 1 DEVICE TYPE sbt 
  PARMS 'ENV=(OB_MEDIA_FAMILY=first_pool)'; 
# configure channel 2 to pool named second_pool
CONFIGURE CHANNEL 2 DEVICE TYPE sbt 
  PARMS 'ENV=(OB_MEDIA_FAMILY=second_pool)'; 
BACKUP DATABASE; # first stream goes to 'first_pool' and second to 'second_pool'

例6-1では、バックアップ・データは2つのテープ・デバイス間で分割されます。構成済の各チャネルは、データの合計の約半分ずつをバックアップします。

CONFIGURE CHANNELとパラレル化設定の関係

PARALLELISM設定は、固有に構成したチャネルの数に制約を受けません。たとえば、20の異なるテープ・デバイスにバックアップを実行する場合、20の異なるSBTチャネルを構成できます。各チャネルには、手動で番号(1から20まで)を割り当て、個別の一連のチャネル・オプションを設定します。このような場合、PARALLELISMにデバイス数(この例では20)以下の任意の値を設定できます。

パラレル・チャネルには、常に、Recovery Managerによって1から順にPARALLELISM設定の値までの番号が付けられます。たとえば、デフォルト・デバイスがSBTで、パラレル化が3に設定されている場合、チャネルの名前は次のようになります。

ORA_SBT_TAPE_1
ORA_SBT_TAPE_2
ORA_SBT_TAPE_3

DEVICE TYPE sbt(シノニムsbt_tapeではない)を構成した場合でも、Recovery Managerでは常にORA_SBT_TAPE_nという名前が使用されます。また、チャネルを個別に構成した場合はそのチャネルを使用し、構成していない場合は汎用チャネルを使用して、常に、PARALLELISMに指定したチャネルの番号が割り当てられます。パラレル化設定より大きい数で特定のチャネルを構成した場合、Recovery Managerではこれらのチャネルが使用されないことに注意してください。

参照:

チャネルの詳細は、「Recovery Managerチャネル」を参照してください。 

高度なバックアップ・オプションの構成

バックアップを作成するようにRecovery Managerを構成する方法の基本については、「Recovery Managerバックアップの環境の構成」を参照してください。この項では、より高度な構成オプションについて説明します。この項の内容は、次のとおりです。

バックアップ・セットの最大サイズの構成

テープ・バックアップでは、複数のテープにまたがって多重バックアップ・セットを使用できます。つまり、バックアップ・セットの各データファイルにあるブロックは、複数のテープに書き込まれます。マルチボリュームのバックアップ・セットのいずれかのテープで障害が発生すると、1つのテープのみでなく、すべてのテープ上のデータが失われます。バックアップがマルチセクション・バックアップでない場合、バックアップ・セットには、データファイルの一部ではなくデータファイル全体が常に含まれます。MAXSETSIZEを使用すると、各バックアップ・セットが複数のテープにまたがるのではなく、1つのテープに収まるように指定できます。

CONFIGURE MAXSETSIZEコマンドを使用すると、チャネルに作成されるバックアップ・セットの最大サイズを制限できます。このCONFIGURE設定は、チャネルが手動で割り当てられたか構成されたかにかかわらず、BACKUPコマンドを使用してバックアップ・セットを作成する際にすべてのチャネルに適用されます。デフォルト値はバイトで指定され、KBの単位に切り捨てられます。

CONFIGURE MAXSETSIZEコマンドで設定した値は、指定したチャネルのデフォルトになります。構成済のMAXSETSIZE値は、個別のBACKUPコマンドにMAXSETSIZEオプションを指定して上書きできます。

Recovery Managerプロンプトで次のコマンドを発行するとします。

CONFIGURE DEFAULT DEVICE TYPE TO sbt;
CONFIGURE CHANNEL DEVICE TYPE sbt PARMS 'ENV=(OB_MEDIA_FAMILY=first_pool)'; 
CONFIGURE MAXSETSIZE TO 7500K;
BACKUP TABLESPACE users;
BACKUP TABLESPACE tools MAXSETSIZE 5G;

結果は次のようになります。

バックアップ・ピースの最大サイズの構成

バックアップ・ピースのサイズがファイル・システムまたはメディア管理ソフトウェアで許容される最大ファイル・サイズを超えると、問題が発生します。CONFIGURE CHANNELまたはALLOCATE CHANNELコマンドのMAXPIECESIZEパラメータを使用すると、バックアップ・ピースのサイズを制限できます。

たとえば、バックアップ・ピースのサイズを常に2GB以下に制限するには、自動DISKチャネルを次のように構成して、BACKUP DATABASEを実行します。

CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 2G;
BACKUP DATABASE;


注意:

バージョン2.0のMedia Management APIでは、メディア・マネージャに書込み可能なバックアップ・ピースの最大サイズを指定できるのはメディア管理ベンダーです。Recovery Managerは、MAXPIECESIZEの設定に関係なく、この制限を優先します。 


参照:

CONFIGURE CHANNEL ... MAXPIECESIZEコマンドについては、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。 

バックアップの多重化の構成

CONFIGURE ... BACKUP COPIESコマンドを使用すると、指定したファイル・タイプの指定したデバイス・タイプ上に作成する各バックアップ・ピースのコピー数を指定できます。このタイプのバックアップは、多重バックアップ・セットと呼ばれます。多重化を行うためのCONFIGURE設定は、バックアップ・セットへのデータファイル、制御ファイルおよびアーカイブ・ログのバックアップにのみ影響し、イメージ・コピーには影響しません。


注意:

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


Recovery Managerでは、ディスクまたはテープにバックアップを多重化できますが、テープとディスクにバックアップを同時に多重化することはできません。テープへのバックアップ時に、コピーの数が、使用可能なテープ・デバイスの数を超えないようにしてください。多重化の構成の例を次に示します。

# Makes 2 disk copies of each datafile and control file backup set
# (autobackups excluded)
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 2;
# Makes 3 copies of every archived redo log backup to tape
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE sbt TO 3;

BACKUP COPIES構成をデフォルト値に戻すには、同じCONFIGUREコマンドにCLEARオプションを指定して実行します。次に例を示します。

CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE sbt CLEAR;

デフォルトでは、各デバイス・タイプのCONFIGURE ... BACKUP COPIES1に設定されています。


注意:

永続的なコピー構成を作成しない場合は、BACKUP COPIESおよびSET BACKUP COPIESコマンドでコピーを指定してください。 


参照:

  • バックアップの多重化の概要は、「Recovery Managerを使用したバックアップの複数のコピー」を参照してください。

  • 多重バックアップの作成方法については、「バックアップ・セットの多重化」を参照してください。

  • BACKUP構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

  • CONFIGURE構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

  • SET構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

 

データベース全体のバックアップから除外する表領域の構成

次の場合のように、指定した表領域を通常のバックアップ・スケジュールから除外することもできます。

CONFIGURE EXCLUDE FOR TABLESPACEを実行すると、指定した表領域をBACKUP DATABASEコマンドから除外できます。この除外条件は、これ以降にこの表領域に追加されるすべてのデータファイルに適用されます。

たとえば、テスト表領域cwmliteおよびexampleをデータベース全体のバックアップから除外するには、次のコマンドを実行します。

CONFIGURE EXCLUDE FOR TABLESPACE cwmlite;
CONFIGURE EXCLUDE FOR TABLESPACE example;

次のコマンドを実行すると、cwmliteおよびexample以外のデータベース内のすべての表領域がバックアップされます。

BACKUP DATABASE;

除外されるように構成した表領域は、BACKUPコマンドでそれらの表領域を明示的に指定するか、またはBACKUP DATABASEコマンドでNOEXCLUDEオプションを指定して、バックアップすることができます。たとえば、次のコマンドのいずれかを入力します。

# backs up the whole database, including cwmlite and example
BACKUP DATABASE NOEXCLUDE;
BACKUP TABLESPACE cwmlite, example;  # backs up only cwmlite and example

cwmliteおよびexampleに対する除外機能を無効にするには、次のコマンドを実行します。

CONFIGURE EXCLUDE FOR TABLESPACE cwmlite CLEAR;
CONFIGURE EXCLUDE FOR TABLESPACE example CLEAR;

これらの表領域は、これ以降に実行されるデータベース全体のバックアップでバックアップされます。

参照:

  • BACKUP構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

  • CONFIGURE構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

 

バックアップ圧縮アルゴリズムの構成

Recovery Managerでは、バックアップ・セットのバイナリ圧縮がサポートされています。サポートされているアルゴリズムは、BZIP2(デフォルト)およびZLIBです。BZIP2アルゴリズムは最大の圧縮用に最適化され、ZLIBアルゴリズムはCPUの効率用に最適化されます。BZIP2は、ZLIBより多くのCPUリソースを消費しますが、通常はより圧縮されたバックアップを作成します。ZLIB圧縮の場合、Oracle Advanced Compressionオプションが必要なため、COMPATIBLE初期化パラメータを11.0.0以上に設定する必要があります。

次の構文で圧縮アルゴリズムを構成できます。ここで、alg_nameは、BZIP2またはZLIBを指定するプレースホルダです。

例6-2    バックアップ圧縮アルゴリズムの構成

CONFIGURE COMPRESSION ALGORITHM TO 'alg_name';

バックアップの暗号化の構成

セキュリティを向上させるために、Recovery Managerバックアップ・セットに対してバックアップの暗号化を構成できます。暗号化バックアップは、不正なユーザーが取得しても読み取ることができません。この機能を使用するには、Enterprise Editionのデータベースが必要です。

バックアップの暗号化

V$RMAN_ENCRYPTION_ALGORITHMSビューには、Recovery Managerでサポートされている暗号化アルゴリズムのリストが含まれています。暗号化アルゴリズムが指定されていない場合、デフォルトの暗号化アルゴリズムは128ビットAdvanced Encryption Standard(AES)です。Recovery Managerの暗号化では、ターゲット・データベースでCOMPATIBLE初期化パラメータが10.2.0以上に設定されている必要があります。

Recovery Managerには、次の暗号化モードがあります。

暗号化バックアップは、必要な復号化キーが使用可能な場合にかぎり、リストアおよびリカバリ中に自動的に復号化されます。バックアップ・セットごとに別々のキーが取得されます。キーは、暗号化形式でバックアップ・ピースに格納されます。バックアップは、ユーザーが指定するパスワードまたはOracleウォレットによって取得されたキーを使用して復号化されます。

Recovery Managerを使用してディスクに暗号化バックアップを作成するには、データベースでAdvanced Security Optionを使用している必要があります。Oracle Secure Backup SBTは、暗号化Recovery Managerバックアップをテープに直接作成するためにサポートされている唯一のインタフェースです。Oracle Secure Backup以外のSBTライブラリを使用して暗号化Recovery Managerバックアップを作成しようとすると、Recovery ManagerはORA-19916エラーを発行します。Advanced Security Optionは、Oracle Secure Backup SBTを使用して暗号化バックアップを作成する場合は必要ありません。

暗号化バックアップ・セットでBACKUP BACKUPSETコマンドを使用すると、バックアップ・セットは暗号化形式でバックアップされます。BACKUP BACKUPSETではすでに暗号化されたバックアップ・セットがディスクまたはテープにコピーされるのみのため、BACKUP BACKUPSET中に復号化キーは必要とされません。操作中にデータが復号化されることはありません。BACKUP BACKUPSETコマンドを実行しても、バックアップ・セットを暗号化または復号化することはできません。

参照:

Oracleウォレットの構成の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。 

バックアップの透過的暗号化

透過的暗号化では、必要なOracleキー管理インフラストラクチャが使用可能な場合にかぎり、DBAの介入なしで暗号化バックアップを作成およびリストアできます。透過的暗号化は、日次バックアップ操作(バックアップを作成元と同じデータベースにリストア)に最適です。透過的暗号化は、Recovery Managerの暗号化のデフォルトです。

透過的暗号化を使用する場合は、まず、『Oracle Database Advanced Security管理者ガイド』の説明に従って、各データベースにOracleウォレットを構成する必要があります。バックアップの透過的暗号化では、暗号化形式および自動ログイン形式のOracleウォレットがサポートされています。Oracleウォレットを使用する場合は、バックアップの暗号化を実行する前にウォレットがオープンされている必要があります。自動ログイン・ウォレットを使用する場合は、暗号化バックアップの操作をいつでも行うことができます。自動ログイン・ウォレットは常にオープンしているためです。


注意:

自動ログイン・ウォレットを使用する場合は、暗号化バックアップ・データとともにバックアップしないようにしてください。バックアップと自動ログイン・ウォレットの両方を取得すると、暗号化バックアップの読取りが可能になるためです。Oracleウォレットはウォレット・パスワードがないと使用できないため、この形式のウォレットはバックアップを作成しても安全です。 


Oracleウォレットを構成した後は、DBAの介入なしで暗号化バックアップを作成およびリストアできます。透過的データ暗号化を使用して暗号化されているデータベース内のいくつかの列をバックアップの暗号化を使用してバックアップすると、バックアップ中にそれらの列に対して2度目の暗号化が行われます。バックアップ・セットがリストア中に復号化されると、暗号化された列は、元の暗号化された形式に戻ります。

Oracleキー管理インフラストラクチャによって以前のすべてのマスター・キーがOracleウォレットにアーカイブされるため、現行のデータベース・マスター・キーを変更または再設定しても、以前のマスター・キーを使用して実行された暗号化バックアップは引き続きリストアできます。データベース・マスター・キーはいつでも再設定できます。Recovery Managerは、このデータベースによって作成されたすべての暗号化バックアップを常にリストアできます。


注意:

Oracleウォレットを失うと、透過的に暗号化されたバックアップをリストアすることができなくなります。 


バックアップのパスワード暗号化

パスワード暗号化では、暗号化バックアップを作成およびリストアする場合に、DBAがパスワードを入力する必要があります。パスワード暗号化バックアップをリストアするには、バックアップを作成する場合に使用したパスワードと同じパスワードが必要となります。

パスワード暗号化は、リモートの場所でリストアし、送信中は保護されている必要があるバックアップに有効です。パスワード暗号化は、永続的には構成できません。パスワード暗号化を排他的に使用する場合は、Oracleウォレットを構成する必要はありません。


注意:

パスワード暗号化バックアップを暗号化するときに使用したパスワードを忘れた(または失った)場合は、バックアップをリストアできなくなります。 


パスワード暗号化を使用するには、Recovery ManagerスクリプトでSET ENCRYPTION ON IDENTIFIED BY password ONLYコマンドを使用します。

バックアップのデュアル・モード暗号化

デュアル・モード暗号化バックアップでは、透過的なリストアまたはパスワードを指定したリストアのいずれかを実行できます。デュアル・モード暗号化バックアップは、通常はOracleウォレットを使用してオンサイトでリストアされるが、Oracleウォレットを使用できないオフサイトでリストアする必要がある場合もあるバックアップを作成する場合に有効です。

デュアル・モード暗号化バックアップをリストアする場合は、Oracleウォレットまたは復号化用のパスワードのいずれかを使用できます。


注意:

デュアル・モード暗号化バックアップを暗号化するときに使用したパスワードを忘れ(または失い)、Oracleウォレットも失った場合は、バックアップをリストアできなくなります。 


デュアル・モード暗号化バックアップ・セットを作成するには、Recovery ManagerスクリプトでSET ENCRYPTION ON IDENTIFIED BY passwordコマンドを指定する必要があります。

Recovery Managerバックアップの暗号化モードの構成

CONFIGUREコマンドを使用すると、バックアップの透過的暗号化を永続的に構成できます。このコマンドを使用して、次の内容を指定できます。

SET ENCRYPTIONコマンドを使用して、次の処理を実行することもできます。

アーカイブREDOログのバックアップを暗号化するかどうかを制御する永続的な構成はありません。アーカイブREDOログ・ファイルを含むバックアップ・セットは、次のいずれかの条件が満たされている場合に暗号化されます。

この動作によって、データファイルの暗号化バックアップに関連付けられているREDOも暗号化されます。

すべてのRecovery Managerバックアップが暗号化されるように環境を構成する手順
  1. 『Oracle Database Advanced Security管理者ガイド』の説明に従って、暗号化ウォレットを設定します。

  2. 次のRecovery Managerコマンドを発行します。

    CONFIGURE ENCRYPTION FOR DATABASE ON;
    
    

    この段階では、デフォルトで、このデータベースによって作成されるすべてのRecovery Managerバックアップ・セットで透過的暗号化が使用されます。

次のコマンドを使用すると、Recovery Managerセッションの永続的な暗号化構成を明示的に上書きできます。

SET ENCRYPTION ON;

暗号化設定は、Recovery Managerセッション中にSET ENCRYPTION OFFコマンドを発行するか、または次のコマンドを使用して永続的な設定を再度変更するまで有効です。

CONFIGURE ENCRYPTION FOR DATABASE OFF;

バックアップ暗号化アルゴリズムの構成

CONFIGUREコマンドを使用すると、バックアップ・セットの書込み時に、暗号化に使用するデフォルト・アルゴリズムを永続的に構成できます。指定可能な値は、V$RMAN_ENCRYPTION_ALGORITHMSに表示されます。デフォルト・アルゴリズムは、128ビットAESです。

デフォルトのバックアップ暗号化アルゴリズムを構成する手順
  1. Recovery Managerを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

  2. ターゲット・データベースがマウントまたはオープンされていることを確認します。

  3. V$RMAN_ENCRYPTION_ALGORITHMS.ALGORITHM_NAMEから有効な値を指定して、CONFIGURE ENCRYPTION ALGORITHMコマンドを実行します。

    次の例では、アルゴリズムを256ビットAES暗号化に構成します。

    CONFIGURE ENCRYPTION ALGORITHM TO 'AES256';
    

補助インスタンスのデータファイル名の構成

表領域のPoint-in-Timeリカバリを実行するか、またはRecovery Managerを使用してデータ転送を実行するとします。この場合、TSPITRまたはデータベースの複製を開始する前に、補助インスタンスのデータファイルの名前を設定する必要がある場合があります。補助インスタンスのデータファイル名を設定するには、次のコマンドを実行します。ここで、datafileSpecにはデータファイルの元の名前または番号を指定し、filenameには指定したファイルの新しいパスを指定します。

CONFIGURE AUXNAME FOR datafileSpec TO 'filename';

たとえば、datafile 2の新しい補助ファイル名を次のように構成するとします。

CONFIGURE AUXNAME FOR DATAFILE 2 TO '/newdisk/datafiles/df2.df';

このCONFIGUREコマンド設定は、他の設定と同様に、次の例に示すようにCONFIGURE ... CLEARを使用してクリアしないかぎり、Recovery Managerセッション間で永続的に適用されます。

CONFIGURE AUXNAME FOR DATAFILE 2 CLEAR;

TSPITRまたはDUPLICATEコマンドを実行する場合、CONFIGURE AUXNAMEを使用すると、補助データベースで使用するファイル名を事前に構成でき、これらの操作の実行中に補助ファイル名を手動で指定する必要がなくなります。

DUPLICATEコマンドでファイルの名前を変更する場合は、SET NEWNAMEコマンドのかわりにCONFIGURE AUXNAMEを使用できます。AUXNAMEは一度設定すると、その後DUPLICATEコマンドを発行するときにファイル名を再設定する必要がない点でSET NEWNAMEと異なります。AUXNAME設定は、CONFIGURE AUXNAME ... CLEARを発行しないかぎり適用されたままになります。一方、SET NEWNAMEコマンドは、ファイル名を変更するたびに発行する必要があります。

TSPITRとCONFIGURE AUXNAMEを併用する方法の詳細は第20章「Recovery Managerの表領域のPoint-in-Timeリカバリ(TSPITR)の実行」、データベース複製の実行時にCONFIGURE AUXNAMEの使用する方法の詳細は第23章「データベースの複製」を参照してください。

スナップショット制御ファイルの場所の構成

Recovery Managerでは、リカバリ・カタログを読取り一貫性バージョンの制御ファイルと再同期化する必要がある場合、一時スナップショット制御ファイルが作成されます。リカバリ・カタログとの再同期化または現行の制御ファイルのバックアップを実行する場合、スナップショット制御ファイルが必要になります。

スナップショット制御ファイルのデフォルトの場所はプラットフォーム固有であり、各ターゲット・データベースのOracleホームによって異なります。たとえば、一部のLinuxプラットフォームでのデフォルトのファイル名は、$ORACLE_HOME/dbs/snapcf_@.fとなります。ターゲット・データベースに対してフラッシュ・リカバリ領域が構成されている場合、スナップショット制御ファイルのデフォルトの場所はそのフラッシュ・リカバリ領域内ではありません。

スナップショット制御ファイルの構成場所の表示

SHOWコマンドを実行すると、スナップショットの現行の場所を表示できます。次の例では、デフォルトのルールによって決定されたスナップショットの場所を表示します。

RMAN> SHOW SNAPSHOT CONTROLFILE NAME;
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/oracle/dbs/snapcf_trgt.f'; # default

次の例では、デフォルト以外のファイル名を持つスナップショット制御ファイルを示します。

RMAN> SHOW SNAPSHOT CONTROLFILE NAME;
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/oracle/oradata/trgt/snap_trgt.ctl';

スナップショット制御ファイルの場所の設定

CONFIGURE SNAPSHOT CONTROLFILE NAME TO 'filename'コマンドを使用すると、スナップショット制御ファイルの名前を変更できます。これ以降にRecovery Managerによって作成されるスナップショット制御ファイルには、指定したファイル名が使用されます。

たとえば、Recovery Managerを起動して次のコマンドを入力するとします。

CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/oracle/oradata/trgt/snap_trgt.ctl';

また、スナップショット制御ファイル名をRAWデバイスに設定することもできます。

スナップショット制御ファイルの場所をデフォルトにリセットするには、CONFIGURE SNAPSHOT CONTROLFILE LOCATION CLEARコマンドを実行します。

参照:

  • 「リカバリ・カタログの再同期化」

  • Oracle RAC構成でのスナップショット制御ファイルの処理については、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

 

共有サーバーで使用するためのRecovery Managerの構成

Recovery Managerは、共有サーバー・ディスパッチャを介しては、ターゲット・データベースに接続できません。Recovery Managerには専用サーバー・プロセスが必要です。ターゲット・データベースが共有サーバー用に構成されている場合、Oracle Net構成を変更し、Recovery Manager接続専用のサーバー・プロセスを指定する必要があります。

ターゲット・データベースが共有サーバー用に構成されている場合にRecovery Managerをディスパッチャに接続しないようにするには、Recovery Managerで使用するネット・サービス名の接続文字列のCONNECT_DATA属性に(SERVER=DEDICATED)を含める必要があります。

Oracle Net構成は、システムによって大幅に異なります。次に、多くの構成方法の一例を示します。この例では、共有サーバー・アーキテクチャを使用して、tnsnames.ora内の次のサービス名がターゲット・データベースに接続すると想定しています。ここで、inst1SERVICE_NAMES初期化パラメータの値です。

inst1_shs =
  (DESCRIPTION=
    (ADDRESS=(PROTOCOL=tcp)(HOST=inst1_host)(port=1521))
    (CONNECT_DATA=(SERVICE_NAME=inst1)(SERVER=shared))
  ) 
Recovery Managerを共有サーバーで使用する手順
  1. tnsnames.oraファイルに、共有されないSIDに接続するネット・サービス名を作成します。たとえば、次のように入力します。

    inst1_ded =
      (DESCRIPTION=
        (ADDRESS=(PROTOCOL=tcp)(HOST=inst1_host)(port=1521))
        (CONNECT_DATA=(SERVICE_NAME=inst1)(SERVER=dedicated))
      )
    
    
  2. SQL*Plusを起動し、共有サーバー・サービス名と専用サーバー・サービス名の両方を使用して接続することで、各セッションのモードを確定します。

    たとえば、SYSDBA権限でinst1_dedに接続してから、次のSELECT文を実行します(出力例も示します)。

    SQL> SELECT SERVER 
      2  FROM   V$SESSION 
      3  WHERE  SID = (SELECT DISTINCT SID FROM V$MYSTAT);
    
    SERVER   
    ---------
    DEDICATED
    1 row selected.
    
    

    共有サーバー・セッションに接続するには、SYSDBA権限でinst1_shsに接続してから、次のSELECT文を実行します(出力例も示します)。

    SQL> SELECT SERVER 
      2  FROM   V$SESSION 
      3  WHERE  SID = (SELECT DISTINCT SID FROM V$MYSTAT);
    
    SERVER   
    ---------
    SHARED 
    1 row selected.
      
    
  3. Recovery Managerを起動し、専用サービス名を使用してターゲット・データベースに接続します。必要に応じて、リカバリ・カタログに接続します。たとえば、次のように入力します。

    % rman
    RMAN> CONNECT TARGET SYS@inst1_ded 
    
    target database Password: password
    connected to target database: INST1 (DBID=39525561)
    
    RMAN> CONNECT CATALOG rman@catdb
    

    参照:

    Oracle Netの接続文字列構文の詳細は、プラットフォーム固有のOracleマニュアルおよび『Oracle Database Net Servicesリファレンス』を参照してください。 

消失書込みの検出の有効化

データ・ブロックの消失書込みは、実際には永続ストレージで書込みが行われなかったにもかかわらず、I/Oサブシステムでブロック書込みの完了が確認された場合に発生します。この後のブロック読取りでは、失効したデータ・ブロックがI/Oサブシステムによって戻されます。このデータ・ブロックを使用してデータベースの他のブロックを更新すると、ブロックが破損する場合があります。

バッファ・キャッシュ・ブロック読取りがデータベースによってREDOログに記録されるように、DB_LOST_WRITE_PROTECT初期化パラメータをTYPICALまたはFULLに設定することができます。デフォルト設定はNONEです。このパラメータをTYPICALに設定すると、読取り/書込み表領域のバッファ・キャッシュ読取りはインスタンスによってREDOログに記録されますが、読取り専用表領域は記録されません。FULLに設定すると、読取り専用表領域の読取りもインスタンスによって記録されます。TYPICALモードでのパフォーマンス・オーバーヘッドは約5〜10%です。Oracle RACでは、FULLモードでのオーバーヘッドが20%まで増加する可能性があります。

消失書込みの検出は、Data Guardとともに使用すると最も効果的です。この場合、プライマリ・データベースとスタンバイ・データベースの両方にDB_LOST_WRITE_PROTECTを設定します。スタンバイ・データベースは、管理リカバリ中にREDOを適用する際、対応するブロックを読み取ってSCNをREDOログ内のSCNと比較します。プライマリ・データベースのブロックSCNがスタンバイ・データベースのブロックSCNより小さい場合は、プライマリ・データベース上の消失書込みを検出し、外部エラー(ORA-752)をスローします。SCNが大きい場合は、スタンバイ・データベース上の消失書込みを検出し、内部エラー(ORA-600 [3020])をスローします。いずれの場合も、スタンバイ・データベースは障害の理由をアラート・ログおよびトレース・ファイルに書き込みます。

消失書込みをプライマリ・データベースで修復するには、スタンバイ・データベースへのフェイルオーバーを開始する必要があります。消失書込みをスタンバイ・データベースで修復するには、スタンバイ・データベース全体を再作成するか、または影響を受けたファイルのみのバックアップをリストアする必要があります。

Data Guardを使用しない場合も、消失書込みの検出を有効にすると役に立ちます。この場合、消失書込みは、通常のデータベース操作中またはメディア・リカバリ中に発生する可能性があります。通常のデータベース操作中に発生した場合は、エラーを検出する決定的な方法はありません。表に一貫性がないなどの間接的な兆候を、消失書込みに明確に結び付けることはできません。ただし、消失書込みが発生した可能性がある時点以前に作成したバックアップを保持している場合は、そのバックアップを代替の場所にリストアしてリカバリできます。問題を診断するには、失効したブロック読取りのSCNまでデータベースまたは表領域をリカバリします。これによって、消失書込みエラー(ORA-752)が生成されます。

メディア・リカバリ中に消失書込みエラーが発生した場合は、データベースをRESETLOGSオプションでオープンする対応のみが可能です。データベースは一貫性のある状態ですが、RESETLOGS SCNより後のすべてのデータは消失しています。データベース作成後に作成したバックアップを使用してリカバリする場合は、他の失効したブロックによってデータベースが破損していない保証はないことに注意してください。これは、リストアするバックアップが、消失書込みが発生した後に作成された可能性があるためです。消失書込みによってデータベースが破損していないことを保証するには、データベース作成からのメディア・リカバリを実行する必要があります。ただし、この方法は、ほとんどのデータベース環境で現実的ではありません。

参照:

  • 消失書込みの検出および修復のためにスタンバイ・データベースを使用する方法については、『Oracle Data Guard概要および管理』を参照してください。

  • DB_LOST_WRITE_PROTECT初期化パラメータについては、『Oracle Databaseリファレンス』を参照してください。

 


戻る 次へ
Oracle
Copyright © 2003, 2008, Oracle Corporation.

All Rights Reserved.
目次
目次
索引
索引