機械翻訳について

スコープの定義による表ハイパーリンクを使用したフェデレーテッド表の作成

Autonomous AI Database Tableハイパーリンクを介してフェデレーテッド表を作成できます。 フェデレーテッド表は、表ハイパーリンクで定義された外部表です。 複数のAutonomous AI Databaseインスタンスからのデータを集計できます。

フェデレーテッド表では、外部表と同じハイパーリンク・メカニズムを使用していますが、作成ワークフローは異なります。 外部表の場合、プロバイダは表ハイパーリンクを作成および共有し、各コンシューマはこれらのハイパーリンクを使用して外部表を定義します。 フェデレーテッド表の場合、コンシューマは表の作成を開始し、プロバイダ・データベースに表ハイパーリンクが自動的に作成されます(コンシューマプロバイダで定義された範囲内にある場合)。

プロバイダとして、データベースにスコープを定義して、コンシューマに表ハイパーリンクを自動的に作成する権限を付与できます。 これらのスコープ内の認可されたコンシューマは、手動リンク交換なしで、フェデレーテッド表を作成し、複数のソース・データベースからデータを問い合せることができます。

表ハイパーリンクを作成するためのスコープを定義する主な利点は次のとおりです。
  • 簡易データ共有 - コンシューマは、外部表の作成を個別に開始でき、認可されたスコープに属しているときに表のハイパーリンクを作成できるようになりました。
  • セキュリティの強化 - セキュアでない表ハイパーリンク(URL)の配布方法を排除します。
  • データ・フェデレーション - コンシューマは、フェデレーテッド表を介して複数のプロバイダ・データベースのデータを集計できます。

次の各項では、実例のユースケースでスコープを定義することで、プロバイダおよびコンシューマAutonomous Databasesがフェデレーテッド表を一緒に作成する方法に関する詳細なワークフローの概要を示します。 このワークフローおよび関連するコード例は、要件に応じて変更および実装できます。

フェデレーテッド表を作成するためのワークフロー

次のワークフローには、プロバイダーの自律型AIデータベースと消費者の自律型AIデータベースに対する個別の責任があります。

プロバイダ側から、最初のステップは、プロバイダに表ハイパーリンクをリモートで作成できるコンシューマAutonomous AIデータベースを指定する作成スコープを定義することです。 スコープは、スキーマ・レベルまたはオブジェクト・レベルで設定できます。

次に、プロバイダDBAは、選択したユーザーの DBMS_DATA_ACCESS_ADMIN.GRANT_REGISTERをコールして、スコープを管理できるユーザーを制御します。 これらの特権ユーザーは、 DBMS_DATA_ACCESS_SCOPE.REGISTER_CREATION_SCOPEUPDATE_CREATION_SCOPEおよびUNREGISTER_CREATION_SCOPEを使用して、特定の表またはスキーマのスコープを登録、変更または削除したり、LIST_CREATION_SCOPESを使用して現在の構成を確認できます。 コンシューマが後でハイパーリンクをリクエストすると、リクエスト元のコンシューマAutonomous AI Databaseが登録済スコープと一致することをプロバイダがチェックしてからURL生成を許可し、適格なコンシューマのみがプロバイダ・データへのハイパーリンクを作成できるようにします。

コンシューマの観点からは、プロバイダがコンシューマ・データベースを含むスコープを定義すると、ワークフローが開始されます。 コンシューマDBAは、DBMS_DATA_ACCESS_ADMIN.GRANT_READをコールして、プロバイダ・データを介してフェデレーテッド表を作成する権限を特定のユーザーに付与します。

コンシューマは、DBMS_DATA_ACCESS.CREATE_FEDERATED_TABLEをコールして、コンシューマにかわってプロバイダのデータベースに表ハイパーリンクを作成でき、その結果、コンシューマ内のフェデレーテッド表は、プロデューサ・データをローカル外部表であるかのように問い合せることができます。

フェデレーテッド・アクセスが不要になった場合、コンシューマはDBMS_DATA_ACCESS.DROP_FEDERATED_TABLEをコールしてクリーン・アップします。これにより、プロバイダのスコープはそのままの状態でコンシューマ内のフェデレーテッド表オブジェクトが削除されます。

