機械翻訳について

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

クラウド・リンクは、Autonomous Databaseインスタンス上の読取り専用データにリモートでアクセスするためのクラウド・ベースのメソッドを提供します。

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

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

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

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

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

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

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

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

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

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

ノート:

クラウド・リンクは、Autonomous Databaseインスタンス上のリモート・オブジェクトへの読取り専用アクセスを提供します。 他のOracleデータベースまたはOracle以外のデータベースとのデータベース・リンクを使用する場合、またはDML操作でリモート・データを使用する場合は、データベース・リンクを使用する必要があります。 詳細については、「Autonomous 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 Databaseでリモート・アクセスが有効になっている表またはビューを識別します。 登録されたデータ・セットは、データ・セットへのアクセスを許可されたユーザー(そのスコープ)も示します。 データ・セット登録では、ネームスペースおよびクラウド・リンクで使用する名前を定義します。 データ・セット登録後、これらの値を組み合せてリモート・アクセス用に完全修飾名(FQN)を指定し、クラウド・リンクでデータ・セットのアクセシビリティを管理できるようにします。

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

• スコープ: 登録済データ・セットへのアクセスをユーザーが許可されるユーザーと場所を指定します。 スコープの詳細は、「データ・セット・スコープ、アクセス制御および認可」を参照してください。

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

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

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

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

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

クラウド・リンク監査

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

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

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

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

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

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

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

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

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

データ・セット範囲

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

• 'MY$REGION'
• 'MY$TENANCY'
• 'MY$COMPARTMENT'

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

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

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

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

次に、データ・セットの登録時に設定するスコープによって、ユーザーがデータ・セットにアクセスできる場所が決まります。 DBMS_CLOUD_LINK.REGISTER scopeは、次の1つ以上のカンマ区切りリストです:

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

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

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

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

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

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

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

スコープ値MY$REGION、MY$TENANCYおよびMY$COMPARTMENTは、利便性マクロとして機能し、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 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 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'

詳細については、「データ・セット・スコープ、アクセス制御および認可」を参照してください。

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 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 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 Database共通スキーマは、レルム参加者としてレルムに対して認可される必要があります。

   たとえば:

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

   詳細については、「Oracle Database VaultをAutonomous Databaseとともに使用」を参照してください。

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

• データ・セットを登録したり、リモート・データセットを表示およびアクセスするには、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 DatabaseインスタンスにスキーマCLOUDLINKがある場合、2つのオブジェクトSALES_VIEW_AGGおよびSALES_ALLを登録し、異なる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 =>  '[e-mail]' );
   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 =>  '[e-mail]' );
   END;
   /

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

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

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

     • 表(ヒープ、外部またはハイブリッドを含む)
     • ビュー
     • マテリアライズド・ビュー
     • クラウド表(詳細は、「クラウド表を使用したロギングおよび診断情報の格納」を参照してください。)

     ノート:

     分析ビューやシノニムなどの他のオブジェクトはサポートされていません。

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

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

   • name: クラウド・リンク(クラウド・リンクFQNの1つの部分)にアクセスするために指定した名前です。

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

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

     詳細については、「データ・セット・スコープ、アクセス制御および認可」を参照してください。

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

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

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

   この例では、登録が完了した後、DBMS_CLOUD_LINK.REGISTERで指定したスコープ・パラメータに基づいて、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権限がある場合は、別のユーザーのスキーマに存在する表またはビューを登録できます。

• Autonomous Databaseは登録時に階層妥当性チェックを実行せず、スコープ外の登録は表示またはアクセスできません。

  たとえば、次の順序を考えてみましょう。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   たとえば、Autonomous 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 =>  '[e-mail]' );
   END;
   /

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

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

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

     • 表(ヒープ、外部またはハイブリッドを含む)
     • ビュー
     • マテリアライズド・ビュー

     ノート:

     分析ビューやシノニムなどの他のオブジェクトはサポートされていません。

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

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

   • name: クラウド・リンク(クラウド・リンクFQNの1つの部分)にアクセスするために指定した名前です。

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

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

     詳細については、「データ・セット・スコープ、アクセス制御および認可」を参照してください。

   • 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 Databaseでのリフレッシュ可能なクローンのリフレッシュ」を参照してください。

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

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

   たとえば:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

