保護されたデータベース

保護データベースは、集中管理される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 リカバリ・アプライアンス・バックアップ・モジュール」の説明

関連項目:

リカバリ・アプライアンス・バックアップ・モジュールのインストール方法を学習するには、『Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイド』を参照してください
SBTのチャネルとデバイスについてさらに学習するには、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

保護ポリシー

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

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

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

サービス階層	リカバリ・ウィンドウ	追加設定
プラチナ	ディスクに45日間、テープに90日間^脚注 1	データベース・バックアップ、リアルタイムREDOトランスポート、レプリケーションおよびテープ・バックアップ。すべての設定が必須です。
ゴールド	ディスクに35日間、テープに90日間	データベース・バックアップ、リアルタイムREDOトランスポート、レプリケーションおよびテープ・バックアップ(テープが使用可能な場合)。
シルバー	ディスクに10日間、テープに45日間	データベース・バックアップ、リアルタイムREDOトランスポートおよびテープ・バックアップ(テープが使用可能な場合)。
ブロンズ	ディスクに3日間、テープに30日間	データベース・バックアップおよびテープ・バックアップ(テープがある場合)。リアルタイムREDOトランスポートはありません。

^脚注1

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

関連項目:

リアルタイムREDOトランスポートの構成方法を学習するには、『Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイド』を参照してください。

保護ポリシーの属性

保護ポリシーは、DBMS_RA.CREATE_PROTECTION_POLICYプロシージャまたはCloud Controlを使用して作成されます。保護ポリシーは、割り当てられているすべての保護されたデータベースに対して次の属性の一部を設定します。一部の属性は相互に排他的です。次に、新しい保護ポリシーで考慮する属性の代表リストを示します。

表2-3 保護ポリシーの属性(サブセット)

属性	説明
`storage_location_name`	バックアップを格納するリカバリ・アプライアンスの記憶域の場所
`polling_policy_name`	オプションのバックアップ・ポーリング・ポリシー。リカバリ・アプライアンスが記憶域の場所をポーリングしてバックアップを探すかどうかを決定します。
`recovery_window_goal`	保護データベースのディスク・リカバリ・ウィンドウ目標
`recovery_window_sbt`	保護データベースの SBT保存期間
`guaranteed_copy`	コピー保証設定。これにより、このポリシーで保護されているバックアップを、削除対象になる前にテープまたはクラウドにコピーする必要があるかどうかを決定します。
`allow_backup_deletion`	これを`NO`に設定すると、RMANユーザーはコンプライアンス・ルールに必要なリカバリ・アプライアンス上のバックアップを削除できなくなります。デフォルト値は`YES`に設定されます。
`store_and_forward`	バックアップおよびREDOフェイルオーバー機能の設定です。この設定は、このポリシーに関連付けられた保護されたデータベースが、プライマリ・リカバリ・アプライアンスの停止時にバックアップおよびREDOをリダイレクトする代替リカバリ・アプライアンスで定義されている保護ポリシーでのみ使用されます。
`max_retention_window`	この保存ポリシーを使用するデータベースのバックアップをリカバリ・アプライアンスが保存する最長期間
`unprotected_window`	現在時刻からデータベースをリストアできる最短時刻までの最長許容時間
`autotune_reserved_space`	この設定は、リカバリ・アプライアンスがこのポリシーに関連付けられているデータベースの`reserved_space`設定を自動的に定義および更新するかどうかを制御するために使用されます。
`recovery_window_compliance`	この設定では、バックアップが削除されないデータベース・バックアップごとの時間範囲を指定します。この値は、`recovery_window_goal`以下である必要があります。値が大きすぎる場合、コンプライアンス保護されたバックアップで`disk_reserved_space`が一杯になる可能性があります。それによって、新しいバックアップが拒否されます。
`keep_compliance`	この設定により、管理者は`RMAN CHANGE`コマンドを使用して、アーカイブ・バックアップに指定された保持期限を縮小できなくなります。`KEEP_COMPLIANCE`が`YES`の場合、`KEEP FOREVER`バックアップは削除されません。 `NO`は、アーカイブ・バックアップの保持期限を`RMAN CHANGE`コマンドで変更できることを意味します。デフォルトは`NO`です。
`max_reserved_space`	保護ポリシーの各データベースに許可される最大`disk_reserved_space`設定。この値の形式は、`0-9`のみで構成される数字の後に、必要に応じて次の単位指定子のいずれかを付けた文字列です。 `max_reserved_space`がNULLとして指定されている場合、データベースの`max_reserved_space`設定はデフォルトで`2 x disk_reserved_space`に設定されます。
`secure_mode`	リカバリ・アプライアンスに格納されているバックアップを暗号化する必要があるかどうかを決定します。 `YES`は、暗号化されたバックアップおよびREDOのみがリカバリ・アプライアンスによって受け入れられることを意味します。 `NO`は、暗号化されていないバックアップをリカバリ・アプライアンスに格納できることを意味します。デフォルトは`NO`です。
`level0_refresh`	指定した場合、リカバリ・アプライアンスは、各バックアップから数個のデータ・ファイルをレベル0のバックアップとして選択します。これにより、新しいレベル0のバックアップ・データの作成が`level0_refresh`間隔で分散されます。リフレッシュ・サイクルは、`INTERVAL '20' DAY` (20日)など、有効な`INTERVAL DAY TO SECOND`式として指定します。値を100日に設定すると、データベースの1%でレベル0のバックアップが毎日実行されます。実際には、100日が完了すると、すべてのデータファイルが`RA_FORMAT=TRUE`(つまりブロック・プールのフォーマット)でレベル0になります。このオプションの目的は、データベースのリストアに必要なデータ暗号化キー(DEK)ハッシュの数を制限することです。レベル1のバックアップごとに、新しいDEKが設定されます。リストア時には、すべてのブロックが、それらに関連付けられているすべてのDEKとともにクライアントに送信されます。収集時には、DEKがカウントされます。バッファの最大DEK数の65%に達すると、そのデータファイルに対して新しいレベル0のリフレッシュが設定されます。

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

