11g リリース1（11.1）
E05737-03
 目次 |
 索引 |
| Oracle Database 2日でReal Application Clustersガイド 11g リリース1（11.1） E05737-03 |
|
この章では、Oracle Real Application Clusters（Oracle RAC）データベースをバックアップおよびリカバリする方法について説明します。
この章の内容は次のとおりです。
ハードウェア障害からOracle RACデータベースを保護するには、データベース・ファイルの物理コピーが必要です。バックアップおよびリカバリ機構により保護されているファイルはデータファイル、制御ファイル、サーバー・パラメータ・ファイル（SPFILE）およびアーカイブREDOログ・ファイルを含むOracle Enterprise Managerに構築されます。これらのファイルを使用して、データベースを再構築できます。物理レベルで機能するバックアップ・メカニズムは、データファイルの予期せぬ削除やディスク・ドライブの障害などのファイル・レベルでの問題を回避します。データベースのリカバリ には、破損しているファイルのバックアップからのリストアまたはコピーおよびリストアされたファイル上でのメディア・リカバリの実行が含まれます。メディア・リカバリは、現在または指定した他の時間に更新するための、リストアされたデータファイルに対するREDOログまたは増分バックアップのアプリケーションです。
Oracle Flashback DropやOracle Flashback TableなどのOracle Databaseフラッシュバック機能によって、物理的および論理的にデータをリカバリする一連のツールが提供されます。これは、物理的および論理的に行うバックアップ操作の代替手段であり、効率的に実行でき、使いやすいツールです。フラッシュバック機能によって、データファイルをバックアップからリストアしたり、メディア・リカバリを実行することなく、データベースに対して行われた不要な変更の影響を無効にできます。
Oracle Enterprise Managerの物理バックアップおよびリカバリ機能は、Recovery Manager（RMAN）コマンドライン・クライアントに組み込まれています。Oracle Enterprise Managerでは、多くのRecovery Manager機能が使用でき、ウィザードおよび自動化された方法で、Recovery Managerベースのバックアップおよびリカバリを簡素化およびさらに自動化できます。
Oracle Enterprise Managerのガイド付きリカバリ機能は、次のようなファイルのリストアおよびリカバリの幅広いシナリオで必要になるロジックが組み込まれたリカバリ・ウィザードとして提供されています。
データベース・ファイルが破損するか、リカバリが必要な場合、Oracle Enterprise Managerでは、データベース内でリストアおよびバックアップからのリカバリが必要な部分を特定できます。たとえば、データベース・ファイルの破損などの状況を迅速に検出できます。またOracle Enterprise Managerでは、リカバリ・プロセスをガイドし、必要な情報の入力を求め、必要なリカバリ・アクションを実行します。
|
参照:
|
フラッシュ・リカバリ領域を使用すると、バックアップ関連のファイル用にディスク領域を手動で管理したり、様々なタイプのファイル間で使用する領域を均等に分散する必要性が最小限に抑えられます。バックアップ管理を簡略化するためにフラッシュ・リカバリ領域を有効にすることをお薦めします。
フラッシュ・リカバリ領域は大きく取るほど便利になります。フラッシュ・リカバリ領域は、次のファイルすべてを含めるために十分な大きさとすることをお薦めします。
Oracle RACの推奨構成は、データファイルとは異なる自動ストレージ管理（ASM）ディスク・グループをリカバリ領域として使用する構成です。あるいは、クラスタ・ファイル・システムのアーカイブ方式を使用することもできます。
場所とディスク割当て制限は、すべてのインスタンスで同一である必要があります。これを実行するには、フラッシュ・リカバリ領域を共有ASMディスクに配置することをお薦めします。また、すべてのインスタンスに対してDB_RECOVERY_FILE_DESTおよびDB_RECOVERY_FILE_DEST_SIZEパラメータを同じ値に設定する必要があります。
フラッシュ・リカバリ領域を使用するには、最初にOracle RACクラスタの各インスタンスに対して、フラッシュ・リカバリ領域を構成する必要があります。
REDOログをアーカイブすると、そのREDOログ・ファイルが上書きされる前に、別の場所に書き込まれます。この場所をアーカイブ・ログと呼びます。これらのREDOログ・ファイルのコピーによって、リカバリ用に保存および使用されるREDOデータの量が増えます。データベースではアーカイブを有効または無効のいずれかに設定できますが、有効にすることをお薦めします。
Oracle Database Configuration Assistant（DBCA）を使用してOracle RACデータベースを作成すると、各インスタンスには、共有記憶域に格納されるREDOログ・ファイルが2つ以上作成されます。クラスタ・ファイル・システムを使用する場合、これらのファイルは共有ファイル・システムのファイルになります。クラスタ・ファイル・システムを使用しない場合、これらのファイルはRAWデバイス・ファイルになります。ASMを使用する場合、これらのファイルはASMディスク・グループに格納されます。
Oracle Real Application Clustersの場合、各インスタンスに独自のREDOスレッドがあります。Oracle RACの推奨構成は、データファイルに使用するASMディスク・グループとは別のASMディスク・グループを使用したフラッシュ・リカバリ領域の構成です。あるいは、クラスタ・ファイル・システムのアーカイブ方式を使用することもできます。
「可用性」サブページが表示されます。
「リカバリ設定」ページが表示されます。
クラスタ・データベースでは、アーカイブREDOログ・ファイルが属するREDOログ・スレッドを示すために、アーカイブ・ログファイル名の書式に%t修飾子を含める必要があります。ベスト・プラクティスとしては、アーカイブ・ログ・ファイル名の書式に、%s（ログ順序番号）および%r修飾子（RESETLOGS識別子）も含める必要があります。
たとえば、ASMを使用する場合は、+DATAに設定し、各ノードでローカルにアーカイブする場合は、/u01/oradata/archに設定します。
すべてのインスタンスに対して異なるアーカイブ・ログの保存先を構成する必要がある場合は、「初期化パラメータ」ページに移動して、アーカイブ・ログの保存先を構成する必要があるインスタンスに対応するLOG_ARCHIVE_DEST_1パラメータを変更する必要があります。「インスタンス」列には、インスタンス名（docrac1など）が表示されます。そのインスタンスのアーカイブ・ログの保存先が含まれるように、「値」フィールドを変更します。
データベースを再起動するように求められたら、「はい」をクリックします。
データベースが再起動されたら、ログイン資格証明を入力するように求められます。
|
参照:
|
バックアップまたはリカバリ操作を実行する場合を除き、インスタンスが別のインスタンスのアーカイブREDOログ・ファイルにアクセスする必要はありません。複数のインスタンスにわたってバックアップ操作を実行する場合は、使用するアーカイブ・ログのネーミング・スキームが重要になります。これは、インスタンスがファイル・システム上の特定のファイル名のログに書き込む際に、このアーカイブREDOログ・ファイルへのアクセスを必要とするすべてのインスタンスからそのファイルを読み取れる必要があるためです。
また、Oracle RACデータベースに実装するバックアップとリカバリの計画は、各インスタンスのアーカイブ先を構成する方法によっても異なります。
ASMを使用してOracle RACデータベースのアーカイブREDOログ・ファイルを格納している場合、データベースで生成されるすべてのアーカイブREDOログ・ファイルへのアクセス権が各インスタンスに自動的に付与されます。共有記憶域またはRAWデバイスを使用して各ノードにアーカイブREDOログ・ファイルを格納している場合は、これらのディレクトリへのアクセス権を必要とするクラスタ・データベース内の各インスタンスにアクセス権が付与されるようオペレーティング・システムを構成する必要があります。
|
参照:
|
バックアップおよびリカバリ用の一部の構成タスクを実行したり、バックアップ・ジョブをスケジュールしてリカバリを実行したりするには、適切な資格証明を持っている必要があります。必要になる可能性がある資格証明は次のとおりです。
Recovery Managerタスクを実行またはスケジュールするには、Oracle Enterprise ManagerにSYSDBA権限を持つユーザーとしてログインするか、dbaグループのメンバーであるユーザーのホスト・オペレーティング・システムの資格証明を指定する必要があります。ホスト・オペレーティング・システム・ユーザーにRecovery Managerのコマンドライン・クライアントの実行権限があることも必要になります。
ホスト・オペレーティング・システムの資格証明を必要とするタスクでは、タスクの実行に使用されるページの最下部に「ホスト資格証明」フォームが表示されます。Oracle Enterprise Managerでは、ユーザーがリクエストまたはスケジュールしたジョブを実行するため、Recovery Managerを起動する際にこの資格証明を使用します。
「ホスト資格証明」フォームには常に、「優先資格証明として保存」というラベルの付いたオプションがあります。アクションを実行する前にこのオプションを選択すると、提示された資格証明が、その時点でログインしているOracleデータベース・ユーザー用に永続的に格納されます。そのユーザーとしてログインしてホスト資格証明が必要な操作を実行する際には、常にデフォルトでこの優先資格証明が再利用されます。
フラッシュ・リカバリ領域が構成されている場合は、バックアップの格納方法、バックアップされるデータ、およびフラッシュ・リカバリ領域から消去されるまでのバックアップの保持期間を決定する、多数の設定およびポリシーを構成できます。また、設定を構成すると、環境に対するバックアップ・パフォーマンスを最適化することもできます。
|
参照:
|
ASMを使用してデーベース・ファイルを管理する場合は、バックアップを作成するためにRecovery Managerを使用することをお薦めします。バックアップおよびリカバリ操作を実行するには、データベース権限（SYSDBA）とホスト・オペレーティング・システムの資格証明（OSDBA）の両方が必要です。
SYSDBA権限でOracle Enterprise Managerにログインすると、Recovery Managerのコマンドライン・クライアントの実行権限を持つオペレーティング・システムのユーザーなら誰でもOracle RACデータベースのバックアップを実行できます。一方、SYSDBA権限を持たないデータベース・ユーザーとしてログインすると、バックアップ操作の実行前に、OSDBAグループのメンバーであるオペレーティング・システム・ユーザーの名前とパスワードを指定する必要があります。
「クラスタ・データベース: 可用性」ページが表示されます。
参照:
Recovery Managerは、バックアップおよびリカバリのタスクを実行するためにデータベース・サーバーで実行されるプロセスであるサーバー・セッションに依存します。各サーバー・セッションは順にRecovery Managerチャネルに対応し、バックアップ・デバイスとの間で交わされるデータの1ストリームを表します。Recovery Managerではパラレル化がサポートされます。パラレル化とは、単一のバックアップ・タスクまたはファイルのリストア・タスクの作業を実行するために、複数のチャネルおよびサーバー・セッションを使用することです。
制御ファイル、SPFILEおよびデータファイルはどのインスタンスからもアクセス可能なため、これらのファイルのバックアップ操作は、割当て済のあらゆるチャネルに分散されます。アーカイブREDOログ・ファイルのバックアップでは、Oracle RACデータベースで使用されるアーカイブ方式のタイプによってRecovery Managerの実行する処理が決まります。
ローカル・アーカイブ方式を使用する場合は、各インスタンスでアーカイブREDOログ・ファイルがローカル・ディレクトリに書き込まれます。アーカイブREDOログ・ファイルへのアクセス権を持つチャネルが複数割り当てられている場合は、各アーカイブREDOログ・ファイルについて、そのアーカイブREDOログ・ファイルへのアクセス権を持つチャネルがRecovery Mangareで判別されます。続いて、チャネルからアクセス可能なアーカイブREDOログ・ファイルがRecovery Managerによってグループ化され、バックアップ・ジョブがそのチャネルを使用してスケジュールされます。
クラスタ内の各ノードで、アーカイブREDOログ・ファイルをASM、クラスタ化されたファイル・システムまたはその他のタイプの共有記憶域に書き込む場合、各インスタンスにはすべてのアーカイブREDOログ・ファイルへのアクセス権があります。この場合、アーカイブREDOログ・ファイルのバックアップは、割当て済の全チャネルに分散されます。
|
参照:
|
アーカイブ・ログのバックアップを実行するのが1つのノードのみか全ノードかに関係なく、すべてのノードのすべてのアーカイブREDOログ・ファイルを確実にバックアップします。ローカル・アーカイブ方式を使用する場合は、Recovery ManagerがすべてのアーカイブREDOログ・ファイルにアクセスできるように複数のチャネルを割り当てます。
アーカイブREDOログ・ファイルが正常にバックアップされた後にそのファイルをディスクから自動的に削除するようにRecovery Managerを構成できます。この機能を使用すると、Oracle RACデータベースで使用するディスク領域を削減し、使用可能なディスク領域が不足した場合に発生する可能性のある不要な停止を防ぐことができます。
Oracle Enterprise Managerのガイド付きリカバリ機能には、リカバリ・ウィザードがあり、リストアやリカバリの幅広い使用例で必要となるロジックが、このウィザードでカプセル化されています。Oracle Enterprise Managerを使用すると、リストアやリカバリがデータベースのどの部分に必要なのかを判断でき、破損したデータベース・ファイルがあるなどの状況もあらかじめ検出されます。Oracle Enterprise Managerを使用すると、ユーザーは必要な情報および必要なファイルのリストアおよびリカバリ・アクションの実行を求められ、リカバリ・プロセスの全体に対応できます。
Oracle RACデータベースのリカバリが実行されるノードでは、必要なデータファイルをすべてリストアできる必要があります。また、このノードでは、ディスクにあるすべての必要なアーカイブREDOログ・ファイルを読み取れるか、アーカイブREDOログ・ファイルをバックアップ・ファイルからリストアできる必要があります。
この項の内容は次のとおりです。
リカバリ中、リカバリを実行するノードからアーカイブ・ログ・ファイルの保存先が表示されるかぎり、リカバリ中にアーカイブREDOログへ正常にアクセスできます。
共有記憶域またはクラスタ・ファイル・システムを使用せずにクラスタ・データベースにアーカイブREDOログ・ファイルを格納する場合、リカバリを実行しているノードがアーカイブREDOログ・ファイルを使用できるようにする必要があります。
Oracle RACでの障害インスタンスのリカバリは、自動的に行われます。Oracle RACデータベース・インスタンスで障害が発生した場合、障害が発生していないデータベース・インスタンスが、障害インスタンスによって生成されたオンラインREDOログを処理し、データベースの内容が一貫性のある状態であることを保証します。リカバリが完了すると、Oracle Clusterwareは障害インスタンスの再起動を自動的に試行します。
メディア・リカバリは、データベースのクローズ時に手動で実施するプロセスです。ヘッドの不調などのディスクの物理的な問題により、データベースの実行に必要なディスク・ファイルの読取りまたは書込み操作が失敗することをメディア障害と呼びます。どのようなデータベース・ファイルもメディア障害の対象になる可能性があります。メディア障害が発生した場合、メディア・リカバリを実行して、破損したデータベース・ファイルのリストアとリカバリを行う必要があります。メディア・リカバリは常に、クラスタ内の1つのインスタンスで実行します。
メディア・リカバリを開始する前に、リカバリを実行するインスタンスをMOUNTモードで起動する必要があります。その他のインスタンスは必ずNOMOUNTモードで起動します。
|
参照:
|
この項では、インスタンス・リカバリとメディア・リカバリの両方について説明します。この項には次のトピックが含まれています。
Oracle Enterprise ManagerおよびRecovery Managerを使用している場合、Oracle RACデータベースのリカバリとリストアのプロセスは、基本的には単一インスタンスのOracleデータベースの場合と同様です。ただし、「可用性」ページからRecovery Managerに対し、インスタンス・レベルではなくクラスタ・データベース・レベルでアクセスする点が異なります。
「クラスタ・データベース: 可用性」ページが表示されます。
参照:
Oracle Enterprise Managerを使用して、損失または破損したサーバー・パラメータ・ファイル（SPFILE）をリカバリできます。
MOUNTで起動します。
「クラスタ・データベース: 可用性」ページが表示されます。
データベースがオープンされていない場合は、「リカバリの実行」リンクで、SPFILEのリストア・ページに移動します。
参照:
リストア操作中には、使用可能なデータベースの最新のバックアップがRecovery Managerによって自動的に検出されます。特定のノードに接続されているチャネルでは、そのノードにのみバックアップされたファイルのリストアが試行されます。たとえば、順序番号1001のアーカイブREDOログ・ファイルがノードdocrac1に接続されているデバイスにバックアップされ、順序番号1002のアーカイブREDOログ・ファイルがノードdocrac2に接続されているデバイスにバックアップされているとします。リストア操作用に、ノードdocrac1に接続するチャネルとノードdocrac2に接続するチャネルを割り当てると、docrac1に接続されているチャネルでは順序番号1001のログはリストアされますが、順序番号1002のログはリストアされません。docrac2に接続されているチャネルでは順序番号1002のログはリストアできますが、順序番号1001のログはリストアできません。
アーカイブREDOログ・ファイルの格納にASMまたはクラスタ化ファイル・システムを使用すると、そのアーカイブREDOログ・ファイルはすべてのインスタンスでリストアできます。
|
参照:
|
Oracle RACでは、インスタンス障害およびメディア・リカバリの最適な並列度が自動的に選択されます。
Oracle Enterprise ManagerおよびRecovery Managerを使用してリカバリを実行すると、Oracle RACでは、次に示す3段階のリカバリが自動的にパラレル化されます。
参照:
Recovery Managerバックアップ・ファイルの管理（Oracle Enterprise Managerの使用は任意）は、次の2つのタスクで構成されています。
Oracle Enterprise Managerでは、両方のバックアップ・ファイルの管理タスクが簡素化されます。他のタスクには、バックアップ・ファイルの管理に次の項目が含まれるものもあります。
バックアップ・レポートには、Recovery Managerによって実行された過去のバックアップ・ジョブに関するサマリーおよび詳細情報が記録されています。詳細情報には、Oracle Enterprise ManagerとRecovery Managerコマンドライン・クライアントで実行されたバックアップ・ジョブが含まれます。
「可用性」ページが表示されます。
「バックアップ・レポートの表示」ページに最近のバックアップ・ジョブのリストが表示されます。
このページの「検索」セクションを使用すると、バックアップの時刻、バックアップされたデータのタイプ、およびジョブのステータス（成功か失敗か、ジョブの実行中に警告が生成されたかどうか）により、リストされたバックアップを絞り込むことができます。
選択したバックアップ・ジョブの「バックアップ・レポート」ページが表示されます。このページには、バックアップされたファイルの数（タイプ別）、バックアップされたデータの合計サイズ、および作成されたバックアップ・ファイルの数、サイズ、タイプなど、このバックアップ・ジョブに関するサマリー情報が含まれています。
「バックアップ・レポート」ページには「検索」セクションもあり、このセクションを使用して他のバックアップ・ジョブまたは特定の日付範囲にあるバックアップ・ジョブをすばやく検索できます。結果として出力されるレポートには、検索基準に一致するバックアップ・ジョブの集計情報が含まれています。
|
参照:
|
Oracle By Example（OBE）には、Oracle RACデータベースの一連のチュートリアルが含まれています。OBEでは、注釈付きのスクリーンショットを使用して、この章で説明した基本的な管理タスクを学習できます。
データベースのバックアップおよびリカバリの実行に関するOBEのチュートリアルを表示するには、次のURLに移動します。
http://www.oracle.com/technology/obe/10gr2_db_vmware/ha/rman/rman.htm
|
 Copyright © 2006, 2008 Oracle Corporation. All Rights Reserved. |
|