5 リカバリ・アプライアンスでの保護ポリシーの管理
この章では、「リカバリ・アプライアンスの設定と構成」に含まれる保護ポリシーとポーリング・ポリシーの管理方法を説明します。
この章の内容は次のとおりです。
保護ポリシーについて
保護ポリシーは、事前定義されたリカバリ・ウィンドウ目標に基づいてバックアップ記憶域の管理を制御するための中心メカニズムです。DBAの観点では、保護ポリシーの最も重要な要素はディスクとテープのリカバリ・ウィンドウです。
この項には次のトピックが含まれます:
関連項目:
アーキテクチャの概要については、「保護ポリシー」を参照してください
保護ポリシーの目的
保護ポリシーは、関連付けられるすべてのデータベースの次の項目を指定します。
-
テープ・バックアップのリカバリ・ウィンドウ
-
バックアップに使用されるリカバリ・アプライアンスの記憶域の場所
-
バックアップ・ポーリング・ポリシー(オプション)
複数の保護データベースを1つの保護ポリシーに関連付けることができます。リカバリ・アプライアンスは、様々なデータ保護サポート・レベルに対応するために多様な保護ポリシーを使用できます。たとえば、保護ポリシーを一般的なサービス・レベル(ゴールド、シルバーおよびブロンズ)に合せて作成できます。あるいは、保護データベースとアプリケーションの固有の要件に合せることもできます。
保護ポリシーの概要
保護ポリシーは、リカバリ・アプライアンスのメタデータ・データベースに記録される、名前が付けられた論理オブジェクトです。保護データベースをリカバリ・アプライアンスに追加するには、特定の保護ポリシーに関連付ける必要があります。デフォルトの保護ポリシーは、プラチナ、ゴールド、シルバーおよびブロンズです。
各保護ポリシーは、ディスクおよびテープのリカバリ・ウィンドウに関して異なる値を指定します。これらの値は、ポリシーによって保護される各データベースに適用されます。たとえば、図5-1は、それぞれに異なる保護データベースが割り当てられている3つのデフォルト保護ポリシーを示します。この例では、データベースprod3
およびprod11
は同じポリシー内にあるため、両方に3日間の同じディスク・リカバリ・ウィンドウ目標があります。
関連項目:
保護ポリシーのユーザー・インタフェース
この項には次のトピックが含まれます:
Cloud Controlの保護ポリシーの作成ページへのアクセス
Oracle Enterprise Manager Cloud Control (Cloud Control)の保護ポリシーの作成ページは、保護ポリシーを作成するための推奨インタフェースです。
保護ポリシーの作成ページにアクセスするには、次のようにします。
-
「リカバリ・アプライアンスのホームページへのアクセス」の説明に従って、リカバリ・アプライアンスのホームページにアクセスします。
-
「リカバリ・アプライアンス」メニューで「保護ポリシー」を選択します。
リカバリ・アプライアンス・ログイン・ページが表示されます。
-
ログイン資格証明を入力して、「ログイン」をクリックします。
保護ポリシー・ページが表示されます(図5-2の例)。
関連項目:
保護ポリシー・ページの詳細は、Cloud Controlのオンライン・ヘルプを参照してください。
保護ポリシーに関連するDBMS_RAプロシージャ
DBMS_RA
パッケージを使用して、保護ポリシーを作成および管理できます。表5-1に、保護ポリシーに関連する主なプログラム・ユニットを示します。
表5-1 DBMS_RA保護ポリシー・プロシージャ
プログラム・ユニット | 説明 |
---|---|
バックアップ・ポーリング・ポリシーを作成します。 |
|
保護ポリシーを作成します。 |
|
保護ポリシーを削除します。 |
関連項目:
保護ポリシーのリカバリ・カタログ・ビュー
リカバリ・アプライアンスのカタログ・ビューを使用して保護ポリシーをモニタリングできます。表5-2に、保護ポリシーとの関連が深いビューをまとめています。
表5-2 保護ポリシーのリカバリ・カタログ・ビュー
ビュー | 説明 |
---|---|
このビューは、定義済の保護ポリシーを示します。 |
|
このビューは、定義済のバックアップ・ポーリング・ポリシーを示します。 |
|
このビューの |
|
このビューの |
関連項目:
保護ポリシーを管理するための基本タスク
この項では、保護ポリシーの管理に含まれる基本的なタスクについて説明します。図5-3は、「リカバリ・アプライアンスのワークフロー」に説明されている全体的なワークフローを、保護ポリシーのタスクを強調して示したものです。
通常、保護ポリシーのタスクを実行する順序は次のとおりです。
-
計画フェーズでは、データベースを階層でグループ分けし、各階層のリカバリ要件を決定します。
「リカバリ・アプライアンスの計画」でこれらのタスクを説明しています。
-
構成フェーズ(「リカバリ・アプライアンスの設定と構成」を参照)では、各データベース階層に1つの保護ポリシーを作成します。
-
バックアップ・ポーリングの場所へのアクセス権がリカバリ・アプライアンスにあり、コマンドライン・ツールを使用して構成を実行している場合は、必要に応じて、バックアップ・ポーリング・ポリシーを作成します。
「バックアップ・ポーリング・ポリシーの作成(コマンドラインのみ)」でこのタスクについて説明しています。
ノート:
Cloud Controlを使用すると、ポーリング・ポリシーと保護ポリシーを同じページで構成できます。
-
特定のデータベース階層の保護ポリシーを作成します。
「保護ポリシーの作成」でこのタスクについて説明しています。
-
-
進行中のメンテナンス・フェーズでは(「リカバリ・アプライアンスのメンテナンス・タスク」を参照)、必要に応じて保護ポリシーを変更します。一般的な変更タスクには次のものがあります。
-
保護ポリシーの属性を更新します。
「保護ポリシーの更新」でこのタスクについて説明しています。
-
保護ポリシーを削除します。
「保護ポリシーの削除」でこのタスクについて説明しています。
-
バックアップ・ポーリング・ポリシーの作成(コマンドラインのみ)
オプションのバックアップ・ポーリング・ポリシーによって、保護データベースがリカバリ・アプライアンスと直接やりとりせずにバックアップ・セットを配置するディレクトリが定義されます。バックアップ・ポーリング・ディレクトリは、外部ファイル・システムに作成し、リカバリ・アプライアンスからNFSマウント・ポイントとしてアクセスできるようにしておく必要があります。ポーリング・ポリシーでは、記憶域のファイル・システム・パスと、リカバリ・アプライアンスが新しいバックアップ・セット(イメージ・コピーではない)をチェックする頻度を定義します。保護ポリシー内にポーリング・ポリシー名を指定します。
ノート:
バックアップ・ポリシーを作成する個別のステップはCloud Controlでは必要ありません。保護ポリシーの作成ページに含まれています。
バックアップ・ポーリング・ポリシーが役立つのはシナリオは次のとおりです。
-
リカバリ・アプライアンスがオフラインになった場合、保護データベースがバックアップ・ポーリングの場所にバックアップの送信を続けられます。リカバリ・アプライアンスがオンラインになったときに、これらの場所でバックアップをポーリングします。
-
記憶域のネットワークがイーサネットよりも高速な場合に、ポーリングの場所をネットワーク記憶域に構成すると、保護データベースがポーリングの場所にバックアップするほうが速くなることがあります。
-
従来のバックアップをリカバリ・アプライアンスに移行するときに、ポーリングの場所を使用できます。
バックアップ・ポーリングを使用する保護データベースでは、共有メモリにバックアップ・ピースおよびアーカイブREDOログ・ファイルを格納します。リカバリ・アプライアンスは、共有記憶域のバックアップを定期的に取得して処理します。
前提条件
前提条件
次の要件を満たすポーリング・ポリシーを作成するとします。
-
リカバリ・アプライアンスは、
/u03/shared/polling1
ディレクトリ(リカバリ・アプライアンスとすべての保護データベースからアクセスできる共有ディレクトリ)をポーリングする必要があります。 -
リカバリ・アプライアンスが、4時間ごとに共有ディレクトリをポーリングします。
-
リカバリ・アプライアンスが、共有ディレクトリのバックアップを処理した後で削除します。
バックアップ・ポーリング・ポリシーを作成するには、次のようにします。
-
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;
-
必要に応じて、リカバリ・カタログを問い合せてポリシーが作成されたことを確認します。
たとえば、次のように
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
関連項目:
-
ポーリングの詳細は、「バックアップ・ポーリング・ポリシー」を参照してください
-
プロシージャの引数の詳細は、「CREATE_POLLING_POLICY」を参照してください
保護ポリシーの作成
この項では、Cloud Control (推奨)またはDBMS_RA.CREATE_PROTECTION_POLICY
プロシージャを使用して保護ポリシーを作成する方法について説明します。ベスト・プラクティスは、データベースの各階層に別の保護ポリシーを作成することです(「タスク1: 保護データベースの階層グループ分け」を参照)。
Cloud Controlを使用した保護ポリシーの作成
この項では、Cloud Controlの保護ポリシー・ページで保護ポリシーを作成する方法について説明します。
前提条件
次の前提条件を満たしている必要があります。
前提条件
開発環境のデータベース階層に対してbronze_dev
という名前の保護ポリシーを作成します。このポリシーによって保護されるすべてのデータベースの要件は次のとおりです。
-
ディスク・リカバリ・ウィンドウ目標は3日間であり、ディスク・バックアップを使用してすべてのデータベースを現在時刻から3日間前までの任意の時点にリカバリできる必要があります。
-
バックアップをテープにアーカイブする必要はありません。
-
使用可能な記憶域が不足するために古いバックアップを削除しなければならない場合でも、リカバリ・アプライアンスが新しいバックアップを受信できるようにします。
-
バックアップ・ポーリング・ポリシーは有効にしません。
保護ポリシーを作成するには、次のようにします。
-
「Cloud Controlの保護ポリシーの作成ページへのアクセス」の説明に従って、保護ポリシーの作成ページにアクセスします。
-
「作成」をクリックします。
-
次の値を入力します。
-
「名前」フィールドに新しい保護ポリシーの名前を入力します。
たとえば、
bronze_dev
を入力します。 -
「説明」フィールドに、新しいポリシーの説明を入力します。
たとえば、
「Policy with disk recovery window of 3 days and no tape backup」
と入力します。 -
「ディスク・リカバリ・ウィンドウ目標」セクションの「リカバリ・ウィンドウ」フィールドに、リカバリ・アプライアンスがディスク・バックアップを使用したポイント・イン・タイム・リカバリに関して達成する必要があるリカバリ・ウィンドウ目標を指定し、単位を選択します。
たとえば、
3
を入力して、「日」を選択します。 -
「保護されていないデータ・ウィンドウのしきい値」セクションの「しきい値」フィールドに、データ損失を許容できる最長期間を入力します。
たとえば、
5
を入力して、「分」を選択します。 -
必要に応じて、「メディア・マネージャ・リカバリ・ウィンドウ・ポリシー」の「リカバリ・ウィンドウ」フィールドに、メディア・マネージャがポイント・イン・タイム・リカバリを実行できるさらに長いウィンドウを指定できます。
たとえば、テープ・バックアップの必要がない場合はこのフィールドを空にしておきます。
-
「最大ディスク・バックアップ保存期間」セクションの「最大保存」フィールドに、リカバリ・アプライアンスがディスク・バックアップを保存する必要がある最大期間を入力します。
たとえば、このフィールドを空にしておくと、明示的にパージする場合や記憶域の場所に領域不足がある場合を除き、リカバリ・アプライアンスによってバックアップがパージされません。
-
オプションで、「バックアップのポーリング位置」セクションで、バックアップ・ポーリング・ポリシーを定義します。
-
「場所」フィールドに、リカバリ・アプライアンスでアクセスできるディレクトリを指定します。
-
「頻度」フィールドに、間隔を指定し、時間の単位を入力します。
-
リカバリ・アプライアンスがバックアップをコピーした後でポーリングの場所からバックアップを削除するように指定するには、「コピー後にバックアップを削除」を選択します。
たとえば、バックアップ・ポーリングを無効にするように指定するには、フィールドを空にしておきます。
-
-
「バックアップ・コピー・ポリシー」セクションで、リカバリ・アプライアンスがバックアップを削除する前にレプリケートまたはテープへのコピーを行う必要があるかどうかを指定します。
たとえば、「たとえまだテープにコピーまたはレプリケートされていない既存のバックアップを削除する必要があっても、新規のバックアップを常に受け入れます。」を選択します。
-
-
「OK」をクリックします。
保護ポリシー・ページが表示され、新たに作成された保護ポリシーがリスト表示されます。
関連項目:
-
保護ポリシーの作成・ページの詳細は、Cloud Controlのオンライン・ヘルプを参照してください。
DBMS_RAを使用した保護ポリシーの作成
前提条件
前提条件
開発環境のデータベース階層に対してbronze_dev
という名前の保護ポリシーを作成します。このポリシーによって保護されるすべてのデータベースの要件は次のとおりです。
-
ディスク・リカバリ・ウィンドウ目標は3日間であり、ディスク・バックアップを使用してすべてのデータベースを現在時刻から3日間前までの任意の時点にリカバリできる必要があります。
-
バックアップをテープにアーカイブする必要はありません。
-
使用可能な記憶域が不足するために古いバックアップを削除しなければならない場合でも、リカバリ・アプライアンスが新しいバックアップを受信できるようにします。
-
バックアップ・ポーリング・ポリシーは有効にしません。
また、リカバリ・ウィンドウ目標が35日間のポリシーgold_dev
と10日間のポリシーsilver_dev
も作成します。さらに、ディスク・リカバリ・ウィンドウ目標が12時間のtest_dev
という名前のポリシーも作成します。
保護ポリシーを作成するには、次のようにします。
-
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;
-
必要に応じて、リカバリ・カタログを問い合せてポリシーが作成されたことを確認します。
たとえば、次のように
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パッケージを使用して保護ポリシーを更新する方法について説明します。
保護ポリシーの更新の例として、顧客は次のいずれかまたは両方の理由で保護ポリシーの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)を参照してください
Cloud Controlを使用した保護ポリシーの更新
この項では、Cloud Controlの保護ポリシー・ページで保護ポリシーを更新する方法について説明します。
前提条件
前提条件
「Cloud Controlを使用した保護ポリシーの作成」の説明に従って、bronze_dev
ポリシーを作成したと仮定します。ディスク・リカバリ・ウィンドウ目標を3日間から6日間に更新します。
保護ポリシーを更新するには、次のようにします。
-
「Cloud Controlの保護ポリシーの作成ページへのアクセス」の説明に従って、保護ポリシーの作成ページにアクセスします。
-
「保護ポリシー」表で、編集する保護ポリシーを選択します。
たとえば、
BRONZE_DEV
の行を選択します。 -
「編集」をクリックします。
保護ポリシーの編集ページが表示されます。
-
必要に応じて値を変更し、「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日間に変更するとします。
既存の保護ポリシーの属性を更新するには、次のようにします。
-
SQL*PlusまたはSQL Developerを起動し、
RASYS
としてメタデータ・データベースにログインします。 -
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;
-
必要に応じて、リカバリ・カタログを問い合せてポリシーが更新されたことを確認します。
たとえば、次のように
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の保護ポリシー・ページで保護ポリシーを削除する方法について説明します。
前提条件
前提条件
「Cloud Controlを使用した保護ポリシーの作成」の説明に従って、bronze_dev
ポリシーを作成したと仮定します。このポリシーを削除します。
保護ポリシーを削除するには、次のようにします。
-
「Cloud Controlの保護ポリシーの作成ページへのアクセス」の説明に従って、保護ポリシーの作成ページにアクセスします。
-
「保護ポリシー」表で、削除する保護ポリシーを選択します。
たとえば、
BRONZE_DEV
の行を選択します。 -
「削除」をクリックします。
確認を求めるウィンドウが表示されます。
-
「はい」をクリックします。
保護ポリシー・ページが表示され、削除された保護ポリシーの表示がなくなっています。
関連項目:
保護ポリシー・ページの詳細は、Cloud Controlのオンライン・ヘルプを参照してください。
DBMS_RAを使用した保護ポリシーの削除
前提条件
-
RASYS
としてメタデータ・データベースにログインする必要があります。 -
保護ポリシーを、いずれかの保護データベースに関連付ける必要があります。1つ以上のデータベースに関連付けられたポリシーを削除するには、それらのデータベースを別のポリシーに関連付ける必要があります。その後、目的のポリシーを削除できます。
前提条件
「保護ポリシーの作成」で作成した保護ポリシーtest_dev
を削除するとします。
保護ポリシーを削除するには、次のようにします。
-
SQL*PlusまたはSQL Developerを起動し、
RASYS
としてメタデータ・データベースにログインします。 -
削除しようとする保護ポリシーが保護データベースに現在関連付けられていないことを確認します。
たとえば、次のようにしてデータベースに関連付けられていないすべての保護ポリシーを問い合せます。
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
-
ポリシーを削除します。
たとえば、次のPL/SQL匿名ブロックを実行すると、保護ポリシー
test_dev
が削除されます。BEGIN DBMS_RA.DELETE_PROTECTION_POLICY( protection_policy_name => 'test_dev'); END;
-
必要に応じて、削除を確認します。
たとえば、
test_dev
という名前のポリシーの行をカウントします(出力例も示します)。SELECT COUNT(*) FROM RA_PROTECTION_POLICY WHERE POLICY_NAME = 'TEST_DEV'; COUNT(*) ---------- 0