1. 管理者ガイド
  2. リカバリ・アプライアンスのアーキテクチャ

2 リカバリ・アプライアンスのアーキテクチャ

この章では、一般的にリカバリ・アプライアンスと呼ばれるZero Data Loss Recovery Applianceの基本的なアーキテクチャと概念について説明します。

この章の内容は次のとおりです。

リカバリ・アプライアンス環境

最小のリカバリ・アプライアンス環境は、リカバリ・アプライアンスと1つの保護データベースで構成されます。図2-1に示すサンプル環境は典型的なものです。

図2-1 サンプル・リカバリ・アプライアンス環境

図2-1の説明が続きます
「図2-1 サンプル・リカバリ・アプライアンス環境」の説明

この項には次のトピックが含まれます:

リカバリ・アプライアンス環境の主要コンポーネント

図2-1に示す典型的なリカバリ・アプライアンス環境の例には、次のコンポーネントが含まれています。

  • 複数の保護データベース

    各保護データベースは、バックアップおよびリアルタイムREDOをリカバリ・アプライアンスに送信します。保護データベースは様々なリリースのOracle Database上で稼働できます。たとえば、混在環境に、Oracle Database 10g、Oracle Database 11gおよびOracle Database 12cの保護データベースが含まれることがあります。

  • リカバリ・アプライアンス

    図2-1の中央のリカバリ・アプライアンスは、増分バックアップとリアルタイムREDOを保護データベースから受信します。リカバリ・アプライアンスには、リカバリ・アプライアンスのメタデータ・データベースが含まれています。このデータベースのコンポーネントは、次のとおりです。

    • 複数の仮想リカバリ・カタログに細分化されたRMANリカバリ・カタログ。

    • 1つ以上の記憶域の場所。リカバリ・アプライアンスの記憶域にデルタ・ストアが含まれ、ここに複数のデルタ・プールがあります。

    図2-1では、中央のリカバリ・アプライアンスが第2リカバリ・アプライアンスにバックアップをレプリケートし、さらに第2リカバリ・アプライアンスが第3リカバリ・アプライアンスにそれらのバックアップを転送しています。

  • Oracle Enterprise Manager Cloud Control (Cloud Control)

    図2-1では、環境内の独立したサーバーでCloud Controlが稼働しています。管理者はCloud Controlを使用して、リカバリ・アプライアンス環境内のすべてのリカバリ・アプライアンス、保護データベースおよびテープ・デバイスを管理できます。

  • DBMS_RA PL/SQLパッケージ

    これはリカバリ・アプライアンスへのコマンドライン・インタフェースです。このパッケージは、リカバリ・アプライアンス・メタデータ・データベースに格納され、Cloud Controlの基本的な機能を提供します。

  • Oracle Secure Backup

    図2-1では、リカバリ・アプライアンスがOracle Secure Backupを使用してバックアップをテープ・ライブラリにアーカイブしています。この図では、ダウンストリーム・リカバリ・アプライアンスも別のテープ・ライブラリにバックアップをアーカイブしています。

関連項目:

リカバリ・アプライアンス環境のユーザー・アカウント

リカバリ・アプライアンス環境の中心コンポーネントは、保護データベース、リカバリ・アプライアンスおよびCloud Controlです。表2-1に、この環境で最も重要なユーザー・アカウントをまとめています。

表2-1 リカバリ・アプライアンス環境のユーザー・アカウント

コンポーネント アカウント・タイプ ユーザー名 説明

Cloud Control

Cloud Controlスーパーユーザー

SYSMAN

このアプリケーション・アカウントはデフォルトで存在します。目的は、Cloud Controlそのものの管理です。リカバリ・アプライアンスや保護データベースの管理には直接関係ありません。

Cloud Control

Cloud Control管理者

ユーザー指定

特定の保護データベースまたは特定のリカバリ・アプライアンスの管理に必要な役割と権限を付与されたCloud Controlユーザー・アカウント。ビジネス要件によっては複数のCloud Control管理者アカウントを設定できます。

リカバリ・アプライアンス

リカバリ・アプライアンス・メタデータ・データベース・スーパーユーザー

SYS

SYSはリカバリ・アプライアンスのユーザー・アカウントを作成できます。ただし、通常はそれ以外のリカバリ・アプライアンスの管理には使用されません。

リカバリ・アプライアンス

リカバリ・アプライアンス管理者

RASYS

このデータベース・アカウントは、RMANリカバリ・カタログとDBMS_RA PL/SQLパッケージを含むリカバリ・アプライアンス・スキーマを所有します(「DBMS_RAパッケージ・リファレンス」を参照)。RASYSユーザー名は固定されており、変更できません。RASYSには、データベース・ユーザー・アカウントを作成するために必要な権限はありません。

リカバリ・アプライアンス

リカバリ・アプライアンス・ユーザー・アカウント

ユーザー指定

このアカウントには、リカバリ・アプライアンスに登録されたデータベースのバックアップを送受信し、それらのデータベースのリカバリ・カタログ・メタデータを操作する権限があります。これは、保護されたデータベースからリカバリ・アプライアンスにREDOデータを送信するために使用するアカウントでもあります。RASYSとは異なり、リカバリ・アプライアンス・ユーザー・アカウントには、リカバリ・アプライアンスにおける管理権限はありません。

通常、リカバリ・アプライアンス・メタデータ・データベースには複数のリカバリ・アプライアンス・ユーザー・アカウントが含まれます。これらのアカウントは、保護データベースへのアクセスを構成するときに作成されます(「保護されたデータベース・アクセスのためのリカバリ・アプライアンスの構成」を参照)。

すべてのリカバリ・アプライアンス・ユーザー・アカウントは仮想プライベート・カタログを所有します。カタログ所有者がアクセスして変更できるのは、アクセス権が認められているデータベースに関連するリカバリ・カタログ内の行のみです。このカタログ・ユーザー名はRMAN CONNECT CATALOGコマンドで参照されます。

保護データベース

保護データベース・バックアップ管理者

SYSBACKUP (SYSBACKUPがサポートされないリリースではSYSDBA)権限を持つユーザー・アカウント。

このアカウントには、保護データベースのバックアップ、リストアおよびリカバリを行う権限があります。これは、RMAN CONNECT TARGETコマンドで参照されるデータベース・ユーザー名です。

図2-2に、RASYSと2つのリカバリ・アプライアンス・ユーザー・アカウントの関係を示します。この例では、各リカバリ・アプライアンス・ユーザー・アカウントが個別の仮想プライベート・カタログを所有しています。リカバリ・アプライアンス・スキーマの所有者であるRASYSは、RMANリカバリ・カタログの所有者でもあることに注意してください。

図2-2 RASYSとリカバリ・アプライアンス・ユーザー・アカウント

図2-2の説明が続きます
「図2-2 RASYSとリカバリ・アプライアンス・ユーザー・アカウント」の説明

関連項目:

データベース・ユーザー・アカウントの作成方法の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

バックアップのライフサイクル: シナリオ

