1. 管理者ガイド
  2. リカバリ・アプライアンスの管理
  3. リカバリ・アプライアンスでの保護ポリシーの管理

8 リカバリ・アプライアンスでの保護ポリシーの管理

この章では、「リカバリ・アプライアンスの設定と構成」に含まれる保護ポリシーとポーリング・ポリシーの管理方法を説明します。

この章の内容は次のとおりです。

保護ポリシーについて

保護ポリシーは、事前定義されたリカバリ・ウィンドウ目標に基づいてバックアップ記憶域の管理を制御するための中心メカニズムです。DBAの観点では、保護ポリシーの最も重要な要素はディスクとテープのリカバリ・ウィンドウです。

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

関連項目:

アーキテクチャの概要については、「保護ポリシー」を参照してください

保護ポリシーの目的

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

  • ディスク・バックアップのリカバリ・ウィンドウ目標

  • テープ・バックアップのリカバリ・ウィンドウ

  • バックアップの削除前にリカバリ・アプライアンスがレプリケートまたはテープへのコピーを行う必要があるか

  • バックアップに使用されるリカバリ・アプライアンスの記憶域の場所

  • バックアップ・ポーリング・ポリシー(オプション)

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

保護ポリシーの概要

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

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

図8-1 保護ポリシー

図8-1の説明が続きます。
「図8-1 保護ポリシー」の説明

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

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

  • 保護ポリシー内のすべてのデータベースで次のものを共有する必要があります。

    • リカバリ・ウィンドウ・コンプライアンス(14日/30日など)。これは、リカバリ・ウィンドウ目標よりも小さくする必要があります。リカバリ・ウィンドウ・コンプライアンスはnullにできます。大きすぎる場合、コンプライアンスのための古いバックアップがまだ期限切れになっておらず、受信バックアップで記憶域を再利用できるようになるため、リカバリ・アプライアンスで新しいバックアップが拒否される可能性があります。

    • リカバリ・ウィンドウ目標(14日/30日など)。これは目指す目標であり、必要な記憶域の容量の決定に役立ちます。ただし、空き記憶域の容量が小さすぎる場合、最も古いバックアップでは、新しいバックアップ用に記憶域を再利用する場合があります。このような場合、目標は達成されませんが、操作は続行され、受信バックアップの受信は妨げられません。これがリカバリ・ウィンドウ・コンプライアンスとの違いです。

    • 最大ディスク保持(デフォルト/21日/35日など)

    • テープ保存ポリシー(90日/365日/7年)

    • テープ操作スケジュール(日曜日完全/日次増分/日次ARCH)

    • レプリケーション構成(レプリケートまたはレプリケートなし、レプリケート先のリカバリ・アプライアンス)

  • 本番データベースをレプリケートする必要があるが、開発データベースではレプリケートしない場合は、2つの保護ポリシーが必要です。

    同様に、ある本番データベースはレプリケートする必要があるが、別の本番データベースはレプリケートしない場合、この場合も2つの保護ポリシーが必要です。

  • 地理的な地域や様々な事業部門では、追加の保護ポリシーを意味する場合があります。たとえば、北米とヨーロッパの地域では、2つの保護ポリシーが必要になることがあります。

  • 異なる日に発生するテープ操作には、日ごとに保護ポリシーが必要です。

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

  • テープ保持の日数が2つのデータベース間で異なる場合、2つの保護ポリシーが必要です。

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

各保護ポリシーは、ディスクおよびテープのリカバリ・ウィンドウに関して異なる値を指定します。これらの値は、ポリシーによって保護される各データベースに適用されます。たとえば、図8-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ログ・スイッチが受け入れられます。

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

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

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

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

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

  1. 「リカバリ・アプライアンスのホームページへのアクセス」の説明に従って、リカバリ・アプライアンスのホームページにアクセスします。

  2. 「リカバリ・アプライアンス」メニューで「保護ポリシー」を選択します。

    リカバリ・アプライアンス・ログイン・ページが表示されます。

  3. ログイン資格証明を入力して、「ログイン」をクリックします。

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

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

    図8-2の説明が続きます。
    「図8-2 保護ポリシー・ページ」の説明
