| Oracle Real Application Clusters管理およびデプロイメント・ガイド 11gリリース1（11.1） E05738-05 |
|
 戻る |
 次へ |
この章では、インスタンス・リカバリおよびRecovery Manager（RMAN）を使用したOracle Real Application Clusters（Oracle RAC）データベースのバックアップおよびリストアの方法について説明します。また、Oracle RACインスタンス・リカバリ、パラレル・バックアップ、SQL*Plusを使用したリカバリ、およびOracle RACでのフラッシュ・リカバリ領域の使用についても説明します。内容は次のとおりです。
|
注意: Oracle RAC環境でのリストアおよびリカバリでは、リカバリを実行するインスタンスを、すべてのデータ・ファイルをリストアする唯一のインスタンスとしても構成する必要はありません。Oracle RACでは、クラスタのすべてのノードからデータ・ファイルにアクセスできるため、すべてのノードでアーカイブREDOログ・ファイルをリストアできます。 |
|
関連項目: Oracle Cluster Registry（OCR）などのOracle Clusterwareコンポーネントおよび投票ディスクのバックアップおよびリストアについては、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
非クラスタ・ファイル・システム環境の場合、各ノードでバックアップできるのは、ノード固有のローカル・アーカイブREDOログ・ファイルのみです。たとえば、リモート・アクセスに対応するようにネットワーク・ファイル・システムを構成しないかぎり、ノード1は、ノード2またはノード3のアーカイブREDOログ・ファイルへはアクセスできません。バックアップに対応するようにネットワーク・ファイル・システム・ファイルを構成した場合、各ノードはアーカイブREDOログをローカル・ディレクトリにバックアップします。
この項では、次の一般的なRecovery Managerのリストア機能の使用例について説明します。
Oracle Enterprise ManagerまたはEnterprise Managerを使用したサーバー・パラメータ・ファイル（SPFILE）のリストア
|
注意: クラスタ・ファイル・システムのスキームでのリストアおよびリカバリの手順は、シングル・インスタンスのOracleの場合とほぼ同じです。 |
この項で説明するスキームでは、「自動ストレージ管理およびクラスタ・ファイル・システムのアーカイブ・スキーム」が使用されていると仮定します。このスキームでは、ノード3がCFSへバックアップを実行したとします。リストアおよびリカバリ操作にノード3が使用可能で、すべてのアーカイブ・ログがバックアップ済か、ディスク上にある場合は、次のコマンドを実行して完全リカバリを実行します。
RESTORE DATABASE; RECOVER DATABASE;
バックアップを実行したノード3が使用できない場合は、残りのノードの1つに対してメディア管理デバイスを構成し、このノードでノード3のバックアップ・メディアを使用可能にします。
この項で説明するスキームでは、「非クラスタ・ファイル・システムのローカル・アーカイブ・スキーム」が使用されていると仮定します。このスキームでは、各ノードが異なるディレクトリにローカルでアーカイブします。たとえば、ノード1は/arc_dest_1に、ノード2は/arc_dest_2に、ノード3は/arc_dest_3にアーカイブします。リカバリ・ノードが残りのノードでアーカイブ・ディレクトリを読み取ることができるように、ネットワーク・ファイル・システム・ファイルを構成する必要があります。
すべてのノードが使用可能で、すべてのアーカイブREDOログがバックアップされている場合は、データベースをマウントして任意のノードで次のコマンドを実行することで、完全なリストアおよびリカバリを実行できます。
RESTORE DATABASE; RECOVER DATABASE;
ネットワーク・ファイル・システム構成では、各ノードにその他のノードに対する読取りアクセス権があるため、リカバリ・ノードは、ローカルおよびリモート・ディスクにあるアーカイブREDOログの読取りおよび適用が可能です。手動によるアーカイブREDOログの転送は不要です。
Recovery Managerでは、サーバー・パラメータ・ファイルをデフォルト位置または指定された位置にリストアできます。
Oracle Enterprise Managerを使用して、SPFILEをリストアすることもできます。「メンテナンス」タブの「バックアップ/リカバリ」セクションで、「リカバリの実行」をクリックします。「リカバリの実行」リンクは状況依存のリンクであり、データベースがクローズしている場合にのみ、SPFILEのリストアにナビゲートされます。
インスタンス障害は、ソフトウェアまたはハードウェアの問題によってインスタンスが無効になった場合に発生します。インスタンス障害の後、Oracle DatabaseはオンラインREDOログ・ファイルを使用して、次の各項で説明するデータベース・リカバリを自動的に実行します。
Oracle RACでのインスタンス・リカバリでは、障害が発生したインスタンス上で実行していたアプリケーションのリカバリは実行されません。Oracle Clusterwareがインスタンスを自動的に再起動します。Oracle Technology Network（OTN）の例のように、コールアウト・プログラムを使用して、アプリケーションのリカバリをトリガーすることもできます。
実行中のアプリケーションは、障害の認識とリカバリの機能を使用して実行を継続します。これによって、ハードウェアまたはソフトウェア障害が発生しても、一貫性のある連続的なサービスが提供されます。あるインスタンスが別のインスタンスのリカバリを実行する場合、障害が発生しなかったインスタンスは、障害が発生しているインスタンスによって生成されたオンラインREDOログ・エントリを読み取り、その情報を使用して、コミットされたすべてのトランザクションがデータベースに記録されるようにします。 したがって、コミットされたトランザクションのデータが失われることはありません。 リカバリを実行中のインスタンスは、障害発生時にアクティブだったトランザクションをロールバックし、それらのトランザクションによって使用されたリソースを解放します。
|
注意: すべてのオンラインREDOログは、インスタンスのリカバリのためにアクセスできる必要があります。オンラインREDOログをミラー化することをお薦めします。 |
複数ノード障害が発生した場合は、障害を受けなかったインスタンスが1つでもあるかぎり、Oracle RACは、障害が発生したすべてのインスタンスに対してインスタンス・リカバリを実行します。 Oracle RACデータベースのすべてのインスタンスに障害が発生した場合、Oracle Databaseは、次のインスタンスがデータベースをオープンするときにリカバリを自動的に実行します。リカバリを実行するインスタンスは、Oracle RACデータベースのどのノードからでも、クラスタ・データベースまたは排他モードでデータベースをマウントできます。このリカバリ手順は、1つのインスタンスが、障害が発生したすべてのインスタンスのリカバリを実行するという点以外は、共有モードで実行しているOracle Databaseでも、排他モードで実行しているOracle Databaseでも同じです。
Oracle Databaseには、データベースのバックアップおよびリストアを行うRecovery Managerがあります。Recovery Managerを使用すると、データ・ファイル、制御ファイル、SPFILEおよびアーカイブREDOログのバックアップ、リストアおよびリカバリを実行できます。Recovery ManagerはOracle Databaseサーバーに含まれているため、デフォルトでインストールされます。Recovery Managerは、コマンドラインから実行するか、またはEnterprise ManagerのBackup Managerから使用できます。また、自動ストレージ管理（ASM）を使用している場合、バックアップおよびリカバリ・ツールとしてRecovery Managerを使用することをお薦めします。
Oracle RAC環境でRecovery Managerを使用する手順は、シングル・インスタンスのOracle環境の場合とほぼ同じです。シングル・インスタンスのRecovery Managerのバックアップ手順の詳細は、バックアップおよびリカバリに関するOracleのマニュアル・セットを参照してください。
インスタンスへのチャネル接続は、チャネル構成で定義された接続文字列を使用して判別されます。たとえば、次の構成では、user1/pwd1@service_nameを使用して3つのチャネルが割り当てられています。ロード・バランシングが有効の状態でSQL Netサービス名を構成した場合、ロード・バランシング・アルゴリズムによって決定されたノードにチャネルが割り当てられます。
CONFIGURE DEVICE TYPE sbt PARALLELISM 3;
CONFIGURE DEFAULT DEVICE TYPE TO sbt;
CONFIGURE CHANNEL DEVICE TYPE SBT CONNECT 'user1/pwd1@service_name'
ただし、接続文字列で使用されるサービス名がロード・バランシング用ではない場合、次のようにチャネル構成ごとに個別の接続文字列を使用して、どのインスタンスにチャネルを割り当てるかを制御できます。
CONFIGURE DEVICE TYPE sbt PARALLELISM 3; CONFIGURE CHANNEL 1.. CONNECT 'user1/pwd1@node1'; CONFIGURE CHANNEL 2.. CONNECT 'user2/pwd2@node2'; CONFIGURE CHANNEL 3.. CONNECT 'user3/pwd3@node3';
前述の例では、Oracle RAC環境の定義済ノードに接続するSQL Netサービス名は、node1、node2およびnode3であると仮定しています。また、手動で割り当てたチャネルを使用してデータベース・ファイルをバックアップすることもできます。たとえば、次のコマンドを実行すると、SPFILE、制御ファイル、データ・ファイルおよびアーカイブREDOログがバックアップされます。
RUN
{
ALLOCATE CHANNEL CH1 CONNECT 'user1/pwd1@node1';
ALLOCATE CHANNEL CH2 CONNECT 'user2/pwd2@node2';
ALLOCATE CHANNEL CH3 CONNECT 'user3/pwd3@node3';
BACKUP DATABASE PLUS ARCHIVED LOG;
}
少なくとも1つの割り当てられたチャネルからアーカイブ・ログにアクセス可能であるかぎり、バックアップ操作中、Recovery Managerはそのチャネル上の特定のログのバックアップを自動的にスケジュールします。制御ファイル、SPFILEおよびデータ・ファイルはどのチャネルからでもアクセス可能であるため、これらのファイルのバックアップ操作は、割り当てられたチャネル間で分散されます。
ローカル・アーカイブ・スキームの場合、ローカル・アーカイブ・ログに記録するすべてのノードに1つ以上のチャネルが割り当てられている必要があります。CFSアーカイブ・スキームの場合、すべてのノードが同じCFSのアーカイブ・ログに記録すると仮定して、アーカイブ・ログのバックアップ操作は、割り当てられたチャネル間で分散されます。
バックアップの実行中は、チャネルの接続先インスタンスは、すべてマウントされているか、すべてオープン状態である必要があります。たとえば、ノード2とノード3のインスタンスにはオープン状態のデータベースがあるが、ノード1のインスタンスにマウントされたデータベースがある場合は、バックアップに失敗します。
一部のクラスタ・データベース構成では、クラスタの一部のノードは、他のデータ・ファイルに対するアクセスよりも高速に特定のデータ・ファイルにアクセスします。Recovery Managerは、これを自動的に検出します。これは、ノード・アフィニティの認識と呼ばれています。特定のデータ・ファイルのバックアップに使用するチャネルを決定する場合、Recovery Managerは、バックアップするデータ・ファイルに対して高速にアクセスするノードを優先します。たとえば、3ノードのクラスタがあり、ノード1はデータ・ファイル7、8および9に対して他のノードよりも高速に読取り/書込みアクセスを行う場合、ノード1は、ノード2および3に比べて、これらのファイルに対するノード・アフィニティが高いと言えます。
|
関連項目: CONFIGURE CHANNEL文のCONNECT句の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。 |
「クラスタ・インスタンスへのチャネル接続」の説明に従って自動チャネルを構成したと仮定した場合、次の例を使用してn回バックアップしたアーカイブ・ログを削除できます。デバイス・タイプは、DISKまたはSBTになります。
DELETE ARCHIVELOG ALL BACKED UP n TIMES TO DEVICE TYPE device_type;
少なくとも1つの割り当てられたチャネルからアーカイブ・ログにアクセス可能であるかぎり、削除操作中、Recovery Managerはそのチャネル上の特定のログの削除を自動的にスケジュールします。ローカル・アーカイブ・スキームの場合、アーカイブ・ログを削除できる1つ以上のチャネルが割り当てられている必要があります。CFSアーカイブ・スキームの場合、すべてのノードが同じCFSのアーカイブ・ログに記録すると仮定して、割り当てられた任意のチャネルからアーカイブ・ログを削除できます。
自動チャネルを構成していない場合、次のようにメンテナンス・チャネルを手動で割り当てて、アーカイブ・ログを削除できます。
ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE DISK CONNECT 'SYS/oracle@node1'; ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE DISK CONNECT 'SYS/oracle@node2'; ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE DISK CONNECT 'SYS/oracle@node3'; DELETE ARCHIVELOG ALL BACKED UP n TIMES TO DEVICE TYPE device_type;
Recovery Managerは、バックアップまたはリストアが必要なすべてのファイルのオートロケーションを自動的に実行します。非クラスタ・ファイル・システムのローカル・アーカイブ・スキームを使用している場合、各ノードが読み取ることができるのは、そのノードのインスタンスによって生成されたアーカイブREDOログのみです。Recovery Managerは、アーカイブREDOログを読み取れない場合、チャネルでのログのバックアップを試行しません。
リストアの操作時に、Recovery Managerはバックアップのオートロケーションを自動的に実行します。ノードにバックアップされたファイルのリストアが試行されるのは、特定のノードに接続されているチャネルのみです。たとえば、ログ順序番号1001はノード1に連結されているドライブにバックアップされ、ログ1002はノード2に連結されているドライブにバックアップされるとします。各ノードに接続するチャネルを割り当てる場合、ノード1に接続されたチャネルは（ログ1002ではなく）ログ1001をリストアでき、ノード2に接続されたチャネルは（ログ1001ではなく）ログ1002をリストアできます。
メディア・リカバリは、クライアント・アプリケーションを介してユーザーが起動する必要があります。一方、インスタンス・リカバリは、データベースによって自動的に実行されます。 この場合は、Recovery Managerを使用してデータ・ファイルのバックアップをリストアしてから、データベースをリカバリします。Oracle RAC環境でのRecovery Managerのメディア・リカバリ手順は、シングル・インスタンス環境のRecovery Managerのメディア・リカバリ手順とほぼ同じです。
リカバリを実行するノードは、必要なデータ・ファイルをすべてリストアできることが必要です。また、このノードは、ディスク上の必要なアーカイブREDOログをすべて読み取ることができるか、バックアップしたデータ・ファイルをリストアできることが必要です。
暗号化された表領域を使用してデータベースをリカバリする場合（SHUTDOWN ABORTまたはデータベース・インスタンスをダウンさせた重大なエラーの発生後など）、リカバリ・プロセスでデータ・ブロックおよびREDOを復号できるように、データベースのマウント後、データベースを開く前にOracleウォレットを開く必要があります。
Oracle Databaseでは、インスタンス・リカバリ、クラッシュ・リカバリ、メディア・リカバリの最適な並列度は自動的に選択されます。CPUの可用性に基づいたパラレル・プロセスの最適な数を使用して、アーカイブREDOログが適用されます。次の項目で説明するように、Oracle RACデータベースでは、パラレル・インスタンス・リカバリおよびパラレル・メディア・リカバリを使用できます。
|
関連項目: 詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
Recovery ManagerのRESTOREおよびRECOVERコマンドを使用すると、次に示す3段階のリカバリ・プロセスが自動的にパラレル化されます。
データ・ファイルのリストア データ・ファイルをリストアする場合、Recovery Managerのリカバリ・スクリプトに割り当てられているチャネル数によって、Recovery Managerが使用するパラレル化が効果的に設定されます。たとえば、5つのチャネルを割り当てると、最大5つのパラレル・ストリームでデータ・ファイルをリストアできます。
増分バックアップの適用 同様に、増分バックアップを適用する場合、割り当てるチャネル数によって潜在的なパラレル化が決定されます。
アーカイブREDOログの適用 Recovery Managerでは、アーカイブREDOログの適用は、パラレルに実行されます。Oracle Databaseでは、使用可能なCPUリソースに基づいて最適な並列度が自動的に選択されます。
Oracle RACでフラッシュ・リカバリ領域を使用するには、この領域を、ASMディスク・グループ、クラスタ・ファイル・システムまたは共有ディレクトリのいずれかに配置する必要があります。共有ディレクトリとは、ネットワーク・ファイル・システム・ファイルによって各Oracle RACインスタンスに対して構成されたディレクトリです。つまり、フラッシュ・リカバリ領域は、Oracle RACデータベースのすべてのインスタンスで共有される必要があります。また、すべてのインスタンスに対してDB_RECOVERY_FILE_DESTパラメータを同じ値に設定します。
Oracle Enterprise Managerを使用すると、フラッシュ・リカバリ領域を設定できます。この機能を使用するには、次の手順を実行します。
クラスタ・データベースの「ホーム」ページで、「メンテナンス」タブをクリックします。
「バックアップ/リカバリ」オプション・リストから、「リカバリ設定の構成」をクリックします。
ページの「フラッシュ・リカバリ領域」セクションで、要件を指定します。
詳細は、このページの「ヘルプ」をクリックしてください。
