プライマリ・コンテンツに移動
Oracle® Real Application Clusters管理およびデプロイメント・ガイド
11g リリース2 (11.2)
B56290-06
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

6 Recovery Managerの構成およびアーカイブ

この章では、Oracle Real Application Clusters (Oracle RAC)環境で使用するためのRecovery Manager (RMAN)の構成方法について説明します。Oracle RAC環境でアーカイブを実行するために使用する方法、オンラインREDOログおよびアーカイブREDOログに関する考慮事項についても説明します。

内容は次のとおりです。

Oracle RACのRMANの構成の概要

RMANを使用すると、データ・ファイル、制御ファイル、サーバー・パラメータ・ファイル(SPFILE)およびアーカイブREDOログ・ファイルのバックアップ、リストアおよびリカバリを実行できます。RMANはOracle Databaseに含まれているため、個別にインストールする必要はありません。RMANは、コマンドラインから実行するか、Oracle Enterprise ManagerのBackup Managerで使用できます。

Oracle RACでのアーカイブ・モード

REDOログ・ファイルがアーカイブされるためには、Oracle RACデータベースがARCHIVELOGモードになっている必要があります。データベースがローカル・インスタンスによってマウントされていても、いずれのインスタンスでもオープンされていないため、SQL文ALTER DATABASEを実行すると、Oracle RACでアーカイブ・モードを変更できます。この文を実行するために、パラメータの設定を変更する必要はありません。


注意:

  • ARCHIVELOGモードは、インスタンス・レベルではなく、データベース・レベルで設定します。すべてのインスタンスがアーカイブされるか、1つもされないかのどちらかです。

  • Oracle Enterprise ManagerのOracle RACデータベースの「ホーム」ページにある「メンテナンス」タブの「リカバリ設定」ページを使用して、アーカイブ・ログ・モードを変更することもできます。



関連項目:

アーカイブ・モードの設定の詳細は、『Oracle Database管理者ガイド』を参照してください。

RMANのスナップショット制御ファイルの位置の構成

スナップショット制御ファイルは、RMANによってオペレーティング・システム固有の位置に作成されるデータベース制御ファイルのコピーです。RMANでは、制御ファイルの一貫性バージョンを保持して、リカバリ・カタログの再同期化時または制御ファイルのバックアップ時に使用できるように、スナップショット制御ファイルを作成します。

クラスタ・ファイル・システムまたはRAWデバイス接続先をスナップショット制御ファイルの位置に指定できます。このファイルはクラスタ内のすべてのノードで共有され、クラスタ内のすべてのノードがアクセスできる必要があります。次のRMANのコマンドを実行して、スナップショット制御ファイルの構成位置を判別します。

SHOW SNAPSHOT CONTROLFILE NAME;

スナップショット制御ファイルの構成位置は変更できます。たとえば、LinuxシステムおよびUNIXシステムの場合は、RMANのプロンプトで次のコマンドを入力し、スナップショット制御ファイルの位置を$ORACLE_HOME/dbs/scf/snap_prod.cfに指定できます。

CONFIGURE SNAPSHOT CONTROLFILE NAME TO '$ORACLE_HOME/dbs/scf/snap_prod.cf';

このコマンドは、クラスタ・データベースのすべてのインスタンスのスナップショット制御ファイルの位置構成をグローバルに設定します。したがって、バックアップを実行するすべてのノードに$ORACLE_HOME/dbs/scfディレクトリがあることを確認してください。

CONFIGUREコマンドを使用すると、複数のRMANセッションにまたがる永続的な設定を作成できます。したがって、スナップショット制御ファイルの位置を変更しないかぎり、再度このコマンドを実行する必要はありません。

スナップショット制御ファイルを削除するには、次に示すように、最初にスナップショット制御ファイルの位置を変更してから、古い位置のファイルを削除する必要があります。

CONFIGURE SNAPSHOT CONTROLFILE NAME TO 'new_name';
DELETE COPY OF CONTROLFILE;