中央プロバイダーのAutonomous AI Databaseが共有マスター・データを保持し、部門の消費者向けAutonomous AI Databaseがデータの重複やサポート・チケットなしで分析アクセスを必要としているOracle Autonomous AI Databaseインスタンスを使用する組織について考えてみましょう。 分析部門のビジネス・アナリストは、プロバイダ定義のスコープを使用してガバナンスを維持しながら、レポートをより迅速に実行するために、プロバイダ・データに対する外部表のセルフサービス作成を必要とします。 次の要件で終了しました。
  1. ADMIN (Provider)は、DBMS_DATA_ACCESS_ADMIN.GRANT_REGISTERプロシージャを使用してスコープ登録権限をデータ所有者に付与します。
    BEGIN
    DBMS_DATA_ACCESS_ADMIN.GRANT_REGISTER(
    username => 'DATA_OWNER',
    scope => 'MY$COMPARTMENT'
    );
    END;
    /
  2. ADMINとして、データ所有者(DATA_OWNER)ユーザーに実行権限を付与します。
    grant execute on DBMS_DATA_ACCESS_SCOPE to DATA_OWNER;
  3. データ所有者は、DBMS_DATA_ACCESS_SCOPE.REGISTER_CREATION_SCOPEプロシージャを使用して、プロバイダAutonomous AI Databaseの共有スキーマまたはオブジェクトに作成スコープを登録します。 これにより、同じコンパートメント内のコンシューマAutonomous AIデータベースが、表ハイパーリンクをリモートで作成できるようになります。
    BEGIN
    DBMS_DATA_ACCESS_SCOPE.REGISTER_CREATION_SCOPE(
    schema_name => 'DATA_OWNER',
    schema_object_name => 'SALES_DATA',
    scope => 'MY$COMPARTMENT'
    );
    END;
    /
  4. コンシューマADMINは、DBMS_DATA_ACCESS_ADMIN.GRANT_READプロシージャを使用してビジネス・アナリストに対して読取り権限を付与します。
    BEGIN
    DBMS_DATA_ACCESS_ADMIN.GRANT_READ(
    username => 'BI_ANALYST',
    remote_schema_name => 'DATA_OWNER',
    remote_schema_object_name=> 'SALES_DATA'
    );
    END;
    /

    これにより、アナリストはフェデレーテッド表の作成を開始できます。

  5. コンシューマADMINは、bi_analystユーザーに実行権限を付与します。
    grant execute on DBMS_DATA_ACCESS to bi_analyst;
  6. ビジネス・アナリストは、DBMS_DATA_ACCESS.CREATE_FEDERATED_TABLEプロシージャを使用して、コンシューマAutonomous AI Databaseにフェデレーテッド外部表を作成します。 これにより、プロバイダの介入が不要な場所にスコープが一致した場合に、表のハイパーリンクが自動的に生成されます。

    例:

    BEGIN
    DBMS_DATA_ACCESS.CREATE_FEDERATED_TABLE(
    table_name => 'DEPT_SALES_XT',
    remote_schema_name => 'DATA_OWNER',
    remote_schema_object_name => 'SALES_DATA',
    db_ocids => '[{"region": "IAD", "db_ocid": "OCID1.AUTONOMOUSDATABASE.OC1.IAD.EXAMPLE123"}]'
    );
    END;
    /

    ノート:

    データベースOCID (db_ocid)は大文字である必要があります。
    BEGIN
    DBMS_DATA_ACCESS.CREATE_FEDERATED_TABLE(
    table_name                => 'DEPT_SALES_XT',
    remote_schema_name        => 'DATA_OWNER',
    remote_schema_object_name => 'SALES_DATA',
    db_names                  => '[{"region": "IAD", "db_name": "NU8PYOYTEWX1L5M_SALESDB"}]'
    );
    END;
    /
  7. アナリストは、外部表に部門分析を問い合せます。
    SELECT * FROM DEPT_SALES_XT WHERE region = 'West';

    前述のコード例は、要件に従って変更および実装できます。

  8. ADMIN (Provider)は、DBMS_DATA_ACCESS_ADMIN.REVOKE_REGISTERプロシージャを使用して、データ所有者からスコープ登録権限を取り消します。
    BEGIN
      DBMS_DATA_ACCESS_ADMIN.REVOKE_REGISTER(username => 'DATA_OWNER');
    END;
    /

前述のファンクションおよびパラメータの詳細は、DBMS_DATA_ACCESS_SCOPEパッケージDBMS_DATA_ACCESS_ADMINパッケージおよびDBMS_DATA_ACCESSパッケージを参照してください。