保護ポリシーに関連するDBMS_RAプロシージャ

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

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

プログラム・ユニット 説明

CREATE_POLLING_POLICY

バックアップ・ポーリング・ポリシーを作成します。

CREATE_PROTECTION_POLICY

保護ポリシーを作成します。

DELETE_PROTECTION_POLICY

保護ポリシーを削除します。

UPDATE_PROTECTION_POLICY

保護ポリシーを更新します。

関連項目:

DBMS_RAパッケージのリファレンス

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

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

表8-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列に、このレプリケーション・サーバー構成に関連付けられている保護ポリシーが示されます。

関連項目:

リカバリ・アプライアンスのビュー・リファレンス

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

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

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

図8-3の説明が続きます。
「図8-3 リカバリ・アプライアンス・ワークフローの保護ポリシー・タスク」の説明

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

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

    「リカバリ・アプライアンスの計画」でこれらのタスクを説明しています。

  2. 構成フェーズ(「リカバリ・アプライアンスの設定と構成」を参照)では、各データベース階層に1つの保護ポリシーを作成します。

    1. バックアップ・ポーリングの場所へのアクセス権がリカバリ・アプライアンスにあり、コマンドライン・ツールを使用して構成を実行している場合は、必要に応じて、バックアップ・ポーリング・ポリシーを作成します。

      「バックアップ・ポーリング・ポリシーの作成(コマンドラインのみ)」でこのタスクについて説明しています。

      ノート:

      Cloud Controlを使用すると、ポーリング・ポリシーと保護ポリシーを同じページで構成できます。

    2. 特定のデータベース階層の保護ポリシーを作成します。

      「保護ポリシーの作成」でこのタスクについて説明しています。

  3. 進行中のメンテナンス・フェーズでは(「リカバリ・アプライアンスのメンテナンス・タスク」を参照)、必要に応じて保護ポリシーを変更します。一般的な変更タスクには次のものがあります。

保護ポリシーの作成

この項では、Cloud Control (推奨)またはDBMS_RA.CREATE_PROTECTION_POLICYプロシージャを使用して保護ポリシーを作成する方法について説明します。ベスト・プラクティスは、データベースの各階層に別の保護ポリシーを作成することです(「タスク1: 保護データベースの階層グループ分け」を参照)。

RASYSアカウントで、またはuser_type=adminに設定してdb_userという名前で、リカバリ・アプライアンスにログインする必要があります。

