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

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

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

保護ポリシーについて

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

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

関連項目:

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

保護ポリシーの目的

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

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

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

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

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

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

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

保護ポリシーの概要

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

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

関連項目:

「保護ポリシー」

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

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

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

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

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

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

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

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

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

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

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

    図5-2の説明は図の下のリンクをクリックしてください。
    「図5-2 保護ポリシー・ページ」の説明

関連項目:

保護ポリシー・ページの詳細は、Cloud Controlのオンライン・ヘルプを参照してください。

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

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

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

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

CREATE_POLLING_POLICY

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

CREATE_PROTECTION_POLICY

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

DELETE_PROTECTION_POLICY

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

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

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

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

ビュー 説明

RA_PROTECTION_POLICY

このビューは、定義済の保護ポリシーを示します。

RA_POLLING_POLICY

このビューは、定義済のバックアップ・ポーリング・ポリシーを示します。

RA_DATABASE

このビューのPOLICY_NAME列に、この保護データベースで使用される保護ポリシーが示されます。

RA_REPLICATION_SERVER

このビューのPROTECTION_POLICY列に、レプリケーションで使用される特定のリカバリ・アプライアンスの保護ポリシーが示されます。

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

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

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

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

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

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

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

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

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

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

      注意:

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

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

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

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

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

オプションのバックアップ・ポーリング・ポリシーによって、保護データベースがリカバリ・アプライアンスと直接やりとりせずにバックアップ・セットを配置するディレクトリが定義されます。バックアップ・ポーリング・ディレクトリは、外部ファイル・システムに作成し、リカバリ・アプライアンスから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

関連項目:

保護ポリシーの作成

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

Cloud Controlを使用した保護ポリシーの作成

この項では、Cloud Controlの保護ポリシー・ページで保護ポリシーを作成する方法について説明します。

前提条件

次の前提条件を満たしている必要があります。

  • RASYSとしてリカバリ・アプライアンスにログインする必要があります。

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

前提条件

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

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

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

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

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

保護ポリシーを作成するには、次のようにします。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • 必要に応じて、「メディア・マネージャ・リカバリ・ウィンドウ・ポリシー」の「リカバリ・ウィンドウ」フィールドに、メディア・マネージャがポイント・イン・タイム・リカバリを実行できるさらに長いウィンドウを指定できます。

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

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

      たとえば、このフィールドを空にしておくと、明示的にパージする場合や記憶域の場所に領域不足がある場合を除き、リカバリ・アプライアンスによってバックアップがパージされません。

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

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

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

      • リカバリ・アプライアンスがバックアップをコピーした後でポーリングの場所からバックアップを削除するように指定するには、「コピー後にバックアップを削除」を選択します。

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

    • 「バックアップ・コピー・ポリシー」セクションで、リカバリ・アプライアンスがバックアップを削除する前にレプリケートまたはテープへのコピーを行う必要があるかどうかを指定します。

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

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

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

関連項目:

DBMS_RAを使用した保護ポリシーの作成

保護ポリシーを作成するには、DBMS_RA.CREATE_PROTECTION_POLICYプロシージャを実行します。

前提条件

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

前提条件

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

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

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

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

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

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

保護ポリシーを作成するには、次のようにします。

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

  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

保護ポリシーの更新

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

Cloud Controlを使用した保護ポリシーの更新

この項では、Cloud Controlの保護ポリシー・ページで保護ポリシーを更新する方法について説明します。

前提条件

RASYSとしてリカバリ・アプライアンスにログインする必要があります。

前提条件

「Cloud Controlを使用した保護ポリシーの作成」の説明に従って、bronze_devポリシーを作成したと仮定します。ディスク・リカバリ・ウィンドウ目標を3日間から6日間に更新します。

保護ポリシーを更新するには、次のようにします。

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

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

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

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

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

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

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

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

関連項目:

保護ポリシー・ページの詳細は、Cloud Controlのオンライン・ヘルプを参照してください。

DBMS_RAを使用した保護ポリシーの更新

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

前提条件

メタデータ・データベースにRASYSとしてログインする必要があります。「DBMS_RAを使用した保護ポリシーの作成」で作成した保護ポリシーbronze_devが存在する必要があります。

前提条件

bronze_devのディスク・リカバリ・ウィンドウ目標を3日間から6日間に変更するとします。

既存の保護ポリシーの属性を更新するには、次のようにします。

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

  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パッケージを使用して保護ポリシーを削除する方法について説明します。

Cloud Controlを使用した保護ポリシーの削除

この項では、Cloud Controlの保護ポリシー・ページで保護ポリシーを削除する方法について説明します。

前提条件

RASYSとしてリカバリ・アプライアンスにログインする必要があります。

前提条件

「Cloud Controlを使用した保護ポリシーの作成」の説明に従って、bronze_devポリシーを作成したと仮定します。このポリシーを削除します。

保護ポリシーを削除するには、次のようにします。

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

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

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

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

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

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

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

関連項目:

保護ポリシー・ページの詳細は、Cloud Controlのオンライン・ヘルプを参照してください。

DBMS_RAを使用した保護ポリシーの削除

保護ポリシーを削除するには、DBMS_RA.DELETE_PROTECTION_POLICYプロシージャを実行します。

前提条件

次の前提条件を満たしている必要があります。

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

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

前提条件

「保護ポリシーの作成」で作成した保護ポリシーtest_devを削除するとします。

保護ポリシーを削除するには、次のようにします。

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

  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
    -----------------------
    TEST_DEV
    
  3. ポリシーを削除します。

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

    BEGIN
      DBMS_RA.DELETE_PROTECTION_POLICY(
        protection_policy_name => 'test_dev');
    END;
    
  4. 必要に応じて、削除を確認します。

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

    SELECT COUNT(*)
    FROM   RA_PROTECTION_POLICY
    WHERE  POLICY_NAME = 'TEST_DEV';
    
      COUNT(*)
    ----------
             0