次の表に、スコープとその説明を設定して、フェデレーテッド表の作成ワークフローに関与する操作を示します。
操作 説明 この操作を実行するユーザー
作成スコープの定義 プロバイダAutonomous AI Databaseインスタンスに表ハイパーリンクをリモートで作成できるデータベースを定義します。 詳細は、「作成範囲」を参照してください。 プロバイダ
登録権限を付与

プロバイダAutonomous AI Databaseインスタンスのどのユーザーがスコープを登録または更新できるかを付与します。

詳細は、Grant Registerを参照してください。

プロバイダ
作成スコープの登録

指定された認可スコープの下に作成される表ハイパーリンクを持つことができるデータベース・オブジェクトを定義します。

詳細は、登録作成範囲を参照してください。

プロバイダ
作成スコープの更新 既存の作成スコープを変更します。 詳細は、作成範囲の更新を参照してください。 プロバイダ
作成スコープの登録解除 スキーマ、単一オブジェクトまたはオブジェクトのリストに対して以前に登録された作成スコープ設定を削除します。 詳細は、Unregister Creation Scopeを参照してください。 プロバイダ
作成スコープの取得 指定されたスキーマまたはオブジェクトの登録済作成スコープを問い合せて取得します。 詳細は、リスト作成スコープを参照してください。 プロバイダ
フェデレーテッド表の作成 フェデレーテッド表を作成します。 詳細は、フェデレーテッド表の作成を参照してください。 Consumer
読取りの付与 リモート・スキーマまたはオブジェクトに対する読取り権限をコンシューマ・ユーザーに付与し、フェデレーテッド表の作成を可能にします。 詳細は、Grant Readを参照してください。 Consumer
読取りの取消 フェデレーテッド表を作成するための、以前に付与された読取り権限を取り消します。 詳細は、Revoke Readを参照してください。 Consumer
フェデレーテッド表の削除 指定されたフェデレーテッド表をデータベースから削除します。 詳細は、フェデレーテッド表の削除を参照してください。 Consumer

作成スコープ

プロバイダ・データベース内の作成スコープによって、プロバイダ・データベースに表ハイパーリンクをリモートで作成できるコンシューマAutonomous AI Databaseインスタンスが決まります。

スコープは複数のレベルで定義できます。
  • テナンシ・ベース(MY$TENANCY) - プロバイダ・データベースと同じテナンシ内のすべてのデータベース。
  • コンパートメントベース(MY$COMPARTMENT) - プロバイダ・データベースと同じコンパートメントにある任意のデータベース。
  • リージョン・ベース(MY$REGION) - プロバイダ・データベースと同じリージョンにある任意のデータベース。
  • プールベース(MY$POOL) - プロバイダ・データベースと同じプール内のすべてのデータベース。
  • オブジェクト・レベル - スキーマ内の特定の表またはビュー。
  • スキーマ・レベル - 特定のスキーマ内のすべてのオブジェクト。

ノート:

オブジェクトにスキーマ・レベルのスコープとオブジェクト・レベルのスコープの両方がある場合、コンシューマ・リクエストは両方のスコープを満たしてフェデレーテッド表を作成する必要があります。

スコープを登録、登録解除、更新および取得するプロシージャを提供するDBMS_DATA_ACCESS_SCOPEパッケージを使用して、作成スコープを管理できます。 詳細は、DBMS_DATA_ACCESS_SCOPEを参照してください。

登録権限を付与

プロバイダAutonomous AI DatabaseのADMIN (またはPDB_DBA)は、DBMS_DATA_ACCESS_ADMIN.GRANT_REGISTERを使用して、作成スコープの管理を許可するローカル・ユーザーを決定します。

スコープを登録、更新または登録解除できるのは、これらの特権ユーザーのみであり、プロバイダ表の非制御エクスポージャを防止できます。

BEGIN
DBMS_DATA_ACCESS_ADMIN.GRANT_REGISTER(
username => 'ANALYTICS_ADMIN',
scope => 'MY$COMPARTMENT'
);
END;
/

前述の例では、MY$COMPARTMENTスコープ内にデータ・セットを登録する権限をANALYTICS_ADMINユーザーに付与しています。

構文リファレンスについては、GRANT_REGISTERを参照してください。

作成スコープの登録

