11g リリース1（11.1）
E05700-03
 目次 |
 索引 |
| Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド 11g リリース1（11.1） E05700-03 |
|
この章では、設定および構成作業を実行する方法について説明します。この章の内容は、次のとおりです。
「チャネルの構成」ではチャネルの構成の基本が説明されていますが、この項では、より高度なチャネルのトピックについて説明します。この項の内容は、次のとおりです。
チャネルの構成および割当ての概要については「Recovery Managerチャネル」、
参照:
CONFIGURE構文については『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
チャネルを手動で割り当てる場合も自動チャネル割当てを使用する場合も、チャネル・コマンドおよびオプションを使用して、チャネルの動作を制御できます。表6-1に、チャネルの動作を制御する方法の概要を示します。特に明記されていないかぎり、CONFIGURE CHANNELとALLOCATE CHANNELコマンドの両方ですべてのチャネル・パラメータがサポートされています。
| チャネル制御のタイプ | コマンド |
|---|---|
|
I/O帯域幅消費に対する制限 |
バックアップの制限メカニズムとして機能する |
|
バックアップ・セットおよびバックアップ・ピースに対する制限 |
|
|
ベンダー固有の手順 |
|
|
バックアップおよびリストア操作でのチャネルのパラレル化 |
チャネルは、 |
|
データベース・インスタンスの接続設定 |
|
特定のタイプのすべてのチャネルに適用されるパラメータの構成に加えて、特定のチャネルに適用されるパラメータを構成することもできます。特定のチャネルを構成するには、CONFIGURE CHANNEL n（nは255未満の正の整数）コマンドを実行します。
チャネルに番号を手動で割り当てる場合、各チャネルに1つ以上のチャネル・オプション（MAXPIECESIZE、FORMATなど）を指定する必要があります。固有の番号を割り当てたチャネルをバックアップで使用すると、構成済の汎用チャネル設定ではなく、そのチャネルの構成設定が使用されます。
各チャネルに設定されたパラメータを個別に制御する必要がある場合は、固有のチャネルを番号ごとに構成します。この方法は、次のような場合に実行する必要があります。
PARMS設定が必要なメディア・マネージャを使用している場合。次の例では、ディスク・バックアップを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つのテープ・ドライブがあり、各テープ・ドライブで異なるテープ・メディア・ファミリのテープを使用するという別の場合を想定します。デフォルトの出力デバイスおよびデフォルトのテープ・チャネルを次の例のように構成して、データベース・バックアップをパラレル化します。
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つのテープ・デバイス間で分割されます。構成済の各チャネルは、データの合計の約半分ずつをバックアップします。
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バックアップの環境の構成」を参照してください。この項では、より高度な構成オプションについて説明します。この項の内容は、次のとおりです。
テープ・バックアップでは、複数のテープにまたがって多重バックアップ・セットを使用できます。つまり、バックアップ・セットの各データファイルにあるブロックは、複数のテープに書き込まれます。マルチボリュームのバックアップ・セットのいずれかのテープで障害が発生すると、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;
結果は次のようになります。
users表領域のバックアップには、構成済チャネルSBTおよび構成済のMAXSETSIZEのデフォルト設定である7500Kが使用されます。
tools表領域のバックアップには、BACKUPコマンドのMAXSETSIZEに設定した5Gが使用されます。
参照:
BACKUP構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
バックアップ・ピースのサイズがファイル・システムまたはメディア管理ソフトウェアで許容される最大ファイル・サイズを超えると、問題が発生します。CONFIGURE CHANNELまたはALLOCATE CHANNELコマンドのMAXPIECESIZEパラメータを使用すると、バックアップ・ピースのサイズを制限できます。
たとえば、バックアップ・ピースのサイズを常に2GB以下に制限するには、自動DISKチャネルを次のように構成して、BACKUP DATABASEを実行します。
CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 2G; BACKUP 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 COPIESが1に設定されています。
|
参照:
|
次の場合のように、指定した表領域を通常のバックアップ・スケジュールから除外することもできます。
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;
これらの表領域は、これ以降に実行されるデータベース全体のバックアップでバックアップされます。
Recovery Managerでは、バックアップ・セットのバイナリ圧縮がサポートされています。サポートされているアルゴリズムは、BZIP2（デフォルト）およびZLIBです。BZIP2アルゴリズムは最大の圧縮用に最適化され、ZLIBアルゴリズムはCPUの効率用に最適化されます。BZIP2は、ZLIBより多くのCPUリソースを消費しますが、通常はより圧縮されたバックアップを作成します。ZLIB圧縮の場合、Oracle Advanced Compressionオプションが必要なため、COMPATIBLE初期化パラメータを11.0.0以上に設定する必要があります。
次の構文で圧縮アルゴリズムを構成できます。ここで、alg_nameは、BZIP2またはZLIBを指定するプレースホルダです。
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ウォレットが使用されます。ウォレットは、認証および署名資格証明（秘密鍵、証明書、SSLで必要な信頼できる証明書など）の格納に使用されるパスワード保護されたコンテナです。
このモードでは、パスワード保護のみが使用されます。暗号化バックアップを作成およびリストアする場合、パスワードを入力する必要があります。
このモードでは、ウォレットまたはパスワードが必要です。
暗号化バックアップは、必要な復号化キーが使用可能な場合にかぎり、リストアおよびリカバリ中に自動的に復号化されます。バックアップ・セットごとに別々のキーが取得されます。キーは、暗号化形式でバックアップ・ピースに格納されます。バックアップは、ユーザーが指定するパスワードまたは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キー管理インフラストラクチャが使用可能な場合にかぎり、DBAの介入なしで暗号化バックアップを作成およびリストアできます。透過的暗号化は、日次バックアップ操作（バックアップを作成元と同じデータベースにリストア）に最適です。透過的暗号化は、Recovery Managerの暗号化のデフォルトです。
透過的暗号化を使用する場合は、まず、『Oracle Database Advanced Security管理者ガイド』の説明に従って、各データベースにOracleウォレットを構成する必要があります。バックアップの透過的暗号化では、暗号化形式および自動ログイン形式のOracleウォレットがサポートされています。Oracleウォレットを使用する場合は、バックアップの暗号化を実行する前にウォレットがオープンされている必要があります。自動ログイン・ウォレットを使用する場合は、暗号化バックアップの操作をいつでも行うことができます。自動ログイン・ウォレットは常にオープンしているためです。
Oracleウォレットを構成した後は、DBAの介入なしで暗号化バックアップを作成およびリストアできます。透過的データ暗号化を使用して暗号化されているデータベース内のいくつかの列をバックアップの暗号化を使用してバックアップすると、バックアップ中にそれらの列に対して2度目の暗号化が行われます。バックアップ・セットがリストア中に復号化されると、暗号化された列は、元の暗号化された形式に戻ります。
Oracleキー管理インフラストラクチャによって以前のすべてのマスター・キーがOracleウォレットにアーカイブされるため、現行のデータベース・マスター・キーを変更または再設定しても、以前のマスター・キーを使用して実行された暗号化バックアップは引き続きリストアできます。データベース・マスター・キーはいつでも再設定できます。Recovery Managerは、このデータベースによって作成されたすべての暗号化バックアップを常にリストアできます。
パスワード暗号化では、暗号化バックアップを作成およびリストアする場合に、DBAがパスワードを入力する必要があります。パスワード暗号化バックアップをリストアするには、バックアップを作成する場合に使用したパスワードと同じパスワードが必要となります。
パスワード暗号化は、リモートの場所でリストアし、送信中は保護されている必要があるバックアップに有効です。パスワード暗号化は、永続的には構成できません。パスワード暗号化を排他的に使用する場合は、Oracleウォレットを構成する必要はありません。
パスワード暗号化を使用するには、Recovery ManagerスクリプトでSET ENCRYPTION ON IDENTIFIED BY password ONLYコマンドを使用します。
デュアル・モード暗号化バックアップでは、透過的なリストアまたはパスワードを指定したリストアのいずれかを実行できます。デュアル・モード暗号化バックアップは、通常はOracleウォレットを使用してオンサイトでリストアされるが、Oracleウォレットを使用できないオフサイトでリストアする必要がある場合もあるバックアップを作成する場合に有効です。
デュアル・モード暗号化バックアップをリストアする場合は、Oracleウォレットまたは復号化用のパスワードのいずれかを使用できます。
デュアル・モード暗号化バックアップ・セットを作成するには、Recovery ManagerスクリプトでSET ENCRYPTION ON IDENTIFIED BY passwordコマンドを指定する必要があります。
CONFIGUREコマンドを使用すると、バックアップの透過的暗号化を永続的に構成できます。このコマンドを使用して、次の内容を指定できます。
SET ENCRYPTIONコマンドを使用して、次の処理を実行することもできます。
CONFIGURE ENCRYPTIONコマンドで指定された暗号化設定を無効にします。たとえば、SET ENCRYPTION OFFを使用すると、暗号化バックアップを作成するようにデータベースが構成されている場合でも、暗号化されていないバックアップが作成されます。
アーカイブREDOログのバックアップを暗号化するかどうかを制御する永続的な構成はありません。アーカイブREDOログ・ファイルを含むバックアップ・セットは、次のいずれかの条件が満たされている場合に暗号化されます。
この動作によって、データファイルの暗号化バックアップに関連付けられているREDOも暗号化されます。
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です。
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コマンドを実行します。
|
参照:
|
Recovery Managerは、共有サーバー・ディスパッチャを介しては、ターゲット・データベースに接続できません。Recovery Managerには専用サーバー・プロセスが必要です。ターゲット・データベースが共有サーバー用に構成されている場合、Oracle Net構成を変更し、Recovery Manager接続専用のサーバー・プロセスを指定する必要があります。
ターゲット・データベースが共有サーバー用に構成されている場合にRecovery Managerをディスパッチャに接続しないようにするには、Recovery Managerで使用するネット・サービス名の接続文字列のCONNECT_DATA属性に(SERVER=DEDICATED)を含める必要があります。
Oracle Net構成は、システムによって大幅に異なります。次に、多くの構成方法の一例を示します。この例では、共有サーバー・アーキテクチャを使用して、tnsnames.ora内の次のサービス名がターゲット・データベースに接続すると想定しています。ここで、inst1はSERVICE_NAMES初期化パラメータの値です。
inst1_shs = (DESCRIPTION= (ADDRESS=(PROTOCOL=tcp)(HOST=inst1_host)(port=1521)) (CONNECT_DATA=(SERVICE_NAME=inst1)(SERVER=shared)) )
tnsnames.oraファイルに、共有されないSIDに接続するネット・サービス名を作成します。たとえば、次のように入力します。
inst1_ded = (DESCRIPTION= (ADDRESS=(PROTOCOL=tcp)(HOST=inst1_host)(port=1521)) (CONNECT_DATA=(SERVICE_NAME=inst1)(SERVER=dedicated)) )
たとえば、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.
% rman RMAN> CONNECT TARGET SYS@inst1_ded target database Password: password connected to target database: INST1 (DBID=39525561) RMAN> CONNECT CATALOG rman@catdb
データ・ブロックの消失書込みは、実際には永続ストレージで書込みが行われなかったにもかかわらず、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より後のすべてのデータは消失しています。データベース作成後に作成したバックアップを使用してリカバリする場合は、他の失効したブロックによってデータベースが破損していない保証はないことに注意してください。これは、リストアするバックアップが、消失書込みが発生した後に作成された可能性があるためです。消失書込みによってデータベースが破損していないことを保証するには、データベース作成からのメディア・リカバリを実行する必要があります。ただし、この方法は、ほとんどのデータベース環境で現実的ではありません。
|
 Copyright © 2003, 2008, Oracle Corporation. All Rights Reserved. |
|