17 Oracle Database機能と組み合せたOracle Data Redactionの使用

Oracle Data Redactionは他のOracle機能とともに使用できますが、一部のOracle機能にはOracle Data Redactionについて制限がある場合があります。

17.1 Oracle Data Redactionの一般的な使用上のガイドライン

Oracle Data Redactionを使用するための使用上のガイドラインを理解することが重要です。

  • SQL文のGROUP BY句およびSELECTリストで使用されるSQL式に、リダクションされた列を含めないでください。Oracleではこのような動作はサポートされないため、「ORA-00979: GROUP BYの式ではありません。」のエラーが発生します。これはSELECTリスト内の式がデータ・リダクションにより内部で変更される必要があるために発生しますが、(その時点ではデータ・リダクションにより更新されていない)GROUP BY句を処理するときに見つからなくなっている原因となり、この予期せぬエラー・メッセージが発生します。

  • SQL文のDISTINCT句とORDER BY句の両方で使用されるSQL式にリダクションされた列を含めることはできません。Oracleではこのような動作はサポートされないため、「ORA-01791: SELECT式が無効です。」エラーが発生します。これはSELECTリスト内の式がデータ・リダクションにより内部で変更される必要があるために発生しますが、ORDER BY句を処理するときに見つからなくなっている原因となり、この予期せぬエラー・メッセージが発生します。この問題を回避するには、インライン・ビューを含むように問合せをリライトして、セマンティック・レイヤーが列を検出できるようにします。たとえば、次の問合せを考えてみます。

    SELECT DISTINCT sensitive_column
    FROM table_name
    ORDER BY sensitive_column;

    次のように問合せを書き直します:

    SELECT sensitive_column FROM
    (SELECT DISTINCT sensitive_column
     FROM table_name
     ORDER BY sensitive_column);
  • リダクション・ポリシーから除外されていないユーザーに、リダクションされた列を含む複雑なSQL問合せをしたために、「ORA-28094: SQL構造はデータ・リダクションでサポートされていません」のエラーが発生します。複雑なSQL問合せをしているユーザーに、EXEMPT REDACTION POLICYシステムまたはスキーマ権限がある場合、このエラーは発生しません。

    ORA-28094エラーを回避するには、次のプロパティが問合せにあることを確認します。

    • UNION内の列にリダクション・ポリシーがある場合、UNIONの各ブランチ内の対応する列は、次のすべてのプロパティに対して同じ値を持つリダクション・ポリシーを使用する必要があります。

      • 関数のタイプ

      • 関数パラメータまたはREGEXPパラメータ

      • ポリシー式

      • フラグの有効化

      別のリダクション・ポリシーでもかまいませんが、これらのプロパティはすべて同じである必要があります。

    • インライン・ビューでは、UNIONに副問合せを含めることはできません。

    • CREATE VIEW定義またはインライン・ビューでは、リダクションされた列を含むSQL式(concatsumtrimminmaxなど)は存在できません。WITH句はインライン・ビューとしても処理されるため、リダクションされた列を含むSQL式をWITH句に含めることはできません。

  • ORA-28093: 列%sでの操作は、データ・リダクションでサポートされていません」エラーは、ユーザーがXML構文を含む問合せを発行し、そのユーザーにEXEMPT REDACTION POLICYシステム権限が付与されていない場合に発生します。ORA-28093は、リダクション・ポリシーから除外されていないユーザーに対してのみ発生し、これらのユーザーはリダクションされた列を含むXML構文は使用できませんが、リダクション・ポリシーから除外されるユーザーには許可されます。

  • Oracleでは、次の機能はサポートされていません。

    • 仮想列でのデータ・リダクション・ポリシーの追加

      DBA_TAB_COLSデータ・ディクショナリ・ビューにアクセスできるユーザーが、次の問合せを使用してDBA_TAB_COLSVIRTUAL_COLUMN列を参照して仮想列を検索し、データ・リダクション・ポリシーを作成するためのDBMS_REDACTコールにその仮想列が指定されているかどうかを確認できます。

      SELECT COLUMN_ID, COLUMN_NAME, VIRTUAL_COLUMN
      FROM DBA_TAB_COLS
      WHERE TABLE_NAME = 'table_name_that_you_attempted_to_redact'
      AND VIRTUAL_COLUMN = 'YES'
      ORDER BY COLUMN_ID;
    • 仮想列のベース列でのデータ・リダクション・ポリシーの追加

      DBA_TAB_COLSデータ・ディクショナリ・ビューにアクセスできるユーザーが、次の問合せを使用してDBA_TAB_COLSDATA_DEFAULT列を参照して(前述に対して内部的に作成される)仮想列式を検索し、データ・リダクション・ポリシーを作成するためのDBMS_REDACTコールに指定されている列名が、仮想列式に含まれているかどうかを確認できます。

      SELECT COLUMN_ID, COLUMN_NAME, VIRTUAL_COLUMN, DATA_DEFAULT
       FROM DBA_TAB_COLS
       WHERE TABLE_NAME = 'table_name_that_you_attempted_to_redact'
       AND VIRTUAL_COLUMN = 'YES'
       ORDER BY COLUMN_ID;
    • ファンクション索引のベース列へのデータ・リダクション・ポリシーの追加

      DBA_TAB_COLSデータ・ディクショナリ・ビューにアクセスできるユーザーが、次の問合せを使用してDBA_TAB_COLSDATA_DEFAULT列を参照して(DBMS_REDACT PL/SQLコールに設定されているファンクション索引に対して内部的に作成される)仮想列式を検索し、データ・リダクション・ポリシーを作成するためのDBMS_REDACTコールに指定されている列名が、仮想列式に含まれているかどうかを確認できます。

      SELECT COLUMN_ID, COLUMN_NAME, VIRTUAL_COLUMN, DATA_DEFAULT
      FROM DBA_TAB_COLS
      WHERE TABLE_NAME = 'table_name_that_you_attempted_to_redact'
      AND VIRTUAL_COLUMN = 'YES'
      ORDER BY COLUMN_ID;
    • 拡張統計の一部である任意の列へのデータ・リダクション・ポリシーの追加

      DBA_TAB_COLSデータ・ディクショナリ・ビューにアクセスできるユーザーが、次の問合せを使用してDBA_TAB_COLSDATA_DEFAULT列を参照して(DBMS_REDACT PL/SQLコールに設定されている拡張統計情報に対して内部的に作成される)仮想列式を検索し、データ・リダクション・ポリシーを作成するためのDBMS_REDACTコールに指定されている列名が、仮想列式に含まれているかどうかを確認できます。

      SELECT COLUMN_ID, COLUMN_NAME, VIRTUAL_COLUMN, DATA_DEFAULT
      FROM DBA_TAB_COLS
      WHERE TABLE_NAME = 'table_name_that_you_attempted_to_redact'
      AND VIRTUAL_COLUMN = 'YES'
      ORDER BY COLUMN_ID;
    • ベース列にデータ・リダクション・ポリシーが定義されている仮想列の追加

      次の問合せを使用して、REDACTION_COLUMNSデータ・ディクショナリ・ビューのCOLUMN_NAME列を参照し、仮想列の作成に使用されている列にデータ・リダクション・ポリシーが定義されているかどうかを確認できます。

      SELECT OBJECT_NAME, COLUMN_NAME
      FROM REDACTION_COLUMNS
      WHERE COLUMN_NAME = 'column_name_that_is_used_for_virtual_expr';
    • データ・リダクション・ポリシーがある列でのファンクション索引の作成
    • データ・リダクション・ポリシーがある列での拡張統計の作成