Cloud Controlを使用して保護ポリシーを作成するには、次の手順に従います。

  1. 「Cloud Controlでの保護されたデータベース・ページへのアクセス」に説明されているとおりに、保護されたデータベース・ページにアクセスします。

  2. 「追加」をクリックします。

    保護されたデータベースの追加ページが表示されます。

    図8-4 保護されたデータベースの追加ページ

    図8-4の説明が続きます。
    「図8-4 保護されたデータベースの追加ページ」の説明

  3. 「作成」をクリックします。

    保護ポリシーの作成ページが表示されます。

    図8-5 保護ポリシーの作成ページ

    図8-5の説明が続きます。
    「図8-5 保護ポリシーの作成ページ」の説明

    このページでは、デフォルトのリカバリ・アプライアンスの記憶域の場所DELTAがすでに選択されています。

  4. 次の値を入力します。

    • 「名前」フィールドに新しい保護ポリシーの名前を入力します。

      たとえば、bronze_devを入力します。

    • 「説明」フィールドに、新しいポリシーの説明を入力します。

      たとえば、「Policy with disk recovery window of 3 days and no tape backup」と入力します。

    • 「ディスク・リカバリ・ウィンドウ目標」セクションの「リカバリ・ウィンドウ」フィールドに、ディスク・バックアップを使用したポイント・イン・タイム・リカバリに関してリカバリ・アプライアンスで達成する必要があるリカバリ・ウィンドウ目標を指定し、単位を選択します。

      たとえば、3を入力して、「日」を選択します。

    • 保護ポリシーが規制操作用に構成されている場合は、リカバリ・ウィンドウ・コンプライアンスを指定します。この設定では、バックアップが削除されないデータベース・バックアップごとの時間範囲を指定します。この値は、recovery_window_goal以下である必要があります。値が大きすぎる場合、コンプライアンス保護されたバックアップでdisk_reserved_spaceが一杯になる可能性があります。それによって、新しいバックアップが拒否されます。

    • 「保護されていないデータ・ウィンドウのしきい値」セクションの「しきい値」フィールドに、データ損失を許容できる最長期間を入力します。

      たとえば、5を入力して、「分」を選択します。

    • 保護ポリシーがコンプライアンス操作用に構成されている場合は、保持コンプライアンスにより、バックアップをそれらの保持期限まで保持するように指定します。

    • 予約済領域の自動チューニングにより、このポリシーに関連付けられているデータベースのreserved_spaceをリカバリ・アプライアンスで自動的に定義および更新(あるいはそのいずれか)するかどうかを指定します。

      コンプライアンス・バックアップの場合、reserved_spaceは特定のデータベースに割り当てられたハード制限であるため、autotune_reserved_spaceは適用されません。

    • オプションで、「メディア・マネージャ・リカバリ・ウィンドウ・ポリシー」の「リカバリ・ウィンドウ」フィールドに、メディア・マネージャからのポイント・イン・タイム・リカバリが維持される時間帯としてさらに長い時間を指定できます。

      たとえば、テープ・バックアップの必要がない場合はこのフィールドを空にしておきます。

    • 「最大ディスク・バックアップ保存期間」セクションの「最大保存」フィールドに、リカバリ・アプライアンスでディスク・バックアップを保存する必要がある最大期間を入力します。これは、リカバリ・ウィンドウ目標以上である必要があります。

      たとえば、指定しなかった場合は、ディスク・リカバリ目標を超えても、領域があるかぎりバックアップが保持されます。

  5. オプションで、「詳細」セクションの項目を変更できます。

    • 「バックアップおよびREDOフェイルオーバー」セクションで、この保護ポリシーに関連付けられている保護データベースが代替宛先としてこのリカバリ・アプライアンスを使用しているかどうかを指定します。

    • リカバリ・ウィンドウ・コンプライアンスも保持コンプライアンスも使用しない場合は、オプションで、「バックアップの削除」セクションにおいて、リカバリ・アプライアンスでRMAN DELETE (管理者ロール)によるバックアップ削除を許可するかどうかを指定します。

    • 「バックアップのポーリング位置」セクションで、バックアップ・ポーリング・ポリシーを定義します。

      • 「場所」フィールドに、リカバリ・アプライアンスでアクセスできるディレクトリを指定します。

      • 「頻度」フィールドに、間隔を指定し、時間の単位を入力します。

      たとえば、バックアップ・ポーリングを無効にするように指定するには、フィールドを空にしておきます。

    • 「バックアップ・コピー・ポリシー」セクションで、リカバリ・アプライアンスでバックアップを削除前にレプリケートするかテープにコピーするかを指定します。

      たとえば、「たとえまだテープにコピーまたはレプリケートされていない既存のバックアップを削除する必要があっても、新規のバックアップを常に受け入れます。」を選択します。

    • 「アーカイブ・ログ・バックアップの圧縮」で、アーカイブ・ログ・バックアップの圧縮アルゴリズムを選択できます。

  6. 「OK」をクリックします。

    保護ポリシー・ページが表示され、新たに作成された保護ポリシーがリスト表示されます。