この項では、図2-1に示すリカバリ・アプライアンス環境でのバックアップの流れにそって、バックアップのライフサイクルを説明します。このサンプル・シナリオでは、各保護データベースは必須である最初のレベル0増分バックアップをリカバリ・アプライアンスにすでに格納しています。基本的なデータ・フローは次のとおりです。

  1. 保護データベース、またはこのデータベースを保護しているスタンバイ・データベースが、レベル1増分バックアップをRecovery Applianceに送信します。

    リカバリ・アプライアンスが他のバックアップ・ソリューションと異なる点は、データ・ファイルごとにレベル0バックアップが1つしか必要ないことです。レベル1増分バックアップは、変更時にデータ・ブロックのみがバックアップされるため最も効率的です。

    累積レベル1増分バックアップの作成をお薦めします(『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照)。各累積レベル1バックアップでは、ベースラインとして最新の仮想レベル0バックアップが使用されます。通常、この仮想レベル0バックアップは、最新のレベル1バックアップに相当します。

    注意:

    レベル1累積バックアップをRecovery Applianceに組み込めない場合(記憶域の破損などにより)、次のレベル1バックアップが同じ仮想レベル0ベースラインを持つため、Recovery Applianceは新しいレベル1増分バックアップをシームレスに組み込めます。このため、累積バックアップは、差分バックアップよりも多いオーバーヘッドを持つことはほとんどありません。

  2. リカバリ・アプライアンスが増分バックアップを受信します。

    受信したバックアップをすぐに取り出すことができますが、リカバリ・アプライアンスがまだインデックスを付けていません。したがって、対応する仮想完全バックアップはまだありません。リカバリ・アプライアンスがインデックスを付ける前に、保護データベースのリカバリにこのバックアップが必要になった場合、RMANは前の仮想完全バックアップを自動的にリストアし、この増分バックアップを適用します。

  3. リカバリ・アプライアンスが増分バックアップを処理します。

    次の操作は非同期で行われます。

    • リカバリ・アプライアンスが、バックアップ収集を実行します。リカバリ・アプライアンスは次のようにバックアップを処理します。

      • 保護データベースから送信されたバックアップをスキャンします。

      • 少数のブロックからなるグループに分割して、各データ・ファイルのブロックを個別のデルタ・プールに割り当てます

      • データベースの保護ポリシ-に応じて、グループを適切な記憶域の場所に書き込みます

      • 仮想バックアップ・セットが作成されたら、元のバックアップ・セットを削除します。

        注意:

        リカバリ・アプライアンスが、仮想バックアップの作成と同時に元のバックアップを削除できない場合があります。このため、元のバックアップと仮想バックアップの両方が、リカバリ・カタログ内で2つのコピーとして短時間同時に存在する可能性があります。

      バックアップ収集時に、リカバリ・アプライアンスはバックアップのインデックスを付けます。この処理では、各データ・ブロックの内容と物理的な場所に関する情報をメタデータ・データベースに格納します。リカバリ・アプライアンスは保護データベースのリカバリ・カタログを含むため、これで新たにインデックス付けした仮想完全バックアップをRMANが使用できるようになります(リカバリで必要となる場合)。

    • リカバリ・アプライアンス・レプリケーションが構成されている場合、リカバリ・アプライアンスはバックアップをダウンストリーム・リカバリ・アプライアンスに転送します。

      様々なレプリケーション構成が可能です。図2-1には、1対1の構成が示されています。中央のリカバリ・アプライアンスがアップストリーム・リカバリ・アプライアンス(バックアップの送信側)として、ダウンストリーム・リカバリ・アプライアンス(バックアップの受信側)として機能する別のリカバリ・アプライアンスにバックアップを転送します。図2-1には、ダウンストリーム・リカバリ・アプライアンスがバックアップを第3のリカバリ・アプライアンスに転送するカスケード・レプリケーションも示されます。

    • 自動のcopy-to-tapeポリシーが有効になっている場合、リカバリ・アプライアンスがバックアップをテープにアーカイブします。

      図2-1では、中央のリカバリ・アプライアンスがOracle Secure Backupソフトウェアを使用してテープ・デバイスと通信しています。また、レプリケーション・スキームで最もダウンストリーム側にあるリカバリ・アプライアンスもバックアップをテープにアーカイブしています。この方法には次のメリットがあります。

      • 冗長性を実現するために、同一のバックアップが2つのテープ・デバイスに存在します。図2-1では、プライマリ・リカバリ・アプライアンスと最もダウンストリーム側のリカバリ・アプライアンスがテープにアーカイブしています。

      • ダウンストリーム・リカバリ・アプライアンスがテープにバックアップすることで、アップストリーム・リカバリ・アプライアンスのテープ・アーカイブ処理の負担を軽減できます。

    • Recovery Applianceは、バックアップおよびREDOが有効であることを定期的に確認します。

      Recovery Applianceは、ディスクにあるバックアップを、インバウンド・レプリケーションとアウトバウンド・レプリケーション中に自動的に検証します。Recovery Applianceは、テープ・バックアップのクロスチェックを自動的に実行します。データ・ファイルのバックアップの場合と同じように、Recovery Applianceは、すべての操作においてREDOログ・ブロックの整合性を検証します。これには、保護されたデータベースからREDOを受信し、これを圧縮されたアーカイブ・ログのバックアップ・セットに格納する処理が含まれます。RMAN VALIDATEコマンドを手動で実行する必要はありません。

    • リカバリ・アプライアンスが、自動デルタ・プール領域管理を実行します。

      このフェーズでは、ディスクとテープ両方で不要になったバックアップや期限切れになったバックアップの削除や、デルタ・プールの最適化が行われます。

関連項目:

保護データベース

保護データベースは、集中管理されるRMANバックアップおよびリカバリの宛先として、特定のリカバリ・アプライアンスを使用します。図2-1では、集中管理されている1つのリカバリ・アプライアンスに複数の保護データベースがバックアップを送信しています。リカバリ・アプライアンスによって保護される各データベースは、リカバリ・アプライアンス・メタデータ・データベースにあるリカバリ・カタログを使用する必要があります。

保護データベースがバックアップをリカバリ・アプライアンスに送信するには、リカバリ・アプライアンスにアクセスできるように構成する必要があります。構成には、適切なリカバリ・アプライアンス・ユーザーおよび権限の作成、保護された各データベースと保護ポリシーの関連付け、および各データベースへのリカバリ・アプライアンス接続の資格証明の配布が含まれます。

この項には次のトピックが含まれます:

リカバリ・アプライアンス・バックアップ・モジュール

Zero Data Loss Recovery Applianceバックアップ・モジュール(リカバリ・アプライアンス・バックアップ・モジュール)は、RMANがバックアップ・データをネットワークを介してリカバリ・アプライアンスに転送するために使用する、Oracle提供のSBTライブラリです。SBTライブラリは、バックアップ・デバイスのタイプ(テープ・デバイスまたはリカバリ・アプライアンス)との間でデータをやりとりします。RMANは、このモジュールを使用して、リカバリ・アプライアンスへのすべてのバックアップと完全なバックアップ・セットのすべてのリストアを実行します。

リカバリ・アプライアンス・バックアップ・モジュールは次の場所にインストールする必要があります。

  • リカバリ・アプライアンスにバックアップを送信するすべての保護データベースのOracleホーム

    たとえば、1つのホストにOracle Database 11g OracleホームとOracle Database 12c Oracleホームがあるとします。各Oracleホームがそれぞれ5つの保護データベースをサポートし、このホストで合計10個のデータベースが実行しています。このケースでは、インストールする必要があるリカバリ・アプライアンスは2つのみ(各Oracleホームに1つずつ)です。

  • リカバリ・アプライアンス・レプリケーション環境の場合、ダウンストリーム・リカバリ・アプライアンスにバックアップを送信するすべてのアップストリーム・リカバリ・アプライアンス(「リカバリ・アプライアンスでのバックアップのレプリケート」を参照)

