Autonomous AI Database上の読取り専用データへのアクセスに対するクラウド・リンクを使用

クラウド・リンクは、自律型AIデータベース・インスタンス上の読取り専用データにリモートでアクセスするためのクラウドベースの方法を提供します。

Autonomous AI Databaseのクラウド・リンクについて

クラウド・リンクを使用すると、データ所有者は、データ所有者が定義したとおりに、選択したオーディエンスに対するリモート・アクセス用の表またはビューを登録し、登録時にアクセス権が付与されたユーザーがデータにアクセスできます。クラウド・リンクを設定するためにこれ以上のアクションは必要ありません。また、データを表示してアクセスする必要があるユーザーは、データを検出して操作できます。

クラウド・リンクの実装では、Oracle Cloud Infrastructureのアクセス・メカニズムを利用して、特定のスコープ内でデータにアクセスできるようにします。スコープは、データにリモートでアクセスできるユーザーを示します。スコープは、データベースが存在するリージョン、個々のテナンシ、コンパートメントなどの様々なレベルに設定できます。また、データ・セットにアクセスする認可が1つ以上のAutonomous AI Databaseインスタンスに制限されるように指定できます。

ソース(データ・セット所有者)のAutonomous AI Databaseインスタンスから1つ以上のクロス・リージョン・リフレッシュ可能クローンを作成することで、クラウド・リンクを使用して複数のリージョン間でデータを共有できます。

クラウド・リンクは、従来のデータベース・リンク・メカニズムと比較して、自律型AIデータベース・インスタンス間での表またはビューの共有を大幅に簡素化します。クラウド・リンクを使用すると、複雑なデータベース・リンクの設定を必要とせずにデータを検出できます。自律型AIデータベースは、SQLを使用して透過的なアクセスを提供し、クラウド・リンク・スコープおよび個々の自律型AIデータベース・インスタンスに認可を付与することで、権限の適用を実装します。

クラウド・リンクには、リージョン・ネームスペースの概念と、リモートからアクセス可能にするデータの名前が導入されています。これは、"LWARD"などのネームスペース(スキーマ)に存在する"EMP"など、表が存在する既存のOracle表と似ています。データベースに存在できるLWARD.EMPは1つのみです。クラウド・リンクは、リージョン・レベルで同様のネームスペースと名前を提供します。これは、単一のデータベースには関連付けられませんが、スコープで指定され、オプションでデータベース認可で指定されている多くのAutonomous AI Databaseインスタンスに適用されます。

たとえば、ネームスペースFORESTの下にデータ・セットを登録し、セキュリティ上の目的やネーミングを容易化する目的で、元のスキーマ名およびオブジェクト名以外のネームスペースと名前を指定することができます。この例では、TREE_DATAは登録済データ・セットの表示可能な名前であり、この名前をソース表の名前にする必要はありません。ネームスペースおよび名前に加えて、cloud$linkキーワードは、ソースをクラウド・リンクとして解決する必要があることをデータベースに示します。

登録済データ・セットにアクセスするには、SELECT文のFROM句にネームスペース、名前およびcloud$linkキーワードを含めます:

SELECT county, species, height FROM FOREST.TREE_DATA@cloud$link;

オプションで、1つ以上のデータベースからデータ・セットへのアクセスをリフレッシュ可能クローンにオフロードするように指定できます。コンシューマAutonomous AI Databaseがデータ・セットのオフロード・リストにリストされている場合、データ・セットへのアクセスはリフレッシュ可能クローンに送信されます。また、統合問合せオフロード機能を使用すると、エラスティック・プール・リーダーまたはメンバーをクラウド・リンク・プロバイダとして構成し、プロキシSQL問合せオフロードを有効にして、問合せ(読取り)を任意の数のリフレッシュ可能クローンにオフロードできます。

ノート

ノート:クラウド・リンクでは、Autonomous AI Databaseインスタンス上のリモート・オブジェクトへの読取り専用アクセス権が提供されます。他のOracleデータベースまたはOracle以外のデータベースとのデータベース・リンクを使用する場合、またはDML操作でリモート・データを使用する場合は、データベース・リンクを使用する必要があります。詳細は、Autonomous AI Databaseでのデータベース・リンクの使用を参照してください。

クラウド・リンクでは、プライベート・シノニムとパブリック・シノニムがサポートされています。たとえば、FOREST.TREE_DATA@cloud$linkのシノニムを定義して使用できます。

CREATE SYNONYM S1 for FOREST.TREE_DATA@cloud$link;
SELECT county, species, height FROM S1;

CREATE PUBLIC SYNONYM S2 for FOREST.TREE_DATA@cloud$link;
SELECT * FROM S2;

シノニムの詳細は、「シノニムの概要」を参照してください。

クラウド・リンクの操作時に使用する概念と用語はいくつかあります。

  • 登録済データ・セット(データ・セット): Autonomous AI Databaseでのリモート・アクセスに対して有効になっている表またはビューを識別します。登録済データ・セットは、データ・セットへのアクセスを許可されているユーザー(スコープ)も示します。データ・セット登録では、クラウド・リンクで使用するネームスペースと名前を定義します。データ・セット登録後、これらの値は一緒にリモート・アクセス用の完全修飾名(FQN)を指定し、クラウド・リンクでデータ・セットのアクセシビリティを管理できるようにします。

  • データ・セット所有者: データ・セットに関する質問の連絡先を提供するデータ・セット所有者を指定します。

  • スコープ: 登録したデータ・セットへのアクセスを許可されるユーザー、およびその場所を指定します。スコープの詳細は、Data Set Scope、Access ControlおよびAuthorizationを参照してください。

  • OCID (Oracle Cloud Identifier): 特定のテナンシ、コンパートメントまたはデータベースを識別します。登録済データ・セットのスコープは、OCIDsで表すことができます。詳細は、「リソース識別子」を参照してください。

  • データ登録: データ登録では、ユーザーは、スコープによって課されるアクセス制限に従って、リモート・アクセスに対して表またはビューを使用可能にし、オプションで追加の認可ステップに従います。データベースに格納されている表またはビュー、またはオブジェクト・ストアに格納されているデータに対するクラウド・リンクによるリモート・アクセスを許可できます。

  • データ検出: 登録済データ・セットは、データベースからのテキスト問合せを使用して検出できます。データ・セットにアクセスする権限がある場合のみ、検出にデータ・セットが表示されます。登録済データ・セットは、名前または摘要で検索できます。

  • データ記述: ユーザーは、登録済データ・セットとして使用可能になった表またはビューの説明またはメタデータを取得できます。

  • オフロード・ターゲット: オプションで、1つ以上のオフロード・ターゲットを指定できます。オフロード・ターゲットは、クラウド・リンクのデータ・セットを指定されたAutonomous AI Databaseインスタンスに提供するリフレッシュ可能なクローンです。オフロード・ターゲットを指定することで、Autonomous AI Databaseインスタンス専用にデータ・セットを提供して、本番環境を開発から分離したり、パフォーマンスを確保したり、セキュリティを確保したり、その他の理由で本番環境を分離できます。詳細は、Autonomous AI Databaseでのリフレッシュ可能クローンの使用を参照してください。

クラウド・リンクを使用した登録済データ・セットへのアクセスは、監査目的でログに記録されます。ログには、データ・セットにアクセスしたテナンシ、コンパートメントまたはデータベース、アクセスされるデータの量および追加情報が含まれます。V$CLOUD_LINK_ACCESS_STATSビューおよびGV$CLOUD_LINK_ACCESS_STATSビューには、監査情報が表示されます。

データ・セット・メタデータおよび監査ビュー

各Autonomous AI Databaseインスタンスには、データ・セット・メタデータを公開し、データ使用状況をモニターおよび監査できるビューが用意されています。詳細は、クラウド・リンク情報のモニターおよび表示を参照してください。

データ・セットのスコープ、アクセス制御および認可

クラウド・リンクは、Oracle Cloud Infrastructureのアクセス・メカニズムを利用して、登録されたデータ・セットにアクセス可能にし、アクセス制限によりデータを保護します。

Autonomous AI Databaseは、登録済データ・セットのアクセシビリティを次のように決定します。

  • ADMINユーザーは、指定されたスコープに基づいてデータ・セットを登録できるユーザーのスコープを指定します。

  • データ・セットを登録する権限を付与されているユーザーは、データ・セットを登録するときにスコープを指定します。

  • オプションで、データ・セットを登録するときに、認可権限を付与されたユーザーは、データ・セットへのアクセスに必要な認可ステップを指定できます。この認可ステップは、スコープ・レベルのアクセス認可の他にあります。

データ・セット範囲

ADMINは、DBMS_CLOUD_LINK_ADMIN.GRANT_REGISTERを使用してユーザーのスコープを次のいずれかに設定します。

  • 'MY$REGION'

  • 'MY$TENANCY'

  • 'MY$COMPARTMENT'

  • 'MY$POOL'

ユーザーのスコープは階層型であり、これらのスコープのいずれかを付与されたユーザーは、次のようにアクセスを許可できます。

  • MY$REGION: データ・セットを登録しているAutonomous AI Databaseインスタンスのリージョン内で、他のテナンシへのリモート・データ・アクセス権を付与できます。これは、最も制限の少ないスコープです。

  • MY$TENANCY: データ・セットを登録しているAutonomous AI Databaseインスタンスのテナンシ内で、任意のリソース、テナンシ、コンパートメントまたはデータベースへのリモート・データ・アクセス権を付与できます。このスコープは、MY$REGIONスコープより制限されています。

  • MY$COMPARTMENT: データ・セットを登録しているAutonomous AI Databaseインスタンスのコンパートメント内で、任意のリソース、コンパートメントまたはデータベースへのリモート・データ・アクセス権を付与できます。これは、GRANT_REGISTERを持つユーザーに設定できる最も制限的なスコープです。

  • MY$POOL: ユーザーは、データ・セットを登録しているAutonomous AI Databaseインスタンス(親/子テナンシを含む)と同じElastic Pool内の任意のAutonomous AIデータベースへのリモート・データ・アクセス権を付与できます。このスコープは、MY$TENANCYおよびMY$REGIONスコープより限定的ですが、MY$COMPARTMENTよりも広いため、リモート接続の前にユーザーのデータベースに対して権限チェックが実行され、プール内のセキュアでデータ・コピーなしの共有が可能になります。