関連項目:

PL/SQLを使用して保護ポリシーを作成するには、次の手順に従います。

開発環境のデータベース階層に対してbronze_devという名前の保護ポリシーを作成します。このポリシーによって保護されるすべてのデータベースの要件は次のとおりです。

  • ディスク・リカバリ・ウィンドウ目標は3日間であり、ディスク・バックアップを使用してすべてのデータベースを現在時刻から3日間前までの任意の時点にリカバリできる必要があります。

  • バックアップをテープにアーカイブする必要はありません。

  • 使用可能な記憶域が不足するために古いバックアップを削除しなければならない場合でも、リカバリ・アプライアンスが新しいバックアップを受信できるようにします。

  • バックアップ・ポーリング・ポリシーは有効にしません。

また、リカバリ・ウィンドウ目標が35日間のポリシーgold_devと10日間のポリシーsilver_devも作成します。さらに、ディスク・リカバリ・ウィンドウ目標が12時間のbronze_devという名前のポリシーも作成します。

  1. SQL*PlusまたはSQL Developerを起動してから、RASYSとして、またはuser_type=adminに設定してdb_userという名前で、メタデータ・データベースにログインします。

  2. DBMS_RA.CREATE_PROTECTION_POLICYプロシージャを実行します。

    たとえば、次のPL/SQL無名ブロックを実行します。

    BEGIN
 DBMS_RA.CREATE_PROTECTION_POLICY (
  protection_policy_name => 'bronze_dev',
  description            => 'For protected dbs in bronze tier',
  storage_location_name  => 'delta',
  recovery_window_goal   => INTERVAL '3' DAY,
  guaranteed_copy        => 'NO');
 DBMS_RA.CREATE_PROTECTION_POLICY (
  protection_policy_name => 'silver_dev',
  description            => 'For protected dbs in silver tier',
  storage_location_name  => 'delta',
  recovery_window_goal   => INTERVAL '10' DAY,
  guaranteed_copy        => 'NO');
 DBMS_RA.CREATE_PROTECTION_POLICY (
  protection_policy_name => 'gold_dev',
  description            => 'For protected dbs in gold tier',
  storage_location_name  => 'delta',
  recovery_window_goal   => INTERVAL '35' DAY,
  guaranteed_copy        => 'NO');
 DBMS_RA.CREATE_PROTECTION_POLICY (
  protection_policy_name => 'test_dev',
  description            => 'Test policy',
  storage_location_name  => 'delta',
  recovery_window_goal   => INTERVAL '12' HOUR,
  guaranteed_copy        => 'NO');
END;

    ノート:

    コンプライアンスに関連付けられているパラメータと、バックアップの削除または予約済領域の自動チューニングのパラメータなど、相互に排他的な属性に注意してください。

  3. 必要に応じて、リカバリ・カタログを問い合せてポリシーが作成されたことを確認します。

    たとえば、次のようにRA_PROTECTION_POLICYを問い合せます(出力例も示します)。 

    COL POLICY_NAME FORMAT a11
COL DESCRIPTION FORMAT a36
SELECT POLICY_NAME, DESCRIPTION, 
       TO_CHAR(EXTRACT(DAY FROM RECOVERY_WINDOW_GOAL),'fm00')||':'||
       TO_CHAR(EXTRACT(HOUR FROM RECOVERY_WINDOW_GOAL),'fm00')||':'||
       TO_CHAR(EXTRACT(MINUTE FROM RECOVERY_WINDOW_GOAL),'fm00')||':'||
       TO_CHAR(EXTRACT(SECOND FROM RECOVERY_WINDOW_GOAL),'fm00')
         AS "DD:HH:MM:SS"
FROM   RA_PROTECTION_POLICY
WHERE  POLICY_NAME LIKE '%DEV'
ORDER BY POLICY_NAME;