プロバイダは、DBMS_DATA_ACCESS_SCOPE.REGISTER_CREATION_SCOPEをコールして、特定の表またはスキーマ全体に対して許可されるスコープを登録し、それらのオブジェクトへの表ハイパーリンクを作成します。

例: スキーマ・レベルのスコープの登録
BEGIN
DBMS_DATA_ACCESS_SCOPE.REGISTER_CREATION_SCOPE(
schema_name => 'ANALYTICS',
schema_object_name => 'NULL',
scope => 'MY$COMPARTMENT'
);
END;
/

この例では、ANALYTICSスキーマのスキーマ・レベルでデータ・アクセス・スコープを登録し、それをコンパートメントMY$COMPARTMENTに関連付けます。

例: オブジェクト・レベルのスコープの登録

BEGIN
DBMS_DATA_ACCESS_SCOPE.REGISTER_CREATION_SCOPE(
schema_name => 'ANALYTICS',
schema_object_name => 'SALES_DATA',
scope => 'MY$TENANCY'
);
END;
/

この例では、ANALYTICSスキーマ内の特定のオブジェクトSALES_DATAに対して、よりターゲットを絞ったデータ・アクセス・スコープを登録し、テナンシMY$TENANCYにリンクします。 スキーマ・レベルのバージョンとは異なり、schema_object_nameでは、この表のみに強制が制限されるため、作成権限を詳細に制御できます。

例: 複数のオブジェクトの登録
BEGIN
DBMS_DATA_ACCESS_SCOPE.REGISTER_CREATION_SCOPE(
schema_name => 'ANALYTICS',
schema_object_list => '["SALES_DATA", "CUSTOMER_DATA", "PRODUCT_DATA"]',
scope => 'MY$COMPARTMENT'
);
END;
/

このプロシージャは、リストされたスキーマ・オブジェクト(SALES_DATACUSTOMER_DATAおよびPRODUCT_DATA)をスコープMY$COMPARTMENTに関連付け、そのコンパートメント内のエンティティの作成またはアクセスを制限します。

構文リファレンスは、登録作成範囲を参照してください。

作成スコープの更新

プロバイダがアクセスを変更する必要がある場合、同じまたは別の認可ユーザーがUPDATE_CREATION_SCOPEを起動して、特定のスキーマ・オブジェクトに対してどのコンシューマAutonomous AIデータベースがハイパーリンクを作成できるかを拡張、絞り込みまたは調整します。

BEGIN
DBMS_DATA_ACCESS_SCOPE.UPDATE_CREATION_SCOPE(
schema_name => 'ANALYTICS',
schema_object_name => 'SALES_DATA',
scope => 'MY$COMPARTMENT'
);
END;
/

この例では、ANALYTICSスキーマのSALES_DATA表の作成範囲をMY$COMPARTMENTに更新します。

構文リファレンスは、作成範囲の更新を参照してください。

作成スコープの登録解除

プロバイダがリモート作成機能(表、表のリストまたはスキーマ)を完全に取り消す場合、プロバイダはUNREGISTER_CREATION_SCOPEを呼び出します。 これにより、登録されたスコープが削除され、コンシューマ・データベースによってこれらのオブジェクトに対して新しい表ハイパーリンクが作成されるのを防ぎます。

BEGIN
DBMS_DATA_ACCESS_SCOPE.UNREGISTER_CREATION_SCOPE(
schema_name => 'ANALYTICS',
schema_object_name => 'SALES_DATA'
);
END;
/

このブロックの例では、ANALYTICSスキーマ内のSALES_DATAに対して以前に登録された作成スコープが削除されるため、そのスコープの下に作成された新しいオブジェクトは、適用されるスコープをデータ・アクセス制御によって制御されなくなります。

構文リファレンスについては、Unregister Creation Scopeを参照してください。

作成スコープの取得

認可されたユーザーは、いつでもLIST_CREATION_SCOPESをコールして現在のスコープ定義を取得できます。

DECLARE
l_result CLOB;
BEGIN
DBMS_DATA_ACCESS_SCOPE.LIST_CREATION_SCOPES(
schema_name => 'ANALYTICS',
result => l_result
);
DBMS_OUTPUT.PUT_LINE(l_result);
END;
/

構文リファレンスについては、作成範囲の取得を参照してください。

読取りの付与