次に、データ・セットの登録時に設定するスコープによって、ユーザーがデータ・セットへのアクセスを許可される場所が決まります。DBMS_CLOUD_LINK.REGISTER scopeは、次のものを1つ以上含むコンマで区切られたリストです:

  • データベースOCID: データ・セットへのアクセスは、OC IDによって識別される特定のAutonomous AI Databaseインスタンスに対して許可されています。

  • コンパートメントOCID: データ・セットへのアクセスは、コンパートメントOCIDによって識別されるコンパートメント内のデータベースに対して許可されています。

  • テナンシOCID: データ・セットへのアクセスは、テナンシのOCIDによって識別されるテナンシのデータベースに対して許可されています。

  • リージョン名: データ・セットへのアクセスは、指定したリージョンで識別されるリージョン内のデータベースに対して許可されます。いずれの場合も、クラウド・リンクへのアクセスは1つのリージョン内に制限され、リージョン間には制限されません。

  • MY$COMPARTMENT: データ・セットへのアクセスは、データ・セット所有者と同じコンパートメント内のデータベースに対して許可されます。

  • MY$TENANCY: データ・セットへのアクセスは、データ・セット所有者と同じテナンシ内のデータベースに対して許可されます。

  • MY$REGION: データ・セットへのアクセスは、データ・セット所有者と同じリージョン内のデータベースに対して許可されます。

  • MY$POOL: データ・セットへのアクセスは、データ・セット所有者と同じエラスティック・プール内のデータベースに対して許可されます。

スコープ値MY$REGIONMY$TENANCYMY$COMPARTMENTおよびMY$POOLは、便利なマクロとして機能し、OCIDsに解決される変数です。

ノート

ノート:データ・セットの登録時に設定したスコープは、DBMS_CLOUD_LINK_ADMIN.GRANT_REGISTERで設定された値と一致するか、またはそれよりも制限が大きい場合にのみ適用されます。たとえば、ADMINがGRANT_REGISTERでスコープMY$TENANCYを付与し、ユーザーがDBMS_CLOUD_LINK.REGISTERでデータ・セットを登録するときにMY$REGIONを指定したとします。その場合は、次のようなエラーが表示されます:

ORA-20001: Share privileges are not enabled for current user or it is enabled but not for scope MY$REGION

SYS_CONTEXT値に基づく追加のアクセス制御メカニズムを使用することもできます。このメカニズムでは、SYS_CONTEXT値として使用可能な識別子を返すファンクションDBMS_CLOUD_LINK.GET_DATABASE_IDを使用します。

DBMS_CLOUD_LINK.REGISTERにデータ・セットを登録する場合、Oracle Virtual Private Database (VPD)セキュリティ・ポリシーのSYS_CONTEXT値を使用して、データベース・アクセスを制御し、個々のAutonomous AI Databaseインスタンスでアクセスできる特定のデータをさらに制限および制御できます。

VPDポリシーの使用の詳細は、「登録済データ・セットを保護するための仮想プライベート・データベース・ポリシーの定義」を参照してください。

データベースIDの値は、アクセス統計および監査情報を追跡するV$CLOUD_LINK_ACCESS_STATSビューおよびGV$CLOUD_LINK_ACCESS_STATSビューでも使用できます。

詳細は、「Oracle Virtual Private Databaseを使用したデータ・アクセスの制御」を参照してください。

データ・セット承認

データ・セットを登録するときに、認可権限が付与されている場合は、データ・セットへのアクセスにデータベースOCID認可が必要であることを指定できます。データ・セットのデータベースOCID認可を提供するには、DBMS_CLOUD_LINK.GRANT_AUTHORIZATIONプロシージャを使用して、データ・セットへのアクセスを認可されているAutonomous AI Databaseインスタンスを指定します。DBMS_CLOUD_LINK.GRANT_AUTHORIZATIONを実行する前に、ADMINがDBMS_CLOUD_LINK_ADMIN.GRANT_AUTHORIZEを使用してこのプロシージャを実行することを認可する必要があります。

認可が必要なデータ・セット登録では、次のように、データ・セットに指定されたスコープ・アクセス制御に加えて、データ・セットのデータベース・レベル・アクセスを指定します。

  • 指定されたSCOPE内にあり、DBMS_CLOUD_LINK.GRANT_AUTHORIZATIONで認可されているデータベースは、データ・セットから行を表示できます。

  • 指定されたSCOPE内にあるが、DBMS_CLOUD_LINK.GRANT_AUTHORIZATIONで認可されていないデータベースは、データ・セット行を表示できません。この場合、認可されていないコンシューマは、データ・セットを空とみなします。

  • 指定したSCOPE内にないデータベースは、データ・セットにアクセスしようとしたときにエラーが表示されます。

データベース・ユーザーのクラウド・リンク・アクセス権の付与

ADMINユーザーは、データ・セットを登録する権限をデータベース・ユーザーに付与します。また、ADMINユーザーは、登録済データ・セットにアクセスする権限をデータベース・ユーザーに付与します。

ADMINユーザーが登録権限を付与すると、ユーザーが(スコープ階層内で)データ・セットを登録する際に指定できる最大スコープを指定するスコープが提供されます。DBMS_CLOUD_LINK_ADMIN.GRANT_REGISTERで使用する有効なscope値は、次のとおりです。

  • 'MY$REGION'

  • 'MY$TENANCY'

  • 'MY$COMPARTMENT'

  • 'MY$POOL'

詳細は、Data Set Scope、 Access Control、 and Authorizationを参照してください。

  1. ADMINユーザーとして、指定したスコープ内のデータ・セットの登録をユーザーに許可します。

    BEGIN
    DBMS_CLOUD_LINK_ADMIN.GRANT_REGISTER(
      username => 'DB_USER1',
      scope    => 'MY$REGION');
    END;
    /

    これは、ユーザーDB_USER1が、指定されたスコープ'MY$REGION'内でデータ・セットを登録する権限を持っていることを指定します。

    ユーザーは、SYS_CONTEXT('USERENV', 'CLOUD_LINK_REGISTER_ENABLED')を問い合せて、データ・セットの登録が有効になっているかどうかを確認できます。

    たとえば、次の問合せをします。

    SELECT SYS_CONTEXT('USERENV', 'CLOUD_LINK_REGISTER_ENABLED') FROM DUAL;

    'YES'または'NO''を返します。

    詳細は、GRANT_REGISTERプロシージャを参照してください。

  2. ADMINユーザーとして、登録済データ・セットへのアクセスをユーザーに許可します。

    EXEC DBMS_CLOUD_LINK_ADMIN.GRANT_READ('LWARD');

    これにより、LWARDはAutonomous AI Databaseインスタンスで使用可能な登録済データ・セットにアクセスできます。

    ユーザーは、SYS_CONTEXT('USERENV', 'CLOUD_LINK_READ_ENABLED')を問い合せて、データ・セットへのREADアクセスが有効になっているかどうかを確認できます。

    たとえば、次の問合せをします。

    SELECT SYS_CONTEXT('USERENV', 'CLOUD_LINK_READ_ENABLED') FROM DUAL;

    'YES'または'NO''を返します。

    詳細は、GRANT_READプロシージャを参照してください。

  3. データ登録時に、認可必須パラメータをTRUEに設定できます。必要な認可がTRUEの場合、ADMINユーザーはDBMS_CLOUD_LINK_ADMIN.GRANT_AUTHORIZEを実行して、DBMS_CLOUD_LINK.GRANT_AUTHORIZATIONを起動する認可を提供する必要があります。DBMS_CLOUD_LINK.GRANT_AUTHORIZATIONを使用して、認可の詳細を指定します。

    詳細は、「認可が必要なデータ・セットの登録」を参照してください。

  4. Autonomous AI DatabaseインスタンスでDatabase Vaultが有効になっており、クラウド・リンクに登録する表またはビューがレルムによって保護されている場合、登録する前に、表またはビューの所有者がレルム所有者としてレルムに認可されている必要があります。

    BEGIN
    DBMS_MACADM.ADD_AUTH_TO_REALM(
      realm_name   => 'myrealm',
      grantee      => '*object_owner*',
      auth_option  => dbms_macutl.g_realm_auth_owner);
    END;
    /

    表またはビューを保護するレルムが必須レルムである場合、接続スキーマとして内部的に使用されるC##DATA$SHAREという名前のAutonomous AI Database共通スキーマは、レルム参加者としてレルムに認可される必要があります。

    たとえば:

    BEGIN
     DBMS_MACADM.ADD_AUTH_TO_REALM(
           realm_name   => 'myrealm',
           grantee      => 'C##DATA$SHARE',
           auth_option  => dbms_macutl.g_realm_auth_participant);
    END;
    /

    詳細は、「Autonomous AI DatabaseでのOracle AI Database Vaultの使用」を参照してください。

    データ・セットを登録するための権限をデータベース・ユーザーに付与するためのノート:

    • データ・セットを登録するか、リモート・データ・セットを参照してアクセスするには、DBMS_CLOUD_LINK_ADMIN.GRANT_REGISTERに登録するか、DBMS_CLOUD_LINK_ADMIN.GRANT_READでデータ・セットを読み取るための適切な権限が付与されている必要があります。

      これはADMINユーザーにも当てはまりますが、ADMINユーザーは自分に権限を付与できます。

    • ビューDBA_CLOUD_LINK_PRIVSおよびUSER_CLOUD_LINK_PRIVSは、ユーザー権限に関する情報を提供します。詳細は、クラウド・リンク情報のモニターおよび表示を参照してください。

    • ユーザーは、次の問合せを実行して、登録済の保護されたデータ・セットの認証が有効になっているかどうかを確認できます。

      SELECT SYS_CONTEXT('USERENV', 'CLOUD_LINK_AUTH_ENABLED') FROM DUAL;