POLICY_NAME DESCRIPTION                          DD:HH:MM:SS
----------- ------------------------------------ ---------------
BRONZE_DEV  For protected dbs in bronze_dev tier 03:00:00:00
GOLD_DEV    For protected dbs in gold_dev tier   35:00:00:00
SILVER_DEV  For protected dbs in silver_dev tier 10:00:00:00
TEST_DEV    Test policy                          00:12:00:00

関連項目:

保護ポリシーの属性

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

表8-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またはkeep_complianceのいずれかのコンプライアンス・パラメータでautotune_reserved_spaceを使用しないでください

autotune_space_limit

このパラメータは、記憶域の場所が一杯になり始めると、予約済領域の自動チューニング機能によって、reserved_spaceの制約のない増加を制限します。

自動チューニングでは、予約済領域の合計使用量がこの指定された制限を下回る場合、予約済領域の増加は制限されません。予約済領域の合計使用量がこの指定された制限を超えると、自動チューニングにより、記憶域の場所内のデータベースごとに、後続のreserved_spaceの増加が週当たり10%に制限されます。

単位を指定しないと、リカバリ・アプライアンスは、値をバイト数として解釈します。autotune_reserved_spaceオプションを使用した予約済領域の増加に制限がない場合、この値はNULLに設定できます。

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に指定されている場合、すべてのデータベースの予約済領域の合計が記憶域の場所内に収まる必要があるという制限を除き、データベースのdisk_reserved_space設定は制約されません。

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

保護ポリシーの更新

この項では、Cloud Control (推奨)またはDBMS_RA PL/SQLパッケージを使用して保護ポリシーを更新する方法について説明します。

RASYSとして、またはuser_type=adminに設定してdb_userという名前で、メタデータ・データベースにログインする必要があります。保護ポリシーは存在する必要があります。

この例では、保護ポリシーはbronze_devであり、そのディスク・リカバリ・ウィンドウ目標を3日から6日に変更しています。

Cloud Controlを使用して、保護されたデータベースを更新するには、次の手順に従います。

  1. 「Cloud Controlの保護ポリシーの作成ページへのアクセス」の説明に従って、保護ポリシーの作成ページにアクセスします。

  2. 「保護ポリシー」表で、編集する保護ポリシーを選択します。

    たとえば、BRONZE_DEVの行を選択します。

  3. 「編集」をクリックします。

    保護ポリシーの編集ページが表示されます。

  4. 必要に応じて値を変更し、「OK」をクリックします。

    たとえば、「ディスク・リカバリ・ウィンドウ目標」セクションの「リカバリ・ウィンドウ」フィールドに6を入力します。

    保護ポリシー・ページが表示され、新たに更新された保護ポリシーがリスト表示されます。

DBMS_RAを使用して保護ポリシーを更新するには、次の手順に従います。

保護ポリシーを更新するには、DBMS_RA.UPDATE_PROTECTION_POLICYプロシージャを実行します。nullのパラメータは既存の値を維持します。たとえば、ある保護ポリシーでguaranteed_copyが現在NOになっている場合にDBMS_RA.UPDATE_PROTECTION_POLICYでこのパラメータにnullを指定すると、値はNOのままです。

  1. SQL*PlusまたはSQL Developerを起動してから、RASYSとして、またはuser_type=adminに設定してdb_userという名前で、メタデータ・データベースにログインします。

  2. DBMS_RA.UPDATE_PROTECTION_POLICYプロシージャを実行します。

    たとえば、次のPL/SQL無名ブロックを実行します。

    BEGIN
 DBMS_RA.UPDATE_PROTECTION_POLICY(
  protection_policy_name => 'bronze_dev',
  recovery_window_goal   => INTERVAL '6' DAY);
END;

  3. 必要に応じて、リカバリ・カタログを問い合せてポリシーが更新されたことを確認します。

    たとえば、次のようにRA_PROTECTION_POLICYを問い合せます(出力例も示します)。 

    COL POLICY_NAME FORMAT a11