関連項目:

スナップショット制御ファイルの構成方法については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

制御ファイルおよびSPFILEを自動的にバックアップするようなRMANの構成

CONFIGURE CONTROLFILE AUTOBACKUPONに設定すると、BACKUPコマンドまたはCOPYコマンドの実行後に、制御ファイルとSPFILEのバックアップがRMANによって自動的に作成されます。リカバリを実行する際のインスタンスの起動にSPFILEが必要な場合(SPFILEのデフォルト位置がOracle RACデータベースのすべてのノードで使用可能である必要があるため)、RMANはSPFILEを自動的にリストアすることもできます。

これらの機能は、リカバリ・カタログがない場合でもRMANが制御ファイルをリストアできるため、障害時リカバリでは重要です。リカバリ・カタログと現行の制御ファイルの両方が失われた場合でも、RMANによって、自動バックアップされた制御ファイルをリストアできます。CONFIGURE CONTROLFILE AUTOBACKUP FORMATコマンドを使用すると、RMANによって指定されたこのファイルのデフォルト名を変更できます。このコマンドで絶対パス名を指定する場合、そのパスはバックアップに使用するすべてのノードにも存在している必要があります。

RMANは、最初に割り当てられたチャネルで制御ファイルの自動バックアップを実行します。したがって、異なるパラメータを使用して複数のチャネルを割り当てる場合、特にCONNECTコマンドを使用してチャネルを割り当てる場合は、どのチャネルで制御ファイルの自動バックアップを実行するかを決定する必要があります。そのノードに、常に最初にチャネルを割り当ててください。

RMANの制御ファイルを使用する他に、Oracle Enterprise Managerを使用してRMAN機能を使用することもできます。


関連項目:

制御ファイルの自動バックアップ機能の使用方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

複数のOracle RACノードでのクロスチェック

複数のノードでクロスチェックを実行する場合(およびRMAN全般を操作する場合)、どのノードでバックアップを作成したかに関係なく、すべてのノードからすべてのバックアップにアクセスできるようにクラスタを構成します。クラスタをこのように構成すると、リストアまたはクロスチェックの操作中に、クラスタ内のすべてのノードにチャネルを割り当てられます。

各ノードからすべてのバックアップにアクセスできるようにクラスタを構成できない場合は、リストアおよびクロスチェックの操作中に、CONFIGURE CHANNELコマンドのCONNECTオプションを使用して複数のノードでチャネルを割り当てて、1つ以上のノードからすべてのバックアップにアクセスできるようにする必要があります。バックアップにアクセス可能なノードでチャネルを構成していなかったために、クロスチェック中にバックアップにアクセスできなかった場合、クロスチェック後にRMANリポジトリ内でそのバックアップにEXPIREDのマークが付けられます。

たとえば、クラスタ内の様々なノードでテープ・バックアップが作成され、各バックアップがバックアップを作成したノードでのみ使用可能なOracle RAC構成で、CONFIGURE CHANNEL ... CONNECTを使用できます。詳細は、「特定のノードを使用するようなチャネルの構成」を参照してください。


関連項目:

クロスチェックの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

Oracle RACでのRMANのチャネルの構成

この項では、RMANでチャネルを構成する方法を説明します。次の各項目で説明するように、チャネルは、自動ロード・バランシングを使用するか、特定のインスタンスに特定のチャネルを指定して構成できます。

自動ロード・バランシングを使用するようなチャネルの構成

自動ロード・バランシングを使用するようにチャネルを構成するには、次の構文を使用します。

CONFIGURE DEVICE TYPE [disk | sbt] PARALLELISM number_of_channels;
...

number_of_channelsは、この操作に使用するチャネル数です。このワンタイム構成を完了した後、BACKUPコマンドまたはRESTOREコマンドを発行できます。

特定のノードを使用するようなチャネルの構成

ポリシー管理Oracle RACデータベース・インスタンスごとに1つのRMANチャネルを構成するには、次の構文を使用します。