データベース・ユーザーのクラウド・リンク・アクセスの取消し

ADMINユーザーは、登録を取り消して、リモート・アクセス用のデータ・セットの登録を禁止できます。ADMINユーザーは、登録済データ・セットにアクセスする権限またはデータベース・ユーザーを取り消すこともできます。

  1. ADMINユーザーとして、データ・セットを登録するユーザーの権限を取り消します。

    たとえば:

     EXEC DBMS_CLOUD_LINK_ADMIN.REVOKE_REGISTER('DB_USER1');

    これにより、ユーザーDB_USER1のデータ・セットを登録する権限が取り消されます。

    DBMS_CLOUD_LINK_ADMIN.REVOKE_REGISTERの実行は、すでに登録されているデータ・セットには影響しません。DBMS_CLOUD_LINK.UNREGISTERを使用して、登録済データ・セットのアクセス権を削除します。

    詳細は、REVOKE_REGISTERプロシージャおよびUNREGISTERプロシージャを参照してください。

  2. ADMINユーザーとして、登録済のデータ・セットへのアクセスを取り消します。

    たとえば:

    EXEC DBMS_CLOUD_LINK_ADMIN.REVOKE_READ('LWARD');

    これにより、ユーザーLWARDのクラウド・リンク・データ・セットへのアクセス権が取り消されます。

    詳細は、REVOKE_READプロシージャを参照してください。

データ・セットの登録

クラウド・リンクと共有する登録済データ・セットとして所有する表またはビューを登録するためのオプションおよびステップについて説明します。

データ・セットの登録または登録解除

所有する表またはビューを登録済データ・セットとして登録できます。データ・セットを削除または置換する場合は、登録を解除する必要があります。データ・セットを登録した後、データ・セットの属性の値を変更できます。

データ・セット登録では、クラウド・リンクで使用するネームスペースおよび名前を定義します。データ・セット登録後、これらの値は一緒にリモート・アクセス用の完全修飾名(FQN)を指定し、クラウド・リンクがデータ・セットのアクセシビリティを管理できるようにします。

データ・セットを登録するには:

  1. ADMINユーザーから権限付与登録を取得します。

    詳細は、データベース・ユーザーに対するクラウド・リンク・アクセス権の付与を参照してください。

  2. 1つ以上のデータ・セットを登録します。

    たとえば、Autonomous AI DatabaseインスタンスにスキーマCLOUDLINKが存在する場合、SALES_VIEW_AGGSALES_ALLの2つのオブジェクトを登録し、異なるscopeパラメータを指定して、オブジェクトへのアクセス方法を決定できます。

    BEGIN
      DBMS_CLOUD_LINK.REGISTER(
        schema_name    => 'CLOUDLINK',
        schema_object  => 'SALES_VIEW_AGG',
        namespace      => 'REGIONAL_SALES',
        name           => 'SALES_AGG',
        description    => 'Aggregated regional sales information.',
        scope          => 'MY$TENANCY',
        auth_required  =>  FALSE,
        data_set_owner =>  'amit@example.com' );
    END;
    /
    BEGIN
       DBMS_CLOUD_LINK.REGISTER(
        schema_name    => 'CLOUDLINK',
        schema_object  => 'SALES_ALL',
        namespace      => 'TRUSTED_COMPARTMENT',
        name           => 'SALES',
        description    => 'Trusted Compartment, only accessible within my compartment. Early sales data.',
        scope          => 'MY$COMPARTMENT',
        auth_required  =>  FALSE,
        data_set_owner =>  'amit@example.com' );
    END;
    /

    パラメータは次のとおりです。

    • schema_name: スキーマ名(オブジェクト所有者)です。

    • schema_object: オブジェクトの名前です。有効なオブジェクトは次のとおりです。

    • namespace: クラウド・リンク(クラウド・リンクFQNの一部)を使用してアクセスするための名前として指定するネームスペースです。

      NULL値は、Autonomous AI Databaseインスタンスに固有の、システム生成のnamespace値を指定します。

    • name: クラウド・リンク(クラウド・リンクFQNの一部)を使用してアクセスするために指定する名前です。

    • description: データを記述するテキストを指定します。

    • scope: スコープを指定します。MY$REGIONMY$TENANCYMY$COMPARTMENTまたはMY$POOLのいずれかの変数を使用するか、1つ以上のOCIDsを指定できます。

      詳細は、Data Set Scope、 Access Control、 and Authorizationを参照してください。

    • auth_required: スコープ・アクセス制御に加えて、データ・セットにデータベース・レベルの認可が必要かどうかを指定するブール値。これをTRUEに設定すると、データ・セットによって追加の認可ステップが強制されます。詳細は、「認可が必要なデータ・セットの登録」を参照してください。

    • data_set_owner: テキスト値は、データ・セットを担当する個人またはデータ・セットに関する質問の連絡先に関する情報を指定します。たとえば、データ・セット所有者のEメール・アドレスを指定できます。

    詳細は、REGISTERプロシージャを参照してください。

    この例では、登録の完了後、DBMS_CLOUD_LINK.REGISTERで指定したscopeパラメータに基づいて、2つの登録済オブジェクトのスコープが異なります。

    • MY$TENANCY: REGIONAL_SALES.SALES_AGGのテナンシ・レベルのスコープを指定します。

    • MY$COMPARTMENT: TRUSTED_COMPARTMENT.SALESのテナンシ内のより限定的なコンパートメント・レベルのスコープを指定します。

データ・セットを登録した後に、データ・セットの属性の値の一部を更新できます。詳細は、データ・セット登録属性の更新を参照してください。

登録済データ・セットへのリモート・アクセスを取り消す場合は、データ・セットの登録を解除します。

たとえば:

BEGIN
   DBMS_CLOUD_LINK.UNREGISTER(
    namespace      => 'TRUSTED_COMPARTMENT',
    name           => 'SALES');
END;
/

詳細は、UNREGISTERプロシージャを参照してください。

データ・セットの登録または登録解除に関するノート

DBMS_CLOUD_LINK.REGISTERへのデータ・セットの登録およびDBMS_CLOUD_LINK.UNREGISTERへのデータ・セットの登録解除に関するノートを提供します。

  • オブジェクトを登録した後、ユーザーはクラウド・リンクを使用してオブジェクトにアクセスするために最大10分待機する必要がある場合があります。

  • データ・セットを登録し、リモート・リージョンのコンシューマがデータ・セットにアクセスできるようにする場合は、追加ステップを実行して、リモート・リージョンでデータ・セットを使用可能にする必要があります。詳細は、「別のリージョンでのデータ・セットの登録または登録解除」を参照してください。

  • プロシージャDBMS_CLOUD_LINK.UPDATE_REGISTRATIONを使用して、既存のデータ・セットの属性を変更します。

    更新が完了するまでの待機時間は、登録変更が伝播され、クラウド・リンクを介してアクセス可能になるまで最大10分です。この遅延は、DBA_CLOUD_LINK_REGISTRATIONSビューとDBA_CLOUD_LINK_ACCESSビューの両方のデータの精度に影響する可能性があります。

  • 表またはビューに対するREAD WITH GRANT OPTION権限がある場合は、別のユーザーのスキーマに存在する表またはビューを登録できます。

  • 自律型AIデータベースでは、登録時に階層的な妥当性チェックが実行されず、スコープ外の登録は表示またはアクセスできなくなります。

    たとえば、次のシーケンスを考えてみます。

    1. スコープMY$COMPARTMENTを持つユーザーは、個々のデータベースOCIDを指定するスコープでオブジェクトを登録します。

    2. ユーザーが登録済データ・セットへのアクセスをリクエストすると、Autonomous AI Databaseによってチェックが実行され、リクエストが発生したデータベースのデータベースOCIDが、データ・セットの登録時にscopeで指定されたOCIDリストにあることが確認されます。

    3. その後、namespace.nameオブジェクトは、リクエストが発生したデータベースで検出可能、表示可能および使用可能になります。

  • DBMS_CLOUD_LINK.UNREGISTERは、完全に伝播するのに最大10分かかる場合があり、その後、データにリモートでアクセスできるようになります。

別のリージョンでのデータ・セットの登録または登録解除

ソース・リージョンにデータ・セットのソース・データベースが含まれ、1つ以上のリモート・リージョンにソース・データベースのリフレッシュ可能なクローンが含まれている複数のリージョンでクラウド・リンクを使用できます。

cloud-links-cross-region-refreshable-clone.pngの説明が続きます

図cloud-links-cross-region-refreshable-clone.pngの説明

