保護ポリシーのガイドライン

効果的な保護ポリシーを作成するためのいくつかの考慮事項を次に示します。

保護ポリシー内のすべてのデータベースで次のものを共有する必要があります。
- リカバリ・ウィンドウ・コンプライアンス(14日/30日など)。これは、リカバリ・ウィンドウ目標よりも小さくする必要があります。リカバリ・ウィンドウ・コンプライアンスはnullにできます。大きすぎる場合、コンプライアンスのための古いバックアップがまだ期限切れになっておらず、受信バックアップで記憶域を再利用できるようになるため、リカバリ・アプライアンスで新しいバックアップが拒否される可能性があります。
- リカバリ・ウィンドウ目標(14日/30日など)。これは目指す目標であり、必要な記憶域の容量の決定に役立ちます。ただし、空き記憶域の容量が小さすぎる場合、最も古いバックアップでは、新しいバックアップ用に記憶域を再利用する場合があります。このような場合、目標は達成されませんが、操作は続行され、受信バックアップの受信は妨げられません。これがリカバリ・ウィンドウ・コンプライアンスとの違いです。
- 最大ディスク保持(デフォルト/21日/35日など)
- テープ保存ポリシー(90日/365日/7年)
- テープ操作スケジュール(日曜日完全/日次増分/日次ARCH)
- レプリケーション構成(レプリケートまたはレプリケートなし、レプリケート先のリカバリ・アプライアンス)
本番データベースをレプリケートする必要があるが、開発データベースではレプリケートしない場合は、2つの保護ポリシーが必要です。

同様に、ある本番データベースはレプリケートする必要があるが、別の本番データベースはレプリケートしない場合、この場合も2つの保護ポリシーが必要です。
地理的な地域や様々な事業部門では、追加の保護ポリシーを意味する場合があります。たとえば、北米とヨーロッパの地域では、2つの保護ポリシーが必要になることがあります。
異なる日に発生するテープ操作には、日ごとに保護ポリシーが必要です。

たとえば、ボリュームが原因で、日曜日に特定のデータベースで週次の完全バックアップを実行し、月曜日にその他のデータベースでバックアップを実行する場合、2つの保護ポリシーが必要です。日曜日にすべてのデータベースで週次の完全バックアップを実行する場合、1つの保護ポリシーのみが必要です。
テープ保持の日数が2つのデータベース間で異なる場合、2つの保護ポリシーが必要です。

保護ポリシーは、リカバリ・アプライアンスのメタデータ・データベースに記録される、名前が付けられた論理オブジェクトです。保護データベースをリカバリ・アプライアンスに追加するには、特定の保護ポリシーに関連付ける必要があります。デフォルトの保護ポリシーは、プラチナ、ゴールド、シルバーおよびブロンズです。

各保護ポリシーは、ディスクおよびテープのリカバリ・ウィンドウに関して異なる値を指定します。これらの値は、ポリシーによって保護される各データベースに適用されます。たとえば、図7-1は、それぞれに異なる保護データベースが割り当てられている3つのデフォルト保護ポリシーを示します。この例では、データベースprod3およびprod11は同じポリシー内にあるため、両方に3日間の同じディスク・リカバリ・ウィンドウ目標があります。

保護ポリシーの更新の例として、顧客は次のいずれかまたは両方の理由で保護ポリシーのLOG_COMPRESSION_ALGORITHM設定を変更することを選択できます。

アーカイブ・ログ・バックアップの作成および圧縮に起因するアプライアンスのCPU使用率の削減。
リストアされたデータ・ファイルにログを適用する前のアーカイブ・ログ・バックアップの解凍に起因する、リカバリ操作中の保護されたデータベースのCPU使用率の削減。

データ型に強く依存しているため、OracleではアルゴリズムによるCPU使用率および圧縮率の詳細な差異は提供しませんが、通常は次のようになります。

LOWおよびMEDIUM設定では、圧縮/解凍の実行でCPUの使用率がBASICおよびHIGHより低くなり、トレードオフとして圧縮率が低くなります(つまり、アプライアンスの領域使用率が高くなります)。
MEDIUMは、ほとんどの場合、CPU使用率と圧縮率のバランスが最適になります。
LOWは、MEDIUMおよびBASICと比較して、CPU使用率が最も低くなりますが、その代償として圧縮率が最も低く(アプライアンスの領域使用率が高く)なります。
OFFは、圧縮を無効にします。

領域が大幅に増加した場合は、LOG_COMPRESSION_ALGORITHMをBASICに戻すことができます。

HIGH設定はCPU使用率が高くなるためお薦めしません。

ノート:

ログ圧縮の使用方法の詳細は、『ZDLRA: 保護ポリシー圧縮アルゴリズムの変更』(ドキュメントID 2654539.1)を参照してください

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