CONFIGURE CHANNEL DEVICE TYPE sbt CONNECT '@racinst_1'
CONFIGURE CHANNEL DEVICE TYPE sbt CONNECT '@racinst_2'
...

このワンタイム構成手順を実行した後、BACKUPコマンドまたはRESTOREコマンドを発行できます。

Oracle RACでのRMANを使用したアーカイブREDOログの管理

ノードでアーカイブREDOログが生成されると、Oracle Databaseはそのログのファイル名を常にターゲット・データベースの制御ファイルに記録します。リカバリ・カタログを使用している場合、アーカイブREDOログのファイル名は、再同期化の実行時にリカバリ・カタログにも記録されます。

あるノードが特定のファイル名でログをファイル・システムに書き込む場合、このアーカイブREDOログにアクセスするすべてのノードに対してそのファイルが読取り可能になっている必要があるため、使用するアーカイブREDOログのネーミング・スキームが重要となります。たとえば、node1/oracle/arc_dest/log_1_100_23452345.arcにログをアーカイブしている場合、node2は、自身のファイル・システムで/oracle/arc_dest/log_1_100_23452345.arcを読み取ることができる場合にのみ、このアーカイブREDOログをバックアップできます。

選択するバックアップとリカバリの計画は、各ノードのアーカイブ先を構成する方法によって異なります。アーカイブREDOログのバックアップを1つのノードのみで実行するか、全ノードで実行するかに関係なく、すべてのアーカイブREDOログがバックアップされることを確認する必要があります。リカバリ中にRMANのパラレル化を使用する場合、リカバリを実行するノードにはクラスタ内のすべてのアーカイブREDOログに対する読取りアクセス権が必要です。

複数のノードが、アーカイブ・ログをパラレルでリストアできます。ただし、リカバリ中にアーカイブ・ログを適用できるノードは1つのみです。したがって、リカバリを実行中のノードは、リカバリ操作に必要なすべてのアーカイブ・ログにアクセスできる必要があります。デフォルトでは、データベースはパラレル・スレッドの最適数を判断し、リカバリ操作に使用します。RECOVERコマンドのPARALLEL句を使用して、パラレル・スレッドの数を変更できます。

アーカイブREDOログに関するガイドラインおよび考慮事項

アーカイブREDOログに関しては、リカバリ時に(可能な場合はバックアップ時にも)、各ノードからすべてのアーカイブREDOログが読み取れるようにすることが重要です。リカバリ中、アーカイブ・ログの宛先がリカバリを実行するノードから認識可能であれば、Oracle Databaseはアーカイブ・ログのデータを正常にリカバリできます。

Oracle RACのアーカイブREDOログ・ファイルの表記規則

アーカイブREDOログの構成では、LOG_ARCHIVE_FORMATパラメータでアーカイブREDOログを一意に識別します。このパラメータのフォーマットは、オペレーティング・システム固有で、テキスト文字列、1つ以上の変数およびファイル名拡張子を指定できます。

表6-1 アーカイブREDOログ・ファイル名のフォーマット・パラメータ

パラメータ 説明

%r

埋込みなしのリセットログ識別子

log_1_62_23452345

%R

左端に0が埋め込まれたリセットログ識別子

log_1_62_0023452345

%s

埋込みなしのログ順序番号

log_251

%S

左端に0が埋め込まれたログ順序番号

log_0000000251

%t

埋込みなしのスレッド番号

log_1

%T

左端に0が埋め込まれたスレッド番号

log_0001


アーカイブREDOログのすべてのファイル名形式パラメータは、大/小文字のいずれも、Oracle RACに必須です。これらのパラメータによって、Oracle Databaseは、すべてのインカネーションのアーカイブ・ログに対して一意の名前を作成できます。この要件は、COMPATIBLEパラメータが10.0以上に設定されている場合に適用されます。

%Rまたは%rパラメータを使用してリセットログ識別子を含め、以前のインカネーションでログが上書きされないようにします。ログのフォーマットを指定しない場合、デフォルトでオペレーティング・システム固有のフォーマットが使用され、%t%sおよび%rが含まれます。

