ヘッダーをスキップ
Oracle Real Application Clusters管理およびデプロイメント・ガイド
11gリリース1(11.1)
E05738-05
  目次
目次
索引
索引

戻る
戻る
 
次へ
次へ
 

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

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

内容は次のとおりです。

Oracle Real Application ClustersのRecovery Managerの構成の概要

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


ヒント:

バックアップはいつ実行したらよいでしょうか。root.shスクリプトの実行後すぐにバックアップを実行することをお薦めします。また、addNode.shまたはrootdelete.shスクリプトの実行後にも投票ディスクをバックアップする必要があります。

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

スナップショット制御ファイルは、Recovery Managerによってオペレーティング・システム固有の場所に作成されるデータベース制御ファイルのコピーです。Recovery Managerでは、制御ファイルの一貫性バージョンを保持して、リカバリ・カタログの再同期化時または制御ファイルのバックアップ時に使用できるように、スナップショット制御ファイルを作成します。Oracle RACでは、スナップショット制御ファイルは、Recovery Managerがバックアップを実行するノードでのみ必要になります。Oracle RAC環境のすべてのインスタンスにグローバルに使用可能である必要はありません。

クラスタ・ファイル・システムまたはRAWデバイス接続先をスナップショット制御ファイルの位置に指定できます。次のRecovery Managerのコマンドを実行して、スナップショット制御ファイルの構成位置を判別します。

SHOW SNAPSHOT CONTROLFILE NAME;

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

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

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

CONFIGUREコマンドを使用すると、複数のRecovery Managerセッションにまたがる永続的な設定を作成できます。したがって、スナップショット制御ファイルの位置を変更しないかぎり、再度このコマンドを実行する必要はありません。クラスタ・ファイル・システムまたはRAWデバイス接続先をスナップショット制御ファイルの位置に指定することもできます。このファイルは、Oracle RACの他のデータ・ファイルと同じように、クラスタ内のすべてのノードで共有されます。


関連項目:

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

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

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

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

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

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


関連項目:

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

複数のOracle Real Application Clustersノードでのクロスチェック

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

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

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

Oracle Real Application ClustersでのRecovery Managerのチャネルの構成

この項では、Recovery Managerのチャネルを構成する方法について説明します。自動ロード・バランシングを使用するようにチャネルを構成するか、または特定のチャネルを特定のインスタンスに指定することができます。この項の内容は次のとおりです。

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

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

CONFIGURE DEVICE TYPE [disk │ sbt] PARALLELISM number of channels;
...

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

特定のチャネルを使用するチャネルの構成

Oracle RACのインスタンスごとに1つのRecovery Managerチャネルを構成するには、次の構文を使用します。

CONFIGURE CHANNEL DEVICE TYPE sbt CONNECT
'SYS/change_on_install@node1'
CONFIGURE CHANNEL DEVICE TYPE sbt CONNECT
'SYS/change_on_install@node2'
...

このワンタイム構成手順を実行した後、BACKUPコマンドまたはRESTOREコマンドを実行できます。また、この例では、PARMSコマンドを使用してベンダー固有のパラメータを設定できます。

Oracle Real Application ClustersでのRecovery Managerを使用したアーカイブREDOログの管理

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

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

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

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

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

アーカイブREDOログに関しては、リカバリ時に(可能な場合はバックアップ時にも)、各ノードからすべてのアーカイブREDOログが読み取れるようにすることが重要です。 この項では、クラスタ・データベースにアーカイブを構成する際の、アーカイブREDOログのネーミングに関する注意点を示します。ここでは、非クラスタ・ファイル・システムのアーカイブ・スキームの使用例を説明します。次の条件が満たされていることが前提です。

例9-1 初期化パラメータ・ファイルの構成例

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)

次のアーカイブREDOログのファイル名が、制御ファイルに記録されていると仮定します。

/arc_dest_1/log_1_62_23452345.arc
/arc_dest_2/log_2_100_23452345.arc
/arc_dest_2/log_2_101_23452345.arc
/arc_dest_3/log_3_70_23452345.arc
/arc_dest_1/log_1_63_23452345.arc

リカバリ中、アーカイブ・ログの宛先がリカバリを実行するノードから認識可能であれば、Oracle Databaseはアーカイブ・ログのデータを正常にリカバリできます。

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

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

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

パラメータ 説明

%r

リセットログ識別子

log_1_62_23452345

%R

埋め込まれたリセットログ識別子

log_1_62_0023452345

%s

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

log_251

%S

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

log_0000000251

%t

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

log_1

%T

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

log_0001


すべてのスレッド・パラメータは、大/小文字のいずれも、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マニュアルを参照してください。

Recovery Managerのアーカイブ構成使用例

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

自動ストレージ管理およびクラスタ・ファイル・システムのアーカイブ・スキーム

Oracle RACで推奨する構成は、データ・ファイルとは別の自動ストレージ管理(ASM)ディスク・グループをリカバリ領域として使用する構成です。 この構成のかわりに、クラスタ・ファイル・システムのアーカイブ・スキームを使用することもできます。

その場合、各ノードは、単一のクラスタ・ファイル・システムのアーカイブREDOログ宛先に書き込み、他のノードのアーカイブREDOログ・ファイルを読み取ることができます。すべてのノードについての読取りアクセスは、クラスタ・ファイル・システムを使用して行われます。たとえば、ノード1がログをクラスタ・ファイル・システムの/arc_dest/log_1_100_23452345.arcにアーカイブした場合は、クラスタ内の他のすべてのノードもこのファイルを読み取ることができます。


注意:

この例のアーカイブ・ログ名のフォーマットは、CFSの例のみに適用されます。ASMでは、Oracle Managed Files(OMF)ベースの名前のフォーマットが使用されます。

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

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

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

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

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

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

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

sid1.LOG_ARCHIVE_DEST_1="LOCATION=/arc_dest"
sid2.LOG_ARCHIVE_DEST_1="LOCATION=/arc_dest"
sid3.LOG_ARCHIVE_DEST_1="LOCATION=/arc_dest"

次のリストは、前述の例に基づいて、Recovery Managerのカタログまたは制御ファイルに表示されるアーカイブ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 node 3
/arc_dest/log_3_1563_23452345.arc <- thread 3 archived in node 2
/arc_dest/log_2_753_23452345.arc <- thread 2 archived in node 1
/arc_dest/log_2_754_23452345.arc
/arc_dest/log_3_1564_23452345.arc

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

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

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

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

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

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

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

アーカイブ先の値は、次のように初期化パラメータ・ファイルに設定できます。

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"

次のリストは、データベース制御ファイルのアーカイブREDOログ・エントリを示しています。すべてのノードが任意のスレッドからログをアーカイブできることに注意してください。

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

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

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

表9-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


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

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

表9-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ユーザーは、マップされたドライブを使用してこの例と同じ結果を得ることができます。

Oracle Real Application Clustersでのアーカイブ・モードの変更

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


注意:

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

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

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


関連項目:

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