データ・セットの承認必須への登録

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

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

ノート:

権限が付与されるのは、次のステップに示すようにのみです。 ADMINは、DBMS_CLOUD_LINK_ADMIN.GRANT_AUTHORIZEを使用して許可権限を付与します。

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

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

   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 =>  '[e-mail]' );
   END;
   /

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

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

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

     • 表(ヒープ、外部またはハイブリッドを含む)
     • ビュー
     • マテリアライズド・ビュー

     ノート:

     分析ビューやシノニムなどの他のオブジェクトはサポートされていません。

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

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

   • name: クラウド・リンク(クラウド・リンクFQNの1つの部分)にアクセスするために指定した名前です。

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

     詳細については、「データ・セット・スコープ、アクセス制御および認可」を参照してください。

   • 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;
/

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

• REGISTERプロシージャ

• UPDATE_REGISTRATIONプロシージャ

• GRANT_AUTHORIZEプロシージャ

• REVOKE_AUTHORIZATIONプロシージャ

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

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

オプションのoffload_targetsパラメータをDBMS_CLOUD_LINK.REGISTERとともに使用して、アクセスをリフレッシュ可能クローンにオフロードすることを指定します。 各リフレッシュ可能クローンのソース・データベースは、データ・セット(データ・パブリッシャ)を登録するAutonomous 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 DatabaseインスタンスのOCIDです。

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

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

データ・セット・コンシューマが、offload_targetsに登録したデータ・セットへのアクセスをリクエストし、Autonomous 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コンソールで使用できます。

   ノート:

   オフロード・ターゲットとして表示されるリフレッシュ可能クローンのリフレッシュ可能クローンを作成してから最大10分かかる場合があります。 つまり、リフレッシュ可能クローンを作成してクラウド・リンク・オフロード登録で使用できるようにするには、リフレッシュ可能クローンを作成してから最大10分待機する必要がある場合があります。
2. リフレッシュ可能クローンによって提供されるデータを使用して、データ・セットにアクセスする1つ以上のAutonomous DatabaseインスタンスのデータベースIDを取得します。

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

   SELECT DBMS_CLOUD_LINK.GET_DATABASE_ID FROM DUAL:

3. データ・セットを登録し、offload_targetsパラメータを指定します。

   たとえば、Autonomous 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  =>  '[e-mail]',
       offload_targets => '{
     "OFFLOAD_TARGETS": [
       {
         "CLOUD_LINK_DATABASE_ID": "34xxxx754755680",
         "OFFLOAD_TARGET":
   "ocid1.autonomousdatabase.oc1..xxxxxaaba3pv6wkcr4jqae5f44n2b2m2yt2j6rx32uzr4h25vqstifsfghi"
       }
     ]
   }');
   END;
   /

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

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

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

     • 表(ヒープ、外部またはハイブリッドを含む)
     • ビュー
     • マテリアライズド・ビュー

     ノート:

     分析ビューやシノニムなどの他のオブジェクトはサポートされていません。

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

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

   • name: クラウド・リンク(クラウド・リンクFQNの1つの部分)にアクセスするために指定した名前です。

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

     詳細については、「データ・セット・スコープ、アクセス制御および認可」を参照してください。

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

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

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

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

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

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

   ノート:

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

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

   • REGISTERプロシージャ

   • UPDATE_REGISTRATIONプロシージャ

   • Autonomous Databaseでのリフレッシュ可能クローンの使用

   • クラウド・リンクでの統合問合せオフロードの使用

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

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

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

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

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

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

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

   たとえば、DBMS_CLOUD_LINK.UPDATE_REGISTRATIONを使用して、ネームスペースREGIONAL_SALESのデータ・セットのdescription、scopeおよび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$REGION、MY$TENANCYまたはMY$COMPARTMENT、または1つ以上のOCIDsを指定します。

     詳細については、「データ・セット・スコープ、アクセス制御および認可」を参照してください。

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

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

   • offload_targets: データ・セットが登録されているAutonomous Databaseから、データ・セットへのアクセスがオフロードされるリフレッシュ可能クローンの1つ以上のAutonomous 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パラメータを除いて、ソース・データベースの更新に使用した値と同じ値でデータ・セット登録を更新します。

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

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

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

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

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

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

