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

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

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

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

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

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

関連項目:

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

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

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

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

  • ディスク使用率の向上

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

    ノート:

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

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

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

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

Oracle ASMおよびリカバリ・アプライアンスの記憶域

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

関連項目:

DELTA記憶域の場所

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

図2-7 記憶域の場所DELTA

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

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

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

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

関連項目:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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ビューを問い合せて、次にバックアップをパージするデータベースを判別します。

ESTIMATE_SPACEプロシージャは、予約済領域の決定に役立ちます。コンプライアンス保護ポリシーの予約済領域を計算する場合は、周辺条件に対してtarget_windowをRECOVERY_WINDOW_COMPLIANCEと追加の1日にする必要があります。

関連項目:

コピーの保証

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

  • NO (デフォルト)

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

  • YES

    コピーの保証が有効になっている場合は、バックアップがテープまたはクラウドにコピーされないうちにリカバリ・アプライアンスによって削除されることはありません。リカバリ・アプライアンスでは、guaranteed_copy=YESに設定されている、まだすべてのライブラリにコピーされていないバックアップ・データを、disk_reserve_spaceのバイト数までしか保持できません。

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

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

関連項目:

最長保存期間

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

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

関連項目:

リカバリ・ウィンドウ・コンプライアンス

DBMS_RA.CREATE_PROTECTION_POLICYのRECOVERY_WINDOW_COMPLIANCEパラメータは、ポリシーを使用するデータベースごとに、バックアップが削除されない範囲の時間を指定します。これらのバックアップではdisk_reserved_spaceバイトを超える記憶域を使用しないでください。使用する場合は、それらのバックアップが範囲外になるまで新しいバックアップが拒否されます。

RECOVERY_WINDOW_COMPLIANCEはRECOVERY_WINDOW_GOALとは異なり、より多くの制限があります。goalを満たす必要はありませんが、complianceを満たす必要があるためです。目標は、予約記憶域が十分で必要なく、新しいバックアップによって上書きされる場合、リカバリ・アプライアンスが過去30日間の任意の時点に特定のデータベースをリカバリするためのものです。リカバリ・ウィンドウ・コンプライアンスでは、予約記憶域の制約に関係なく、特定のデータベースを過去7日間の任意の時点にリカバリするためにリカバリ・アプライアンスが必要になる場合があります。

バックアップで領域が必要なため、バックアップを格納するために必要な予約領域を予測する必要があります。ESTIMATE_SPACEプロシージャは、予約済領域の決定に役立ちます。予約済領域を計算する場合は、周辺条件に対してtarget_windowをRECOVERY_WINDOW_COMPLIANCEと追加の1日にする必要があります。

ノート:

RECOVERY_WINDOW_COMPLIANCEが大きすぎると、予約記憶域が使用できなくなるため、リカバリ・アプライアンスへの新しいバックアップを追加できません。RECOVERY_WINDOW_COMPLIANCEの消費量が予約済記憶域制限に近づき、受信バックアップ・ピースの使用量がこの制限を超えると、RMANは即時に失敗します。

新しいバックアップのバックアップをより長くまたは短く保持するために、保護ポリシーを変更できます。ただし、特定のバックアップにRECOVERY_WINDOW_COMPLIANCEを設定すると、これは厳密に実行され、RECOVERY_WINDOW_COMPLIANCE期間が期限切れになるまでバックアップは削除されません。

関連項目:

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

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

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

  • CONFIGUREまたはSET ENCRYPTIONを使用して作成されたRMAN暗号化バックアップRMANチャネルがPARMS=(RA_FORMAT=TRUE)で割り当てられている場合は、SET ENCRYPTION ONのバックアップが永久増分に対してサポートされます。

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

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

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

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

関連項目:

領域を効率的に使用する暗号化バックアップ

L0およびL1増分バックアップは、TDEデータベース・バックアップなど、領域を効率的に使用する方法で圧縮および暗号化できます。

RA 23.1でこの機能が提供される前は、TDEデータベースでリカバリ・アプライアンスへの永久増分バックアップがサポートされていました。ただし、暗号化されたデータ形式であるため、リカバリ・アプライアンスでバックアップ圧縮を実行しても、追加の節約はできませんでした。

RA 23.1で、領域を効率的に使用する暗号化バックアップ機能を使用すると、同じウォレットまたはキー・ストアのTDEマスター・キーを、保護されたデータベースに使用して、リカバリ・アプライアンスと連携しているRMANがデータファイル・ブロックを復号化します。その後、ブロックは圧縮されて、新しいデータ暗号化キーで再暗号化されます。次に、できあがったバックアップ・ペイロードが、仮想完全互換用にフォーマットされます。最後に、データ暗号化キーがTDEマスター・キーでラップされて、バックアップに格納されてから、リカバリ・アプライアンスに送信されます。

領域を効率的に使用する暗号化バックアップをリストアする際には、データ・ファイルをデータベース記憶域の宛先に書き込む前に、RMANがリカバリ・アプライアンスのバックアップ・モジュールと連携して、データ・ブロックの復号化、圧縮解除および再暗号化を実行します(TDEの場合)。

リカバリ・アプライアンスは、領域を効率的に使用する暗号化バックアップのライフサイクル(検証、パージなど)をサポートしていますが、データベース・キーへのアクセスやブロック・データの復号化をする必要はありません。これにより、リカバリ・アプライアンスのロールおよび職責を、保護されたデータベースと完全に分離しておくことができます。

ノート:

リストアに必要な古いブロックで古いTDEマスター・キーが必要になる可能性があるため、ウォレットまたはキーストアからキーをパージしないでください。外部記憶域に配置されるバックアップについて考慮することが特に重要です。

古いTDEマスター・キーを保持する必要がある外部ストレージが関係していない場合、TDEマスター・キーに関しては、新しいレベル0バックアップが新しい開始点になります。定期的なレベル0のバックアップを自動化すると、キーの数が増えないようにすることができます。古いバックアップが期限切れになり、パージされるのを待ってから、関連するTDEマスター・キーを取り除いてください。

Oracle Database 23aiより前のデフォルト暗号化アルゴリズムはAES128です。別の暗号化アルゴリズムを設定すれば、そのアルゴリズムを使用できます。

Oracle Database 23ai以降では、デフォルトの暗号化アルゴリズムを構成できます。

領域を効率的に使用する暗号化されたバックアップの構成も参照してください