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

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

図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 RASYSとリカバリ・アプライアンス・ユーザー・アカウント」の説明

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

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

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

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

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

ノート:

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

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

次の操作は非同期で行われます。
- リカバリ・アプライアンスが、バックアップ収集を実行します。リカバリ・アプライアンスは次のようにバックアップを処理します。
  - 保護データベースから送信されたバックアップをスキャンします。
  - 少数のブロックからなるグループに分割して、各データ・ファイルのブロックを個別のデルタ・プールに割り当てます
  - データベースの保護ポリシ-に応じて、グループを適切な記憶域の場所に書き込みます
  - 仮想バックアップ・セットが作成されたら、元のバックアップ・セットを削除します。
    
    ノート:
    
    リカバリ・アプライアンスが、仮想バックアップの作成と同時に元のバックアップを削除できない場合があります。このため、元のバックアップと仮想バックアップの両方が、リカバリ・カタログ内で2つのコピーとして短時間同時に存在する可能性があります。
  バックアップ収集時に、リカバリ・アプライアンスはバックアップのインデックスを付けます。この処理では、各データ・ブロックの内容と物理的な場所に関する情報をメタデータ・データベースに格納します。リカバリ・アプライアンスは保護データベースのリカバリ・カタログを含むため、これで新たにインデックス付けした仮想完全バックアップをRMANが使用できるようになります(リカバリで必要となる場合)。
- リカバリ・アプライアンス・レプリケーションが構成されている場合、リカバリ・アプライアンスはバックアップをダウンストリーム・リカバリ・アプライアンスに転送します。
  
  様々なレプリケーション構成が可能です。図2-1には、1対1の構成が示されています。中央のリカバリ・アプライアンスがアップストリーム・リカバリ・アプライアンス(バックアップの送信側)として、ダウンストリーム・リカバリ・アプライアンス(バックアップの受信側)として機能する別のリカバリ・アプライアンスにバックアップを転送します。図2-1には、ダウンストリーム・リカバリ・アプライアンスがバックアップを第3のリカバリ・アプライアンスに転送するカスケード・レプリケーションも示されます。
- 自動のcopy-to-tapeポリシーが有効になっている場合、リカバリ・アプライアンスがバックアップをテープにアーカイブします。
  
  図2-1では、中央のリカバリ・アプライアンスがOracle Secure Backupソフトウェアを使用してテープ・デバイスと通信しています。また、レプリケーション・スキームで最もダウンストリーム側にあるリカバリ・アプライアンスもバックアップをテープにアーカイブしています。この方法には次のメリットがあります。
  - 冗長性を実現するために、同一のバックアップが2つのテープ・デバイスに存在します。図2-1では、プライマリ・リカバリ・アプライアンスと最もダウンストリーム側のリカバリ・アプライアンスがテープにアーカイブしています。
  - ダウンストリーム・リカバリ・アプライアンスがテープにバックアップすることで、アップストリーム・リカバリ・アプライアンスのテープ・アーカイブ処理の負担を軽減できます。
- リカバリ・アプライアンスは、バックアップおよびREDOが有効であることを定期的に確認します。
  
  リカバリ・アプライアンスは、ディスクにあるバックアップを、インバウンド・レプリケーションとアウトバウンド・レプリケーション中に自動的に検証します。リカバリ・アプライアンスは、テープ・バックアップのクロスチェックを自動的に実行します。データ・ファイルのバックアップの場合と同じように、リカバリ・アプライアンスは、すべての操作においてREDOログ・ブロックの整合性を検証します。これには、保護されたデータベースからREDOを受信し、これを圧縮されたアーカイブ・ログのバックアップ・セットに格納する処理が含まれます。RMAN VALIDATEコマンドを手動で実行する必要はありません。
- リカバリ・アプライアンスが、自動デルタ・プール領域管理を実行します。
  
  このフェーズでは、ディスクとテープ両方で不要になったバックアップや期限切れになったバックアップの削除や、デルタ・プールの最適化が行われます。