保護ポリシーのSECURE_MODEがYESに設定されている場合、暗号化されていないバックアップは、設計によりリカバリ・アプライアンスにアップロードする前に拒否されます。REDOログがリカバリ・アプライアンスに直接送信される場合、REDOログも暗号化する必要があります。ただし、REDO暗号化のチェックはREDOログの完了後に行われるため、リカバリ・アプライアンスで新しいログを開こうとする将来の試行は拒否されます。いくつかのログが開始されてから、REDOが拒否されたことをアーカイブ・ログの宛先ステータスが示す場合があります。この状態は、暗号化されたREDOログ・バックアップがリカバリ・アプライアンスに送信されるとクリアされます。その後、リカバリ・アプライアンスで将来のREDOログ・スイッチが受け入れられます。

ノート:

リリース21.1より前は、場所を問わないバックアップ・コピー(テープまたはクラウド)がバックアップのコピーとしてカウントされ、リカバリ・アプライアンスで削除できるようになります。クラウドとテープの両方がある場合、クラウドとテープのいずれかに不完全なバックアップがある可能性がありますが、リカバリ・アプライアンスではコピーされたセットが誤って考慮されます。さらに、レプリケーションでは、ダウンストリーム・リカバリ・アプライアンスでバックアップを削除でき、バックアップはコピーされないため、アップストリーム・リカバリ・アプライアンスによってリリースされることはありません。

リリース21.1より後では、guaranteed_copy属性がライブラリに追加されました。ライブラリにguaranteed_copyが設定されている場合、リカバリ・アプライアンスはライブラリ内のコピーを直接削除しません。[テープ/クラウド・マネージャもコピーを削除しません。] guaranteed_copy属性を持つ各ライブラリには、リカバリ・アプライアンスからの削除の対象となる前に、特定のバックアップのコピーが必要です。

API create_protection_policyおよびupdate_protection_policyは、protection_policyにguaranteed_copyを設定する前に、guaranteed_copyライブラリ/テンプレート/attribute_setがprotection_policyで使用可能かどうかをチェックします。その他の改善により、ライブラリ、テンプレートまたはattribute_setの変更が、guaranteed_copy属性が設定されたprotection_policyのライブラリ/テンプレート/attribute_setパスの最後の削除から保護されます。

リカバリ・ウィンドウ

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

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

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

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

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

関連項目:

リカバリ・ウィンドウ目標
「テープでのバックアップ保存」
Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイド
リカバリ・ウィンドウの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

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

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

リカバリ・アプライアンスが処理するバックアップを探すためにポーリングする、共有記憶域上のファイル・システム・ディレクトリ(「バックアップ・ポーリングの場所」を参照)
リカバリ・アプライアンスがポーリングする間隔
バックアップ・データを正常に処理した後で削除するかどうか

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

関連項目:

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

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

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