1. Autonomous Databaseインスタンスで使用可能なデータ・セットを検索します。

   たとえば、「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を参照してください。

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

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

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

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

クラウド・リンクは、共有データにアクセスするために、データ・セット・プロデューサまたはリフレッシュ可能クローンのリソースであるAutonomous 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 Databaseのデータベース・サービス名」を参照してください。

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

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

   コンシューマ・データベースでGET_DATABASE_IDを実行して、コンシューマのデータベースIDを取得します。 たとえば:

   SELECT DBMS_CLOUD_LINK.GET_DATABASE_ID FROM DUAL:

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

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

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

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

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

   database_idの値ANYを指定して、service_nameがdatabase_idに関連付けられていないすべてのコンシューマ・データベースで、指定されたservice_nameを使用します。 つまり、service_nameがDBMS_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を使用して構成されることに注意してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

データ・セット・コンシューマでキャッシュを有効にするには、RESULT_CACHEヒントをSHELFLIFEオプションとともに使用します。 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は、120のSHELFLIFE値を指定します。 これは、結果が120秒間メモリーにキャッシュされることを示します。 120秒後、キャッシュされた結果は無効としてマークされます。

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

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

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

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

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

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

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

Autonomous Databaseは、クラウド・リンクをモニターおよび監査できるビューを提供します。

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

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

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

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

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

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

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

たとえば:

1. フル・アクセスを提供するAutonomous 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で対象のデータベースに識別子を取得した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を使用したデータ・アクセスの制御」を参照してください。

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

クラウド・リンクの使用に関するノートおよび制限を示します。

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

  各Autonomous Databaseインスタンスは、4096個以下のデータ・セットを登録できます。 この制限は、「ECPU (データベースがOCPUを使用している場合はOCPU)」の数やインスタンスのストレージ・サイズに関係なく、すべてのAutonomous 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 Databaseでのデフォルトの動作と同様に、リアルタイム・データが必要な場合に結果キャッシュが使用されないようにする必要があります。

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

• クラウド・リンクのリモート接続では、デフォルトでMEDIUMデータベース・サービスが使用されます。 DBMS_CLOUD_LINK_ADMIN.ADD_SERVICE_MAPPINGでデフォルトを変更するには、ANYをDATABASE_IDの値として使用します。 コンシューマの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 Databaseインスタンスに存在する場合は、クラウド・リンクを共有できます。 詳細については、「読取り専用Autonomous Databaseインスタンスからのクラウド・リンクの使用」を参照してください。

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

  詳細については、「データ・セット・アクセスのオフロード・ターゲットへのデータ・セットの登録」と「Autonomous Databaseインスタンスのリフレッシュ可能クローンの作成」を参照してください。

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

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

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

1. データベース・モードを読取り/書込みモードに変更します。
   詳細については、「Autonomous Database操作モードを読取り/書込み、読取り専用または制限付きに変更」を参照してください。
2. データベースが読取り/書込みモードの場合、データ・セットを登録するステップを実行します。
   1. データベース・ユーザーに対するクラウド・リンク・アクセス権の付与
   2. データ・セットの登録または登録解除
3. 1つ以上のデータ・セットを登録した後、データベースを読取り専用モードに変更します。
   詳細については、「Autonomous Database操作モードを読取り/書込み、読取り専用または制限付きに変更」を参照してください。