たとえば、REDOスレッド番号1に対応付けられたインスタンスによって、LOG_ARCHIVE_FORMATlog_%t_%s_%r.arcに設定されると、そのアーカイブREDOログ・ファイル名は次のようになります。

log_1_1000_23435343.arc
log_1_1001_23452345.arc
log_1_1002_23452345.arc
...

関連項目:

アーカイブREDOログ・ファイル名のフォーマットとアーカイブ先の指定については、『Oracle Database管理者ガイド』を参照してください。デフォルトのログ・アーカイブのフォーマットとアーカイブ先については、プラットフォーム固有のOracle Databaseマニュアルを参照してください。

RMANのアーカイブ構成使用例

この項では、Oracle RACデータベースでのアーカイブの使用例について説明します。この章の2つの構成使用例では、Oracle RACデータベース用の3ノードのUNIXクラスタについて説明します。いずれの使用例でも、リカバリを実行するインスタンスに指定するLOG_ARCHIVE_FORMATは、REDOログ・ファイルをアーカイブするインスタンスに指定したフォーマットと同じである必要があります。

この項の内容は次のとおりです。

Oracle Automatic Storage Managementおよびクラスタ・ファイル・システムのアーカイブ・スキーム

Oracle RACで推奨する構成は、データファイル用とは異なるリカバリ・セット用のディスク・グループを使用して、Oracle Automatic Storage Management(Oracle ASM)をリカバリ領域に使用する構成です。Oracle ASMを使用する場合は、Oracle Managed Filesの名前のフォーマットが使用されます。

この構成のかわりに、クラスタ・ファイル・システムのアーカイブ・スキームを使用することもできます。クラスタ・ファイル・システムを使用する場合、各ノードは、REDOログ・ファイルをアーカイブする際にクラスタ・ファイル・システムの1つの場所に書き込みます。各ノードは、他のノードのアーカイブREDOログ・ファイルを読み取ることができます。たとえば、図6-1に示すように、ノード1がREDOログ・ファイルをクラスタ・ファイル・システムの/arc_dest/log_1_100_23452345.arcにアーカイブすると、クラスタの他のノードもこのファイルを読み取ることできます。


関連項目:

リカバリ領域の領域管理およびRMANを使用したアーカイブREDOログのバックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

図6-1 クラスタ・ファイル・システムのアーカイブ・スキーム

図6-1の説明が続きます。
図6-1 クラスタ・ファイル・システムのアーカイブ・スキームの説明


注意:

この例のアーカイブ・ログ名のフォーマットは、クラスタ・ファイル・システムの例のみに適用されます。

クラスタ・ファイル・システムを使用しない場合は、アーカイブREDOログ・ファイルをRAWデバイス上に置くことができません。これは、RAWデバイスでは、連続したアーカイブ・ログ・ファイルの順次書込みができないためです。

クラスタ・ファイル・システムのアーカイブ・スキームのメリット

このスキームには、いずれのノードもログのアーカイブでネットワークを使用しないというメリットがあります。あるノードが書き込んだファイル名はクラスタ内の任意のノードで読み取ることができるため、RMANは、クラスタ内の任意のノードからすべてのログをバックアップできます。各ノードには、すべてのアーカイブREDOログに対するアクセス権があるため、バックアップとリストアのスクリプトが簡素化されます。

クラスタ・ファイル・システムのアーカイブ・スキームに関する初期化パラメータの設定

クラスタ・ファイル・システムのスキームでの各ノードは、クラスタ・データベース内のすべてのインスタンスで同じ名前を使用して識別されるディレクトリにアーカイブします(次の例では/arc_dest)。このディレクトリを構成するには、次の例のようにLOG_ARCH_DEST_1パラメータに値を設定します。

*.LOG_ARCHIVE_DEST_1="LOCATION=/arc_dest"

