リカバリ・アプライアンスの概要

1 リカバリ・アプライアンスの概要

クラウド規模のZero Data Loss Recovery Appliance (通常、リカバリ・アプライアンスと呼ばれる)は、エンタープライズ内のすべてのOracleデータベースでデータ損失とバックアップ・オーバーヘッドを劇的に削減するエンジニアド・システムです。Recovery Manager (RMAN)と統合したリカバリ・アプライアンスによって、クラウド規模の耐障害性の高いハードウェアと記憶域を使用し、多数のデータベースに対応する、集中管理された永久的増分バックアップ計画が実現します。リカバリ・アプライアンスでは、継続してバックアップのリカバリ可能性が検証されます。

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

従来のデータベース・バックアップ方法

すべての本番Oracleデータベースではデータ保護が必要です。Oracleでは優先バックアップ・ソリューションとしてRMANを提供しています。ほとんどのエンタープライズは、この項で説明する1つ以上のデータベース・バックアップ計画を採用しています。

週次完全バックアップと日次増分バックアップ

図1-1に示す一般的なアプローチの1つでは、RMANを使用して、完全バックアップを毎週、増分バックアップを毎日作成します。増分バックアップのパフォーマンスを向上させるには、ブロック変更トラッキングを有効化することをお薦めします。このようなバックアップは、データベースに対するアクティビティが最も少ないときに行われます。

図1-1 テープへの完全バックアップと増分バックアップ

「図1-1 テープへの完全バックアップと増分バックアップ」の説明

この方法のメリットは、本番サーバーに影響するバックアップ・ウィンドウが、増分バックアップを作成する日には比較的短いことです。デメリットは、複数のグローバル・タイムゾーンに合せて稼働している場合のようにデータベースが継続してアクティブなときには、バックアップ・ウィンドウを設定しにくいことです。

1つのソリューションは、Oracle Data Guardを設定して、スタンバイ・データベースをバックアップすることです。こうすると、バックアップの負荷を本番サーバーから除くことができます。ただし、多くの場合、すべてのデータベースをOracle Data Guardで保護することは実用的ではありません。

増分バックアップとRECOVER COPY

図1-2に示すRMANのアプローチは、増分バックアップを毎日作成し、RECOVER COPYコマンドを使用して、増分変更をデータベース全体のコピーにマージします。こうすると、ディスク上のデータベース・コピーが毎日「ロール・フォワード」されます。

図1-2 ディスクでのRECOVER COPYとテープへのバックアップ

「図1-2 ディスクでのRECOVER COPYとテープへのバックアップ」の説明

この方法には次のメリットがあります。

完全バックアップは最初に1回しか必要ないため、毎週のバックアップ・ウィンドウの合計時間が短縮されます。
RMAN SWITCHコマンドで制御ファイルにデータベース・コピーを指定できます。これにより、コピーが実際のデータベース・ファイルになり、RESTOREステップが省かれます。

デメリットは次のとおりです。

データベース全体のコピーをディスクに保持するために十分なディスク領域と、そのリカバリに必要なアーカイブREDOログ・ファイルが必要です。
データベースの物理コピーが1つしか存在しません。どのポイント・イン・タイムのコピーを保存するかを選択しますが、リカバリできるのはそれ移行のポイント・イン・タイムです。たとえば、過去1週間の任意のポイント・イン・タイムにリストアするには、物理コピーがSYSDATE-7よりも古いことが必要です。デメリットは、次のとおりです。
- データベースのコピーを保存した時点よりも前の時点にはリカバリできません。
- リカバリのポイント・イン・タイムが現在時刻に近くなるほど、リストアしてコピーに適用する必要がある増分バックアップ数が増加します。この方法では、全体のリカバリ時間の目標が延長されます。
データベース・コピーを圧縮または暗号化できません。

サードパーティの重複除外アプライアンスへの完全バックアップ

RMANによる増分バックアップとテープ・ドライブのかわりに、サードパーティの重複除外アプライアンスを使用してバックアップ・ストリームを処理する場合もあります。図1-3では、集中管理されるサードパーティ・アプライアンスに3つのデータベースが書き込んでいます。

図1-3 サードパーティの重複除外アプライアンス

「図1-3 サードパーティの重複除外アプライアンス」の説明

この方法には次のメリットがあります。

一元管理されるバックアップの場所で、環境内のすべてのデータベースを処理します。
サードパーティ・ソフトウェアが、バイト・レベルおよびサブバイト・レベルでパターンを検索し、バックアップ間の冗長なデータを消去します。たとえば、完全データベース・バックアップが1週間前のバックアップとほぼ同一である場合、ソフトウェアは、受け取るバックアップ・ストリームから冗長ビットを除去しようとします。
ネットワーク・ロードを抑えるために、ソース側で重複除外を利用することもできます。この場合、バックアップ・ストリームはサードパーティ・アプライアンスではなくデータベース・ホスト上で重複除外されます。通常、この処理ではRMAN SBTプラグインを使用します。