コンシューマAutonomous AI Databaseでは、ADMIN (またはPDB_DBA)がDBMS_DATA_ACCESS_ADMIN.GRANT_READを使用して、リモート・プロバイダ・スキーマまたはオブジェクトに対してフェデレーテッド表を作成する権限を特定のユーザーに付与します。

例: 特定のリモート・オブジェクトへのアクセス権の付与

BEGIN
DBMS_DATA_ACCESS_ADMIN.GRANT_READ(
username => 'BI_ANALYST',
remote_schema_name => 'ANALYTICS',
remote_schema_object_name => 'SALES_DATA'
);
END;
/

この例では、BI_ANALYSTユーザーに、外部データ・プロバイダのANALYTICSスキーマ内の特定のリモートSALES_DATAオブジェクトへの読取りアクセス権を付与します。

構文リファレンスについては、Grant Readを参照してください。

読取りの取消

REVOKE_READプロシージャは、プロバイダ・データベース内の指定されたリモート・スキーマまたはスキーマ・オブジェクトを介してフェデレーテッド表を作成するユーザーの権限を削除します。

リモート・オブジェクト名を省略すると、指定されたリモート・スキーマ内のすべてのオブジェクトに対するそのユーザーのフェデレーテッド表アクセスが取り消されます。

BEGIN
DBMS_DATA_ACCESS_ADMIN.REVOKE_READ(
username => 'BI_ANALYST',
remote_schema_name => 'ANALYTICS',
remote_schema_object_name => 'SALES_DATA'
);
END;
/

構文リファレンスについては、Revoke Readを参照してください。

フェデレーテッド表の作成

読取り権限を付与されたコンシューマ・ユーザーは、DBMS_DATA_ACCESS.CREATE_FEDERATED_TABLEを呼び出して、プロバイダのスコープ内表またはビューに対するフェデレーテッド表を作成します。

このプロシージャでは、データベースOCIDsおよびリージョン情報を使用して表ハイパーリンクを確立し、コンシューマがリモート・データをローカル外部表であるかのように問い合せることができるようにします。

前提条件

  • ユーザーには、GRANT_READプロシージャを使用して読取り権限を付与する必要があります。
  • ユーザーは、必要な権限を持つコンシューマ・データベースとプロバイダ・データベースの両方に存在する必要があります。
  • コンシューマ・データベースは、プロバイダの作成スコープに属している必要があります。
  • プロバイダには、ターゲット・オブジェクトの作成スコープが登録されている必要があります。
  • コンシューマ・データベースとプロバイダ・データベースの間に確立されたネットワーク接続。
リージョン間のサポート
  • プロバイダとコンシューマのAutonomous AI Databaseインスタンスが異なるOCIリージョンにある場合でも、プロバイダ・スコープ表のハイパーリンクを使用してフェデレーテッド表を作成できます。

  • これは、データ・ソース(プロバイダ)が米国東部リージョンにあり、コンシューマ・データベースがヨーロッパ西部にある場合でも、表ハイパーリンクを使用してフェデレーテッド表を設定できることを意味します。

例: 単一プロバイダ

BEGIN
DBMS_DATA_ACCESS.CREATE_FEDERATED_TABLE(
table_name => 'SALES_FED',
remote_schema_name => 'ANALYTICS',
remote_schema_object_name => 'SALES_DATA',
db_ocids => '[{"region": "IAD", "db_ocid": "OCID1.AUTONOMOUSDATABASE.OC1.IAD.EXAMPLE123"}]'
);
END;
/

前述の例では、コンシューマはDBMS_DATA_ACCESS.CREATE_FEDERATED_TABLEをコールして、リモート・プロバイダの表またはビューにリンクするローカル・フェデレーテッド表(たとえば、ANALYTICSスキーマのSALES_DATA)を構築し、JSON db_ocidsを使用してプロバイダ・データベースOCIDsおよびリージョンを指定し、ローカルであるかのようにシームレスな問合せを行います。

コンシューマがフェデレーテッド表を作成するとします。 これらは、通常の外部表と同様に問い合せることができます。
SELECT
REGION,
PRODUCT_ID,
SUM(SALES_AMOUNT) as total_sales,
COUNT(*) as transaction_count
FROM SALES_FED
GROUP BY REGION, PRODUCT_ID
ORDER BY total_sales DESC;

構文リファレンスは、フェデレーテッド表の作成を参照してください。