次のリストは、前述の例に基づいて、RMANのカタログまたは制御ファイルに表示されるアーカイブREDOログ・エントリの例を示しています。すべてのノードが任意のスレッドを使用してログをアーカイブできることに注意してください。

/arc_dest/log_1_999_23452345.arc
/arc_dest/log_1_1000_23435343.arc
/arc_dest/log_1_1001_23452345.arc <- thread 1 archived in node3
/arc_dest/log_3_1563_23452345.arc <- thread 3 archived in node2
/arc_dest/log_2_753_23452345.arc <- thread 2 archived in node1
/arc_dest/log_2_754_23452345.arc
/arc_dest/log_3_1564_23452345.arc

クラスタ・ファイル・システムのアーカイブ・スキームでのアーカイブ・ログの位置

ファイル・システムは共有化されており、各ノードはそのノード自体のアーカイブREDOログをクラスタ・ファイル・システムの/arc_destディレクトリに書き込むため、各ノードはそのノード自体、および他のノードが書き込んだログを読み取ることができます。

非クラスタ・ファイル・システムのローカル・アーカイブ・スキーム

非クラスタ・ファイル・システムにローカルにアーカイブする場合、各ノードは、一意の名前のローカル・ディレクトリにアーカイブします。リカバリが必要な場合は、他のノードのディレクトリにリモートでアクセスできるように、リカバリ・ノードを構成できます。たとえば、LinuxコンピュータおよびUNIXコンピュータのNFSまたはWindowsシステムのマップされたドライブを使用します。したがって、各ノードはローカルの宛先にのみ書き込みますが、他のノード上のリモート・ディレクトリにあるアーカイブREDOログ・ファイルを読み取ることもできます。

非クラスタ・ファイル・システムのローカル・アーカイブの使用に関する考慮事項

メディア・リカバリに非クラスタ・ファイル・システムのローカル・アーカイブを使用する場合、他のノード上のアーカイブ・ディレクトリにあるアーカイブREDOログ・ファイルの読取りができるようにするために、他のノードへのリモート・アクセスのリカバリを実行するノードを構成する必要があります。また、リカバリを実行する際に、使用可能なすべてのアーカイブ・ログがない場合は、アーカイブREDOログの順序番号が欠落している最初の地点まで不完全リカバリを実行する必要があります。このスキームのために特定の構成を使用する必要はありません。ただし、バックアップ処理を複数のノードに分散する最も簡単な方法は、第7章「バックアップおよびリカバリの管理」のバックアップの例に示すとおり、チャネルを構成することです。


注意:

非クラスタの場合は異なるファイル・システムが使用されるため、アーカイブ・ログ・ディレクトリは各ノードで一意である必要があります。たとえば、/arc_dest_1node1でのみ使用可能で、/arc_dest_2node2にのみ直接マウントされます。

その後、node1は、NFSを介してnode2から/arc_dest_2をマウントし、node3から/arc_dest_3をマウントします。


非クラスタ・ファイル・システムのローカル・アーカイブに関する初期化パラメータの設定

ポリシー管理データベースまたは管理者管理のデータベースの初期化パラメータ・ファイルで、アーカイブ先の値を次のように、設定できます。

次の例に示すように、SID指定子を使用して、各インスタンスにSID.LOG_ARCH_DESTパラメータを設定します。

sid1.LOG_ARCHIVE_DEST_1="LOCATION=/arc_dest_1"
sid2.LOG_ARCHIVE_DEST_1="LOCATION=/arc_dest_2"
sid3.LOG_ARCHIVE_DEST_1="LOCATION=/arc_dest_3"

ポリシー管理データベースでは、ノードおよびインスタンス・バインディングを手動で作成し、次のように、sid1が常に同じノードで動作するようにします。

$ srvctl modify database -d mydb -n node1 -i sid1
$ srvctl modify database -d mydb -n node2 -i sid2
$ srvctl modify database -d mydb -n node3 -i sid3