デメリットは次のとおりです。

これらのサードパーティ・アプライアンスではOracleデータベース・ブロックは認識されず、検証されません。アプライアンスの観点からは、データベース・バックアップはファイル・システムのバックアップと同じバイト・ストリームとして認識されます。
重複除外が有効になるのは、冗長性の高い完全データベース・バックアップのみです。多くの場合、増分バックアップを使用する計画では高い重複除外率が達成されることはありません。
サードパーティ・アプライアンスによって、使用するOracle Databaseの機能が指定されます(逆ではありません)。多くの場合、アプライアンスの要件に従うことは、既存のバックアップ・スクリプトの再作成を意味します。

サードパーティの記憶域スナップショット

サードパーティの記憶域スナップショットは、スナップショットの作成時に存在していた記憶域ブロック(Oracleブロックではない)に対するポインタのセットです。この仮想コピーは、元のデータと同じストレージ・アレイに存在します。図1-4は、サードパーティ・スナップショットの1つであるcopy-on-writeスナップショットです。スナップショットが作成された後で、記憶域ブロックに対する最初の変更が発生すると、アレイは変更前イメージ・ブロック(C)をディスク上の別の場所にコピーし、新しいブロック(C')を元の場所に書き込みます。

図1-4 サードパーティのcopy-on-writeスナップショット

「図1-4 サードパーティのcopy-on-writeスナップショット」の説明

この方法には次のメリットがあります。

データベースの初期コピーが必要ありません。スナップショットはブロックの物理コピーとして保存されるわけではないためです。したがって、RMAN計画に比べて使用される記憶域が少なくなります。
スナップショットの処理は非常に高速です。データベースをバックアップ・モードにしてから(記憶域がスナップショット記憶域最適化の要件を満たさない場合を除く)、スナップショットを作成します。スナップショットが物理ブロックを格納する必要があるのはブロックが変更される場合のみです。つまり、変更されていないファイルのバックアップではメタデータしか処理されません。
スナップショットは記憶域を効率よく使用します。1ブロックしか変更されていないファイルのバックアップでは、格納する必要があるのは該当ブロックのもう1つのバージョンのみです。スナップショットの方法に応じて、ブロックの古いバージョンか新しいバージョンが格納されます。

デメリットは次のとおりです。

スナップショットは、Oracleデータベース・ブロック構造を認識していないため、Oracleブロックを検証できません。
スナップショットはソース・データベースと同じストレージ・アレイに存在するため、記憶域の障害やデータ破損に対して脆弱です。アレイにアクセスできない場合、または記憶域にデータ・ブロックの破損が含まれる場合は、スナップショットをリカバリに使用できません。
その場でスナップショットをリストアすると、そのスナップショットの後で作成されたすべてのスナップショットが無効になります。スナップショットは別の場所に完全にリストアする必要があります。

関連項目:

データベースのサードパーティ・スナップショットを作成するための記憶域スナップショット最適化の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

現在のエンタープライズにおけるデータ保護の課題

現在のビジネスでの情報テクノロジの役割は、大きな転換期を迎えています。この転換を推し進める主な要因は次のとおりです。

データの増大

多くの組織でデータの急激な増大が止まりません。このため、効率的なデータの管理と保護の必要性が高まっています。数十個のデータベースにふさわしい計画は、数百あるいは数千個のデータベースには適していない場合があります。多くの場合、これらは複数の物理サーバー上の様々なプラットフォームで稼働しています。
リアルタイム分析

組織は、クリティカルなリアルタイム意思決定を行うためにデータ分析への依存度を増しています。このため、データ整合性を維持しデータ損失を防ぐことが求められています。
連続的なグローバル対応の高可用性

多くのデータベースは複数のタイムゾーンに対して24時間/週7日のアクセスを提供しています。つまり、データベースは絶えずアクティブな状態です。

「従来のデータベース・バックアップ方法」で説明した保護計画は、このような転換によって浮上した課題を解決するものではありません。エンタープライズは一貫したバックアップとリカバリの計画が欠けていたことを認識しています。従来のデータベース・バックアップ方法のほとんどまたはすべてに共通する欠点を次に示します。

データ損失の危険性

データベースをリカバリできるのは、最も新しい有効なバックアップのみですが、それも数時間または数日前に作成されたものです。また、記憶域スナップショットとサードパーティ・アプライアンスは、Oracleデータ・ブロックを検証できず、Oracleブロックレベルの破損も検出できません。
バックアップ・ウィンドウの長さ

データベースのサイズが大きくなると、バックアップ・ウィンドウも長くなり、本番システムの負荷が大きくなります。クリティカル・データベースは、毎日のバックアップやそれに伴う保守アクティビティにリソースを費やす余裕がありません。
バックアップの検証の欠如

ほとんどのサードパーティ・バックアップ・スナップショットとリカバリ・アプライアンスには、Oracleに統合されているデータ・ブロックとデータベースのバックアップの検証機能がないため、リストアとリカバリの操作が失敗する可能性が高くなります。このような失敗によって停止時間が延長し、データ損失が拡大することもあります。
総合的な視野の欠如

データベースの数が急増すると、管理の容易性は低下します。バックアップ・スクリプトが増加して変化します。新しいDBAは、従来のスクリプトの実行内容の理解に苦労することがあります。特定のデータベースのステータス、バックアップの場所およびリカバリ・ポイントの目標(RPO)に関する質問に回答するのが難しくなります。

従来の方法では、大規模なエンタープライズのOracle環境の要求に応える、包括的で効率の高いOracle統合データ保護ソリューションは提供されません。新しいアプローチが求められています。

Oracleのリカバリ・アプライアンス・ソリューション

リカバリ・アプライアンスは、エンタープライズ全体のすべてのOracleデータベースを保護するように設計された、クラウド規模のエンジニアド・システムです。データベースのバックアップとリカバリのほとんどの処理は、集中管理されるリカバリ・アプライアンスで実行され、記憶域使用率、パフォーマンスおよびバックアップの管理性が向上します。

リカバリ・アプライアンスは、RMAN の永久的増分計画を使用して、複数のOracle Databaseのバックアップを1つの統合ディスク・プールで格納および管理します。リカバリ・アプライアンスは、データベース・ブロック・レベルで継続的にバックアップの圧縮、重複解除および検証を行い、一方ではオンデマンドで仮想完全バックアップを作成します。

仮想完全バックアップは、1つのポイント・イン・タイムでの完全なデータベース・イメージです。リカバリ・アプライアンスによる保護データベースの増分バックアップのインデックス化を通じて、仮想完全バックアップは効率よく管理されます。仮想完全バックアップは、受け取ったどの増分バックアップにも対応できます。

図1-5に、サンプルのリカバリ・アプライアンス環境の概要を示します。

図1-5 リカバリ・アプライアンス環境

「図1-5リカバリ・アプライアンス環境」の説明

図1-5に示すように、保護データベースはデータをリカバリ・アプライアンスにバックアップするクライアント・データベースです。各保護データベースは、バックアップのためにZero Data Loss Recovery Applianceバックアップ・モジュール (リカバリ・アプライアンス・バックアップ・モジュール)を使用します。このモジュールは、RMANがネットワークを介したバックアップ・データのリカバリ・アプライアンスへの転送に使用する、Oracle提供のSBTライブラリです。

リカバリ・アプライアンス・メタデータ・データベース(各リカバリ・アプライアンスに存在する)は、RMANリカバリ・カタログに格納されるメタデータと、リカバリ・アプライアンスの記憶域の場所にあるバックアップを管理します。このカタログは、すべての保護データベースがバックアップをリカバリ・アプライアンスに送信するために必要です。

注意:

データベースは、リカバリ・アプライアンスをバックアップ・リポジトリとしては使用せずに、リカバリ・カタログとして使用できます。

管理者は、Oracle Enterprise Manager Cloud Control (Cloud Control)を使用して環境を管理およびモニタリングします。Cloud Controlでは、バックアップが存在する場所(ディスク、テープまたは別のリカバリ・アプライアンス)にかかわらず、各データベースのバックアップ・ライフサイクル全体を一目で把握することができます。

リカバリ・アプライアンスには、次のメリットがあります。

関連項目:

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

データ損失の解消

リカバリ・アプライアンスは様々なメカニズムを使用して、物理ブロック破損も含め、多様なデータ損失からデータを保護します。この項には次のトピックが含まれます:

実行中のトランザクションの保護

従来のバックアップ方法では、オンラインREDOログが失われると、メディア・リカバリは、使用可能な最新のアーカイブREDOログ・ファイルまたは増分バックアップ以降のすべての変更を失います。従来の方法から導出した1日以上のリカバリ・ポイントの目標(RPO)を許容できないことがあります。

リカバリ・アプライアンスでは、保護されたデータベースからアプライアンスへのREDO変更を継続的に送信することより、RPOの問題を解決します。この操作は、リアルタイムREDOトランスポートと呼ばれています。デルタ・プッシュを使用するため、リカバリ・アプライアンスはOracle Database 11gおよびOracle Database 12cデータベースからの非同期REDOトランスポート・サービスのリモート宛先です。

注意:

このテクノロジは、Oracle Data GuardのリアルタイムREDOトランスポート・アルゴリズムに基づいています。保護されたデータベースのパフォーマンスが低下しないようにするために、REDOはリカバリ・アプライアンスに非同期で転送されます。保護されたデータベースが失われると、ほとんどの場合、ゼロから1秒未満のデータ損失が予想されます。

関連項目:

リアルタイムREDOトランスポートの詳細は、「リアルタイムREDOトランスポート」を参照してください
「デルタ・プッシュ」
Oracle Data GuardのREDOトランスポートの詳細は、『Oracle Data Guard概要および管理』を参照してください

セキュア・レプリケーション

サーバーまたはサイトの停電に備えて、あるリカバリ・アプライアンスから別のリカバリ・アプライアンスにバックアップをレプリケートできます。図1-6は、最も単純な形のレプリケーションである一方向リカバリ・アプライアンス・レプリケーションです。ここでは、アップストリーム・リカバリ・アプライアンス(バックアップの送信側)がダウンストリーム・リカバリ・アプライアンス(バックアップの受信側)にバックアップを送信しています。

図1-6 一方向レプリケーション

「図1-6 一方向レプリケーション」の説明

図1-6では、保護データベースは増分バックアップをリカバリ・アプライアンスに送信し、リカバリ・アプライアンスがそれをダウンストリーム・リカバリ・アプライアンスにレプリケートするためにキューに入れます。アップストリーム・リカバリ・アプライアンスが増分バックアップをダウンストリーム・リカバリ・アプライアンスに送信すると、通常どおりに仮想完全バックアップが作成されます。ダウンストリーム・リカバリ・アプライアンスがリカバリ・カタログにバックアップ・レコードを作成します。アップストリーム・リカバリ・アプライアンスがレコードをリクエストすると、ダウンストリーム・リカバリ・アプライアンスがレコードを伝播します。

ローカルのリカバリ・アプライアンスが仮想完全バックアップのリクエストに応じられない場合、そのリクエストをダウンストリーム・リカバリ・アプライアンスに転送します。そして、ダウンストリーム・リカバリ・アプライアンスが仮想完全バックアップを保護データベースに送信します。DBAは通常どおりRMANを使用します。バックアップ・セットが格納されている場所や方法を理解する必要はありません。

関連項目:

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

自律型テープ・アーカイブ

堅牢なバックアップ計画により、意図的な攻撃、不注意のユーザー・エラー(ファイル削除など)、ソフトウェアやハードウェアの障害からデータが保護されます。テープ・ライブラリは、このような可能性に対してデータを効率よく保護します。

図1-7に、各ホストにメディア・マネージャがインストールされた、従来のテープ・バックアップの方法を示します。

図1-7 リカバリ・アプライアンスを使用しないテープへのバックアップ

「図1-7 リカバリ・アプライアンスを使用しないテープへのバックアップ」の説明

図1-8に、リカバリ・アプライアンスでのテープ・バックアップ方法を示します。これら2つの方法の根本的な違いは、保護データベースではなくリカバリ・アプライアンスがテープにバックアップすることです。リカバリ・アプライアンスは、事前にインストール済のOracle Secure Backupソフトウェアに含まれ、オプションでファイバ・チャネル・カードをサポートします。したがって、保護データベース・ホストにメディア・マネージャをインストールする必要はありません。

図1-8 リカバリ・アプライアンスを使用したテープへのバックアップ

「図1-8 リカバリ・アプライアンスを使用したテープへのバックアップ」の説明

リカバリ・アプライアンスが仮想完全バックアップのcopy-to-tapeジョブを実行するときは、物理バックアップ・セットを作成してから、それらをテープにコピーし、メタデータをリカバリ・カタログに書き込みます。必要であれば、リカバリ・アプライアンスで連続増分バックアップやアーカイブREDOログ・ファイルをテープにコピーすることもできます。リカバリ・アプライアンス上のバックアップが仮想であるのに対して、テープ上のバックアップは仮想ではない完全物理バックアップです。リカバリ・アプライアンスは、テープからバックアップをリストアするリクエストを自動的に処理します。管理者が操作する必要はありません。

リカバリ・アプライアンスのテープ・ソリューションのメリットは次のとおりです。

リカバリ・アプライアンスが、テープにコピーするためのすべての処理を自動的に実行し、保護データベース・ホストにはパフォーマンス・ロードはかかりません。
テープのバックアップは最適化されています。リカバリ・アプライアンスは、インテリジェント機能を使用して、テープ用の非仮想完全バックアップの作成に必要なブロックを収集します。
Oracle Secure Backupが事前にインストール済であるため、サードパーティのメディア・マネージャにコストをかける必要がありません。

注意:

既存のテープ・バックアップ・ソフトウェアおよびプロセスと統合するためにサードパーティ・ベンダーのテープ・バックアップ・エージェントをデプロイしてもかまいません。この構成では、エージェントは専用のメディア・サーバーに接続する必要があり、そのメディア・サーバーはリカバリ・アプライアンスの外部にデプロイする必要があります。
テープ・ドライブとテープ・ライブラリの効率が向上します。これは、リカバリ・アプライアンスが1つの大きな集中管理システムであり、テープ・ドライブとテープ・ライブラリを完全に制御できるためです。他のテープ・ソリューションでは、数百または数千のデータベースが協調せずにテープ・リソースを競合する可能性があります。

関連項目:

エンドツーエンド・データ検証

バックアップおよびリカバリの基本原則は、バックアップを正常にリストアできることです。バックアップされたデータ・ブロックに物理的な破損がないことを保証するために、バックアップを定期的に検証する必要があります。検証には通常、RMAN RESTORE VALIDATEジョブの定期的な実行と、別のマシンへの完全リストアおよびリカバリ操作の定期的な実行が含まれます。

リカバリ・アプライアンスによって提供されるエンドツーエンド・ブロック検証は、ワークフローの次のステージで行われます。

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

リカバリ・アプライアンスは、バックアップをディスクに書き込む前に、バックアップ収集フェーズでバックアップ・ストリームを自動的に検証します。リカバリ・アプライアンスは、また、リストア・フェーズ中にバックアップを元のまたは代替のデータベース・サーバーに送信する前に、バックアップを検証します。そのため、手動のRESTORE VALIDATEステップは必要ありません。

また、リカバリ・アプライアンスで実行しているバックグラウンド・タスクによって、デルタ・プール内の仮想完全バックアップの整合性が定期的に検証されます(「デルタ・プール」を参照)。このタスクの目標は、保護された各データベースのそれぞれの仮想完全バックアップの各ブロックを確認し、最小アクティビティが発生しているときにバックグラウンドで動作することです。デフォルトで、ディスク上のデータベースのバックアップの現在のセットの検証が最後に完了した後、検証タスクは14日ごとに実行されます。

データ・ファイルのバックアップの場合と同じように、Recovery Applianceは、すべての操作においてREDOログ・ブロックの整合性を検証します。これには、保護されたデータベースからREDOを受信し、これを圧縮されたアーカイブ・ログのバックアップ・セットに格納する処理が含まれます。
Oracle Automatic Storage Management(ASM)

Oracle ASMはRecovery Applianceのためにバックアップ・データおよびREDOデータを格納します。Oracle ASMのミラー・コピーによって冗長性が実現します(「リカバリ・アプライアンスの記憶域の場所」を参照)。

プライマリ・ミラーで破損したブロックが読み取られた場合、リカバリ・アプライアンスはブロックをミラー・コピーから自動的に修復します。このメカニズムによって、切り離されたブロック破損ケースのほとんどが解決されます。
テープ・ライブラリ

リカバリ・アプライアンスがブロックを検証するのは、テープにコピーするときと、テープからリストアするときです(「テープ・アーカイブ」を参照)。
レプリケーション構成のダウンストリーム・リカバリ・アプライアンス

レプリケーションを構成すると、ダウンストリーム・リカバリ・アプライアンスがバックアップ収集フェーズとリストア・フェーズでデータを検証します(「ダウンストリーム・リカバリ・アプライアンスによるバックアップの処理方法」を参照)。

ここで説明したバックアップ検証プロセスはどれも本番データベース・ホストでは行われません。本番リソースはよりクリティカルな操作ワークロードのために解放されます。

注意:

Oracle最大可用性アーキテクチャのベスト・プラクティスでは、定期的な完全データベース・リカバリ・テストを実行して、操作の実践を確認し、メディア・リカバリ中にのみ発生する可能性のある問題を検出することをお薦めしています。

関連項目:

validate_db_days構成パラメータの詳細は、「CONFIG」を参照してください。
RA_DATABASE.LAST_VALIDATE列の詳細は、「RA_DATABASE」を参照してください。

最小限のバックアップ・オーバヘッド

従来のデータベース・バックアップ方法では、Oracle Databaseホストが処理の大半を実行します。ディスク・バックアップ、テープ・バックアップおよび重複除外のエージェントがすべてそのホストで実行することがあります。さらに、すべてのバックアップ操作(圧縮、検証、削除、マージなど)もデータベース・ホストで実行されます。このようなオーバーヘッドによってデータベースのパフォーマンスが大幅に低下する可能性があります。

リカバリ・アプライアンスによって、保護データベースから負荷のほぼすべてが取り除かれます。ホスト(プライマリ・データベース・ホストまたはスタンバイ・データベース・ホストである場合があります)に求められる唯一のバックアップ操作は、増分バックアップのRecovery Applianceへの送信のみです。永久的増分計画によって、データベース・ホストでのバックアップ・ウィンドウが大幅に短縮されます。リカバリ・アプライアンスが、バックアップ処理、テープ操作、データ整合性チェックおよびルーチン保守を行います。

注意:

リカバリ・アプライアンスは、Oracle Databaseのバックアップのみをサポートし、ファイル・システム・データおよびOracle以外のデータベースはサポートしません。

リカバリ・アプライアンスは、図1-9に示すようにデルタ・プッシュとデルタ・ストアを使用してデータベースの変更部分の管理を最適化します。デルタ・プッシュとデルタ・ストアによって、最終的にバックアップ・ウィンドウの長期化の問題が解消されます。DBAは高速増分バックアップのみを実行し、リカバリ・アプライアンスにバックアップ・ブロックの管理を任せます。

図1-9 デルタ・プッシュとデルタ・ストア

「図1-9 デルタ・プッシュとデルタ・ストア」の説明

関連項目:

「従来のデータベース・バックアップ方法」

デルタ・プッシュ

このソリューションは、各保護データベースで実行される、永久的増分バックアップ計画とリアルタイムREDOトランスポートの2つの操作で構成されます。どちらの操作でも、保護データベースが変更部分をリカバリ・アプライアンスにプッシュします。

永久的増分計画では、各保護ファイルの存続期間でリカバリ・アプライアンスへの増分レベル0バックアップが1つのみ必要です。最初のレベル0バックアップには、コミットされたUNDOブロックおよび現在使用されていない内ブロックは含まれません。

注意:

コミットされたUNDOブロックおよび現在使用されていないブロックの除外は、リカバリ・アプライアンスまたはOracle Secure BackupへのSBTフル・バックアップに対してのみサポートされています。その他のバックアップ製品へのSBTバックアップでは使用できません。

通常の操作では、リカバリ・アプライアンスは増分レベル1バックアップごとに次の手順を自動的に実行します。

各保護データベースから、スケジュール設定された増分レベル1バックアップを受け取ります。
受信したバックアップを検証して、物理ブロック破損からデータを保護します。
特別なブロックレベル・アルゴリズムを使用してバックアップを圧縮します。
バックアップをリカバリ・アプライアンスの記憶域の場所にあるデルタ・ストアに書き込みます。

永久的増分計画では、バックアップ・ウィンドウとオーバーヘッドが大幅に抑えられます。最初の増分レベル0バックアップの後では完全バックアップが必要ないためです。この計画にリアルタイムREDOトランスポートが含まれる場合、従来のアーカイブ・ログ・バックアップが必要なくなるため、バックアップ・ウィンドウはさらに短縮されます。また、リカバリ・アプライアンスは、検証、重複除外および圧縮の負荷を負担します。

注意:

表またはハイブリッド列圧縮を使用して圧縮したブロックは、RMANバックアップ内およびリカバリ・アプライアンスの収集フェーズ中圧縮されたままとなります。

関連項目:

「データ損失の解消」

デルタ・ストア

デルタ・ストアは、リカバリ・アプライアンスの主要な処理エンジンです。保護データベースは、データ・ファイルごとに増分レベル0バックアップを1つのみリカバリ・アプライアンスに送信します。最初の完全バックアップの後のすべてのバックアップは、非常に効率的な累積増分バックアップです。

リカバリ・アプライアンスは増分バックアップを受け取ると、インデックスを付けてデルタ・プールに格納します。リカバリ・アプライアンスにバックアップされる各データ・ファイルには、それぞれ独自のデルタ・プール(バックアップ・ブロックのセット)があります。リカバリ・アプライアンスは自動的にデルタ・プールを管理して、多数の仮想完全バックアップを提供できるようにします。

仮想完全バックアップの作成

仮想完全バックアップを作成するには、リカバリ・アプライアンスが、受け取った増分レベル1バックアップを、仮想の増分レベル0バックアップに変換します。仮想完全バックアップは、リカバリ・カタログでは増分レベル0バックアップとして示されます。ユーザーの観点からは、仮想完全バックアップは非仮想完全バックアップと区別できません。リカバリ・アプライアンスは、仮想バックアップを使用して、頻繁なレベル1バックアップのコストのみで頻繁なレベル0バックアップの保護を実現します。

注意:

リカバリ・アプライアンスによって記憶域サービスが提供されますが、仮想完全バックアップではなく RMAN暗号化バックアップ用です(「アーカイブ・バックアップと暗号化バックアップ」を参照)。これらのバックアップは元の暗号化形式で格納されます。リカバリ・アプライアンスは、暗号化されていないRMANバックアップ・セットと同様にそれらの格納、アーカイブおよび取出しを行うことができます。

仮想完全バックアップを使用した高速リカバリ

リカバリ・アプライアンスは仮想完全バックアップを使用して、リカバリ対象のデータ容量にかからわらず、任意のポイント・イン・タイムへの高速リカバリを提供します。リカバリ・アプライアンスのオンディスク・リカバリ計画のメリットは、RMANが増分バックアップを適用しないで仮想完全バックアップを任意のポイント・イン・タイムにリカバリできることです。

データベースがリカバリ・アプライアンスによって保護されている場合、RMANが行う必要があるのは、RPOの日の単一のレベル0バックアップをリストアし、リアルタイムREDOトランスポート機能を使用して送信されたREDOログ・ファイルを使用して最新の時点にリカバリすることのみです。たとえば、リカバリ・ウィンドウが7日間で、RPOが5日前の場合、RMANは単一の最新仮想完全バックアップ(レベル0)を5日前にリストアしてから、REDO (レベル1増分バックアップではない)を使用してリカバリできます。

関連項目:

「デルタ・ストア」
永久的増分バックアップ計画の詳細は、『Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイド』を参照してください。
リカバリ計画の詳細は、『Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイド』を参照してください。
増分バックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

データ保護の総合的な視点の強化

従来のデータベース・バックアップ方法では、多くの場合、データベース、メディア・サーバーおよびテープ・ドライブの管理が切り離されています。たとえば、DBAグループがデータベースを管理し、別のバックアップ管理者グループがバックアップを管理し、記憶域グループがディスクおよびテープ・デバイスを管理します。プロセス全体を見通しにくいため、リカバリ要件がそれぞれ異なる、数千に及ぶデータベースのバックアップを管理することは難しくなります。

Cloud Controlを使用すると、リカバリ・アプライアンスによって管理されるバックアップのライフサイクル(RMANバックアップがデータベースで開始されたときから、ディスクやテープに格納されるまで、またはダウンストリーム・リカバリ・アプライアンスにレプリケートされるまで)の全貌を完全に把握できます。Zero Data Loss Recovery Applianceプラグイン(リカバリ・アプライアンス・プラグイン)用のEnterprise Managerインストールによって、リカバリ・アプライアンスのモニタリングと管理が有効になります。

Cloud Controlを使用してリカバリ・アプライアンスを管理すると次のメリットがあります。

標準メトリック(バックアップ全体のパフォーマンス、集計またはデータベースごとの領域消費量など)
バックアップやリカバリ・アプライアンスの問題に関する即時アラート

たとえば、定義されたRPOを満たすバックアップがない場合またはバックアップの破損が検出された場合に、Cloud Controlが管理者にアラートを通知することができます。
ステータス・レポート(BI Publisherによる)は容量計画に役立ちます。また、リカバリ・ウィンドウ目標を達成できない保護データベースを特定することもできます。

たとえば、リカバリ・アプライアンスの管理者は、領域とネットワーク使用率の履歴に関するレポートを受け取って、バックアップのボリュームとスループットの傾向を確認することができます。これらの傾向に基づいて、既存ラックへのストレージ・サーバーの追加や追加ラックの接続が必要になります。

Cloud Controlはリカバリ・アプライアンス管理の推奨ユーザー・インタフェースですが、コマンドラインから使用できるDBMS_RA PL/SQLパッケージも提供されています。このマニュアルのほとんどのタスクでは、Cloud ControlとDBMS_RA両方の方法を説明しています。コマンドラインでのモニターおよびレポートでは、リカバリ・アプライアンス・カタログ・ビューを問い合せることができます。

関連項目:

クラウド規模の保護

リカバリ・アプライアンスがクラウド・レベルに拡張されると、数十から数百、さらにはデータ・センターの数千のデータベースをサポートするようになります。基本的に、リカバリ・アプライアンスを使用するとエンタープライズ内にプライベートなデータ保護クラウドを作成できます。リカバリ・アプライアンス内の次のテクノロジ・コンポーネントによってこれが可能になります。

ポリシーベースのデータ保護管理

リカバリ・アプライアンスは保護ポリシーを使用して管理を単純化します。次の利点があります。

保護ポリシーは、リカバリ・アプライアンスまたはテープ・デバイスへのバックアップに関して各データベースに適用されるリカバリ・ウィンドウ目標を定義します。

保護ポリシーを使用すると、リカバリ・サービス階層ごとにデータベースをグループ化できます。たとえば、プラチナ・ポリシーで保護されているデータベースでは、バックアップをリカバリ・アプライアンスで45日間、テープで90日間保持する必要がありますが、これは、経過期間が45日間以下のバックアップはディスクとテープに存在するが、45日間を超えるバックアップはテープにのみ存在することを意味します。ゴールド・ポリシーで保護されるデータベースは、バックアップをローカル・リカバリ・アプライアンスには35日間、テープには90日間保存する必要があります。領域の消費を制限するため、または指定期間を超えてバックアップを保存できないことを規定するサービス・レベル合意に準拠するために、必要に応じて、各ポリシーに最長保存期間を定義することもできます。
保護ポリシーは、データベースをグループ分けして管理性を向上させるための手段です。

たとえば、特定の保護ポリシーでリカバリ・アプライアンスのレプリケーションまたはcopy-to-tapeを構成できます。こうすると、このポリシーが関連付けられたすべてのデータベースにその構成が適用されます。データベースをポリシーに追加すると、データベースは自動的にポリシーの構成とスケジュールを継承します。

関連項目:

データベース認識領域管理

リカバリ・アプライアンスは保護ポリシーを使用し、各保護データベースのリカバリ・ウィンドウ目標に合せて、バックアップ記憶領域を管理します。このきめ細かいデータベース指向の領域管理方法により、サードパーティのアプライアンスで行われているように記憶域ボリューム・レベルで領域を管理する必要がなくなります。

領域が使用可能な場合、リカバリ・アプライアンスはリカバリ・ウィンドウ目標よりも古いバックアップを保存でき、ポイント・イン・タイム・リカバリ期間を効率よく延長できます。領域が不足している場合、リカバリ・アプライアンスは定義済のしきい値を使用してバックアップをパージします。リカバリ・アプライアンスは、各データベースのリカバリ・ウィンドウ目標を満たすように、領域を自動的にプロビジョニングします。

関連項目:

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

スケーラブルなアーキテクチャ

「従来のデータベース・バックアップ方法」のアプローチでは、パフォーマンス・ボトルネックや障害点の多重化が発生しがちです。データベース数が増えるにつれ、メディア・サーバー、ディスク・アレイ、テープ・デバイスおよびサードパーティ・アプライアンスの数も増え、全体が複雑になります。「デバイスを追加する」アプローチはスケーラブルではありません。対照的に、リカバリ・アプライアンスは、計算や記憶領域のリソースを単純なモジュラー形式で追加することで、バックアップ・トラフィック、記憶域使用率、データベース数の増加に対応するように拡張できます。

関連項目:

ストレージ・サーバーの追加の詳細は、Zero Data Loss Recovery Applianceオーナーズ・ガイドを参照してください。

最大可用性: Oracle Data Guardと連携するリカバリ・アプライアンス

Oracle Data Guardは、リカバリ・アプライアンスと統合できる高可用性(HA)および障害回復のソリューションのコンポーネントであり、最大限のデータ保護を提供します。Oracle Data Guardは、保護されたデータベースの同期化されたスタンバイ・データベースを維持することによって、サービス中断および生じたデータ損失を最小限に抑えます。プライマリ・システムを使用できない場合、ローカルのリカバリ・アプライアンスへのバックアップを含め、Data Guardのフェイルオーバー操作後、スタンバイ・システムが即座にプライマリ・システムの通常操作を行います。図1-10に、リカバリ・アプライアンスとOracle Data Guardの環境の例を示します。

図1-10 Oracle Data Guardと連携するリカバリ・アプライアンス

「図1-10 Oracle Data Guardと連携するリカバリ・アプライアンス」の説明

図1-10では、プライマリ・データベースとスタンバイ・データベースがそれぞれ、ローカルのリカバリ・アプライアンスに増分バックアップを送信します。プライマリ・データベースはリアルタイムREDO変更をローカルのリカバリ・アプライアンスとフィジカル・スタンバイの両方に送信し、スタンバイ・データベースはREDO変更をリモートのリカバリ・アプライアンスにカスケードします。各リカバリ・アプライアンスには同じデータベースのバックアップおよびREDO情報が存在するため、いずれかのアプライアンスをRMANリストアおよびリカバリ操作に使用できます。

関連項目:

Oracle Data Guardと連携するリカバリ・アプライアンスの詳細は、http://www.oracle.com/technetwork/database/availability/disaster-recovery-2526839.pdfを参照してください
Oracle Data Guardの詳細は、『Oracle Data Guard概要および管理』を参照してください。

次に行うこと

リカバリ・アプライアンスの使用を開始するには、次のトピックを参照してください。

「リカバリ・アプライアンスのアーキテクチャ」を読んで、リカバリ・アプライアンス環境の主なコンポーネントに対する理解を深めます(オプション)。
「リカバリ・アプライアンスのワークフロー」を読んで、基本的なツールとタスクについて学びます。データ保護のためにリカバリ・アプライアンスを使用するには、その前に次のトピックで説明するタスクを実行する必要があります。