異なるリージョンのデータ・セットでクラウド・リンクを使用するには:

  1. リモート・リージョンにソース・データベースのクロス・リージョン・リフレッシュ可能クローンを作成します。

    クロス・リージョン・リフレッシュ可能クローンの追加の詳細は、クロス・テナンシまたはクロス・リージョン・リフレッシュ可能クローンの作成を参照してください。

  2. ソース・データベースで、データ・セットを登録します。

    詳細は、「データ・セットの登録または登録解除」を参照してください。

  3. リフレッシュ可能なクローンをリフレッシュします

    詳細は、Autonomous AI Databaseでのリフレッシュ可能クローンのリフレッシュを参照してください。

  4. リモートの「リフレッシュ可能クローン」で、データ・セットをソース・リージョンに登録するために使用したのと同じ引数を使用して、データ・セットを登録します。

    たとえば、Autonomous AI DatabaseインスタンスにスキーマCLOUDLINKが存在する場合、ソース・データベースにSALES_ALLを登録した後、リフレッシュ可能クローンにSALES_ALLを登録します:

    BEGIN
      DBMS_CLOUD_LINK.REGISTER(
      schema_name    => 'CLOUDLINK',
      schema_object  => 'SALES_ALL',
      namespace      => 'TRUSTED_COMPARTMENT',
      name           => 'SALES',
      description    => 'Trusted Compartment, only accessible within my compartment. Early sales data.',
      scope          => 'MY$COMPARTMENT',
      auth_required  =>  FALSE,
      data_set_owner =>  'amit@example.com' );
    END;
    /

    パラメータは次のとおりです。

    • schema_name: スキーマ名(オブジェクト所有者)です。

    • schema_object: オブジェクトの名前です。有効なオブジェクトは次のとおりです。

      • 表(ヒープ、外部またはハイブリッドを含む)

      • ビュー

      • マテリアライズド・ビュー

        ノート

        ノート: アナリティック・ビューやシノニムなどの他のオブジェクトはサポートされません。

  • namespace: クラウド・リンク(クラウド・リンクFQNの一部)を使用してアクセスするための名前として指定するネームスペースです。

    NULL値は、Autonomous AI Databaseインスタンスに固有の、システム生成のnamespace値を指定します。

    • name: クラウド・リンク(クラウド・リンクFQNの一部)を使用してアクセスするために指定する名前です。

    • description: データを記述するテキストを指定します。

    • scope: スコープを指定します。MY$REGIONMY$TENANCYMY$COMPARTMENTまたはMY$POOLのいずれかの変数を使用するか、1つ以上のOCIDsを指定できます。

      詳細は、Data Set Scope、 Access Control、 and Authorizationを参照してください。

    • auth_required: スコープ・アクセス制御に加えて、データ・セットにデータベース・レベルの認可が必要かどうかを指定するブール値。これをTRUEに設定すると、データ・セットによって追加の認可ステップが強制されます。詳細は、「認可が必要なデータ・セットの登録」を参照してください。

    • data_set_owner: テキスト値は、データ・セットを担当する個人またはデータ・セットに関する質問の連絡先に関する情報を指定します。たとえば、データ・セット所有者のEメール・アドレスを指定できます。

    詳細は、REGISTERプロシージャを参照してください。

    リフレッシュ可能クローンで登録が完了した後、登録済オブジェクトのスコープはMY$COMPARTMENTです: TRUSTED_COMPARTMENT.SALESのテナンシ内の自分のコンパートメントに対して、より制限的なコンパートメント・レベル・スコープを指定します。

リモート・データ・セットの登録は、リモート・リージョン内、またはリモート・リージョンとソース・リージョンの両方でのみ解除できます。

リモート・リージョンでデータ・セットの登録を解除し、データ・セットへのリモート・アクセスを無効にするには:

  1. リフレッシュ可能クローンで、データ・セットの登録を解除します。

    たとえば:

    BEGIN
       DBMS_CLOUD_LINK.UNREGISTER(
        namespace      => 'TRUSTED_COMPARTMENT',
        name           => 'SALES');
    END;
    /
  2. リフレッシュ可能なクローンをリフレッシュします

    詳細は、Autonomous AI Databaseでのリフレッシュ可能クローンのリフレッシュを参照してください。

ソース・データベースでデータ・セットを登録解除し、リモート・リージョン・リフレッシュ可能クローンでデータ・セットを登録解除するには:

  1. リモート・リフレッシュ可能クローンで1つのみの場合、またはリモート・リージョンに複数のリフレッシュ可能クローンがある場合は、そのデータ・セットの登録を解除します。

    たとえば:

    BEGIN
       DBMS_CLOUD_LINK.UNREGISTER(
        namespace      => 'TRUSTED_COMPARTMENT',
        name           => 'SALES');
    END;
    /
  2. ソース・データベースで、データ・セットの登録を解除します。

    詳細は、「データ・セットの登録または登録解除」を参照してください。

  3. リフレッシュ可能クローンをリフレッシュします。

    詳細は、Autonomous AI Databaseでのリフレッシュ可能クローンのリフレッシュを参照してください。

リモート・リージョンへのデータ・セットの登録または登録解除に関するノート

リモート・リージョンにデータ・セットを登録するためのノートを提供します。

  • リモート・リージョン内のリフレッシュ可能クローンにデータ・セットを登録する場合、リモート・リージョン・クローンでのDBMS_CLOUD_LINK.REGISTERの起動では、offload_targetsパラメータを除き、ソース・データベースと同じ値を持つ同じパラメータを使用する必要があります。

    たとえば、ソースAutonomous AI DatabaseインスタンスでスコープをMY$COMPARTMENTに設定してDBMS_CLOUD_LINK.REGISTERを実行する場合、同じスコープ・パラメータ値(MY$COMPARTMENT)を使用してクロス・リージョン・リフレッシュ可能クローンでプロシージャを再度実行します。

  • ソースのDBMS_CLOUD_LINK.REGISTERoffload_targetsパラメータを指定する場合は、リフレッシュ可能クローンにデータ・セットを登録するときにこのパラメータを省略する必要があります。

  • オブジェクトを登録した後、ユーザーはクラウド・リンクを使用してオブジェクトにアクセスするために最大10分待機する必要がある場合があります。

  • 次のアクションでは、リフレッシュ可能クローンをリフレッシュする必要があります。

    • ソースのデータ・セットにVPDポリシーを追加する場合は、リフレッシュ可能クローンをリフレッシュする必要があります。

    • ソース・データベースでデータ・セットに対して付与または取消しを実行する場合は、リフレッシュ可能クローンをリフレッシュする必要があります。

    詳細は、Autonomous AI Databaseでのリフレッシュ可能クローンのリフレッシュを参照してください。

認可が必要なデータ・セットの登録

オプションで、データ・セットを登録するときに、スコープに加えて、データ・セットへのアクセスにデータベース・レベルの認可が必要であることを指定できます。

auth_requiredFALSEに設定した前の例と比較して、この例ではauth_requiredTRUEに設定します。auth_requiredTRUEの場合、データ・セットへのアクセスが認可される1つ以上のデータベースを指定するには、追加のステップが必要です。

ノート

ノート:権限が付与できるのは、次のステップに示すように、認可のみです。ADMINは、DBMS_CLOUD_LINK_ADMIN.GRANT_AUTHORIZEを使用して認可権限を付与します。

  1. DBMS_CLOUD_LINK.REGISTERを使用して、必要な認可でデータを登録します。

    Autonomous AI DatabaseインスタンスにスキーマCLOUDLINKがあり、オブジェクトSALES_VIEW_AGGを登録してauth_requiredTRUEに設定した場合、スコープの定義に加えて、オブジェクトへのアクセス方法を決定するための追加のステップを事前に実行する必要があります。

    BEGIN
       DBMS_CLOUD_LINK.REGISTER(
        schema_name    => 'CLOUDLINK',
        schema_object  => 'SALES_VIEW_AGG',
        namespace      => 'REGIONAL_SALES',
        name           => 'SALES_AGG',
        description    => 'Aggregated regional sales information.',
        scope          => 'MY$TENANCY',
        auth_required  =>  TRUE,
        data_set_owner =>  'amit@example.com' );
    END;
    /

    パラメータは次のとおりです。

    • schema_name: スキーマ名(オブジェクト所有者)です。

    • schema_object: オブジェクトの名前です。有効なオブジェクトは次のとおりです。

      • 表(ヒープ、外部またはハイブリッドを含む)

      • ビュー

      • マテリアライズド・ビュー

        ノート

        ノート:アナリティック・ビューやシノニムなどの他のオブジェクトはサポートされていません。

    • namespace: クラウド・リンク(クラウド・リンクFQNの一部)を使用してアクセスするための名前として指定するネームスペースです。

      NULL値は、Autonomous AI Databaseインスタンスに固有の、システム生成のnamespace値を指定します。

    • name: クラウド・リンク(クラウド・リンクFQNの一部)を使用してアクセスするために指定する名前です。

    • scope: スコープを指定します。MY$REGIONMY$TENANCYMY$COMPARTMENTまたはMY$POOLのいずれかの変数を使用するか、1つ以上のOCIDsを指定できます。

      詳細は、Data Set Scope、 Access Control、 and Authorizationを参照してください。

    • auth_required: スコープ・アクセス制御に加えて、データ・セットにデータベース・レベルの認可が必要かどうかを指定するブール値。これをTRUEに設定すると、データ・セットによって追加の認可ステップが強制されます。

    • data_set_owner: テキスト値は、データ・セットを担当する個人またはデータ・セットに関する質問の連絡先に関する情報を指定します。たとえば、データ・セット所有者のEメール・アドレスを指定できます。

  2. 認可を付与するデータベースのデータベースIDを取得します(データベースのデータ・セットへのアクセスを許可するため)。

    システムで、データ セットへのアクセスを許可します。

    SELECT DBMS_CLOUD_LINK.GET_DATABASE_ID FROM DUAL:
  3. 取得したデータベースIDを使用して、指定したデータ・セットに認可を付与します。

    認可を付与し、このステップに示すようにDBMS_CLOUD_LINK.GRANT_AUTHORIZATIONを実行できるのは、認可されている場合のみです。ADMINは、DBMS_CLOUD_LINK_ADMIN.GRANT_AUTHORIZEを使用して認可を付与します。

    BEGIN
       DBMS_CLOUD_LINK.GRANT_AUTHORIZATION(
        database_id    => '120xxxxxxx8506029999',
        namespace      => 'TRUSTED_COMPARTMENT',
        name           => 'SALES');
    END;
    /

    追加のデータベースを認可する場合は、これらのステップを複数回実行します。

データ・セットを登録した後で、auth_requiredパラメータの値を更新できます。詳細は、データ・セット登録属性の更新を参照してください。

データベースの認可を取り消す場合:

BEGIN
   DBMS_CLOUD_LINK.REVOKE_AUTHORIZATION(
    database_id    => '120xxxxxxx8506029999',
    namespace      => 'TRUSTED_COMPARTMENT',
    name           => 'SALES');
END;
/

詳細は、次を参照してください:

データ・セット・アクセスのオフロード・ターゲットへのデータ・セットの登録

オプションで、データ・セットを登録するときに、データ・セットへのアクセスを、リフレッシュ可能なクローンである1つ以上のAutonomous AI Databaseインスタンスにオフロードできます。

オプションのoffload_targetsパラメータをDBMS_CLOUD_LINK.REGISTERとともに使用して、アクセスがリフレッシュ可能クローンにオフロードされるように指定します。各リフレッシュ可能クローンのソース・データベースは、データ・セット(データ・パブリッシャ)を登録するAutonomous AI Databaseインスタンスです。

offload_targets値は、1つ以上のCLOUD_LINK_DATABASE_IDキーとOFFLOAD_TARGETキー値のペアを定義するJSONドキュメントです。

  • CLOUD_LINK_DATABASE_IDは次のいずれかです。

    • データベースID: OFFLOAD_TARGET値で指定された対応するリフレッシュ可能クローンにリクエストがオフロードされるデータ・セット・コンシューマのデータベースIDを指定します。

      DBMS_CLOUD_LINK.GET_DATABASE_IDを実行して、データベースIDを取得します。詳細は、GET_DATABASE_IDファンクションを参照してください。

    • ANY: データ・セット・コンシューマのリクエストが、対応するオフロード・ターゲットにオフロードされることを指定します。コンシューマのデータ・セット・リクエストは、対応するオフロード・ターゲットにルーティングされます。

      データベースIDを指定せずにANYを指定すると、コンシューマからのすべてのデータ・セット・リクエストは、OFFLOAD_TARGET値で指定されたリフレッシュ可能クローンにオフロードされます。

      データベースIDとANYの両方を指定すると、データベースIDと一致しないコンシューマからのデータ・セット・リクエストは、OFFLOAD_TARGET値で指定されたリフレッシュ可能クローンにオフロードされます。

  • OFFLOAD_TARGETは、リフレッシュ可能なクローンであるAutonomous AI DatabaseインスタンスのOCIDです。

次の図は、オフロード・ターゲットの使用方法を示しています。

イメージの説明が続きます

図cloud-links-offload-targets-any-keyword.pngの説明

データ・セット・コンシューマが、offload_targetsに登録したデータ・セットへのアクセスをリクエストし、Autonomous AI DatabaseインスタンスのデータベースIDがCLOUD_LINK_DATABASE_IDで指定された値と一致した場合、アクセスは、指定されたJSONでOFFLOAD_TARGETで識別されたリフレッシュ可能クローンにオフロードされます。

たとえば、次の例では、3つのOFFLOAD_TARGET/CLOUD_LINK_DATABASE_ID値のペアを持つJSONサンプルを示します。

{
  "OFFLOAD_TARGETS": [
    {
      "CLOUD_LINK_DATABASE_ID": "34xxxxx69708978",
      "OFFLOAD_TARGET":
"ocid1.autonomousdatabase.oc1..xxxxx3pv6wkcr4jqae5f44n2b2m2yt2j6rx32uzr4h25vqstifsfabc"
    },
    {
      "CLOUD_LINK_DATABASE_ID": "34xxxxx89898978",
      "OFFLOAD_TARGET":
"ocid1.autonomousdatabase.oc1..xxxxx3pv6wkcr4jqae5f44n2b2m2yt2j6rx32uzr4h25vqstifsfdef"
    },
    {
      "CLOUD_LINK_DATABASE_ID": "34xxxxx4755680",
      "OFFLOAD_TARGET":
"ocid1.autonomousdatabase.oc1..xxxxx3pv6wkcr4jqae5f44n2b2m2yt2j6rx32uzr4h25vqstifsfghi"
    }
  ]
}

データ・セット・コンシューマが、ANYキーワードを含むoffload_targetsに登録したデータ・セットへのアクセスをリクエストすると、指定されたJSONでOFFLOAD_TARGETで識別されたリフレッシュ可能クローンにアクセスがオフロードされます(指定されたJSON内に一致するデータベースIDエントリを持つコンシューマからのリクエストを除く)。

たとえば、1つの明示的なOFFLOAD_TARGET/CLOUD_LINK_DATABASE_ID値ペアと、対応するOFFLOAD_TARGETを持つ1つのANY値を持つJSONサンプルを次に示します。

{
  "OFFLOAD_TARGETS": [
    {
      "CLOUD_LINK_DATABASE_ID": "ANY",
      "OFFLOAD_TARGET":
"ocid1.autonomousdatabase.oc1..xxxxx3pv6wkcr4jqae5f44n2b2m2yt2j6rx32uzr4h25vqstifsfdef"
    },
    {
      "CLOUD_LINK_DATABASE_ID": "34xxxxx4755680",
      "OFFLOAD_TARGET":
"ocid1.autonomousdatabase.oc1..xxxxx3pv6wkcr4jqae5f44n2b2m2yt2j6rx32uzr4h25vqstifsfghi"
    }
  ]
}

データ・セットを登録し、オフロード・ターゲットを指定するには、次の手順を実行します。

  1. データ・セット・アクセスをオフロードする1つ以上のリフレッシュ可能クローンのOCIDを取得します。リフレッシュ可能クローンOCIDsは、リフレッシュ可能クローンのOracle Cloud Infrastructure Consoleで使用できます。

    ノート

    ノート:リフレッシュ可能クローンをオフロード・ターゲットとして表示するためにリフレッシュ可能クローンを作成した後、最大10分かかる場合があります。つまり、リフレッシュ可能クローンを作成した後、クラウド・リンク・オフロード登録でリフレッシュ可能クローンを使用できるようになるまで最大10分待機する必要がある場合があります。

  2. リフレッシュ可能クローンによって提供されるデータを使用して、データ・セットにアクセスする1つ以上のAutonomous AI DatabaseインスタンスのデータベースIDを取得します。

    リフレッシュ可能クローンからデータ・セットにアクセスするシステムで、次のコマンドを実行します:

    SELECT DBMS_CLOUD_LINK.GET_DATABASE_ID FROM DUAL:
  3. データ・セットを登録し、offload_targetsパラメータを指定します。

    たとえば、Autonomous AI DatabaseインスタンスにスキーマCLOUDLINKが存在する場合、SALES_VIEW_AGGを登録し、データ・セットへのアクセスを提供するリフレッシュ可能クローンを指定できます:

    BEGIN
       DBMS_CLOUD_LINK.REGISTER(
        schema_name     => 'CLOUDLINK',
        schema_object   => 'SALES_VIEW_AGG',
        namespace       => 'REGIONAL_SALES',
        name            => 'SALES_AGG',
        description     => 'Aggregated regional sales information.',
        scope           => 'MY$TENANCY',
        auth_required   =>  FALSE,
        data_set_owner  =>  'amit@example.com',
        offload_targets => '{
      "OFFLOAD_TARGETS": [
        {
          "CLOUD_LINK_DATABASE_ID": "34xxxx754755680",
          "OFFLOAD_TARGET":
    "ocid1.autonomousdatabase.oc1..xxxxxaaba3pv6wkcr4jqae5f44n2b2m2yt2j6rx32uzr4h25vqstifsfghi"
        }
      ]
    }');
    END;
    /

    パラメータは次のとおりです。

    • schema_name: スキーマ名(オブジェクト所有者)です。

    • schema_object: オブジェクトの名前です。有効なオブジェクトは次のとおりです。

      • 表(ヒープ、外部またはハイブリッドを含む)

      • ビュー

      • マテリアライズド・ビュー

        ノート

        ノート:アナリティック・ビューやシノニムなどの他のオブジェクトはサポートされていません。

    • namespace: クラウド・リンク(クラウド・リンクFQNの一部)を使用してアクセスするための名前として指定するネームスペースです。

      NULL値は、Autonomous AI Databaseインスタンスに固有の、システム生成のnamespace値を指定します。

    • name: クラウド・リンク(クラウド・リンクFQNの一部)を使用してアクセスするために指定する名前です。

    • scope: スコープを指定します。MY$REGIONMY$TENANCYMY$COMPARTMENTまたはMY$POOLのいずれかの変数を使用するか、1つ以上のOCIDsを指定できます。

      詳細は、Data Set Scope、 Access Control、 and Authorizationを参照してください。

    • auth_required: スコープ・アクセス制御に加えて、データ・セットにデータベース・レベルの認可が必要かどうかを指定するブール値。これをTRUEに設定すると、データ・セットによって追加の認可ステップが強制されます。詳細は、「認可が必要なデータ・セットの登録」を参照してください。

    • data_set_owner: テキスト値は、データ・セットを担当する個人またはデータ・セットに関する質問の連絡先に関する情報を指定します。たとえば、データ・セット所有者のEメール・アドレスを指定できます。

    • offload_targets: データ・セットが登録されているAutonomous AI Databaseから、データ・セットへのアクセスがオフロードされるリフレッシュ可能クローンの1つ以上のAutonomous AI Database OCIDsを指定します。

      データ・セット・コンシューマごとに、次のいずれかが一致して、リクエストをリフレッシュ可能クローンにオフロードできます。

      • 指定されたcloud_link_database_idの値、つまりコンシューマのデータベースIDと一致する値が一致する場合、アクセスはoffload_targetで指定されたOCIDによって識別されるリフレッシュ可能クローンにオフロードされます。

      • ANYキーワードが指定されている場合、指定されたcloud_link_database_idの値と一致しない場合、アクセスは、対応するoffload_targetで指定されたOCIDによってANYエントリで識別されるリフレッシュ可能クローンにオフロードされます。

    ノート

    ノート:データ・パブリッシャがエラスティック・プール・リーダーまたはエラスティック・プール・メンバーのいずれかである場合、offload_targetsを使用してオフロード・ターゲットの詳細を構成するかわりに、統合問合せオフロード機能を使用できます。この場合、パブリッシャは、ターゲットを構成しなくても、プロキシSQL問合せのオフロードによって、問合せ(読取り)を任意の数のリフレッシュ可能クローンにオフロードできます。詳細は、クラウド・リンクでの統合問合せオフロードの使用を参照してください。

    詳細は、次を参照してください:

データ・セット登録属性の更新

データ・セットを登録した後、一部のデータ・セット属性を更新できます。スキーマ名、スキーマ・オブジェクト、ネームスペースまたは名前の属性は更新できません。

データ・セット属性を更新するには:

  1. データ・セットを登録したユーザーは、その属性をDBMS_CLOUD_LINK.UPDATE_REGISTRATIONで更新できます。

    データ・セット属性を更新する権限がない場合は、ADMINユーザーから権限付与登録権限を取得する必要があります。

    詳細は、データベース・ユーザーに対するクラウド・リンク・アクセス権の付与を参照してください。

  2. データ・セットの1つ以上の属性を更新します。

    たとえば、DBMS_CLOUD_LINK.UPDATE_REGISTRATIONを使用して、ネームスペースREGIONAL_SALES内のデータ・セットのdescriptionscopeおよびauth_required属性をSALES_AGGという名前で更新します。

    BEGIN
       DBMS_CLOUD_LINK.UPDATE_REGISTRATION(
        namespace      => 'REGIONAL_SALES',
        name           => 'SALES_AGG',
        description    => 'Updated description for aggregated regional sales information.',
        scope          => 'MY$COMPARTMENT',
        auth_required  =>  TRUE );
    END;
    /

    必須パラメータは次のとおりです。

    • namespace: データ・セットを登録したときに指定したデータ・セットの名前空間です。

    • name: データ・セットを登録したときに指定したデータ・セットの名前です。

    次に、オプションのパラメータのリストを示します。オプションのパラメータ値にNULLが渡された場合、属性は変更されません。

    • description: データを記述するために更新されたテキストを指定します。

    • scope: スコープを指定します。MY$REGIONMY$TENANCYMY$COMPARTMENTまたはMY$POOLのいずれかの変数を使用するか、1つ以上のOCIDsを指定できます。

      詳細は、Data Set Scope、 Access Control、 and Authorizationを参照してください。

    • auth_required: スコープ・アクセス制御に加えて、データ・セットにデータベース・レベルの認可が必要かどうかを指定するブール値。これをTRUEに設定すると、データ・セットによって追加の認可ステップが強制されます。詳細は、「認可が必要なデータ・セットの登録」を参照してください。

    • data_set_owner: テキスト値は、データ・セットを担当する個人またはデータ・セットに関する質問の連絡先に関する情報を指定します。たとえば、データ・セット所有者のEメール・アドレスを指定できます。

    • offload_targets: データ・セットが登録されているAutonomous AI Databaseから、データ・セットへのアクセスがオフロードされるリフレッシュ可能クローンの1つ以上のAutonomous AI Database OCIDsを指定します。詳細は、データ・セット・アクセス用のオフロード・ターゲットへのデータ・セットの登録を参照してください。

    schema_nameまたはschema_object属性は更新できません。

    詳細は、UPDATE_REGISTRATIONプロシージャを参照してください。

データ・セットが1つ以上のクロス・リージョン・リフレッシュ可能クローンに登録されている場合は、ソース・データベースでの登録に対する変更をリモート・リージョンに伝播する必要があります。

クロス・リージョン・リフレッシュ可能クローンに変更を伝播するには、次の点に注意してください:

  • リージョンAなどで、プロデューサにN個のクロス・リージョン・リフレッシュ可能クローンがある場合は、リージョンAの1つのリフレッシュ可能クローンでDBMS_CLOUD_LINK.UPDATE_REGISTRATIONを実行します。

  • 同じプロデューサに異なるリモート・リージョン(リージョンBなど)のMクロス・リージョン・リフレッシュ可能クローンがある場合は、リージョンBの1つのリフレッシュ可能クローンでDBMS_CLOUD_LINK.UPDATE_REGISTRATIONを実行します。

1つ以上のクロス・リージョン・リフレッシュ可能クローンにデータ・セットが登録されたときに属性を更新するには:

  1. ソース・データベースで、データ・セット登録を更新します。

  2. リモート・リージョンのリモート・リフレッシュ可能クローン(リモート・リージョンが1つのみ存在する場合)または各リモート・リージョンのリモート・リフレッシュ可能クローン(複数のリージョンにレプリケートされたリフレッシュ可能クローンが存在する場合)で、offload_targetsパラメータを除き、ソース・データベースの更新に使用した値と同じ値でデータ・セット登録を更新します。

    いずれのリモート・リージョンでも、そのリージョン内の1つのリフレッシュ可能クローンに対してDBMS_CLOUD_LINK.UPDATE_REGISTRATIONのみを実行する必要があります(リージョンに同じデータ・セットに関連付けられたリフレッシュ可能クローンが複数ある場合、個々のリモート・リージョン内のすべてのリフレッシュ可能クローンに変更を伝播するには、プロシージャを1回のみ実行する必要があります)。

  3. リフレッシュ可能クローンをリフレッシュします。

    詳細は、Autonomous AI Databaseでのリフレッシュ可能クローンのリフレッシュを参照してください。

データ・セットの検索およびクラウド・リンクの使用

クラウド・リンクの読取りアクセス権を付与されたユーザーは、Autonomous AI Databaseインスタンスで使用可能なデータ・セットを検索し、登録済のデータ・セットにアクセスして問合せで使用できます。

ADMINユーザーがGRANT_READを実行した後、ユーザーはクラウド・リンクを検索して使用できます。

  1. 自律型AIデータベース・インスタンスで使用可能なデータセットを見つけます。

    たとえば、文字列「TREE」を含むすべてのデータ・セットを検索します。

    DECLARE
       result CLOB DEFAULT NULL;
    BEGIN
       DBMS_CLOUD_LINK.FIND('TREE', result);
        DBMS_OUTPUT.PUT_LINE(result);
    END;
    /
    
    [{"name":"TREE_DATA","namespace":"FOREST","description":"Urban tree data including county, species and height"}]

    パラメータは次のとおりです。

    • search_string: 検索する文字列。検索文字列は大文字と小文字が区別されません。

    • search_result: データ・セットのネームスペース、名前および説明の値を含むJSONドキュメント。

    詳細は、FINDプロシージャを参照してください。

    DBMS_CLOUD_LINK.FINDプロシージャは、クラウド・リンクで使用できるFQNを提供します。この場合、FOREST.TREE_DATAです。

  2. ビューDBA_CLOUD_LINK_ACCESSを使用して、使用可能なデータ・セットをリストします。

    SELECT * FROM DBA_CLOUD_LINK_ACCESS;
    NAMESPACE            NAME
    
    ---------            --------------
    FOREST               TREE_DATA
    REGIONAL_SALES       SALES_AGG
    TRUSTED_COMPARTMENT  SALES
  3. 登録済データ・セットの詳細を確認するには、プロシージャDBMS_CLOUD_LINK.DESCRIBEを使用します。

    SELECT DBMS_CLOUD_LINK.DESCRIBE('FOREST','TREE_DATA') FROM DUAL;
    DBMS_CLOUD_LINK.DESCRIBE('FOREST','TREE_DATA')
    
    ---------------------------------------------------
    Urban tree data including county, species and height
  4. 問合せで登録済のデータ・セットを使用します。

    SELECT * FROM FOREST.TREE_DATA@cloud$link;

ノート

ノート:データ・セットを表示してアクセスできるようにするには、データ・セットをDBMS_CLOUD_LINK.REGISTERに登録してから最大10分かかる場合があります。

クラウド・リンクでは、プライベート・シノニムとパブリック・シノニムがサポートされています。たとえば、FOREST.TREE_DATA@cloud$linkのシノニムを定義して使用できます。

CREATE SYNONYM S1 for FOREST.TREE_DATA@cloud$link;
CREATE PUBLIC SYNONYM S2 for FOREST.TREE_DATA@cloud$link;

SELECT * FROM S1;

SELECT * FROM S2;

詳細は、CREATE SYNONYMを参照してください。

クラウド・リンク・コンシューマ・オプションの使用

コンシューマ・データベースからデータにアクセスするために使用するサービス名マッピングを設定できます。また、問合せの結果またはクラウド・リンク・データにアクセスする問合せフラグメントに対して、データ・セット・コンシューマへのキャッシュを有効にできます。

クラウド・リンク・コンシューマのデータベース・サービス名マッピングの設定

クラウド・リンク・コンシューマがデータ・セット所有者のデータにアクセスするときに使用するサービス名マッピングを設定できます。

クラウド・リンクは、共有データにアクセスするために、データ・セット・プロデューサであるAutonomous AI Databaseインスタンス内のデータベース・リソースまたはリフレッシュ可能クローンのリソースに依存します。デフォルトでは、コンシューマがクラウド・リンク・データにアクセスするためのリモート接続では、MEDIUMデータベース・サービスが使用されます。

DBMS_CLOUD_LINK_ADMIN.ADD_SERVICE_MAPPINGを使用して、コンシューマのデータベース・サービス・マッピングを設定します。この手順では、コンシューマ・サービス・マッピングを指定するデータベースIDまたはキーワードANYを指定します。たとえば、次の図は、コンシューマAからHIGHサービスへのマッピング、コンシューマBからMEDIUMサービスへのマッピング、コンシューマCからLOWサービスへのマッピング、およびANYからTPサービスへのマッピングを示しています。つまり、他のすべてのコンシューマがTPサービスを使用してクラウド・リンクにアクセスします。

autonomous-cloud-links-service-mapping.pngの説明が続きます

図autonomous-cloud-links-service-mapping.pngの説明

データベース・サービスの特性の詳細は、Autonomous AI Databaseのデータベース・サービス名を参照してください。