17.2 Oracle Data Redactionと、DMLおよびDDL操作

Oracle Data Redactionは、DMLおよびDDL操作に影響を与えます。特に、リダクションされた列を持つ表に対して非定型SQLを発行するユーザーがいる場合に、これが当てはまります。

次の点に注意してください。

  • Oracle Data Redactionは、結果は表示されませんが、DML文のRETURNING INTO句を問合せとして処理します。バッファに送信されるのは、RETURNING INTO句が通常のSQL問合せとして実行された場合に表示される結果で、DML文の一部として実行された場合の結果ではありません。アプリケーションがRETURNING INTOの値を格納したバッファ上でさらに処理を実行する場合、バッファ内でリダクションされた結果を検索することができないため、アプリケーションの変更を検討してください。

  • リダクションされた列がDMLまたはDDL操作のソースとして現れた場合、Oracle Data Redactionは、これをポリシーを回避する試みとみなし、EXEMPT REDACTION POLICY権限がないかぎり、「ORA-28081: 権限が不十分です。コマンドはリダクション済のオブジェクトを参照しています。」のエラーを表示して拒否します。 EXEMPT REDACTION POLICY権限は、システム・レベルに加えてスキーマで付与できることに注意してください。内部的にはOracle Data Pumpがこの種の操作を実行するため、リダクションされた列がある表のスキーマ・レベルのエクスポートを実行する必要があるユーザーには、システムまたはスキーマ・レベルのEXEMPT REDACTION POLICY権限の付与が必要になることがあります。

  • 内部では、Oracle Data MiningがDMLおよびDDL操作を発行するため、ユーザーが、リダクションされた列を持つ表に基づいてデータ・マイニング・モデルを作成する必要がある場合は、そのユーザーにEXEMPT REDACTION POLICYシステム権限を付与することが必要になることがあります。