COL DESCRIPTION FORMAT a36
SELECT POLICY_NAME, DESCRIPTION, 
       TO_CHAR(EXTRACT(DAY FROM RECOVERY_WINDOW_GOAL),'fm00')    ||':'||
       TO_CHAR(EXTRACT(HOUR FROM RECOVERY_WINDOW_GOAL),'fm00')   ||':'||
       TO_CHAR(EXTRACT(MINUTE FROM RECOVERY_WINDOW_GOAL),'fm00') ||':'||
       TO_CHAR(EXTRACT(SECOND FROM RECOVERY_WINDOW_GOAL),'fm00')
         AS "DD:HH:MM:SS"
FROM   RA_PROTECTION_POLICY
WHERE  POLICY_NAME='BRONZE_DEV';

POLICY_NAME DESCRIPTION                          DD:HH:MM:SS
----------- ------------------------------------ ---------------
BRONZE_DEV  For protected dbs in bronze tier     06:00:00:00

保護ポリシーの削除

この項では、Cloud Control (推奨)またはDBMS_RA PL/SQLパッケージを使用して保護ポリシーを削除する方法について説明します。

RASYSとして、またはuser_type=adminに設定してdb_userという名前で、リカバリ・アプライアンスのメタデータ・データベースにログインする必要があります。

保護ポリシーを、いずれかの保護データベースに関連付ける必要があります。1つ以上のデータベースに関連付けられたポリシーを削除するには、それらのデータベースを別のポリシーに関連付ける必要があります。その後、目的のポリシーを削除できます。

次の例では、bronze_devポリシーを削除する必要があると想定しています。

Cloud Controlを使用して、保護されたデータベースを削除するには、次の手順に従います。

  1. 「Cloud Controlの保護ポリシーの作成ページへのアクセス」の説明に従って、保護ポリシーの作成ページにアクセスします。

  2. 「保護ポリシー」表で、削除する保護ポリシーを選択します。

    たとえば、BRONZE_DEVの行を選択します。

  3. 「削除」をクリックします。

    確認を求めるウィンドウが表示されます。

  4. 「はい」をクリックします。

    保護ポリシー・ページが表示され、削除された保護ポリシーの表示がなくなっています。

DBMS_RAを使用して、保護されたデータベースを削除するには、次の手順に従います。

次の例では、bronze_devポリシーを削除する必要があると想定しています。

  1. SQL*PlusまたはSQL Developerを起動してから、RASYSとして、またはuser_type=adminに設定してdb_userという名前で、メタデータ・データベースにログインします。

  2. 削除しようとする保護ポリシーが保護データベースに現在関連付けられていないことを確認します。

    たとえば、次のようにしてデータベースに関連付けられていないすべての保護ポリシーを問い合せます。 

    SELECT POLICY_NAME AS "Currently unused policy"
FROM   RA_PROTECTION_POLICY
WHERE  POLICY_NAME NOT IN (SELECT POLICY_NAME FROM RA_DATABASE)
ORDER BY POLICY_NAME;

Currently unused policy
-----------------------
BRONZE_DEV

  3. ポリシーを削除します。

    たとえば、次のPL/SQL無名ブロックを実行すると、保護ポリシーbronze_devが削除されます。 

    BEGIN
  DBMS_RA.DELETE_PROTECTION_POLICY(
    protection_policy_name => 'BRONZE_DEV');
END;

  4. 必要に応じて、削除を確認します。

    たとえば、bronze_devというポリシーの行をカウントします(出力例も示します)。 

    SELECT COUNT(*)
FROM   RA_PROTECTION_POLICY
WHERE  POLICY_NAME = 'BRONZE_DEV';

  COUNT(*)
----------
         0

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

