11g リリース1（11.1）
E05700-03
 目次 |
 索引 |
| Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド 11g リリース1（11.1） E05700-03 |
|
この章では、Recovery ManagerのインタフェースおよびRecovery Manager環境の基本的な構成要素について説明します。この章の内容は、次のとおりです。
Recovery Manager環境は、バックアップおよびリカバリ計画で使用される様々なアプリケーションおよびデータベースから構成されます。
表3-1に、通常のRecovery Manager環境の構成要素の一部を示します。
| 構成要素 | 説明 |
|---|---|
|
ターゲット・データベースに対するバックアップおよびリカバリ操作を管理するクライアント・アプリケーション。Recovery Managerクライアントは、Oracle Netを使用してターゲット・データベースに接続できるため、Oracle Netを介してターゲット・ホストに接続された任意のホスト上に配置できます。 |
|
|
Recovery Managerによってバックアップまたはリストアされる制御ファイル、データファイルおよびオプションのアーカイブREDOログが含まれているデータベース。Recovery Managerは、ターゲット・データベースの制御ファイルを使用して、ターゲット・データベースに関するメタデータを収集します。また、Recovery Managerの操作に関する情報は、制御ファイルに格納されます。バックアップおよびリカバリ操作は、ターゲット・データベース上で動作するサーバー・セッションによって実行されます。 |
|
|
リカバリ・カタログが含まれているデータベース。バックアップおよびリカバリを実行するためにRecovery Managerで使用されるメタデータが含まれています。複数のターゲット・データベースのRecovery Managerメタデータが含まれている1つのリカバリ・カタログを作成することができます。Recovery Managerをフィジカル・スタンバイ・データベースで使用しないかぎり、Recovery Manager使用時のリカバリ・カタログはオプションです。Recovery Managerでは、メタデータが各ターゲット・データベースの制御ファイルに格納されるためです。 |
|
|
リカバリ・カタログ・データベース内のユーザー。Recovery Managerによってメンテナンスされるメタデータ表を所有します。Recovery Managerは、定期的に、ターゲット・データベースの制御ファイルからリカバリ・カタログにメタデータを伝播します。 |
|
|
プライマリ・データベースのコピー。プライマリ・データベースによって作成されたアーカイブREDOログを使用して更新されます。フィジカル・スタンバイ・データベースには、プライマリ・データベースと同じ スタンバイ・データベースは、Recovery Managerを使用して作成、バックアップまたはリカバリできます。スタンバイ・データベースで作成したバックアップは、同じ本番データベースのプライマリ・データベースまたは別のスタンバイ・データベースでも使用できます。Data Guard環境でRecovery Managerを使用する場合は、リカバリ・カタログが必要です。 注意: Recovery Managerでは、ロジカル・スタンバイ・データベースは別のデータベースとして処理されます。プライマリ・データベースとはDBIDが異なるためです。 Data Guard環境でのRecovery Managerの使用方法については、『Oracle Data Guard概要および管理』を参照してください。 |
|
|
テスト目的で使用するプライマリ・データベースのコピー。コピー元のデータベースとはDBIDが異なります。 |
|
|
制御ファイルのコピー、オンラインREDOログのコピー、アーカイブREDOログ、フラッシュバック・ログ、Recovery Managerバックアップなどのリカバリ関連ファイルの格納のために使用可能なディスクの場所。フラッシュ・リカバリ領域内のファイルは、OracleおよびRecovery Managerによって自動的に管理されます。 |
|
|
Recovery Managerでストレージ・システム（テープなど）へのバックアップを実行するための、ベンダー固有のアプリケーション。 |
|
|
メディア管理アプリケーションについてのメタデータを格納するベンダー固有のリポジトリ。 |
|
|
Oracle Enterprise Manager |
データベースに対するブラウザベースのインタフェース。Recovery Managerによるバックアップおよびリカバリにも使用できます。 |
Recovery Manager環境に必須の構成要素は、ターゲット・データベースおよびRecovery Managerクライアントのみですが、実際の構成はより複雑です。たとえば、複数のメディア・マネージャに接続しているRecovery Managerクライアント、複数のターゲット・データベースおよび複数の補助データベースが存在し、それらがすべてEnterprise Managerを介してアクセスされる環境を構成する場合もあります。
図3-1に、Recovery Manager環境での構成要素の例を示します。この例では、プライマリ・データベース、スタンバイ・データベースおよびリカバリ・カタログ・データベースがすべて別々のコンピュータ上に配置されています。プライマリ・データベースおよびスタンバイ・データベースのホストでは、ローカル接続されたテープ・ドライブが使用されます。Recovery ManagerクライアントおよびEnterprise Managerコンソールは、別のコンピュータ上で実行されます。
Recovery Managerコマンドライン・クライアントを使用すると、バックアップおよびリカバリ操作を詳細に管理するためのコマンドを入力できます。Recovery Managerは、コマンドを対話モードまたはバッチ・モードで実行できるコマンド言語インタプリタを使用します。Recovery Managerの上位に構築されたEnterprise Managerでバックアップおよびリカバリ機能を使用している場合でも、Recovery Managerクライアントがバックグラウンドで実行されています。
Recovery Managerクライアントは、データベース・サーバー・セッションに、すべてのバックアップおよびリカバリ作業を実行するように指示します。セッションの構成は、オペレーティング・システムによって異なります。たとえば、Linuxでは、サーバー・セッションはサーバー・プロセスに対応しますが、Windowsでは、データベース・サービス内のスレッドに対応します。
Recovery Managerクライアント自体は、バックアップ、リストアまたはリカバリ操作を実行しません。Recovery Managerクライアントをターゲット・データベースに接続すると、Recovery Managerは、サーバー・セッションをターゲット・インスタンスに割り当て、操作を実行するようにサーバー・セッションに指示します。
チャネルは、デバイス・タイプに対する1つのデータ・ストリームであり、1つのデータベース・サーバー・セッションに対応します。チャネルは、データをPGAメモリーに読み取り、処理して出力デバイスに書き込みます。チャネルの基本的な動作については、「Recovery Managerのパフォーマンスのチューニングの基本的な概念」を参照してください。
大部分のRecovery Managerコマンドはチャネルによって実行されます。チャネルは、Recovery Managerセッション間にわたって保持されるように構成するか、または手動で各Recovery Managerセッションに割り当てる必要があります。図3-2に示すように、チャネルは、ターゲット・データベースまたは補助データベースのインスタンス上でサーバー・セッションを開始することによって、Recovery Managerクライアントからそれらのインスタンスへの接続を確立します。
Recovery Managerでサポートされているデバイス・タイプは、ディスクおよびSBT（テープへのシステム・バックアップ）です。SBTデバイスは、サード・パーティのメディア・マネージャによって制御されます。通常、SBTデバイスはテープ・ライブラリおよびテープ・ドライブです。
バックアップにディスク・チャネルを使用すると、チャネルによって、ディスク上の、バックアップを作成しているターゲット・データベース・インスタンスのファイル名領域にバックアップが作成されます。データファイルを格納できる任意のデバイスに、バックアップを実行できます。Recovery Managerは、ディスク・バックアップの作成時にメディア・マネージャをコールしません。
ディスク以外のメディアにバックアップを作成するには、Oracle Secure Backupなどのメディア管理ソフトウェアを使用して、このソフトウェアでサポートされるチャネルを割り当てる必要があります。Recovery Managerは、割り当てられたチャネル・タイプがディスクでない場合は常にメディア・マネージャと通信します。SBTチャネルを使用した場合にメディア・マネージャがリソースを割り当てる方法およびタイミングは、ベンダーによって異なります。コマンドが発行された時点でリソースを割り当てるメディア・マネージャや、読取り用または書込み用にファイルをオープンしてからリソースを割り当てるメディア・マネージャがあります。
CONFIGURE CHANNELコマンドを使用すると、Recovery Managerセッション間にわたってディスクまたはテープとともに使用できるようにチャネルを構成できます。この方法は、自動チャネル割当てと呼ばれます。Recovery Managerでは、ディスクへのバックアップに使用できるDISKチャネルが1つ、事前に構成されています。
自動チャネルを使用できるコマンドを実行すると、Recovery ManagerはCONFIGUREコマンドで指定されたオプションを使用して自動的にチャネルを割り当てます。BACKUPコマンドを実行すると、Recovery Managerは、指定したメディアへのバックアップに必要なチャネル・タイプのみを割り当てます。RESTOREコマンドおよびRecovery Managerのメンテナンス・コマンドを実行すると、Recovery Managerは、コマンドの実行に必要なすべてのデバイス・タイプ用のチャネルを割り当てます。自動チャネルの名前はRecovery Managerによって決定されます。
また、チャネルの手動割当てを選択することもできます。手動で割り当てられた各チャネルは、データベースに個別に接続します。手動でチャネルを割り当てる場合は、dev1、ch2などのユーザー定義の名前を指定します。
コマンドの実行時にデバイスで使用できるチャネルの数によって、コマンドの実行中にRecovery Managerがこのデバイスに対する読取りまたは書込みをパラレルに行うかどうかが決まります。パラレル化では、ファイルのバックアップが複数のチャネルで実行されます。各チャネルで複数のファイルをバックアップできますが、マルチセクション・バックアップを実行しないかぎり、ファイルは複数のチャネルでバックアップされません。
|
参照:
|
Recovery Managerリポジトリは、Recovery Managerがバックアップ、リカバリおよびメンテナンスに使用する、ターゲット・データベースに関するメタデータのコレクションです。Recovery Managerは常にそのメタデータを制御ファイルに格納します。制御ファイル内のこのメタデータは、データベースのRecovery Managerバックアップに関する正式なレコードです。このため、制御ファイルの保護は、バックアップ計画において重要です。Recovery Managerは、Recovery Managerリポジトリ情報を格納した制御ファイルのみを使用して、必要なすべてのバックアップおよびリカバリ操作を実行することができ、構成された保存方針を満たすために必要なすべてのレコードをメンテナンスします。
また、リカバリ・カタログも作成できます。リカバリ・カタログは、Oracle Databaseスキーマに格納されるRecovery Managerメタデータのリポジトリです。制御ファイルにバックアップ・アクティビティを記録する場合は領域に制限がありますが、リカバリ・カタログにはより長期の履歴を格納できます。すべてのデータベースのRecovery Managerメタデータが含まれているリカバリ・カタログを1つ作成することによって、バックアップおよびリカバリを簡単に管理できます。
リカバリ・カタログの所有者は、他のデータベース・ユーザーに対してカタログへの制限つきアクセス権の付与および取消しを行うことができます。制限付きユーザーは、それぞれ仮想プライベート・カタログと呼ばれる独自のメタデータへの完全な読取り/書込み権限を持っています。データベースに1つ以上の仮想プライベート・カタログが存在する場合、そのデータベースには1セットのカタログ表が含まれています。これらの表は、ベース・リカバリ・カタログの所有者によって所有されています。ベース・リカバリ・カタログの所有者は、各仮想プライベート・カタログ・ユーザーがアクセスできるデータベースを制御します。
一部のRecovery Manager機能は、リカバリ・カタログを使用している場合にのみ機能します。たとえば、リカバリ・カタログにストアド・スクリプトを作成し、このスクリプトでRecovery Managerジョブを実行できます。それ以外のRecovery Managerコマンドが、特にリカバリ・カタログの管理に関連している場合もあります。これらのコマンドは、Recovery Managerがリカバリ・カタログに接続されていない場合は使用できません（また、使用する必要はありません）。
リカバリ・カタログは、Recovery Managerによってのみメンテナンスされます。ターゲット・データベース・インスタンスがカタログに直接アクセスすることはありません。Recovery Managerは、リポジトリを更新するなんらかの操作が終了した後、および特定の操作が行われる前に、データベース構造についての情報、アーカイブREDOログ、バックアップ・セット、およびデータファイルのコピーを、ターゲット・データベースの制御ファイルからリカバリ・カタログに伝播します。
オラクル社提供のメディア管理レイヤー（MML）APIを使用すると、サード・パーティ・ベンダーはメディア・マネージャを構築できます。メディア・マネージャとは、Recovery Managerとともにベンダーのハードウェアで動作し、シーケンシャル・メディア・デバイス（テープ・ドライブなど）へのバックアップを可能にするソフトウェアです。メディア・マネージャは、テープなどのシーケンシャル・メディアのロード、アンロードおよびラベル付けを処理します。シーケンシャル・メディア・デバイスでRecovery Managerを使用するには、メディア・マネージャ・ソフトウェアをインストールする必要があります。
バックアップまたはリストア時、Recovery Managerクライアントは、ターゲット・データベース・インスタンスに接続して、メディア・マネージャに要求を送信するようにインスタンスに指示します。Recovery Managerクライアントとメディア・マネージャが直接通信することはありません。
メディア・マネージャにバックアップまたはリストアを実行する前に、メディア・マネージャとの通信を処理する1つ以上のチャネルを割り当てておく必要があります。メディア・マネージャで使用するデフォルトのチャネルも構成できます。このチャネルは、チャネルを明示的に割り当てていないメディア・マネージャを使用するすべてのバックアップおよびリカバリ作業で使用されます。
Recovery Managerは、テープのロード、ラベル付けまたはアンロードを行う固有のコマンドを発行しません。バックアップ時、Recovery Managerは、メディア・マネージャにバイト・ストリームを渡し、そのストリームに一意の名前を関連付けます。バックアップをリストアする必要がある場合、Recovery Managerは、メディア・マネージャにバイト・ストリームの取得を要求します。ストリームの格納方法および格納場所の詳細は、メディア・マネージャによって管理されます。たとえば、メディア・マネージャは、テープおよび各テープ上のファイルの名前をラベル付けして管理し、テープを自動的にロードおよびアンロードしたり、テープをロードおよびアンロードするようにオペレータに通知します。
メディア・マネージャの中には、プロキシ・コピー機能をサポートしているものがあります。この機能を使用すると、メディア・マネージャが、データファイルとバックアップ・デバイス間のデータの移動全体を処理します。このような製品では、ストレージ・サブシステムとメディア・サブシステム間で高速接続などの技術を使用して、プライマリ・データベース・サーバーの負荷を軽減している場合があります。Recovery Managerは、バックアップまたはリストアが必要なファイルのリストをメディア・マネージャに提供し、メディア・マネージャは、データを移動する方法およびタイミングに関するすべての決定を行います。
Oracle Secure Backupは、ファイル・システムをテープにバックアップすることによって信頼性の高い安全なデータ保護を提供するメディア・マネージャです。SAN、ギガビット・イーサネットおよびSCSI環境のすべての主要なテープ・ドライブおよびライブラリがサポートされています。
Oracle Secure Backupは、データベースのバックアップおよびリカバリのアルゴリズムに関する専用の機能は備えていませんが、SBTインタフェースを介してRecovery Managerのメディア管理レイヤーとして機能できます。この機能で、Oracle Secure Backupは、サポートされている他のサード・パーティのSBTライブラリと同じサービスをRecovery Managerに提供します。ただし、Oracle Secure Backupは、他のメディア・マネージャにはない機能も備えています。
Oracle Partner Programの一部であるOracle Backup Solutions Program（BSP）には、オラクル社のMML仕様に準拠した製品を生産している、メディア・マネージャのベンダーが参加しています。ベンダーのメディア管理製品を、ご使用のプラットフォームで使用できる場合があります。詳細は、Oracleサポート・サービスに連絡して使用可能な製品のリストを入手するか、または各ベンダーに連絡してBSPへの参加を確認してください。あるいは、次に示すBackup Solutions ProgramのWebサイトにアクセスしてください。
http://www.oracle.com/technology/deploy/availability
オラクル社は、Recovery Managerとの互換性に関してメディア・マネージャ・ベンダーを認証しているわけではありません。可用性、バージョンの互換性および機能については、オラクル社ではなく、メディア・マネージャ・ベンダーに問い合せてください。
バックアップおよびリカバリ関連の様々なファイルを作成するコンポーネントは、互いを認識しません。また、それぞれのデータが格納されるファイル・システムのサイズも認識しません。ディスクベースの自動バックアップおよびリカバリでは、フラッシュ・リカバリ領域（単にリカバリ領域とも呼ばれる）を作成できます。バックアップ関連のファイルは、フラッシュ・リカバリ領域によって自動的に管理されます。
フラッシュ・リカバリ領域を使用すると、バックアップ関連のファイル用のディスク領域の管理および異なるタイプのファイル間での領域使用の均衡化を手動で行う必要性が最小限に抑えられます。このような点から、フラッシュ・リカバリ領域を使用すると、データベースの継続的な管理が簡単になります。リカバリ領域を有効にしてバックアップ管理を簡単にすることをお薦めします。
リカバリ領域の作成時には、ディスク上の場所および記憶領域の上限を選択します。また、バックアップ・ファイルがリカバリに必要となる期間を制御するバックアップの保存方針も設定します。データベースは、この領域内で、データベースのバックアップ、アーカイブREDOログおよびその他のリカバリ関連ファイルに使用されるストレージを管理します。不要になったファイルは、Recovery Managerが新しいファイル用の領域を要求したときに削除されます。
Data Guard環境でRecovery Managerを使用する場合は、リカバリ・カタログが必要です。リカバリ・カタログには、すべてのプライマリ・データベースおよびスタンバイ・データベースのメタデータを格納できます。
Data Guard環境のデータベースは、初期化パラメータ・ファイルのDB_UNIQUE_NAMEパラメータで一意に識別されます。Data Guard環境でRecovery Managerを正常に動作させるには、同じDBIDを持つすべてのデータベース間でDB_UNIQUE_NAMEが一意である必要があります。
バックアップおよびリカバリでのRecovery Managerの継続的な使用を簡単にするには、プライマリ・データベースおよびフィジカル・スタンバイ・データベースのそれぞれに多くの永続構成を設定します。これらの設定によって、Recovery Managerの動作の様々な点が制御されます。たとえば、バックアップの保存方針、テープまたはディスクへのバックアップのデフォルトの格納先、デフォルトのバックアップ・デバイス・タイプなどを構成できます。
FOR DB_UNIQUE_NAME句を指定してCONFIGUREコマンドを使用すると、TARGETとしてスタンバイ・データベースまたはプライマリ・データベースに接続せずに、Data Guard環境でデータベースの永続構成を作成できます。たとえば、Recovery Managerをリカバリ・カタログに接続し、SET DBIDコマンドを実行してから、データベース作成時にRecovery Managerの構成が適用されるように、フィジカル・スタンバイ・データベースを作成する前にその構成を作成できます。
Recovery Managerは、TARGETとしてデータベースに接続されている場合、リカバリ・カタログの再同期化中にデータベースの制御ファイルを更新します。ただし、データベースにTARGETとして接続されていない場合、このデータベースに対してFOR DB_UNIQUE_NAMEを使用すると、Recovery Managerはリカバリ・カタログ内の構成のみを変更します。
Recovery Managerは、リカバリ・カタログを使用して、Data Guard環境内のすべてのデータベース・ファイルのファイル名を追跡します。また、カタログには、オンラインREDOログ・ファイル、スタンバイREDOログ・ファイル、一時ファイル、アーカイブREDOログ・ファイル、バックアップ・セットおよびイメージ・コピーが作成される場所も記録されます。
Recovery Managerコマンドは、リカバリ・カタログのメタデータを使用して、Data Guard環境内の異なる物理データベース間で透過的に動作します。たとえば、表領域をフィジカル・スタンバイ・データベースにバックアップして、プライマリ・データベースにリストアおよびリカバリすることができます。また、表領域をプライマリ・データベースにバックアップして、フィジカル・スタンバイ・データベースにリストアおよびリカバリすることもできます。
スタンバイ制御ファイルのバックアップと非スタンバイ制御ファイルのバックアップには互換性があります。たとえば、スタンバイ制御ファイルをプライマリ・データベースにリストアし、プライマリ制御ファイルをフィジカル・スタンバイ・データベースにリストアできます。この互換性は、制御ファイルのバックアップをData Guard環境の1つのデータベースにオフロードできることを意味します。データベース・ファイルのファイル名は、データベースのリストアおよびリカバリ中にRecovery Managerによって自動的に更新されます。
リカバリ・カタログは、すべてのデータベース・ファイルまたはバックアップ・ファイルをDB_UNIQUE_NAMEに関連付けることによって、Data Guard環境内のファイルを追跡します。ファイルを作成するデータベースは、そのファイルに関連付けられます。たとえば、Recovery Managerでstandby1という一意の名前を持つデータベースをバックアップすると、standby1がこのバックアップに関連付けられます。CHANGE ... RESET DB_UNIQUE_NAMEを使用してバックアップを別のデータベースに関連付けないかぎり、バックアップは作成したデータベースに対応付けられたままです。
バックアップのアクセシビリティは、その関連付けとは異なります。Data Guard環境では、関連付けられたデータベースのみがディスク・バックアップにアクセスできるとリカバリ・カタログによってみなされますが、1つのデータベースに作成されたテープ・バックアップにはすべてのデータベースがアクセスできます。バックアップ・ファイルがいずれのデータベースにも関連付けられていない場合、リカバリ・カタログ・ビュー内のバックアップ・ファイルに関する行のSITE_KEY列にnullが表示されます。デフォルトでは、Recovery Managerは、TARGETとして接続されているデータベースにSITE_KEYがnullのファイルを関連付けます。
BACKUP、RESTORE、CROSSCHECKなどのRecovery Managerコマンドは、すべてのアクセス可能なバックアップで動作します。たとえば、RECOVER COPY操作の場合、Recovery Managerでは、データベースに関連付けられているイメージ・コピーのみがリカバリの対象とみなされます。Recovery Managerでは、ディスクおよびテープ上の増分バックアップが、イメージ・コピーのリカバリ対象とみなされます。データベース・リカバリでは、Recovery Managerによって、データベースおよびテープ上のすべてのファイルに対応付けられたディスク・バックアップのみがリストアの対象とみなされます。
バックアップのアクセシビリティの相違点を説明するために、データベースprodとstandby1が異なるホストに存在していると想定します。Recovery Managerは、prod上のデータファイル1を本番ホスト上の/prmhost/disk1/df1.dbfおよびテープにバックアップします。Recovery Managerは、standby1上のデータファイル1をスタンバイ・ホスト上の/sbyhost/disk2/df1.dbfおよびテープにバックアップします。Recovery Managerがprodデータベースに接続している場合、Recovery Managerコマンドを使用しても、スタンバイ・ホストにある/sbyhost/disk2/df1.dbfバックアップでは操作を実行できません。ただし、Recovery Managerでは、standby1で作成されたテープ・バックアップはリストアの対象とみなされます。
|
参照:
|
|
 Copyright © 2003, 2008, Oracle Corporation. All Rights Reserved. |
|