図2-3では、同一のホストでOracle Database 11gとOracle Database 12cの保護データベースが実行しています。各Oracleホームにインストールされたリカバリ・アプライアンス・バックアップ・モジュールがリカバリ・アプライアンスと通信して、バックアップをダウンストリーム・リカバリ・アプライアンスにレプリケートします。

図2-3 リカバリ・アプライアンス・バックアップ・モジュール

図2-3の説明が続きます
「図2-3 リカバリ・アプライアンス・バックアップ・モジュール」の説明

関連項目:

保護ポリシー

保護ポリシーは、プロパティのコレクションに名前を付けたもので、複数の保護データベースに割り当てることができます。複数のデータベースに1つのポリシーを使用することで、リカバリ・アプライアンスの管理時間を短縮し、1回の操作で複数の保護データベースのプロパティを変更できます。多様なバックアップとリカバリの要件を備えたデータベースに対応するために、必要な数の保護ポリシーを作成します。

リカバリ・アプライアンスのデフォルト・インストールの保護ポリシーを表2-2に示します。

表2-2 デフォルト保護ポリシー

サービス階層 リカバリ・ウィンドウ 追加設定

プラチナ

ディスクに45日間、テープに90日間脚注 1

データベース・バックアップ、リアルタイムREDOトランスポート、レプリケーションおよびテープ・バックアップ。すべての設定が必須です。

ゴールド

ディスクに35日間、テープに90日間

データベース・バックアップ、リアルタイムREDOトランスポート、レプリケーションおよびテープ・バックアップ(テープが使用可能な場合)。

シルバー

ディスクに10日間、テープに45日間

データベース・バックアップ、リアルタイムREDOトランスポートおよびテープ・バックアップ(テープが使用可能な場合)。

ブロンズ

ディスクに3日間、テープに30日間

データベース・バックアップおよびテープ・バックアップ(テープがある場合)。リアルタイムREDOトランスポートはありません。

脚注1

経過期間が45日間以下のバックアップはディスクとテープの両方に存在しますが、経過期間が45日間を超えるバックアップはテープにのみ存在します。リカバリ・アプライアンスは、ディスクのバックアップ後ただちにテープ・バックアップを作成するため、90日間のテープ保存期間は45日間のディスク保存期間と同時に開始します。

関連項目:

保護ポリシーの属性

DBMS_RA.CREATE_PROTECTION_POLICYプロシージャまたはCloud Controlを使用して作成する保護ポリシーは、割り当てられるすべての保護データベースに次の属性を設定します。

表2-3 保護ポリシーの属性

属性 説明

storage_location_name

バックアップを格納するリカバリ・アプライアンスの記憶域の場所

polling_policy_name

オプションのバックアップ・ポーリング・ポリシー。リカバリ・アプライアンスが記憶域の場所をポーリングしてバックアップを探すかどうかを決定します。

recovery_window_goal

保護データベースのディスク・リカバリ・ウィンドウ目標

recovery_window_sbt

保護データベースのSBT保存期間

guaranteed_copy

コピー保証設定。このポリシーで保護されるバックアップの削除が検討される前に、テープにコピーするかレプリケートするかを決定します。

max_retention_policy

この保存ポリシーを使用するデータベースのバックアップをリカバリ・アプライアンスが保存する最長期間

unprotected_window

現在時刻からデータベースをリストアできる最短時刻までの最長許容時間

オプションのレプリケーション・サーバー構成を保護ポリシーに関連付けることができます。レプリケーション構成は、保護ポリシーが関連付けられているすべての保護データベースに適用されます。

関連項目:

リカバリ・ウィンドウ

保護ポリシーを作成するときに、期間(通常は日数)を表す次の2つのリカバリ・ウィンドウ属性を定義できます。

  • ディスク・リカバリ・ウィンドウ目標

    ポリシーに割り当てられるデータベースごとに、リカバリ・アプライアンスは、現在の時刻からさかのぼって、この期間の任意の時点へのポイント・イン・タイム・リカバリをサポートしようとします。たとえば、リカバリ・ウィンドウ目標が15日間で、現在の日時が4月25日正午の場合、4月10日正午以降の任意の時点にポイント・イン・タイム・リカバリを実行することが目標です。4月26日正午であれば、4月11日正午以降の任意の時点にポイント・イン・タイム・リカバリを実行することが目標になります。

    ディスクの場合、この期間は目標であり、保証されるものではありません。ディスク領域が少なくなり、目標が達成できない状況が発生すると、リカバリ・アプライアンスはバックアップをパージすることがあります。各保護データベースの予約済ディスク領域プロパティを調整することによって、最低数のバックアップが確保されるようにできます。

  • SBT保存期間

    現在の日時からさかのぼって、この期間内の任意の時点へのポイント・イン・タイム・リカバリに対応できるように、割り当てられたデータベースごとのバックアップがテープに保存されます。SBTの場合、この期間は保証されます。

関連項目:

バックアップ・ポーリング・ポリシー

バックアップ・ポーリング・ポリシーの指定内容は次のとおりです。

  • リカバリ・アプライアンスが処理するバックアップを探すためにポーリングする、共有記憶域上のファイル・システム・ディレクトリ(「バックアップ・ポーリングの場所」を参照)

  • リカバリ・アプライアンスがポーリングする間隔

  • バックアップ・データを正常に処理した後で削除するかどうか

保護ポリシーを使用してバックアップ・ポーリング・ポリシーを保護データベースに割り当てます。必要に応じて、各保護ポリシーが1つのポーリング・ポリシーを参照できます。

関連項目:

「バックアップ・ポーリング・ポリシーの作成(コマンドラインのみ)」

サポートされるOracle Databaseリリース