オプションのバックアップ・ポーリング・ポリシーによって、保護データベースがリカバリ・アプライアンスと直接やりとりせずにバックアップ・セットを配置するディレクトリが定義されます。バックアップ・ポーリング・ディレクトリは、外部ファイル・システムに作成し、リカバリ・アプライアンスからNFSマウント・ポイントとしてアクセスできるようにしておく必要があります。ポーリング・ポリシーでは、記憶域のファイル・システム・パスと、リカバリ・アプライアンスが新しいバックアップ・セット(イメージ・コピーではない)をチェックする頻度を定義します。保護ポリシー内にポーリング・ポリシー名を指定します。

ノート:

バックアップ・ポリシーを作成する個別のステップはCloud Controlでは必要ありません。保護ポリシーの作成ページに含まれています。

バックアップ・ポーリング・ポリシーが役立つのはシナリオは次のとおりです。

  • リカバリ・アプライアンスがオフラインになった場合、保護データベースがバックアップ・ポーリングの場所にバックアップの送信を続けられます。リカバリ・アプライアンスがオンラインになったときに、これらの場所でバックアップをポーリングします。

  • 記憶域のネットワークがイーサネットよりも高速な場合に、ポーリングの場所をネットワーク記憶域に構成すると、保護データベースがポーリングの場所にバックアップするほうが速くなることがあります。

  • 従来のバックアップをリカバリ・アプライアンスに移行するときに、ポーリングの場所を使用できます。

バックアップ・ポーリングを使用する保護データベースでは、共有メモリにバックアップ・ピースおよびアーカイブREDOログ・ファイルを格納します。リカバリ・アプライアンスは、共有記憶域のバックアップを定期的に取得して処理します。

前提条件

メタデータ・データベースにRASYSとしてログインする必要があります。

前提条件

次の要件を満たすポーリング・ポリシーを作成するとします。

  • リカバリ・アプライアンスは、/u03/shared/polling1ディレクトリ(リカバリ・アプライアンスとすべての保護データベースからアクセスできる共有ディレクトリ)をポーリングする必要があります。

  • リカバリ・アプライアンスが、4時間ごとに共有ディレクトリをポーリングします。

  • リカバリ・アプライアンスが、共有ディレクトリのバックアップを処理した後で削除します。

バックアップ・ポーリング・ポリシーを作成するには、次のようにします。

  1. SQL*PlusまたはSQL Developerを起動し、RASYSとしてメタデータ・データベースにログインします。

  2. DBMS_RA.CREATE_POLLING_POLICYプロシージャを実行します。

    たとえば、次のPL/SQL無名ブロックを実行します。

    BEGIN
  DBMS_RA.CREATE_POLLING_POLICY (
    polling_policy_name   => 'nas_polling1',
    polling_location      => '/u03/shared/polling1',
    polling_frequency     =>  INTERVAL '4' HOUR,
    delete_input          =>  TRUE);
END;

  3. 必要に応じて、リカバリ・カタログを問い合せてポリシーが作成されたことを確認します。

    たとえば、次のようにRA_POLLING_POLICYを問い合せます(出力例も示します)。 

    COL POLLING_NAME FORMAT a15
COL DEST FORMAT a40
SELECT POLLING_NAME, DEST, DELETE_INPUT,
       TO_CHAR(EXTRACT(DAY FROM FREQUENCY),'fm00')||':'||
       TO_CHAR(EXTRACT(HOUR FROM FREQUENCY),'fm00')||':'||
       TO_CHAR(EXTRACT(MINUTE FROM FREQUENCY),'fm00')||':'||
       TO_CHAR(EXTRACT(SECOND FROM FREQUENCY),'fm00')
         AS "DD:HH:MM:SS"
FROM   RA_POLLING_POLICY;

POLLING_NAME    DEST                                     DELET DD:HH:MM:SS
--------------- ---------------------------------------- ----- ---------------
NAS_POLLING1    /u03/shared/polling1/                    TRUE  00:04:00:00

関連項目: