この章では、Oracle Real Application Clusters (Oracle RAC)環境で使用するためのRecovery Manager (RMAN)の構成方法について説明します。Oracle RAC環境でアーカイブを実行するために使用する方法、オンラインREDOログおよびアーカイブREDOログに関する考慮事項についても説明します。
内容は次のとおりです。
RMANを使用すると、データ・ファイル、制御ファイル、サーバー・パラメータ・ファイル(SPFILE)およびアーカイブREDOログ・ファイルのバックアップ、リストアおよびリカバリを実行できます。RMANはOracle Databaseに含まれているため、個別にインストールする必要はありません。RMANは、コマンドラインから実行するか、Oracle Enterprise ManagerのBackup Managerで使用できます。
REDOログ・ファイルがアーカイブされるためには、Oracle RACデータベースがARCHIVELOG
モードになっている必要があります。データベースがローカル・インスタンスによってマウントされていても、いずれのインスタンスでもオープンされていないため、SQL文ALTER DATABASE
を実行すると、Oracle RACでアーカイブ・モードを変更できます。この文を実行するために、パラメータの設定を変更する必要はありません。
注意:
|
関連項目: アーカイブ・モードの設定の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
スナップショット制御ファイルは、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バックアップおよびリカバリ・リファレンス』を参照してください。 |
CONFIGURE CONTROLFILE AUTOBACKUP
をON
に設定すると、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バックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
複数のノードでクロスチェックを実行する場合(およびRMAN全般を操作する場合)、どのノードでバックアップを作成したかに関係なく、すべてのノードからすべてのバックアップにアクセスできるようにクラスタを構成します。クラスタをこのように構成すると、リストアまたはクロスチェックの操作中に、クラスタ内のすべてのノードにチャネルを割り当てられます。
各ノードからすべてのバックアップにアクセスできるようにクラスタを構成できない場合は、リストアおよびクロスチェックの操作中に、CONFIGURE CHANNEL
コマンドのCONNECT
オプションを使用して複数のノードでチャネルを割り当てて、1つ以上のノードからすべてのバックアップにアクセスできるようにする必要があります。バックアップにアクセス可能なノードでチャネルを構成していなかったために、クロスチェック中にバックアップにアクセスできなかった場合、クロスチェック後にRMANリポジトリ内でそのバックアップにEXPIRED
のマークが付けられます。
たとえば、クラスタ内の様々なノードでテープ・バックアップが作成され、各バックアップがバックアップを作成したノードでのみ使用可能なOracle RAC構成で、CONFIGURE CHANNEL ... CONNECT
を使用できます。詳細は、「特定のノードを使用するようなチャネルの構成」を参照してください。
関連項目: クロスチェックの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
この項では、RMANでチャネルを構成する方法を説明します。次の各項目で説明するように、チャネルは、自動ロード・バランシングを使用するか、特定のインスタンスに特定のチャネルを指定して構成できます。
自動ロード・バランシングを使用するようにチャネルを構成するには、次の構文を使用します。
CONFIGURE DEVICE TYPE [disk | sbt] PARALLELISM number_of_channels;
...
number_of_channels
は、この操作に使用するチャネル数です。このワンタイム構成を完了した後、BACKUP
コマンドまたはRESTORE
コマンドを発行できます。
ノードでアーカイブ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はアーカイブ・ログのデータを正常にリカバリできます。
アーカイブREDOログの構成では、LOG_ARCHIVE_FORMATパラメータでアーカイブREDOログを一意に識別します。このパラメータのフォーマットは、オペレーティング・システム固有で、テキスト文字列、1つ以上の変数およびファイル名拡張子を指定できます。
表6-1 アーカイブREDOログ・ファイル名のフォーマット・パラメータ
パラメータ | 説明 | 例 |
---|---|---|
|
埋込みなしのリセットログ識別子 |
|
|
左端に0が埋め込まれたリセットログ識別子 |
|
|
埋込みなしのログ順序番号 |
|
|
左端に0が埋め込まれたログ順序番号 |
|
|
埋込みなしのスレッド番号 |
|
|
左端に0が埋め込まれたスレッド番号 |
|
アーカイブREDOログのすべてのファイル名形式パラメータは、大/小文字のいずれも、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
は、REDOログ・ファイルをアーカイブするインスタンスに指定したフォーマットと同じである必要があります。
この項の内容は次のとおりです。
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バックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
注意: この例のアーカイブ・ログ名のフォーマットは、クラスタ・ファイル・システムの例のみに適用されます。 |
クラスタ・ファイル・システムを使用しない場合は、アーカイブ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
非クラスタ・ファイル・システムにローカルにアーカイブする場合、各ノードは、一意の名前のローカル・ディレクトリにアーカイブします。リカバリが必要な場合は、他のノードのディレクトリにリモートでアクセスできるように、リカバリ・ノードを構成できます。たとえば、LinuxコンピュータおよびUNIXコンピュータのNFSまたはWindowsシステムのマップされたドライブを使用します。したがって、各ノードはローカルの宛先にのみ書き込みますが、他のノード上のリモート・ディレクトリにあるアーカイブREDOログ・ファイルを読み取ることもできます。
メディア・リカバリに非クラスタ・ファイル・システムのローカル・アーカイブを使用する場合、他のノード上のアーカイブ・ディレクトリにあるアーカイブREDOログ・ファイルの読取りができるようにするために、他のノードへのリモート・アクセスのリカバリを実行するノードを構成する必要があります。また、リカバリを実行する際に、使用可能なすべてのアーカイブ・ログがない場合は、アーカイブREDOログの順序番号が欠落している最初の地点まで不完全リカバリを実行する必要があります。このスキームのために特定の構成を使用する必要はありません。ただし、バックアップ処理を複数のノードに分散する最も簡単な方法は、第7章「バックアップおよびリカバリの管理」のバックアップの例に示すとおり、チャネルを構成することです。
注意: 非クラスタの場合は異なるファイル・システムが使用されるため、アーカイブ・ログ・ディレクトリは各ノードで一意である必要があります。たとえば、/arc_dest_1 はnode1 でのみ使用可能で、/arc_dest_2 はnode2 にのみ直接マウントされます。
その後、 |
ポリシー管理データベースまたは管理者管理のデータベースの初期化パラメータ・ファイルで、アーカイブ先の値を次のように、設定できます。
次の例に示すように、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-3に示すようにNFSを構成する必要があります。
表6-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ユーザーは、マップされたドライブを使用してこの例と同じ結果を得ることができます。 |
RMAN構成がOracle RAC環境で操作可能になった後、GV$ARCHIVE_PROCESSES
ビューとV$ARCHIVE_PROCESSES
ビューを使用してアーカイバ・プロセスのステータスを判断します。これらのビューには、問合せ対象がグローバル・ビューかローカル・ビューのいずれであるかに従って、すべてのデータベース・インスタンスに関する情報または接続先のインスタンスのみに関する情報がそれぞれ表示されます。
注意: kill コマンドを使用してアーカイバ・プロセスを停止した場合、そのデータベース・インスタンスは失敗します。 |
関連項目:
|