各リリースで使用可能な機能を含め、リカバリ・アプライアンスでサポートされているOracle Databaseリリースの詳細は、My Oracle SupportノートのドキュメントID 1995866.1 (http://support.oracle.com/epmos/faces/DocumentDisplay?id=1995866.1)を参照してください。

リアルタイムREDOトランスポート

REDOデータにはデータベースに加えられたすべての変更の記録が格納されるので、データ障害が発生した場合のデータ損失を最小限に抑えるために不可欠です。リカバリ・アプライアンスのリアルタイムREDOトランスポート機能を使用すると、連続するアーカイブREDOログのバックアップ間でデータ損失の危険にさらされる期間が大幅に短くなります。リアルタイムREDOトランスポートを有効にすると、通常のRPOは0から1秒未満の値です。

図2-4に、増分バックアップとREDOログをリカバリ・アプライアンスに送信する保護されたデータベースを示します。

図2-4 REDOログの送信

図2-4の説明が続きます
「図2-4 REDOログの送信」の説明

リアルタイムREDOトランスポートを有効にすると、保護されたデータベースはメモリー内にREDO変更を生成してから、すぐにリカバリ・アプライアンスに転送します。リカバリ・アプライアンスはそれを検証し、ステージング領域に書き込みます。

保護データベースがオンラインREDOログ切替えを実行すると、リカバリ・アプライアンスはREDO変更を変換して、圧縮されたアーカイブREDOログ・ファイル・バックアップにアセンブルしますRecovery Applianceカタログは、リカバリ・カタログ内のこれらのアーカイブREDOログ・バックアップを自動的に追跡します。RMANは、これらのアーカイブREDOログ・バックアップを通常どおりにリストアおよび適用できます。このメリットは次のとおりです。

  • REDOストリームが予期せず終了した場合、リカバリ・アプライアンスは、受信中のREDOストリームを終了して、部分的なアーカイブREDOログ・ファイル・バックアップを作成できます。これにより、アプライアンスが受信した直近の変更までトランザクションが保護されます。リカバリ・アプライアンスはREDOストリームの再開を検出した時点で、欠落しているすべてのアーカイブREDOログ・ファイルを保護データベースから自動的に取得します。このように、リカバリ・アプライアンスによってリカバリ・ウィンドウ目標が守られます。

  • Recovery Applianceは、リアルタイムREDOログをアーカイブREDOログ・ファイルに自動的に変換するため、アーカイブREDOログ・ファイルをデータベース・ホストからRecovery Applianceにバックアップする必要はありません。

Recovery Applianceは、受信するREDOを、保護されたデータベースによって送信されたバックアップには適用しません。このため、更新された仮想レベル0バックアップの提供を続行するために、Recovery Applianceは新しい増分バックアップをデルタ・ストアに組み込む必要があります。アプライアンスでは、保護されたデータベースが送信したレベル1増分バックアップごとに対応する仮想レベル0バックアップを提供します。リカバリ・シナリオの場合、適切なレベル0バックアップをリストアしてから、REDOログ・ファイルを使用してロール・フォワードします。

関連項目:

リアルタイムREDOトランスポートおよびその有効化方法の詳細は、『Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイド』を参照してください

リカバリ・アプライアンスのメタデータ・データベース

リカバリ・アプライアンスの重要なコンポーネントはリカバリ・アプライアンス・メタデータ・データベースです。このデータベースは、すべてのバックアップのメタデータを管理し、RMANリカバリ・カタログも格納します。リカバリ・アプライアンス・メタデータ・データベースは、事前に構成およびチューニングされており、リカバリ・アプライアンスによって管理されます。図2-5に、保護データベースとのやりとりを行うリカバリ・アプライアンス・メタデータ・データベースを示します。

図2-5 リカバリ・アプライアンスのメタデータ・データベース

図2-5の説明が続きます
「図2-5 リカバリ・アプライアンス・メタデータ・データベース」の説明

この項には次のトピックが含まれます:

デルタ・ストア

デルタ・ストアは、リカバリ・アプライアンスの記憶域の場所にあるすべての保護データベース・バックアップ・データ全体です。すべてのデータ・ファイルとアーカイブREDOバックアップがデルタ・ストアに含まれます。デルタ・ストアには、すべての保護データベースのすべてのデータ・ファイルためのデルタ・プールがあります。

デルタ・プール

デルタ・ストアはデルタ・プールのコレクションです。リカバリ・アプライアンスは保護データベースからバックアップを受け取ると、インデックスを付けてデルタ・プールに格納します。デルタ・プールはデータ・ファイル・ブロックのセットであり、リカバリ・アプライアンスがこれを元に仮想完全バックアップを作成します。リカバリ・アプライアンスは、受信した任意の増分バックアップに対応する仮想完全バックアップを作成できるように、自動的にデルタ・プールを管理します。

リカバリ・アプライアンスにバックアップが送信される各データ・ファイルには、それぞれ独自のデルタ・プールがあります。たとえば、prod1のデータ・ファイル10は独自のデルタ・プールがあり、データベースprod2のデータ・ファイル1にも独自のデルタ・プールがあります。図2-6に示すように、リカバリ・アプライアンスによって保護されるデータベースのすべてのデルタ・プールがデルタ・ストアに含まれます。

図2-6 デルタ・ストアのデルタ・プール

図2-6の説明が続きます
「図2-6 デルタ・ストアのデルタ・プール」の説明

自動デルタ・プール領域管理

リカバリ・アプライアンスがバックアップを管理する一連の操作は、自動デルタ・プール領域管理と呼ばれます。領域管理では具体的には次の自動タスクが行われます。

  • ディスク・リカバリ・ウィンドウ目標とSBT保存ポリシーに基づいて、不要すなわち期限切れになったバックアップの削除(リカバリ・アプライアンスの記憶域の場所とテープの両方)

    リカバリ・アプライアンスは、ディスクに格納しておく必要がないバックアップを定期的に判別して、ディスク領域を再利用できるようにします。リカバリ・アプライアンスが、デルタ・プールにあるバックアップを不要と判別するとき、通常、そのバックアップを構成する個々のブロックは、不要ではないブロックと一緒に物理ファイルに配置されています。リカバリ・アプライアンスはそれらの物理ファイルを再書込みして、不要ブロックが占有していた領域をデルタ・プールが再利用できるようにします。

  • デルタ・プールを定期的に再編成して、リストア操作のパフォーマンスを改善します

    デルタ・プールの自動トラッキングと再編成は、デルタ・プールの最適化と呼ばれます。古いブロックが削除され、更新されたデータ・ファイルに関する新しい増分バックアップが届くと、バックアップ内のブロックの連続性が低下することがあります。この状態によって、リストア操作のパフォーマンスが低下する可能性があります。リカバリ・アプライアンスは、自動的に仮想完全バックアップ・ブロックを再編成して連続性を維持するバックグラウンド・タスクを実行し、これにより、リストア操作の読取りアクセスを最適化します。

関連項目:

「リカバリ・アプライアンスによる記憶域の管理方法」

リカバリ・アプライアンス・スキーマ

リカバリ・アプライアンス・スキーマに含まれるメタデータは、リカバリ・アプライアンスが保護データベースにかわってバックアップを管理するために内部で使用します。RASYSは、リカバリ・アプライアンス・スキーマを所有するリカバリ・アプライアンス管理ユーザーです。リカバリ・アプライアンス・スキーマにはRMANリカバリ・カタログが含まれます。

関連項目:

「リカバリ・アプライアンス環境のユーザー・アカウント」

リカバリ・アプライアンス・カタログ

リカバリ・カタログの更新は、リカバリ・アプライアンスのインデックス付けと領域管理コレクションの結果を反映します。このような更新は、保護データベースの制御ファイルでは行われません。この理由から、リカバリ・アプライアンスにバックアップを格納する保護データベースはリカバリ・アプライアンス・カタログを使用する必要があります。

注意:

保護データベースは、バックアップ・リポジトリとしてリカバリ・アプライアンスを使用しなくても、リカバリ・アプライアンス内のリカバリ・カタログを使用できます。

RMANは、バックアップおよびリカバリ操作に利用されるのと同じリカバリ・アプライアンス・アカウントを使用してリカバリ・アプライアンス・カタログに接続します。各リカバリ・アプライアンス・ユーザー・アカウントは、仮想プライベート・カタログ・アカウントでもあります。DBMS_RA.GRANT_DB_ACCESSプロシージャは、リカバリ・アプライアンス権限を特定の保護データベースのデータベース・ユーザー・アカウントに付与します。

関連項目:

リカバリ・アプライアンスの記憶域

リカバリ・アプライアンスでは次のタイプの記憶域が使用されます。

  • リカバリ・アプライアンスの記憶域の場所

    Oracle ASMの場所は、Recovery Applianceディスク上のバックアップのメイン記憶域であり、保護されたデータベースのバックアップの保存先として機能します。

  • バックアップ・ポーリングの場所

    共有記憶域上のファイル・システム・ディレクトリ(オプション)。リカバリ・アプライアンスの外部で、保護データベースのバックアップ・ピースやアーカイブREDOログ・ファイルが格納される場所です。リカバリ・アプライアンスは、指定された間隔でディレクトリをポーリングし、バックアップが見つかったら取り出し、処理して格納します。

  • REDOステージング領域

    リアルタイムREDOトランスポートに対応するリカバリ・アプライアンス・インストールの場合、保護データベースがリカバリ・アプライアンスに送信するREDOストリームの宛先です。ステージング領域はリカバリ・アプライアンス・ディスク上にあります。リカバリ・アプライアンスはデータをアーカイブREDOログ・ファイルに収集し、圧縮アーカイブREDOログ・バックアップに変換してから、リカバリ・アプライアンスの記憶域の場所に書き込みます。

関連項目:

リカバリ・アプライアンスの記憶域の場所

リカバリ・アプライアンスの記憶域の場所は、複数の保護データベースが共有できます。リカバリ・アプライアンス管理者が、記憶域のそれぞれの場所を使用するクライアントを決定します。

Recovery Applianceの記憶域のメリット

リカバリ・アプライアンスの記憶域の場所のメリットは次のとおりです。

  • ディスク使用率の向上

    Recovery Applianceは共通記憶域を使用してすべての保護データベースのスパイクに対応するため、割当て過剰な記憶域の合計容量が減少します。従来のRMANバックアップおよびリカバリでは高速リカバリ領域には、リカバリ関連のファイルが格納されます。個々の高速リカバリ領域では、予期される最大のアクティビティ・スパイク(多くの場合、これによって記憶域が浪費されます)に対処するために必要な記憶域容量を各データベースで保持する必要があります。

    注意:

    Recovery Appliance内のデフォルトの記憶域の場所にもカタログ・バックアップ用の高速リカバリ領域が含まれます。

    保護されたデータベースで、ローカルのオンラインおよびアーカイブされたREDOログ・ファイルの記憶域、制御ファイルの自動バックアップ、およびフラッシュバック・ログの高速リカバリ領域を保持し続けることをお薦めします。リカバリ・アプライアンス環境では、RMANバックアップはリカバリ・アプライアンスに格納されるため、高速リカバリ領域の容量要件が小さくなります。

  • データベースに合うように最適化されたバックアップの重複除外と圧縮

  • 共有ディスク・バックアップ・プール。各データベースのディスク・リカバリ・ウィンドウ目標を定義するデータベース保護ポリシーに基づいて分散されています。

Oracle ASMおよびRecovery Applianceの記憶域

Recovery Applianceの記憶域の場所は、Oracle ASMディスク・グループ内の領域を占有します。デフォルトでは、デルタ・プールは、通常の冗長性Oracle ASMディスク・グループ内に格納されます。つまり、Recovery Applianceは、すべてのオンディスク・バックアップのコピーを2つ管理します。1つのディスクまたはストレージ・サーバーが失われても、データベース・バックアップは残ります。ファイルおよびブロックを追跡するRecovery Applianceメタデータ・データベースは、冗長性が高いOracle ASMディスク・グループ内に格納されます。

関連項目:

DELTA記憶域の場所

デフォルトでは、リカバリ・アプライアンスに構成されるすべてのディスク記憶域は、DELTAと呼ばれる1つの記憶域の場所に割り当てられます。図2-7では、すべての保護データベースがこの記憶域の場所を共有しています。

図2-7 記憶域の場所DELTA

図2-7の説明が続きます
「図2-7 記憶域の場所DELTA」の説明

さらに複雑な実装では、拡張や領域割当てなどの理由から、複数の記憶域の場所が必要になることがあります。図2-8に、記憶域の場所(DELTA (デフォルト)とDELTA2 (デフォルト以外))が2つ構成されたリカバリ・アプライアンスを示します。

図2-8 複数の記憶域の場所

図2-8の説明が続きます
「図2-8 複数の記憶域の場所」の説明

バックアップ・ポーリングの場所

バックアップ・ポーリング・ポリシーによって、保護データベースがリカバリ・アプライアンスと直接やりとりせずにバックアップを配置する、ファイル・システム・ディレクトリが定義されます。バックアップ・ポーリング・ディレクトリはNFSマウント・ポイントであり、リカバリ・アプライアンスのストレージ・サーバーにはありません。

ポーリング・ポリシーでは、記憶域のファイル・システム・パスと新しいバックアップの検索が行われる頻度を定義します。ポーリング・ポリシーはオプションです。ポーリング方法を使用してバックアップがリカバリ・アプライアンスに送信されない場合、作成する必要はありません。

関連項目:

「バックアップ・ポーリング・ポリシー」

バックアップ・ポーリングのステージ

バックアップ・ポーリングは次のステージで実行されます。

  1. 保護データベースが、リカバリ・アプライアンスの関与なしにバックアップを書き込みます(バックアップが作成されるときリカバリ・アプライアンスが実行している必要はありません)。

  2. 新たに届いたバックアップを探すためにリカバリ・アプライアンスがポーリングします。

  3. リカバリ・アプライアンスはポーリングでファイルを検出すると、内容を調査して、保護データベースに関連付けようとします。その後、次のいずれかを行います。

    • 登録されている保護データベースにファイルが関連する場合、リカバリ・アプライアンスはそのバックアップを処理します。

    • 登録されたどの保護データベースともファイルが関連付けられていない場合、リカバリ・アプライアンスは警告メッセージをログに記録し、ファイルの処理は行いません。

リカバリ・アプライアンスによるバックアップ・ポーリング・ディレクトリのバックアップの処理方法

バックアップがリカバリ・アプライアンスの記憶域にコピーされるようにポーリングを設定するには、リカバリ・アプライアンスの記憶域の場所ではないが、リカバリ・アプライアンスがアクセスできるバックアップ・ポーリング・ディレクトリを構成する必要があります。保護データベースは、ポーリング・ポリシーに指定されたポーリング・ディレクトリにバックアップを書き込みます。

リカバリ・アプライアンスは、新たに作成されたバックアップがないかどうかポーリング・ディレクトリをチェックします。バックアップが存在していると、リカバリ・アプライアンスは、ポーリング・ディレクトリにあるバックアップをリカバリ・アプライアンス内部の記憶域の場所にコピーして処理します。リカバリ・アプライアンスがバックアップをコピーするために十分な時間が経過してから、保護データベースがポーリング・ディレクトリからバックアップを削除します。図2-9にこの構成を示します。

図2-9 バックアップ・ポーリング

図2-9の説明が続きます
「図2-9 バックアップ・ポーリング」の説明

リカバリ・アプライアンスによる記憶域の管理方法

リカバリ・アプライアンス管理者の重要な役目は、指定された保存ウィンドウとデータベース・サイズに適したディスク容量を計画することです。条件は変化するため、リカバリ・アプライアンスによって、記憶域の場所とデータベースのレベルで領域管理のモニタリングとアラートが提供されます。予測した記憶域のニーズが使用可能な記憶域の容量に近づくと、アラートと警告が生成され、管理者が記憶域の需要に対処する時間を取ることができます。

RA_DATABASEビューでアクセスできる次の属性によって、リカバリ・アプライアンスが記憶域とバックアップの保存を管理する方法が決まります。

関連項目:

永久的増分計画に含まれないRMANバックアップに適用される特別なアルゴリズムについては、「アーカイブ・バックアップと暗号化バックアップ」を参照してください

リカバリ・ウィンドウ目標

DBMS_RA.CREATE_PROTECTION_POLICYのrecovery_window_goalパラメータは、現在日時からさかのぼって、ポイント・イン・タイム・リカバリを可能にしておく必要がある期間(通常は日数)を指定します。recovery_window_goalが1日に設定されているとします。8月7日の深夜0時の時点では、現在時刻から8月6日の深夜0時までの任意の時点にリカバリできることが目標です。8月8日の深夜0時であれば、現在時刻から8月7日の深夜0時までの任意の時点にリカバリできることが目標になります。

リカバリ・アプライアンスは、各データベースに定義されたリカバリ・ウィンドウ目標を達成するために十分なバックアップを保存しようとします。たとえば、リカバリ・アプライアンスがデータベースSTORE01、STORE02およびSTORE03を保護しているとします。STORE01のリカバリ・ウィンドウ目標は1日です。8月7日の深夜0時に、STORE01がリカバリ・ウィンドウ目標を達成するためにバックアップ用として624.2GBが必要な場合、リカバリ・アプライアンスは、少なくともこれに相当する領域をSTORE01バックアップに割り当てようとします。

十分な領域が記憶域に存在する場合、リカバリ・ウィンドウ目標よりも前に作成されたバックアップを使用できますが、これは保証されるとはかぎりません。以前のバックアップのパージが不要な場合、リカバリ・アプライアンスはそれらを保持し、効果的にポイント・イン・タイム・リカバリが可能な期間を延長できます。たとえば、8月7日にSTORE01で使用可能な領域が700GB以上あっても、必要となるのは624.2GBのみです。同様の状況がSTORE02とSTORE03でも発生することがあります。

十分な領域が記憶域に存在しない場合、デフォルト(guaranteed_copy=NO)でリカバリ・アプライアンスはバックアップをパージできます。領域を再利用するとき、リカバリ・アプライアンスはまずリカバリ・ウィンドウ要件を優先しようとします。

関連項目:

予約済領域

リカバリ・ウィンドウ目標の次に重要なのは、DBMS_RA.ADD_DBおよびDBMS_RA.UPDATE_DBのreserved_spaceパラメータです。予約済領域によって、各保護データベースがリカバリ・ウィンドウ目標を達成するために保証されるディスク領域の容量が定義されます。

注意:

これは、保護ポリシーではなくADD_DBに指定される唯一の記憶域パラメータです。

バックアップで領域が必要なため、バックアップを格納するために必要な領域を予測する必要があります。たとえば、1024GBの予約済領域をDB1124データベースに割り当てるとします。これは、仮にリカバリ・ウィンドウ目標を達成するためにデータベースでこの容量が必要になった場合に、リカバリ・アプライアンスが1024GBをDB1124に保証することを意味します。次の図は、保護されたデータベースの詳細レポートの一部です。

pdb_details.pngの説明が続きます。
図pdb_details.pngの説明

この例で、DB1124のディスク・リカバリ・ウィンドウ目標は3日間で、実際のリカバリ・ウィンドウ(現時点でリカバリ・アプライアンスがリカバリできる期間)は4.59日間です。リカバリ・ウィンドウ目標を達成するには、182.3GBのバックアップ・データが必要です。この容量は、指定された予約済領域設定1024GBの20%未満です。デフォルトでは、任意の時点でデータベースが実際に保持する容量は、指定の予約済領域より少ないことも多いこともあります。

注意:

予約済領域は容量(GB)で計測されますが、リカバリ・ウィンドウ目標は時間で計測されます。

リカバリ・アプライアンスはリカバリ・ウィンドウ目標と予約済領域の設定を使用して、ビジネス要件を満たす記憶域を動的に割り当てます。リカバリ・アプライアンスが、各データベースのリカバリ・ウィンドウ目標を満たした上でできるだけ多くのバックアップ・データをパージし、さらに領域が必要な場合は、各データベースの予約済領域設定を検証します。リカバリ・アプライアンスは、予約済領域の超過率が最も高いバックアップが存在しているデータベースのバックアップをパージし、RA_INCIDENT_LOGビューにメッセージのログを記録します。RA_PURGING_QUEUEビューを問い合せて、次にバックアップをパージするデータベースを判別します。

関連項目:

コピーの保証

記憶域管理のポイントとなる質問は、古いバックアップのコピーまたはレプリケートと、新しいバックアップおよびREDOの受入れのどちらが重要かということです。DBMS_RA.CREATE_PROTECTION_POLICYのguaranteed_copyパラメータを次のように設定できます。

  • NO (デフォルト)

    新しいバックアップの領域を用意するために必要であれば、リカバリ・アプライアンスは、バックアップをテープにコピーしたりレプリケートしたりせずにパージできます。この場合、保護データベースが保持する容量は予約済領域よりも多いことも少ないこともあります。

  • YES

    コピーの保証が有効になっていると、バックアップがテープにコピーされるかレプリケートされないうちにリカバリ・アプライアンスがバックアップを削除することはありません。また、コピーまたはレプリケートされていないバックアップの合計サイズが、データベースのreserved_space設定を超えることはリカバリ・アプライアンスで許可されません。

    リカバリ・アプライアンスが、コピーまたはレプリケートされていないバックアップで予約済領域を使い果たしてしまうと、新しいバックアップまたはREDOを受け入れることができません。この設定は、テープ・システムまたはレプリケート先リカバリ・アプライアンスが長時間使用できない場合に、記憶域管理の動作のみを変更します。

    リカバリ・アプライアンスは、永久的増分バックアップ計画の仮想バックアップに対しては別のアルゴリズムを使用します。非仮想バックアップは特定の容量の領域を占有し、テープ・コピーが行われるかどうかは設定によります。仮想バックアップの場合、テープ・スケジュールによって、すべての仮想バックアップのレベル1またはレベル0バージョンがリカバリ・アプライアンスに書き込まれます。また、仮想バックアップの領域計算は複雑です。領域にはバックアップをサポートするために必要なブロックが含まれるためです。これは、バックアップをテープに書き込むために必要な領域とは異なる場合があります。これらの理由から、リカバリ・アプライアンスは、仮想データ・ファイル・バックアップをテープに書き込んだ後で、このバックアップのすべてのバージョンとこのデータ・ファイルの古い仮想バックアップすべてがテープにコピーされた(レプリケートされた)とみなします。

関連項目:

最長保存期間

DBMS_RA.CREATE_PROTECTION_POLICYのmax_retention_windowパラメータは、このポリシーを使用するデータベースのバックアップをリカバリ・アプライアンスが保存する最長期間を指定します。nullを指定すると、記憶域の場所の領域不足やユーザー・アクションによって引き起こされないかぎり、バックアップのパージが発生しません。

リカバリ・アプライアンスは、データベースのリカバリ・ウィンドウ目標を維持するために必要な場合のみ、バックアップを保存ウィンドウよりも長く保存します。この設定の効果は、リカバリ・アプライアンスによるバックアップの削除が、設定がない場合よりも早い時点で行われることです。

関連項目:

アーカイブ・バックアップと暗号化バックアップ

次のタイプのバックアップは、永久的増分計画に含めたり、仮想完全バックアップの作成に使用したりできません。

  • BACKUP ... KEEPコマンドを使用して作成されるRMANアーカイブ・バックアップ

  • CONFIGUREまたはSET ENCRYPTIONを使用して作成されたRMAN暗号化バックアップ

リカバリ・アプライアンスは、永久的増分計画のバックアップとは異なる方法でこれらのバックアップを管理します。リカバリ・アプライアンスは、指定されたリカバリ・ウィンドウ目標とは関係なくアーカイブ・バックアップを保存します。ただし、暗号化バックアップはリカバリ・ウィンドウ設定に対応します。

アーカイブ・バックアップが、リカバリ・アプライアンスによる削除対象になるのはKEEPの時間が経過してからのみです。アーカイブ・バックアップを格納する期間を延長する場合は、次のガイドラインに注意してください。

  • それらに対応する予約済領域を調整します。アーカイブ・バックアップによって、リカバリ・ウィンドウ目標の達成に使用可能な領域が減少するため、対応する領域を設定する必要があります。

  • リカバリ・アプライアンスでは、アーカイブ・バックアップがテープに自動的にコピーされないため、COPY_BACKUPプロシージャを使用して手動でコピーする必要があります。このプロシージャを使用すると、リカバリ・アプライアンスの記憶域の場所の外部にあるディスク上の場所にアーカイブ・バックアップをコピーすることもできます。MOVE_BACKUPプロシージャは、アーカイブ・バックアップをディスクまたはテープにコピーして、記憶域から削除します。

関連項目:

Oracle Secure Backup

Oracle Secure Backupは、リカバリ・アプライアンスのテープ管理コンポーネントです。リカバリ・アプライアンスは、保護データベースからリカバリ・アプライアンスへのテープ・バックアップ操作から解放されます。したがって、保護データベース・ホストではRMAN統合メディア管理ソフトウェア・モジュールが必要ありません。このかわりに、Oracle Secure Backupモジュールのコピーがリカバリ・アプライアンスにインストールされます。リカバリ・アプライアンスは、すべての保護データベースに関してバックアップのテープへのコピーを自動的に管理します。

関連項目:

『Oracle® Databaseバックアップおよびリカバリ・リファレンス』

テープ・アーカイブ

保護データベースはバックアップをリカバリ・アプライアンスに送信し、リカバリ・アプライアンスがそれらをディスク上の指定された記憶域の場所に格納します。ディスク領域を再利用し、トランスポータブル・テープ・バックアップを作成するには、ビジネス要件でテープへのアーカイブが求められることがあります。

テープ・バックアップは、リカバリ・アプライアンスが自動化してバックグラウンド・タスクとして実行する繰返しタスクです。リカバリ・アプライアンス管理者はルールを構成して、リカバリ・アプライアンスがテープ・バックアップを作成する間隔を指定します。保護ポリシーはデータベースの特徴に合ったグループ分けであり、同じ保護ポリシーを共有するデータベースは同じテープ・アーカイブ要件を共有します。

リカバリ・アプライアンスが、バックアップにブロックを提供するすべての完全バックアップまたは増分バックアップの最大互換バージョンと一致する互換バージョンのテープ・バックアップを作成します。リカバリ・アプライアンスがメディア管理レイヤーに送信するデータベースID情報は、データベースがバックアップを送信した場合に送信される情報と同一です。この一致により、バックアップが作成されたデータベースがそのバックアップを使用することが保証されます。

関連項目:

「Oracle Schedulerを使用したテープ・バックアップ・ジョブのスケジューリング」

テープ取得

バックアップは完全なバックアップ・セットとしてテープに格納されます。したがって、リカバリ・アプライアンスの仲介なしにRMANがテープ・バックアップを使用できます。テープのバックアップをリストアするには次の方法があります。

  • リカバリ・アプライアンスによる取得

    これは、リカバリ・アプライアンスによって作成されたSBTバックアップをリストアする最も簡単な方法です。RMANが、リカバリ・アプライアンスにリストアをリクエストします。その特定のバックアップがテープに移されたことを認識している必要はありません。リカバリ・アプライアンスは、リクエストされたバックアップ・セットがテープにあることを認識し、バックアップをメディア・マネージャからリストアするSBTセッションを開き、ネットワークを介してデータを保護データベース・ホストに送信します。

  • 保護データベースによる取得

    SBTバックアップはクライアント互換フォーマットとして存在しているため、RMANはリカバリ・アプライアンスと連動せずに、テープからホストにバックアップを直接リストアできます。この場合、RMANはまずバックアップ・ピースをカタログ化してから、テープからリストアする必要があります。また、Oracle Secure Backupライブラリを保護データベース・ホストにインストールすることも必要です。

関連項目:

テープからバックアップをリストアする方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください

リカバリ・アプライアンス・レプリケーション

リカバリ・アプライアンス・レプリケーションでは、1つのリカバリ・アプライアンス(アップストリーム・リカバリ・アプライアンス)が別のリカバリ・アプライアンス(ダウンストリーム・リカバリ・アプライアンス)にバックアップを転送します。最初の構成以降、レプリケーションは完全に自動的に行われます。レプリケーション・トポロジの各リカバリ・アプライアンスは、それぞれの保護ポリシーとポーリング・ポリシーを管理します。

ダウンストリーム・リカバリ・アプライアンスによるバックアップの処理方法

アップストリーム・リカバリ・アプライアンスは、バックアップをダウンストリーム・リカバリ・アプライアンスに転送するために、保護データベースがバックアップの送信に使用するのと同じリカバリ・アプライアンス・バックアップ・モジュールを使用します。バックアップを処理する基本手順は次のとおりです。

  1. 保護データベースがリカバリ・アプライアンス・バックアップ・モジュールを使用して、バックアップをリカバリ・アプライアンスに送信します。

  2. リカバリ・アプライアンスはバックアップを受信し、それらを通常どおり処理します。

    注意:

    ダウンストリーム・リカバリ・アプライアンスは、自らがダウンストリームの役割を果たしていることを認識していません。ダウンストリーム・リカバリ・アプライアンスでのバックアップの受信と処理のロジックは、アップストリーム・リカバリ・アプライアンスでの処理内容とは独立しています。

  3. アップストリーム・リカバリ・アプライアンスがバックアップをダウンストリーム・リカバリ・アプライアンスに転送します。

    注意:

    リアルタイムREDOトランスポートが有効である場合、受信したREDO変更はリカバリ・アプライアンスによってリアルタイムではレプリケートされません。アーカイブREDOログのバックアップが作成されると、Recovery Applianceは、このバックアップをデータ・ファイルのバックアップとともにレプリケートします。

  4. ダウンストリーム・リカバリ・アプライアンスがアップストリーム・リカバリ・アプライアンスからバックアップを受信すると、独自のメタデータ・データベースを更新します。

  5. アップストリーム・リカバリ・アプライアンスが、ダウンストリーム・メタデータのメタデータ更新をリクエストします。

アップストリーム・リカバリ・アプライアンスは、定期的に、そのすぐダウンストリームにあるリカバリ・アプライアンスにメタデータ更新をリクエストします。ダウンストリーム・リカバリ・アプライアンスは、メタデータ・リクエストを受信するとメタデータ更新をアップストリーム・リカバリ・アプライアンスに送信します。アップストリーム・リカバリ・アプライアンスが自らのリカバリ・カタログを更新します。リカバリ・アプライアンス・レプリケーションで、このプロセスは調整と呼ばれます。

関連項目:

「バックアップのライフサイクル: シナリオ」

レプリケーションのユースケース

ダウンストリーム・リカバリ・アプライアンスはアップストリーム・リカバリ・アプライアンスに依存せずにバックアップを処理するため、バックアップを格納する各データベースに対してまったく異なるポリシーを持つことができます。このように合せる必要がないため多様なユースケースを構成できます。その一部を図2-10に示します。

図2-10 リカバリ・アプライアンス・レプリケーションのユースケース

図2-10の説明が続きます
「図2-10 リカバリ・アプライアンス・レプリケーションのユースケース」の説明

図2-10は次のユースケースを示しています。

  • 一方向

    バックアップ・データがローカル・データベースからアップストリーム・リカバリ・アプライアンスに送信され、アップストリーム・リカバリ・アプライアンスがリモートのダウンストリーム・リカバリ・アプライアンスに転送します。

  • 双方向

    バックアップがローカル・データベースからローカルのリカバリ・アプライアンスに送信され、さらにリモートのリカバリ・アプライアンスに転送されます。反対に、バックアップがリモート・データベースからリモートのリカバリ・アプライアンスに送信され、さらにローカルのリカバリ・アプライアンスに転送されます。

    このケースでは、各リカバリ・アプライアンスがレプリケーション・トポロジのアップストリームとダウンストリーム両方の役割を果たします。すべてのリカバリ・アプライアンスは、一方の保護データベース・セットのプライマリ・バックアップの場所、および他方のセットのセカンダリ・バックアップの場所として使用されます。このように、それぞれのリカバリ・アプライアンスがよく利用され、もう一方のリカバリ・アプライアンスに障害回復サービスを提供します。

  • ハブアンドスポーク

    一方のデータベース・セットのバックアップがローカル・リカバリ・アプライアンスに送信され、別のデータベース・セットのバックアップが別のローカル・リカバリ・アプライアンスに送信されます。これらのローカル・リカバリ・アプライアンスはバックアップを1つのリモート・リカバリ・アプライアンスに転送し、リモート・リカバリ・アプライアンスがバックアップをテープにアーカイブします。

これらのユースケースのどれでもカスケード・レプリケーションに使用できます。カスケード・レプリケーションでは、ダウンストリーム・リカバリ・アプライアンスがバックアップを第2のダウンストリーム・リカバリ・アプライアンスに転送して、リカバリ・アプライアンスの一方向チェーンを構築します。

関連項目:

リカバリ・アプライアンスでのバックアップのレプリケート

データ暗号化手法

図2-11に示すように、Recovery Applianceに送信されたバックアップおよびREDOで使用可能な暗号化オプションが各種用意されています。Recovery Applianceではサーバー側の暗号化は行われません。つまり、Recovery Appliance自体がデータを暗号化および復号化することはありません。

図2-11 データ暗号化手法

図2-11の説明が続きます
「図2-11 データ暗号化手法」の説明

次のタイプの暗号化がサポートされています。

本番データベースの表領域での透過的データ暗号化(TDE)

データベース内のTDEを有効化し、通常どおり増分バックアップをとることをお薦めします。TDEには、アドバンスト・セキュリティ・オプションが必要です。TDEの利点は、次のとおりです。

  • TDEはアプリケーションに対して透過的に行われます。

  • 暗号化された表領域のバックアップ、およびこれらの表領域への変更を説明するREDOが暗号化されます。TDEによって暗号化されたデータ・ブロックは、保護されたデータベース、Recovery Applianceの記憶域、テープ・デバイス、レプリケート・アプライアンスで保護されるだけでなく、ネットワーク接続を介して転送される際にも保護されます。

  • ソース・データベースでのTDEにより、ダウンストリーム・サーバーでのオーバーヘッドが削減されます。

  • この手法は、永久的増分計画および仮想完全バックアップをサポートしています。

注意:

RMAN SETまたはCONFIGURE ENCRYPTIONコマンドを使用してバックアップを暗号化することはお薦めしません。詳細は、「アーカイブ・バックアップと暗号化バックアップ」を参照してください

次の表は、RMAN暗号化またはRMAN圧縮あるいはその両方が、保護されたデータベース・バックアップで使用される場合の永久増分のサポートを示します。

表2-4 RMAN暗号化およびRMAN圧縮での永久増分のサポート

データベースのデータ バックアップ暗号化なしおよびRMAN圧縮なし RMAN暗号化 RMAN圧縮 バックアップ暗号化およびRMAN圧縮
暗号化されません はい いいえ はい いいえ
TDE表領域暗号化 はい はい いいえ いいえ

関連項目:

Recovery Applianceへのネットワーク転送用のOracle Netセキュリティ

Oracle Netセキュリティには、LDAP準拠のディレクトリ・サーバー、デジタル証明書およびSecure Sockets Layer (SSL)が含まれます。Oracle Netセキュリティでは、Recovery ApplianceへのバックアップおよびREDOの転送が暗号化されます。この手法では、データベースのTDE暗号化、LOG_ARCHIVE_DEST_nを使用したREDO暗号化、またはRMANバックアップの暗号化からは独立した転送中のネットワークの暗号化を実現します。

関連項目:

LOG_ARCHIVE_DEST_nを使用したREDO暗号化

有効である場合、LOG_ARCHIVE_DEST_nのENCRYPTION属性は、Recovery Appliance上で停止しているREDOと、Recovery Applianceへのネットワーク転送中のREDOの両方を暗号化します。基本的なプロセスは次のとおりです。

  1. 保護されたデータベースは、保護されたデータベース上のOracleウォレットに含まれる秘密鍵を使用してメモリー内のREDOを暗号化します。

  2. 保護されたデータベースは、ネットワークを介してREDOをRecovery Applianceに転送します。

    注意:

    Oracle Netセキュリティも有効である場合、REDOはネットワーク転送中に二重に暗号化されます。

  3. Recovery Applianceは、Recovery Appliance上でのみ暗号化形式で存在するアーカイブREDOログ・ファイルに暗号化REDOを書き込みます。

リカバリ・シナリオでは、RMANは、(Recovery Appliance上ではなく)保護されたデータベース上のOracleウォレットに格納されている暗号化鍵を使用して、保護されたデータベース上の暗号化REDOログ・ファイルをリストアおよび復号化します。RMANは、メディア・リカバリ中に暗号化REDOログ・ファイルを適用することはありません。

関連項目:

テープ・ドライブベースのハードウェア暗号化

Recovery Applianceは、テープ・ドライブベースのハードウェア暗号化をサポートしています。この場合、テープ・ドライブはソフトウェアではなくデータを暗号化します。

注意:

Oracle Secure Backupは、Recovery Applianceがバックアップ・ピースをテープにコピーする前にこれらを暗号化できます。ただし、ソフトウェアベースの暗号化を使用することをお薦めしません。なぜなら、この場合、パフォーマンスに悪影響が及ぶ可能性があるからです。

鍵の管理については、すべての暗号化鍵を一元的に認証、保護および管理するOracle Key Managerを使用することをお薦めします。Oracle Key Managerは、データの暗号化および復号化時にRecovery ApplianceでCPUを消費しません。

関連項目:

ハードウェアの暗号化の詳細は、『Oracle Secure Backup管理者ガイド』を参照してください。