フェデレーテッド表の削除

フェデレーテッド・アクセスが不要になった場合、コンシューマ・ユーザーはDBMS_DATA_ACCESS.DROP_FEDERATED_TABLEをコールしてフェデレーテッド表を削除します。

このプロシージャは、コンシューマ側のオブジェクトをクリーン・アップし、その特定のフェデレーテッド・アクセス・パスを効果的に終了しますが、基礎となるプロバイダ・スコープおよび権限はプロバイダ制御下にとどまります。

BEGIN
DBMS_DATA_ACCESS.DROP_FEDERATED_TABLE(
table_name => 'SALES_FED'
);
END;
/

前述の例では、SALES_FED表を削除します。

構文リファレンスについては、フェデレーテッド表の削除を参照してください。

APIクイック・リファレンス

この項では、フェデレーテッド表で使用可能な主要なAPIの概要を簡単に説明します。 これらのAPIを使用すると、データ・アクセス権限の管理、フェデレーテッド表作成スコープの制御、およびフェデレーテッド表操作の実行を行うことができます。

フェデレーテッド表のキーAPIのサマリー

パッケージ プロシージャまたはファンクション

DBMS_DATA_ACCESS_ADMINパッケージ

  • GRANT_REGISTER: データ・ソースを登録する権限を付与します。

  • REVOKE_REGISTER: 登録データ・ソースから権限を取り消します。

  • GRANT_READ: 読取りアクセス権限を付与します。

  • REVOKE_READ: 読取りアクセス権限を取り消します。

DBMS_DATA_ACCESS_SCOPEパッケージ

  • REGISTER_CREATION_SCOPE: フェデレーテッド表の作成スコープを登録します。

  • UPDATE_CREATION_SCOPE: 既存の作成スコープを更新します。

  • UNREGISTER_CREATION_SCOPE: 作成スコープを削除します。

  • LIST_CREATION_SCOPES: 使用可能なすべての作成スコープをリストします。

DBMS_DATA_ACCESSパッケージ

  • CREATE_FEDERATED_TABLE: フェデレーテッド表を作成します。

  • DROP_FEDERATED_TABLE: フェデレーテッド表を削除します。

トラブルシューティング・シナリオ

この項では、発生する可能性のある障害のタイプおよび問題のトラブルシューティングの手順について説明します。

  1. 範囲外のコンシューマ・データベース

    問題: コンシューマは、フェデレーテッド表を作成しようとしたときに認可エラーを受け取ります。

    解決方法

    • コンシューマ・データベースIDがプロバイダのスコープ基準と一致することを確認します。
    • GRANT_READプロシージャを使用して、ユーザーに読取り権限が付与されていることを確認します。
    • チェック・プロバイダは、REGISTER_CREATION_SCOPEプロシージャを使用して適切な作成スコープを登録しました。
    • OCIコンソールでデータベース登録ステータスを確認します。
  2. フェデレーテッド表の作成に失敗する

    問題: 前提条件を満たしていても、CREATE_FEDERATED_TABLEプロシージャは失敗します。

    解決方法
    • ユーザーがコンシューマ・データベースとプロバイダ・データベースの両方に存在することを確認します。
    • ユーザーにリモート・オブジェクトに対するオブジェクト所有権またはGRANT OPTION権限があることを確認します。
    • リモート・スキーマおよびオブジェクト名が正しいことを確認してください(大/小文字が区別されます)。
    • db_ocids JSONに有効なリージョン・コードとデータベースOCIDsが含まれていることを確認します。
    • プロバイダ・スコープが有効で、コンシューマ・データベースが含まれていることを確認します。
  3. 承認エラー

    問題: ユーザーはスコープを登録したり、フェデレーテッド表にアクセスできません。

    解決方法

    • GRANT_REGISTERプロシージャ(プロバイダ側)を使用して、ユーザーにREGISTER権限が付与されていることを確認します。
    • GRANT_READ (コンシューマ側)を使用して、ユーザーにREAD権限が付与されていることを確認します。
    • オブジェクト・レベルの操作の場合は、ユーザーがオブジェクトを所有しているか、またはGRANTオプション権限を持っていることを確認します。
    • スキーマ・レベルの操作の場合、ユーザーがADMINであるか、PDB_DBAロールを持っていることを確認します。
    • 権限失効履歴をチェックして、権限が明示的に取り消されていないことを確認してください。