17.3 ネストした関数、インライン・ビューおよびWHERE句でのOracle Data Redaction

Oracle Data Redactionは、ネストした関数、インライン・ビュー、およびSELECT文のWHERE句と一緒に使用できます。

Oracle Data Redactionポリシーは次のように動作します。

  • ネストしたファンクションは、リダクションされたデータに対して機能します。たとえば、SELECT SUM(AVG(TO_NUMBER(((X))) FROM HR.EMPLOYEES WHERE ...では、列Xが最初にリダクションされ、次にリダクションされたデータに対して、最も内側から外側に向かう順序でファンクションが実行されます。

  • インライン・ビューは、最も外側からリダクションされます。たとえば、SELECT XYZ ... AS SELECT A... AS SELECT B... AS SELECT C...では、SELECT CSELECT BおよびSELECT Aが実行された後に、SELECT XYZのみがリダクションされます。

  • WHERE句はリダクションされません。データ・リダクションでは、列のSELECTリストのデータのみがリダクションされます。

17.4 Oracle Data Redactionおよびデータ・リダクション・ポリシーによって保護される列に対する問合せ

Oracle Data Redactionポリシーによって保護された列に対して、DISTINCT句を含む問合せをすると、返される行が少なくなることがあります。同様に、Oracle Data Redactionポリシーによって保護された列を選択するSQL文の間のUNION句を含むSQL問合せをすると、返される行が少なくなることがあります。

これは、最初に列に対してリダクションが実行され、次にリダクションされたデータにDISTINCT句が適用されるためです。同様にUNIONの場合も、列が最初にリダクションされ、リダクションされたデータにSELECT文からUNIONが適用されます。

この問題を回避するには、DISTINCTまたはUNION操作がリダクションの前に実行されるように、問合せを書き直してインライン・ビューを含めてください。たとえば、次の問合せを考えてみます:

SELECT DISTINCT sensitive_column
FROM table_name;

SELECT sensitive_column FROM table_name
UNION
SELECT sensitive_column FROM table_name;

次のように問合せを書き直します:

SELECT sensitive_column FROM
(SELECT DISTINCT sensitive_column
 FROM table_name);

SELECT sensitive_column FROM
(SELECT sensitive_column FROM table_name
 UNION
 SELECT sensitive_column FROM table_name);

17.5 Oracle Data Redactionとデータベース・リンク

データベース・リンクを参照するデータベース・ビューでOracle Data Redactionポリシーを作成しないでください。

DBA_DB_LINKSデータ・ディクショナリ・ビューを問い合せることによって、既存のデータベース・リンクについての情報を検索できます。

17.6 Oracle Data Redactionおよび集計関数

集計関数は、Oracle Data Redactionポリシーのパフォーマンス・オーバーヘッドに影響を与えることがあります。

Oracle Data Redactionは列の各行の値を動的に変更するため、集計関数を使用する特定のSQL問合せでは、行の値が静的であると仮定しているデータベース最適化を最大限に利用できません。

集計関数をコールするSQL問合せでは、リダクションが原因でパフォーマンス・オーバーヘッドが発生する可能性があります。

17.7 Oracle Data Redactionおよびオブジェクト型

オブジェクト型を使用して、顧客アカウントなどの実世界のエンティティをモデル化できます。

オブジェクト型はユーザー定義の型です。オブジェクト型をリダクションすることはできません。これは、データベース・リダクションでは、オブジェクト型を構成できる可能性のある一部の方法を処理できないためです(ユーザー定義であるため)。オブジェクトで使用する型は、ALL_OBJECTSデータ・ディクショナリ・ビューのOBJECT_NAMEおよびOBJECT_TYPE列を問い合せることで検索できます。

17.8 Oracle Data RedactionおよびXML生成

Oracle Data Redactionポリシーが定義されている列で、XML生成関数を使用することはできません。

この制限は、Oracle Data Redactionポリシーが有効化されているか無効化されているか、または問合せを行っているユーザーに対してアクティブかどうかに関係なく適用されます。

17.9 Oracle Data Redactionおよびエディション

エディション化ビューはリダクションできません。エディションが有効なスキーマのエディション化可能なビューはリダクションできません。

これら2つの制限に加えて、エディション管理されたビューの定義では、リダクションされた列を使用できません。DBA_EDITIONSデータ・ディクショナリ・ビューを問い合せると、エディションに関する情報を検索できます。

17.10 Oracle Data RedactionとOracle Virtual Private Database

VPD述語を含むVPDインライン・ビューは実際の値で動作するため、Oracle Virtual Private DatabaseポリシーはOracle Data Redactionの影響を受けません。

Oracle Data Redactionは、次の点でOracle Virtual Private Databaseとは異なります。

  • Oracle Data Redactionは、NULLリダクションのみをサポートするOracle Virtual Private Databaseよりも多くのリダクション機能を提供します。多くのアプリケーションでは、NULLリダクションを使用できないため、そのようなアプリケーションでは、データ・リダクションは有効な解決策です。

  • Oracle Virtual Private Databaseポリシーは静的、動的および文脈依存を使用できる一方、データ・リダクション・ポリシーは、静的および文脈依存のポリシー表現のみを使用できます。

  • データ・リダクションは、表またはビューに定義するポリシーを1つのみを許可する一方、オブジェクトには、複数の仮想プライベート・データベースのポリシーを定義できます。

  • アプリケーション・ユーザーは、シノニムを使用するデータ・リダクション・ポリシーで保護されたオブジェクトにアクセスできますが、(Oracle Virtual Private Databaseの場合とは異なり、)データ・リダクションではシノニム自体に直接ポリシーを作成できません。

17.11 Oracle Data RedactionとOracle Database Real Application Security

Oracle Data Redactionは、アプリケーションに対するセキュリティの実装方法の点でOracle Database Real Application Securityとは異なります。

Oracle Data Redactionは、アプリケーション・セキュリティに包括的な認可フレームワークを提供している点で、Oracle Database Real Application Securityとは異なります。

Real Application Security内の列セキュリティは、Real Application Securityフレームワークを使用してアプリケーションで定義されるアプリケーション権限に基づきます。

17.12 Oracle Data RedactionとOracle Database Vault

Oracle Database Vault環境で、Oracle Data Redactionを使用できます。

たとえば、オブジェクトがOracle Database Vaultレルムに含まれている場合、レルムの所有者または参加者の認証済リストに属していないユーザーは、ユーザーにEXEMPT REDACTION POLICY権限が付与されているかどうかにかかわらず、オブジェクト・データを表示できません。ユーザーがデータに対してDMLまたはDDL文を試みると、エラー・メッセージが表示されます。

17.13 Oracle Data RedactionとOracle Data Pump

Oracle Data Pumpのエクスポート操作は、Oracle Data Redactionポリシーを含むオブジェクトに影響を与えることがあります。

17.13.1 Oracle Data RedactionのためのOracle Data Pumpセキュリティ・モデル

DATAPUMP_EXP_FULL_DATABASEロールには、強力なEXEMPT REDACTION POLICYシステム権限が含まれます。

デフォルトでは、DBAロールにDATAPUMP_EXP_FULL_DATABASEロールおよび DATAPUMP_IMP_FULL_DATABASEロールが付与されることに注意してください。

これによって、これらのロールを付与されたユーザーは、データ・リダクション・ポリシーから除外されます。このため、オブジェクトに定義されているデータ・リダクション・ポリシーでオブジェクトをエクスポートすると、保護されている表の実際のデータは、リダクションされずにData Pumpのターゲット・システムにコピーされます。DBAロールを含むこれらのロールを持つユーザーは、ターゲット・システム内の実際のデータを参照できます。

ただし、デフォルトでは、Data Pumpのソース・システムの任意の表およびビューに関連付けられたすべてのデータ・リダクション・ポリシーも(オブジェクト自体とともに)エクスポートおよびインポート操作に含まれ、ターゲット・システムのオブジェクトに適用されるため、ユーザーがターゲット・システム内のオブジェクトを問い合せると、データはリダクションされます。

17.13.2 Oracle Data Redactionポリシーが定義されているオブジェクトのエクスポート

Oracle Data Redactionポリシーがすでに定義されているオブジェクトをエクスポートできます。

17.13.2.1 Oracle Data Pumpで使用されるオブジェクト・タイプの検索

Oracle Data Redactionポリシーが定義されているオブジェクトをエクスポートする前に、Oracle Data Pumpで使用されるオブジェクト・タイプを検索する必要があります。

これらのオブジェクト・タイプを検索した後、これらのオブジェクト・タイプをEXPDPユーティリティのINCLUDEディレクティブに対するパラメータとして使用して、その特定のオブジェクト・タイプのメタデータのみをダンプ・ファイルに選択的にエクスポートできます。

  • オブジェクト・タイプを検索するには、DATABASE_EXPORT_OBJECTSビューを問い合せます。

たとえば:

SELECT OBJECT_PATH
FROM DATABASE_EXPORT_OBJECTS
WHERE OBJECT_PATH LIKE 'RADM_%'; 

次のような出力が表示されます。

OBJECT_PATH
------------
RADM_FPTM
RADM_POLICY
RADM_POLICY_EXPR
17.13.2.2 データ・リダクション・ポリシーに関連するデータ・ディクショナリ・メタデータのみのエクスポート

Oracle Database Pumpメタデータ・フィルタを使用して、データ・ディクショナリ・メタデータのみをエクスポートできます。

この種のデータ・ポンプ・エクスポートは、開発、テストおよび本番の各データベース間でデータ・リダクション・ポリシーおよび設定の同じセットを使用する必要がある場合などに使用できます。content=metadata_onlyフラグが指定されているため、ダンプ・ファイルに実際のデータは含まれません。

  • データ・リダクション・ポリシー、完全リダクション設定およびポリシー式に関連するデータ・ディクショナリ・メタデータのみをエクスポートするには、RADM_POLICYRADM_FPTMおよびRADM_POLICY_EXPRを次のようなEXPDPユーティリティ・コマンドに含めます:

    expdp system/password \
    full=y \
    COMPRESSION=NONE \
    content=metadata_only \
    INCLUDE=RADM_FPTM,RADM_POLICY,RADM_POLICY_EXPR \
    directory=my_directory \
    job_name=my_job_name \
    dumpfile=my_data_redaction_policy_metadata.dmp
    
17.13.2.3 IMPDPのINCLUDEパラメータを使用したデータ・ディクショナリ・メタデータのみのインポート

Oracle Database Pumpメタデータ・フィルタを使用して、データ・ディクショナリ・メタデータのみをインポートできます。

  • データ・リダクション・ポリシー、完全リダクション設定およびポリシー式に関連するデータ・ディクショナリ・メタデータのみをインポートするには、RADM_POLICYRADM_FPTMおよびRADM_POLICY_EXPRを次のようなIMPDPユーティリティ・コマンドに含めます:

    impdp system/password \
    full=y \
    content=metadata_only \
    INCLUDE=RADM_FPTM,RADM_POLICY,RADM_POLICY_EXPR \
    directory=my_directory \
    job_name=my_job_name \
    dumpfile=my_data_redaction_policy_metadata.dmp

17.13.3 EXPDPユーティリティのaccess_methodパラメータを使用したデータのエクスポート

Oracle Data Pumpによって、データ・リダクション・ポリシーのあるオブジェクトを含むスキーマからデータをエクスポートできます。

Oracle Data Pumpを使用して、新しいデータ・ポンプのデフォルト設定(direct_path)に基づいてデータベースの全体エクスポート操作を実行し、理解できないエラー・メッセージが返された場合、この項を使用して、エラーをより正確に理解できるような方法で操作を繰り返してください。

access_methodパラメータがdirect_pathに設定されたOracle Data Pump Export (EXPDP)ユーティリティを使用してデータをスキーマからエクスポートしようとするとき、このスキーマにデータ・リダクション・ポリシーが定義されているオブジェクトが含まれていると、次のエラー・メッセージが表示される場合があり、エクスポート操作は失敗します。

ORA-31696: unable to export/import TABLE_DATA:"schema.table" using client specified DIRECT_PATH method

この問題は、スキーマ・レベルのエクスポートを、EXP_FULL_DATABASEロールを付与されていないユーザーとして実行する場合にのみ発生します。EXP_FULL_DATABASEロールを必要とするフル・データベース・エクスポート時には発生しません。EXP_FULL_DATABASEロールにはEXEMPT REDACTION POLICYシステム権限が含まれており、これによりデータ・リダクション・ポリシーが無視されます。

潜在的な問題を見つけるには、EXPDP起動を再度試してください。ただし、access_methodパラメータをdirect_pathには設定しないでください。かわりに、automaticexternal_tableのどちらかを使用してください。潜在的な問題とは、たとえば次のような権限の問題です。

ORA-28081: Insufficient privileges - the command references a redacted object.

17.13.4 Oracle Data Redactionで保護されているオブジェクトへのデータのインポート

Oracle Data Redactionで保護されているオブジェクトへのインポート操作中に、問題が発生する可能性があるため注意してください。

Oracle Data Redactionポリシーの意図しない削除

インポート操作中に、インポートされるデータを保護するデータ・リダクション・ポリシーを誤って削除しないように注意してください。

Oracle Data Pumpエクスポート(EXPDP)ユーティリティを使用してエクスポートされたソース表にOracle Data Redactionポリシーが存在しないシナリオを考えてみます。ただし、Oracle Data Pumpインポート(IMPDP)を使用してデータをインポートする宛先表には、Oracle Data Redactionポリシーが存在します。

Data Pumpインポート操作中、インポートされるオブジェクトでのデータ・リダクション・ポリシーのステータスは、IMPDPコマンドのCONTENTオプションによって異なります。
  • IMPDPコマンドでCONTENT=ALL またはCONTENT=METADATA_ONLYオプションを使用する場合、宛先表のデータ・リダクション・ポリシーは削除されます。データ・リダクション・ポリシーを再作成する必要があります。

  • IMPDPコマンドでCONTENT=DATA_ONLYを使用する場合、宛先表のデータ・リダクション・ポリシーは削除されません。

インポートされないデータ・リダクション・ポリシー

インポート操作中に、ORA-28069: A Data Redaction Policy Already Exists On This Objectエラーが発生する可能性があります。

Oracle Data Pump Export (EXPDP)ユーティリティを使用してエクスポートされたソース表にOracle Data Redactionポリシーが存在するシナリオを考えてみます。Oracle Data Pump (IMPDP)を使用してデータをインポートする宛先表にも、Oracle Data Redactionポリシーが存在します。

データ・ポンプ・インポート操作中に、ORA-28069エラーが発生する可能性があります。このエラーを回避するには、CONTENT=DATA_ONLYパラメータを使用してデータのみをインポートする必要があります。または、ターゲット・オブジェクトのリダクション・ポリシーを削除してから、すべてのデータをインポートできます。

17.14 Oracle Data RedactionとData Masking and Subsetting Pack

Oracle Enterprise Manager Data Masking and Subsetting Packを使用して、本番データベースの開発またはテスト・コピーを作成できます。

これを実行するには、このデータを一括でマスクして、出力後のマスクされたデータを開発またはテスト・コピーに配置します。

Oracle Enterprise Manager Data Masking and Subsetting Packですでにマスクされたデータを含む列をリダクションする場合は、データ・リダクション・ポリシーを本番以外のデータベースに適用してもかまいません。

データを開発およびテスト環境に移行する場合は、Oracle Enterprise Manager Data Masking and Subsetting Packを使用して、必ずデータ・セットをマスクしてください。データ・リダクションは、アプリケーション・コードを変更せずに、複数のアプリケーション間で一貫した方法で、起動時に本番アプリケーションをリダクションすることを主な目的として設計されています。

17.15 Oracle Data RedactionおよびJSON

リダクションされたデータでJavaScript Object Notation (JSON)を使用できます。

  • 表の列にis json制約を作成できます。

    ただし、is json制約のある表の列にOracle Data Redactionポリシーを作成することはできません。これを試みると、ORA-28073 - The column column_name has an unsupported datatypeエラーが発生します。回避策として、JSONオブジェクトの上にJSON_TABLE行ソース演算子使用するリレーショナル・ビューを作成し、このビューに対してデータ・リダクション・ポリシーを適用することをお薦めします。

    次の例は、json_tableを使用してリレーショナル・ビューを作成し、このビューにデータ・リダクション・ポリシーを追加する方法を示しています。

    create table tab1
            (c1 varchar2(4000) check (c1 is json))
    
    insert into tab1 values
    ('{"id" : 4,
       "name" : "Large blue soda cup",
       "price" : 12,
       "tags" : ["large1", "green"],
       "phone" : "1-415-555-0100"}'
    )
    
    create or replace view json_view1 as
     select t.* from tab1,
      json_table(c1, '$' columns
           id number path '$.id',
           name varchar2(20) path '$.name',
           price number path '$.price',
           phone varchar2(20) path '$.phone') t ;

    ビューの所有者が列phoneを問い合せた場合、この列はリダクションされません。これで、ビュー内の任意の列(phonepriceなど)にリダクション・ポリシーを追加できます。

  • リダクションされたデータの上にJSON二面性ビューを作成できます。

    ただし、この機能には制限があります。リダクションが有効な列は主キーにできず、二面性ビューのエンティティ・タグ(ETAG)の一部にもできません。