次のステップを実行して、クラウド・リンク・コンシューマに使用するデータベース・サービスを設定します。

  1. サービス・マッピングを設定するデータベースのデータベースIDを取得します。

    コンシューマ・データベースでGET_DATABASE_IDを実行して、コンシューマのデータベースIDを取得します。次に例を示します。

    SELECT DBMS_CLOUD_LINK.GET_DATABASE_ID FROM DUAL:

    詳細は、GET_DATABASE_IDファンクションを参照してください。

  2. データ・セット所有者のAutonomous AI Databaseインスタンスで、サービス・マッピングを指定します。

    このステップは、データ・セット所有者のAutonomous AI Databaseインスタンス(つまり、プロデューサ・データベース)で実行します。

    BEGIN
       DBMS_CLOUD_LINK_ADMIN.ADD_SERVICE_MAPPING(
        database_id      => '*database_id*',
        service_name     => 'HIGH');
    END;
    /

    ここで、database_idパラメータ値は、ステップ1で取得したデータベースIDです。

    指定したservice_nameを、database_idservice_nameが関連付けられていないすべてのコンシューマ・データベースで使用するには、database_idの値ANYを指定します。つまり、service_nameDBMS_CLOUD_LINK_ADMIN.ADD_SERVICE_MAPPINGで設定されていないdatabase_idです。

    詳細は、ADD_SERVICE_MAPPINGプロシージャを参照してください。

    DBMS_CLOUD_LINK_ADMIN.ADD_SERVICE_MAPPINGを実行できるのは、ADMINユーザーおよびPDB_DBAロールを持つスキーマのみです。

  3. クラウド・リンク・サービス・マッピングをリストして、データベースIDおよびサービス・マッピングを確認します。

    たとえば:

    SELECT * FROM  DBA_CLOUD_LINK_SERVICE_MAPPINGS;

    詳細は、「DBA_CLOUD_LINK_SERVICE_MAPPINGSビュー」を参照してください。

サービス・マッピングの設定と変更に関するノート:

  • サービス・マッピングは、接続の確立時に有効になります。特定のコンシューマのサービス・マッピングが変更された場合、新しいマッピングはコンシューマからの新しいセッションに対してのみ有効になります。

  • 特定のコンシューマのデータ・セット所有者に構成されているサービス・マッピングは、コンシューマからのアクセスがリフレッシュ可能クローンにオフロードされている場合でも適用されます。リフレッシュ可能クローンは、データ・セット所有者にサービス・マッピングが構成された時点より後の時点にリフレッシュする必要があります。リフレッシュ可能クローンへのオフロードは、データ・セット登録時に引数offload_targetsを使用して構成されることに注意してください。

    詳細は、データ・セット・アクセス用のオフロード・ターゲットへのデータ・セットの登録を参照してください。

  • 指定したdatabase_idのサービス・マッピングを削除するには、プロシージャDBMS_CLOUD_LINK_ADMIN.REMOVE_SERVICE_MAPPINGを使用します。

    DBMS_CLOUD_LINK_ADMIN.REMOVE_SERVICE_MAPPINGを実行した後、コンシューマはデフォルトのMEDIUMデータベース・サービスを使用するか、database_idANYを指定してDBMS_CLOUD_LINK_ADMIN.ADD_SERVICE_MAPPINGを実行するかどうかを指定するservice_nameを使用します。詳細は、REMOVE_SERVICE_MAPPINGプロシージャを参照してください。

  • リモート・リージョンのクラウド・リンク・コンシューマのデータベース・サービス名マッピングの設定

    ソース・リージョンに登録されたデータ・セットは、リモート・リージョンでクロス・リージョン・リフレッシュ可能クローンを作成するときに、リモート・リージョンのクラウド・リンクを使用してアクセスできます。

リモート・リージョンのクラウド・リンク・コンシューマに対するデータベース・サービス名マッピングの設定

ソース・リージョンに登録されたデータ・セットは、リモート・リージョンでクロス・リージョン・リフレッシュ可能クローンを作成するときに、リモート・リージョンのクラウド・リンクを使用してアクセスできます。

この場合、リモート・リージョンのコンシューマに対するサービス・マッピングは、ソース・データベースおよびリモート・リージョンのリフレッシュ可能クローンで2回追加する必要があります。

次のステップを実行して、リモート・リージョンのクラウド・リンク・コンシューマのサービス・マッピングを設定します。

  1. ソース・データベースのクロス・リージョン・リフレッシュ可能クローンを作成します(リフレッシュ可能クローンは、リモート・リージョンのクラウド・リンク・データ・セット所有者のクローンです)。

    詳細は、クロス・テナンシまたはクロス・リージョン・リフレッシュ可能クローンの作成を参照してください。

  2. データ・セットを登録します。

    詳細は、「データ・セットの登録」を参照してください。

  3. データ・セット所有者にサービス・マッピングを追加します。

    詳細は、クラウド・リンク・コンシューマのデータベース・サービス名マッピングの設定を参照してください。

  4. リフレッシュ可能クローンをリフレッシュします。

    詳細は、Autonomous AI Databaseでのリフレッシュ可能クローンのリフレッシュを参照してください。

  5. リモートの「リフレッシュ可能クローン」で、データ・セットをソース・リージョンに登録するために使用したものと同じ引数を使用して、データ・セットを登録します(つまり、ステップ2で使用したものと同じ引数を使用します)。

  6. リモートのリフレッシュ可能クローンで、ソース・リージョンで使用したものと同じ引数を使用してサービス・マッピングを追加します(つまり、ステップ3で使用したものと同じ引数を使用します)。

リモート・リージョンのコンシューマがクラウド・リンク・データにアクセスする場合、アクセスには、ソース・リージョンのデータ・セット所有者データベースに追加したものと同じサービス・マッピングが使用されます。

クラウド・リンク・コンシューマのキャッシュの有効化

問合せの結果またはクラウド・リンク・データにアクセスする問合せフラグメントに対して、データ・セット・コンシューマに対するキャッシュを有効にできます。

データ・セット・コンシューマでキャッシュを有効にするには、SHELFLIFEオプションを指定してRESULT_CACHEヒントを使用します。SHELFLIFEオプションでは、問合せ結果がキャッシュされる期間(秒)を示す値を指定します。SHELFLIFE間隔が経過すると、キャッシュされた結果は無効としてマークされます。キャッシュされた結果が有効であるかぎり、問合せはコンシューマ・データベースのキャッシュからキャッシュされたデータを取得します。これにより、データ・セット所有者のデータベースへのラウンド・トリップを回避できます。

データ・セットが静的な場合、またはコンシューマが失効した結果を許容できる場合は、RESULT_CACHEヒントをSHELFLIFEオプションとともに使用します。SHELFLIFEの値によって、クラウド・リンク・データ・セット・コンシューマは、キャッシュ内のデータが有効な時間(許容される失効度)を秒単位で制御できます。

問合せ結果が大きく、メモリーに収まらない場合は、RESULT_CACHEヒントとSHELFLIFEオプションとTEMPオプションを両方使用して、結果を一時表領域のディスクに書き込む必要があることを示します。

RESULT_CACHEヒントを使用してクラウド・リンク・データをキャッシュするには:

  1. 問合せで、SHELFLIFEオプションを使用してRESULT_CACHEヒントを指定します。

    たとえば:

    SELECT /*+ RESULT_CACHE (SHELFLIFE=120) */ * FROM FOREST.TREE_DATA@cloud$link;

    このRESULT_CACHEは、SHELFLIFE値120を指定します。これは、結果が120秒間メモリーにキャッシュされることを示します。120秒後に、キャッシュされた結果は無効としてマークされます。

    SHELFLIFE値は正の整数である必要があります。最大SHELFLIFEの値は4294967295です。

  2. 問合せ結果が大きく、メモリーに収まらない場合は、SHELFLIFEオプションとTEMPオプションを両方使用して、結果をディスクの一時表領域に書き込む必要があることを示します。

    SELECT /*+ RESULT_CACHE (TEMP=true SHELFLIFE=360) */ * FROM FOREST.TREE_DATA@cloud$link;

Autonomous AI Databaseで結果キャッシュを使用する方法の詳細は、RESULT_CACHE_MODEを参照してください。

SHELFLIFEを使用したRESULT_CACHEの詳細は、「RESULT_CACHEヒント」を参照してください。

結果キャッシュを管理し、結果キャッシュ内のオブジェクトを無効化するプロシージャの詳細は、DBMS_RESULT_CACHEを参照してください。

クラウド・リンク情報のモニターおよび表示

Autonomous AI Databaseには、クラウド・リンクをモニターおよび監査できるビューが用意されています。

表示 摘要
V$CLOUD_LINK_ACCESS_STATSおよびGV$CLOUD_LINK_ACCESS_STATSビュー Autonomous AI Databaseインスタンスに登録されている各データ・セットへのアクセスを追跡するために使用します。これらのビューでは、経過時間、CPU時間、取得された行数および登録済データ・セットに関する追加情報が追跡されます。これらのビューの情報を使用して、クラウド・リンク・データ・セットのアクセスおよび使用状況を監査できます。
DBA_CLOUD_LINK_REGISTRATIONSビューおよびALL_CLOUD_LINK_REGISTRATIONSビュー Autonomous AI Databaseインスタンスに登録されたデータ・セットの詳細をリストする場合に使用します。
DBA_CLOUD_LINK_ACCESSビューおよびALL_CLOUD_LINK_ACCESSビュー データベースがアクセスを許可されている登録済データ・セットの詳細を取得する場合に使用します。
DBA_CLOUD_LINK_AUTHORIZATIONSビュー どのデータベースに対してどのデータ・セットへのアクセスが認可されているかに関する情報を提供します。これは、auth_requiredパラメータがTRUEのデータ・セットに適用されます。
DBA_CLOUD_LINK_PRIVSビューおよびUSER_CLOUD_LINK_PRIVSビュー すべてのユーザーまたは現在のユーザーに付与された、クラウド・リンク固有の権限REGISTERREADまたはAUTHORIZEに関する情報を提供します。
DBA_CLOUD_LINK_SERVICE_MAPPINGSビュー クラウド・リンク・コンシューマ・データベースのすべてのサービス・マッピングの詳細を表示します。各サービス・マッピングは、クラウド・リンク・データベースIDとデータベース・サービスで構成されます。

