この章では、Oracle Real Application Clusters(Oracle RAC)環境で使用するためのRecovery Managerの構成方法について説明します。Oracle RAC環境でアーカイブを実行するためにRecovery Managerを使用する方法、オンラインREDOログおよびアーカイブREDOログに関する考慮事項についても説明します。
内容は次のとおりです。
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では、制御ファイルの一貫性バージョンを保持して、リカバリ・カタログの再同期化時または制御ファイルのバックアップ時に使用できるように、スナップショット制御ファイルを作成します。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バックアップおよびリカバリ・リファレンス』を参照してください。 |
CONFIGURE CONTROLFILE AUTOBACKUP
をON
に設定すると、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バックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
複数のノードでクロスチェックを実行する場合(およびRecovery Manager全般を操作する場合)、どのノードでバックアップを作成したかに関係なく、すべてのノードからすべてのバックアップにアクセスできるようにクラスタを構成します。 クラスタをこのように構成すると、リストアまたはクロスチェックの操作中に、クラスタ内のすべてのノードでチャネルを割り当てられます。
各ノードからすべてのバックアップにアクセスできるようにクラスタを構成できない場合は、リストアおよびクロスチェックの操作中に、CONFIGURE CHANNEL
コマンドのCONNECT
オプションを使用して複数のノードでチャネルを割り当てて、1つ以上のノードからすべてのバックアップにアクセスできるようにする必要があります。バックアップにアクセス可能なノードでチャネルを構成していなかったために、クロスチェック中にバックアップにアクセスできなかった場合、クロスチェック後にRecovery Managerリポジトリ内でそのバックアップにEXPIRED
のマークが付けられます。
たとえば、クラスタ内の様々なノードでテープ・バックアップが作成され、各バックアップがバックアップを作成したノードでのみ使用可能なOracle RAC構成で、CONFIGURE CHANNEL ... CONNECT
を使用できます。詳細は、「特定のチャネルを使用するチャネルの構成」を参照してください。
この項では、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
コマンドを使用してベンダー固有のパラメータを設定できます。
ノードでアーカイブ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ログのネーミングに関する注意点を示します。ここでは、非クラスタ・ファイル・システムのアーカイブ・スキームの使用例を説明します。次の条件が満たされていることが前提です。
各ノードが、各ノードの同じ名前のローカル・アーカイブ・ディレクトリに書き込むように構成されている。
クラスタ・ファイル・システムを設定していない(つまり、各ノードはそれ自体のローカル・ファイル・システムとの間のみで読取り/書込みを実行できる)。この章の後半に説明されているクラスタ・ファイル・システムに関する情報を参照してください。
クラスタ内のノードを使用可能にしてノード間相互の読取り/書込みアクセス権を取得するために、NFS(ネットワーク・ファイル・システム)またはマップされたドライブを使用していない。
例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はアーカイブ・ログのデータを正常にリカバリできます。
アーカイブREDOログの構成では、LOG_ARCHIVE_FORMAT
パラメータでアーカイブREDOログを一意に識別します。 このパラメータのフォーマットは、オペレーティング・システム固有で、テキスト文字列、1つ以上の変数およびファイル名拡張子を指定できます。
表9-1 アーカイブREDOログ・ファイル名のフォーマット・パラメータ
パラメータ | 説明 | 例 |
---|---|---|
|
リセットログ識別子 |
|
|
埋め込まれたリセットログ識別子 |
|
|
埋込みなしのログ順序番号 |
|
|
左端に0が埋め込まれたログ順序番号 |
|
|
埋込みなしのスレッド番号 |
|
|
左端に0が埋め込まれたスレッド番号 |
|
すべてのスレッド・パラメータは、大/小文字のいずれも、Oracle RACに必須です。これによって、Oracle Databaseは、すべてのインカネーションのアーカイブ・ログに対して一意の名前を作成できます。この要件は、COMPATIBLE
パラメータが10.0
以上に設定されている場合に適用されます。
%R
または%r
パラメータを使用してリセットログ識別子を含め、以前のインカネーションでログが上書きされないようにします。ログのフォーマットを指定しない場合、デフォルトでオペレーティング・システム固有のフォーマットが使用され、%t
、%s
および%r
が含まれます。
たとえば、REDOスレッド番号1に対応付けられたインスタンスによって、LOG_ARCHIVE_FORMAT
がlog_%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マニュアルを参照してください。 |
この項では、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デバイスでは、連続したアーカイブ・ログ・ファイルの順次書込みができないためです。
このスキームには、いずれのノードもログのアーカイブでネットワークを使用しないというメリットがあります。あるノードが書き込んだファイル名はクラスタ内の任意のノードで読み取ることができるため、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
非クラスタ・ファイル・システムのローカル・アーカイブ・スキームでの各ノードは、一意の名前のローカル・ディレクトリにアーカイブします。リカバリが必要な場合は、他のノードのディレクトリにリモートでアクセスできるように、リカバリ・ノードを構成できます。たとえば、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-3に示すようにNFSを構成する必要があります。
表9-3 共有読取りローカル・アーカイブに関するUNIX/NFSの構成
ノード | ディレクトリ | 構成 | マウント先 | ノード |
---|---|---|---|---|
1 |
|
ローカルの読取り/書込み |
該当なし |
該当なし |
1 |
|
NFS読取り |
|
2 |
1 |
|
NFS読取り |
|
3 |
2 |
|
NFS読取り |
|
1 |
2 |
|
ローカルの読取り/書込み |
該当なし |
該当なし |
2 |
|
NFS読取り |
|
3 |
3 |
|
NFS読取り |
|
1 |
3 |
|
NFS読取り |
|
2 |
3 |
|
ローカルの読取り/書込み |
該当なし |
該当なし |
注意: Windowsユーザーは、マップされたドライブを使用してこの例と同じ結果を得ることができます。 |
SQL文ALTER
DATABASE
を実行すると、データベースがローカル・インスタンスにマウントされており、いずれのインスタンスでもオープンされていなければ、Oracle RACでアーカイブ・モードを変更できます。この文を実行するために、パラメータの設定を変更する必要はありません。
注意: Oracle Enterprise ManagerのOracle RACデータベースの「ホーム」ページにある「メンテナンス」タブの「リカバリ設定」ページを使用して、アーカイブ・ログ・モードを変更することもできます。 |