保護ポリシーの属性

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

表7-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です。

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

保護ポリシーの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パスの最後の削除から保護されます。