登録済データ・セットを保護するための仮想プライベート・データベース・ポリシーの定義

登録済データ・セットの仮想プライベート・データベース(VPD)ポリシーを定義することで、特定のリモート・サイトでデータ(行)のサブセットのみが表示されるように、ファイングレイン・クラウド・リンク・アクセス制御を提供できます。

Oracle Virtual Private Database (VPD)は、同じデータ・セットにフィルタを適用することで、ユーザーおよびアプリケーションの行レベルでデータ・アクセスを動的に制御できるセキュリティ機能です。

クラウド・リンクの読取りアクセス権を付与されたユーザーは、登録済データ・セットにアクセスし、そのデータ・セットが登録時に指定されたスコープ内にあり、データ・セットに追加の認可必須パラメータが設定されている場合、そのアクセスは認可済データベースからのアクセスです。各リモート・アクセスは、(データ・セットが登録されたデータベース上の)登録済データ・セットにアクセスするリモートAutonomous AI Databaseインスタンスのコンテキストで実行されます。

リモート・システムで関数DBMS_CLOUD_LINK.GET_DATABASE_IDを使用して、データベースの一意のIDを取得します。データ・セットを登録したデータベースでVPDポリシーを定義することで、リモート・データベースの識別子をSYS_CONTEXTルールとして使用して、より詳細な制御を提供できるようになりました。登録されたデータ・セットにアクセスするリモート・データベースのルールを定義し、クラウド・リンク・スコープを指定することで、可能な範囲を超えてアクセスを制限できます。

REGIONAL_SALES.SALES_AGGがテナンシ・レベルで使用可能になる例を考えてみます。1つの特定のデータベースを除くすべてのデータベースへのアクセスを制限し、指定したデータベースへのフル・アクセスのみを許可する場合は、登録済データ・セットにVPDポリシーを追加できます。

たとえば:

  1. フル・アクセスを提供するAutonomous AI Databaseインスタンスの一意のクラウド・リンク・データベースIDを取得します。

    DECLARE
         DB_ID NUMBER;
     BEGIN
         DB_ID := DBMS_CLOUD_LINK.GET_DATABASE_ID;
         DBMS_OUTPUT.PUT_LINE('Database ID:' || DB_ID);
     END;
     /
  2. ステップ1で該当するデータベースに識別子を取得した特定のデータベースへのフル・アクセスのみを許可して、データ・セットを登録したデータベースにVPDポリシーを作成します。

    CREATE OR REPLACE FUNCTION vpd_policy_sales(
         owner IN VARCHAR2,
         object IN VARCHAR2)
         RETURN VARCHAR2 IS
    BEGIN
      IF SYS_CONTEXT('USERENV', 'CLOUD_LINK_DATABASE_ID')  <> '12121212163948244901' THEN
        RETURN 'time_id >= trunc(sysdate,''year'')';
      ELSE
        RETURN '';
      END IF;
    END;
    /

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

  3. 登録したデータ・セットのVPDポリシーを登録して、ステップ1で識別したデータベースのみへのフル・アクセスを制限します。

    BEGIN
      DBMS_RLS.ADD_POLICY(object_schema => 'CLOUDLINK',
                object_name => 'SALES_VIEW_AGG',
                policy_name => 'THIS_YEAR',
                function_schema => 'ADMIN',
                policy_function => 'VPD_POLICY_SALES',
                statement_types => 'SELECT',
                policy_type => DBMS_RLS.SHARED_CONTEXT_SENSITIVE);
    END;
    /

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

詳細は、「Oracle Virtual Private Databaseを使用したデータ・アクセスの制御」を参照してください。

読取り専用Autonomous AI Databaseインスタンスからのクラウド・リンクの使用

データ・セットが読取り専用Autonomous AI Databaseインスタンスに存在する場合、クラウド・リンクを共有できます。

読取り専用モードのAutonomous AI Databaseインスタンスからクラウド・リンクを共有するには:

  1. データベース・モードを「読取り/書込み」モードに変更します。

    詳細は、Autonomous AI Database操作モードを読取り/書込み専用または制限付きに変更を参照してください。

  2. 読取り/書込みモードのデータベースで、データ・セットを登録するステップを実行します。

    1. データベース・ユーザーへのクラウド・リンク・アクセス権の付与

    2. データ・セットの登録または登録解除

  3. 1つ以上のデータ・セットを登録した後、データベースを読取り専用モードに変更します。

    詳細は、Autonomous AI Database操作モードを読取り/書込み専用または制限付きに変更しますを参照してください。

クラウド・リンクに関するノート

クラウド・リンクを使用するためのノートおよび制限について説明します。

  • 登録できるデータ・セットの数には4096という制限があります。

    各Autonomous AI Databaseインスタンスは、4096個を超えるデータセットを登録できません。この制限は、ECPUの数(データベースがOCPUを使用している場合のOCPU)またはインスタンスのストレージ・サイズに関係なく、すべてのAutonomous AI Databaseインスタンスに適用されます。制限は固定値であり、ECPU数を大きい値に設定しても、より多くのデータセットを登録することはできません。

  • オブジェクトに対するREAD WITH GRANT OPTION権限がある場合は、オブジェクトを別のスキーマに登録できます。

  • データ・セットを登録したり、リモート・データ・セットを参照してアクセスするには、データ・セットを登録または読取りするための適切な権限が付与されている必要があります。これはADMINにも当てはまりますが、ADMINは自分自身にこの権限を付与できます。

  • DBMS_CLOUD_LINK.REGISTERまたはDBMS_CLOUD_LINK.UPDATE_REGISTRATIONを使用するには、DBMS_CLOUD_LINK_ADMIN.GRANT_REGISTERで割り当てられたレジスタ権限に加えて、DBMS_CLOUD_LINKパッケージに対する実行権限が必要です。デフォルトでは、ADMINユーザーおよびPDB_DBAのスキーマのみがこの権限を持ちます。

  • 登録された表を削除して再作成する場合は、リモート・アクセスのために表を再登録する必要があります。

  • ADMINユーザーおよびロールPDB_DBAを持つユーザーのみが、次のビューにアクセスする権限を持ちます。

    • DBA_CLOUD_LINK_ACCESS

    • DBA_CLOUD_LINK_REGISTRATIONS

    • DBA_CLOUD_LINK_AUTHORIZATIONS

    • DBA_CLOUD_LINK_PRIVS

    詳細は、「DBMS_CLOUD_LINKビュー」を参照してください。

  • 登録されているリモート・データにアクセスするには、リモート・データベースをオープンする必要があります。リモート・データベースがクローズまたは制限モードの場合、データにアクセスできず、Oracleエラーが返されます。

  • セッション当たり最大4つのオープン・データベース・リンクの制限があります。この制限を超えると、ORA-02020またはORA-12545が発生する可能性があります。

  • レイクハウス・ワークロードを使用するAutonomous AI Databaseのデフォルトの動作と同様に、結果キャッシュが有効な場合、リアルタイム・データが必要なときに結果キャッシュが使用されないようにする必要があります。

  • ライセンス・タイプを「無料」から「有料」に更新する場合は、クラウド・リンクのデータ・セットを再登録する必要があります。詳細は、Autonomous AI DatabaseでAlways Freeインスタンスを有料に更新を参照してください。

  • クラウド・リンクのリモート接続では、デフォルトでMEDIUMデータベース・サービスが使用されます。ANYDATABASE_IDの値として使用して、DBMS_CLOUD_LINK_ADMIN.ADD_SERVICE_MAPPINGでデフォルトを変更できます。コンシューマのDATABASE_IDを指定することで、DBMS_CLOUD_LINK_ADMIN.ADD_SERVICE_MAPPINGを使用してコンシューマのデータベース・サービスを変更できます。詳細は、クラウド・リンク・コンシューマのデータベース・サービス名マッピングの設定を参照してください。

    リモート接続はユーザーC##DATA$SHAREとしてV$SESSIONに表示され、クラウド・リンク・ビューV$CLOUD_LINK_ACCESS_STATSビューおよびGV$CLOUD_LINK_ACCESS_STATSビューにはリモート接続の詳細が表示されます。

  • 特に明記されていないかぎり、すべてのインタフェースで大文字と小文字が区別されます。次に例を示します。

    • ユーザー名や表名など、データベースに存在する入力内容は、大/小文字が区別され、大文字で入力する必要があります。

    • たとえば、事前定義済のスコープ値など、事前定義済の変数は大文字で入力する必要があります。

    • ネームスペースやネームスペース内の表の名前など、クラウド・リンクの設定に指定したものはすべて、入力されたとおりに指定する必要があります。たとえば、ネームスペースをtreesとして定義する場合、SQLでネームスペースにアクセスするときは、ネームスペースを二重引用符で囲む必要があります("trees")。

  • データ・セットが読取り専用モードのAutonomous AI Databaseインスタンスに存在する場合は、クラウド・リンクを共有できます。詳細は、読取り専用Autonomous AIデータベース・インスタンスからのクラウド・リンクの使用を参照してください。

  • リフレッシュ可能クローンのリフレッシュ可能クローンをオフロード・ターゲットとして表示してから最大10分かかる場合があります。つまり、リフレッシュ可能クローンをクラウド・リンク・オフロード登録で使用できるようにするには、リフレッシュ可能クローンを作成してから最大10分待機する必要がある場合があります。

    詳細は、データ・セット・アクセス用のオフロード・ターゲットへのデータ・セットの登録およびAutonomous AIデータベース・インスタンスのリフレッシュ可能クローンの作成を参照してください。

  • 読取り専用Autonomous AI Databaseインスタンスからのクラウド・リンクの使用

    データ・セットが読取り専用Autonomous AI Databaseインスタンスに存在する場合は、クラウド・リンクを共有できます。