次のリストは、データベース制御ファイルのアーカイブREDOログ・エントリを示しています。障害発生後にデータベースをリカバリするために、すべてのノードは任意のスレッドからアーカイブREDOログの読取りができる必要があることに注意してください。

/arc_dest_1/log_1_1000_23435343.arc
/arc_dest_2/log_1_1001_23452345.arc <- thread 1 archived in node2
/arc_dest_2/log_3_1563_23452345.arc <- thread 3 archived in node2
/arc_dest_1/log_2_753_23452345.arc <- thread 2 archived in node1
/arc_dest_2/log_2_754_23452345.arc
/arc_dest_3/log_3_1564_23452345.arc

非クラスタ・ファイル・システムのローカル・アーカイブでのアーカイブ・ログの位置

表6-2に示すように、3つのノードそれぞれにはローカルのアーカイブREDOログを含むディレクトリがあります。また、NFSまたはマップされたドライブを介して他のノード上のディレクトリをリモートでマウントしている場合、各ノードには、残りのノードがアーカイブしたアーカイブREDOログ・ファイルをRMANで読み取ることができる、2つのリモート・ディレクトリがあります。


注意:

表6-2に記載されているようなアーカイブ・ログ先は、NFSディレクトリを別のノードにマウントする場合に、既存のアーカイブ・ログ・ディレクトリと競合しないように、各ノードで異なっている必要があります。

表6-2 UNIX/NFSのログの位置の例: 非クラスタ・ファイル・システムのローカル・アーカイブ

ノード アーカイブREDOログ・ファイルを読み取るディレクトリ ノードがアーカイブするログ

1

/arc_dest_1

1

1

/arc_dest_2

2(NFSを介して)

1

/arc_dest_3

3(NFSを介して)

2

/arc_dest_1

1(NFSを介して)

2

/arc_dest_2

2

2

/arc_dest_3

3(NFSを介して)

3

/arc_dest_1

1(NFSを介して)

3

/arc_dest_2

2(NFSを介して)

3

/arc_dest_3

3


非クラスタ・ファイル・システムのローカル・アーカイブに関するファイル・システムの構成

リカバリを実行していて、障害が発生しなかったインスタンスが、まだバックアップされていないディスク上のログをすべて読み取る必要がある場合は、表6-3に示すようにNFSを構成する必要があります。

表6-3 共有読取りローカル・アーカイブに関するUNIX/NFSの構成

ノード ディレクトリ 構成 マウント先 ノード

1

/arc_dest_1

ローカルの読取り/書込み

該当なし

該当なし

1

/arc_dest_2

NFS読取り

/arc_dest_2

2

1

/arc_dest_3

NFS読取り

/arc_dest_3

3

2

/arc_dest_1

NFS読取り

/arc_dest_1

1

2

/arc_dest_2

ローカルの読取り/書込み

該当なし

該当なし

2

/arc_dest_3

NFS読取り

/arc_dest_3

3

3

/arc_dest_1

NFS読取り

/arc_dest_1

1

3

/arc_dest_2

NFS読取り

/arc_dest_2

2

3

/arc_dest_3

ローカルの読取り/書込み

該当なし

該当なし



注意:

Windowsユーザーは、マップされたドライブを使用してこの例と同じ結果を得ることができます。

アーカイバ・プロセスの監視

RMAN構成がOracle RAC環境で操作可能になった後、GV$ARCHIVE_PROCESSESビューとV$ARCHIVE_PROCESSESビューを使用してアーカイバ・プロセスのステータスを判断します。これらのビューには、問合せ対象がグローバル・ビューかローカル・ビューのいずれであるかに従って、すべてのデータベース・インスタンスに関する情報または接続先のインスタンスのみに関する情報がそれぞれ表示されます。


注意:

killコマンドを使用してアーカイバ・プロセスを停止した場合、そのデータベース・インスタンスは失敗します。


関連項目:

  • アーカイバ・プロセスの詳細は、『Oracle Database管理者ガイド』を参照してください。

  • データベース・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。