保護ポリシーについて

保護ポリシーの目的

保護ポリシーは、関連付けられるすべてのデータベースの次の項目を指定します。

ディスク・バックアップのリカバリ・ウィンドウ目標
テープ・バックアップのリカバリ・ウィンドウ
バックアップの削除前にリカバリ・アプライアンスがレプリケートまたはテープへのコピーを行う必要があるか
バックアップに使用されるリカバリ・アプライアンスの記憶域の場所
バックアップ・ポーリング・ポリシー(オプション)

複数の保護データベースを1つの保護ポリシーに関連付けることができます。リカバリ・アプライアンスは、様々なデータ保護サポート・レベルに対応するために多様な保護ポリシーを使用できます。たとえば、保護ポリシーを一般的なサービス・レベル(ゴールド、シルバーおよびブロンズ)に合せて作成できます。あるいは、保護データベースとアプリケーションの固有の要件に合せることもできます。

保護ポリシーの概要

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

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

図7-1 保護ポリシー

「図7-1 保護ポリシー」の説明

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

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

保護ポリシー内のすべてのデータベースで次のものを共有する必要があります。
- リカバリ・ウィンドウ・コンプライアンス(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使用率が高くなるためお薦めしません。

ログ圧縮の使用方法の詳細は、保護ポリシー圧縮アルゴリズムの変更(MOSノート・ドキュメントID2654539.1)を参照してください。

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

保護ポリシーのユーザー・インタフェース

この項には次のトピックが含まれます:

Cloud Controlの保護ポリシーの作成ページへのアクセス

Oracle Enterprise Manager Cloud Control (Cloud Control)の保護ポリシーの作成ページは、保護ポリシーを作成するための推奨インタフェースです。

保護ポリシーの作成ページにアクセスするには、次のようにします。

「リカバリ・アプライアンスのホームページへのアクセス」の説明に従って、リカバリ・アプライアンスのホームページにアクセスします。
「リカバリ・アプライアンス」メニューで「保護ポリシー」を選択します。

リカバリ・アプライアンス・ログイン・ページが表示されます。
ログイン資格証明を入力して、「ログイン」をクリックします。

保護ポリシー・ページが表示されます(図7-2の例)。

図7-2 保護ポリシー・ページ

「図7-2 保護ポリシー・ページ」の説明

保護ポリシーに関連するDBMS_RAプロシージャ

DBMS_RAパッケージを使用して、保護ポリシーを作成および管理できます。表7-1に、保護ポリシーに関連する主なプログラム・ユニットを示します。

表7-1 DBMS_RA保護ポリシー・プロシージャ

プログラム・ユニット	説明
`CREATE_POLLING_POLICY`	バックアップ・ポーリング・ポリシーを作成します。
`CREATE_PROTECTION_POLICY`	保護ポリシーを作成します。
`DELETE_PROTECTION_POLICY`	保護ポリシーを削除します。
`UPDATE_PROTECTION_POLICY`	保護ポリシーを更新します。

保護ポリシーのリカバリ・カタログ・ビュー

リカバリ・アプライアンスのカタログ・ビューを使用して保護ポリシーをモニタリングできます。表7-2に、保護ポリシーとの関連が深いビューをまとめています。

表7-2 保護ポリシーのリカバリ・カタログ・ビュー

ビュー	説明
`RA_PROTECTION_POLICY`	このビューは、定義済の保護ポリシーを示します。
`RA_POLLING_POLICY`	このビューは、定義済のバックアップ・ポーリング・ポリシーを示します。
`RA_DATABASE`	このビューの`POLICY_NAME`列に、この保護データベースで使用される保護ポリシーが示されます。
`RA_REPLICATION_CONFIG`	このビューの`PROTECTION_POLICY`列に、レプリケーションで使用される特定のリカバリ・アプライアンスの保護ポリシーが示されます。
`RA_REPLICATION_DATABASE`	このビューの`POLICY_NAME`列に、このレプリケーション・サーバーおよびデータベースに関連付けられている保護ポリシーが示されます。
`RA_REPLICATION_PAIR`	このビューには、保護ポリシーをレプリケートするためのレプリケーション情報がリストされます。
`RA_REPLICATION_POLICY`	このビューの`POLICY_NAME`列に、このレプリケーション・サーバー構成に関連付けられている保護ポリシーが示されます。

保護ポリシーを管理するための基本タスク

この項では、保護ポリシーの管理に含まれる基本的なタスクについて説明します。図7-3は、「リカバリ・アプライアンスのワークフロー」に説明されている全体的なワークフローを、保護ポリシーのタスクを強調して示したものです。

図7-3 リカバリ・アプライアンス・ワークフローの保護ポリシー・タスク

「図7-3 リカバリ・アプライアンス・ワークフローの保護ポリシー・タスク」の説明

通常、保護ポリシーのタスクを実行する順序は次のとおりです。

計画フェーズでは、データベースを階層でグループ分けし、各階層のリカバリ要件を決定します。

「リカバリ・アプライアンスの計画」でこれらのタスクを説明しています。
構成フェーズ(「リカバリ・アプライアンスの設定と構成」を参照)では、各データベース階層に1つの保護ポリシーを作成します。
1. バックアップ・ポーリングの場所へのアクセス権がリカバリ・アプライアンスにあり、コマンドライン・ツールを使用して構成を実行している場合は、必要に応じて、バックアップ・ポーリング・ポリシーを作成します。
  
  「バックアップ・ポーリング・ポリシーの作成(コマンドラインのみ)」でこのタスクについて説明しています。
  
  ノート:
  
  Cloud Controlを使用すると、ポーリング・ポリシーと保護ポリシーを同じページで構成できます。
2. 特定のデータベース階層の保護ポリシーを作成します。
  
  「保護ポリシーの作成」でこのタスクについて説明しています。
進行中のメンテナンス・フェーズでは(「リカバリ・アプライアンスのメンテナンス・タスク」を参照)、必要に応じて保護ポリシーを変更します。一般的な変更タスクには次のものがあります。
- 保護ポリシーの属性を更新します。
  
  「保護ポリシーの更新」でこのタスクについて説明しています。
- 保護ポリシーを削除します。
  
  「保護ポリシーの削除」でこのタスクについて説明しています。