Utilisation de liens cloud pour l'accès aux données en lecture seule sur Autonomous Database

Les liens cloud fournissent une méthode cloud permettant d'accéder à distance aux données en lecture seule sur une instance Autonomous Database.

A propos des liens cloud sur Autonomous Database

Avec Cloud Links, un propriétaire de données enregistre une table ou une vue pour l'accès à distance pour une audience sélectionnée, tel que défini par le propriétaire des données, et les données sont ensuite accessibles à ceux avec accès accordé au moment de l'inscription. Aucune autre action n'est nécessaire pour configurer les liens cloud et quiconque est censé voir et accéder à vos données est en mesure de découvrir et de travailler avec les données.

L'implémentation de Cloud Links s'appuie sur les mécanismes d'accès d'Oracle Cloud Infrastructure pour rendre les données accessibles dans une portée spécifique. La portée indique qui peut accéder à distance aux données. La portée peut être définie sur différents niveaux, y compris sur la région dans laquelle réside la base de données, sur des locations individuelles ou sur des compartiments. En outre, vous pouvez indiquer que l'autorisation d'accéder à un ensemble de données est limitée à des instances Autonomous Database.

En créant des clones actualisables inter-région à partir de l'instance Autonomous Database source (propriétaire de l'ensemble de données), vous pouvez utiliser les liens cloud pour partager des données entre plusieurs régions.

Les liens cloud simplifient considérablement le partage de tables ou de vues entre les instances Autonomous Database, par rapport aux mécanismes de liaison de base de données traditionnels. Avec Cloud Links, vous pouvez repérer des données sans avoir besoin d'une configuration de lien de base de données complexe. Autonomous Database fournit un accès transparent à l'aide de SQL, et implémente l'application des privilèges avec la portée Cloud Links et en accordant l'autorisation à des instances Autonomous Database individuelles.

Cloud Links introduit les concepts d'espaces de noms régionaux et de noms de données accessibles à distance. Cela est similaire aux tables Oracle existantes où il existe une table, par exemple "EMP" qui réside dans un espace de noms (schéma), par exemple "LWARD". Votre base de données ne peut contenir qu'un seul élément LWARD.EMP. Les liens cloud fournissent un espace de noms et un nom similaires au niveau régional, qui ne sont pas liés à une seule base de données mais s'appliquent à de nombreuses instances Autonomous Database, comme indiqué avec la portée et éventuellement avec l'autorisation de base de données.

Par exemple, vous pouvez inscrire un ensemble de données sous l'espace de noms FOREST. Pour des raisons de sécurité ou pour des raisons de nommage, vous pouvez fournir un espace de noms et un nom autres que les noms de schéma et d'objet d'origine. Dans cet exemple, TREE_DATA est le nom visible de l'ensemble de données inscrit et ce nom n'est pas obligatoire pour être le nom de la table source. Outre l'espace de noms et le nom, le mot-clé cloud$link indique à la base de données qu'elle doit résoudre la source en tant que lien cloud.

Pour accéder à un ensemble de données inscrit, incluez l'espace de noms, le nom et le mot-clé cloud$link dans la clause FROM d'une instruction SELECT :

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

Vous pouvez éventuellement indiquer que l'accès à un ensemble de données à partir de bases de données est déchargé vers un clone actualisable. Lorsqu'une instance Autonomous Database destinataire est répertoriée dans la liste de déchargement d'un ensemble de données, l'accès à l'ensemble de données est dirigé vers le clone actualisable.

Remarque

Les liens cloud fournissent un accès en lecture seule aux objets distants sur une instance Autonomous Database. Si vous voulez utiliser des liens de base de données avec d'autres bases de données Oracle ou avec des bases de données non Oracle, ou si vous voulez utiliser vos données distantes avec des opérations LMD, vous devez utiliser des liens de base de données. Reportez-vous à Utilisation de liens de base de données avec Autonomous Database pour en savoir plus.
Les liens cloud prennent en charge les synonymes privés et publics. Par exemple, vous pouvez définir et utiliser un synonyme pour 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;

Pour plus d'informations sur les synonymes, reportez-vous à Présentation des synonymes.

Conditions des liens cloud

Il existe plusieurs concepts et termes à utiliser lorsque vous utilisez des liens cloud :

  • Ensemble de données inscrit (ensemble de données) : identifie une table ou une vue qui a été activée pour l'accès distant dans une instance Autonomous Database. Un jeu de données enregistré indique également qui est autorisé à accéder au jeu de données (sa portée). L'inscription d'ensemble de données définit un espace de noms et un nom à utiliser avec les liens cloud. Après l'inscription du jeu de données, ces valeurs indiquent le nom qualifié complet pour l'accès à distance et permettent aux liens cloud de gérer l'accessibilité du jeu de données.

  • Propriétaire du jeu de données : indiquez un propriétaire de jeu de données afin de fournir un point de contact pour les questions relatives à un jeu de données.

  • Portée : indique à qui et à partir de quel endroit un utilisateur est autorisé à accéder à un ensemble de données inscrit. Pour plus d'informations sur la portée, reportez-vous à Portée de l'ensemble de données, contrôle d'accès et autorisation.

  • OCID : (identificateur Oracle Cloud) identifie une location, un compartiment ou une base de données spécifique. La portée d'un ensemble de données inscrit peut être exprimée en termes d'OCID. Pour plus d'informations, reportez-vous à Identificateurs de ressource.

  • Enregistrement des données : avec l'enregistrement des données, un utilisateur met une table ou une vue à disposition pour l'accès distant, sous réserve des restrictions d'accès imposées par la portée et, éventuellement, d'une étape d'autorisation supplémentaire. Vous pouvez autoriser l'accès distant avec des liens cloud sur une table ou une vue stockée dans la base de données ou sur des données stockées dans la banque d'objets.

  • Repérage de données : un ensemble de données inscrit peut être repéré à l'aide de requêtes textuelles de la base de données. Le repérage n'affiche un jeu de données que s'il existe un privilège permettant d'accéder au jeu de données. Vous pouvez rechercher un jeu de données enregistré par nom ou par description.

  • Description des données : permet à un utilisateur d'extraire une description ou des métadonnées pour une table ou une vue mise à disposition en tant qu'ensemble de données inscrit.

  • Cibles de déchargement : vous pouvez éventuellement indiquer des cibles de déchargement. Les cibles de déchargement sont des clones actualisables qui fournissent des ensembles de données Cloud Links à des instances Autonomous Database spécifiées. En indiquant une cible de déchargement, vous pouvez dédier une instance Autonomous Database aux ensembles de données afin de séparer la production du développement, de garantir la sécurité ou pour d'autres raisons. Pour plus d'informations, reportez-vous à Utilisation des clones actualisables avec Autonomous Database.

Audit des liens cloud

Tout accès à un ensemble de données enregistré à l'aide de Cloud Links est consigné à des fins d'audit. Le journal inclut la location, le compartiment ou la base de données qui a accédé à l'ensemble de données, la quantité de données consultées et des informations supplémentaires. Les vues V$CLOUD_LINK_ACCESS_STATS et GV$CLOUD_LINK_ACCESS_STATS affichent les informations d'audit.

Métadonnées d'ensemble de données et vues d'audit

Chaque instance Autonomous Database fournit des vues qui exposent les métadonnées d'ensemble de données et vous permettent de surveiller et d'auditer l'utilisation des données. Pour plus d'informations, reportez-vous à Surveillance et visualisation des liens cloud.

Portée du jeu de données, contrôle d'accès et autorisation

Les liens cloud s'appuient sur les mécanismes d'accès d'Oracle Cloud Infrastructure pour rendre les ensembles de données inscrits accessibles et protéger vos données avec des restrictions d'accès.

Autonomous Database détermine l'accessibilité des ensembles de données inscrits comme suit :

  • L'utilisateur ADMIN spécifie une portée pour un utilisateur qui lui permet d'enregistrer des jeux de données en fonction de la portée fournie.

  • Un utilisateur disposant de privilèges permettant d'enregistrer des jeux de données spécifie une portée lors de l'enregistrement d'un jeu de données.

  • Lorsque vous enregistrez un jeu de données, un utilisateur disposant de privilèges d'autorisation peut indiquer qu'une étape d'autorisation est requise pour accéder à un jeu de données. Cette étape d'autorisation s'ajoute à l'autorisation d'accès au niveau du périmètre.

Portée du jeu de données

L'utilisateur ADMIN définit la portée d'un utilisateur avec DBMS_CLOUD_LINK_ADMIN.GRANT_REGISTER comme suit :

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

La portée d'un utilisateur est hiérarchique, ce qui signifie qu'un utilisateur disposant de l'une de ces portées peut autoriser l'accès comme suit :

  • MY$REGION : l'utilisateur peut accorder l'accès aux données distantes à d'autres locations de la région de l'instance Autonomous Database qui inscrit l'ensemble de données. Il s'agit de la portée la moins restrictive.

  • MY$TENANCY : un utilisateur peut accorder l'accès aux données distantes à n'importe quelle ressource, location, compartiment ou base de données de la location de l'instance Autonomous Database qui inscrit l'ensemble de données. Cette portée est plus restrictive que la portée MY$REGION.

  • MY$COMPARTMENT : un utilisateur peut accorder l'accès aux données distantes à n'importe quelle ressource, compartiment ou base de données du compartiment de l'instance Autonomous Database qui inscrit l'ensemble de données. Il s'agit de la portée la plus restrictive que vous pouvez définir pour un utilisateur avec GRANT_REGISTER.

Ensuite, la portée que vous définissez lors de l'inscription d'un jeu de données détermine l'endroit à partir duquel les utilisateurs sont autorisés à accéder au jeu de données. DBMS_CLOUD_LINK.REGISTER scope est une liste séparée par des virgules composée des éléments suivants :

  • OCID de base de données : l'accès à l'ensemble de données est autorisé pour les instances Autonomous Database spécifiques identifiées par l'OCID.

  • OCID de compartiment : l'accès à l'ensemble de données est autorisé pour les bases de données des compartiments identifiés par l'OCID de compartiment.

  • OCID de location : l'accès à l'ensemble de données est autorisé pour les bases de données des locations identifiées par l'OCID de location.

  • Nom de région : l'accès à l'ensemble de données est autorisé pour les bases de données de la région identifiée par la région nommée. Dans tous les cas, l'accès aux liens cloud est limité à une seule région et n'est pas inter-région.

  • MY$COMPARTMENT : l'accès à l'ensemble de données est autorisé pour les bases de données du compartiment du propriétaire de l'ensemble de données.

  • MY$TENANCY : l'accès à l'ensemble de données est autorisé pour les bases de données de la location du propriétaire de l'ensemble de données.

  • MY$REGION : l'accès à l'ensemble de données est autorisé pour les bases de données de la région du propriétaire de l'ensemble de données.

Les valeurs de portée, MY$REGION, MY$TENANCY et MY$COMPARTMENT sont des variables qui agissent en tant que macros pratiques et sont résolues en OCID.

Remarque

La portée que vous définissez lors de l'inscription d'un ensemble de données est uniquement prise en compte lorsqu'elle correspond ou est plus restrictive que la valeur définie avec DBMS_CLOUD_LINK_ADMIN.GRANT_REGISTER. Par exemple, supposons que l'utilisateur ADMIN ait accordé la portée 'MY$TENANCY' avec GRANT_REGISTER et que l'utilisateur indique 'MY$REGION' lorsqu'il inscrit un ensemble de données avec DBMS_CLOUD_LINK.REGISTER. Dans ce cas, ils verraient une erreur telle que la suivante :
ORA-20001: Share privileges are not enabled for current user or it is enabled but not for scope MY$REGION

Vous pouvez également utiliser un mécanisme de contrôle d'accès supplémentaire basé sur une valeur SYS_CONTEXT. Ce mécanisme utilise la fonction DBMS_CLOUD_LINK.GET_DATABASE_ID qui renvoie un identificateur disponible en tant que valeur SYS_CONTEXT.

Lorsque vous inscrivez un ensemble de données auprès de DBMS_CLOUD_LINK.REGISTER, vous pouvez utiliser la valeur SYS_CONTEXT dans les stratégies de sécurité Oracle Virtual Private Database (VPD) pour contrôler l'accès à la base de données afin de restreindre et de contrôler davantage les données spécifiques auxquelles les instances Autonomous Database individuelles peuvent accéder.

Pour plus d'informations sur l'utilisation des stratégies VPD, reportez-vous à Définition d'une stratégie de base de données privée virtuelle pour sécuriser un ensemble de données inscrit.

La valeur de l'ID de base de données est également disponible dans les vues V$CLOUD_LINK_ACCESS_STATS et GV$CLOUD_LINK_ACCESS_STATS qui assurent le suivi des statistiques d'accès et des informations d'audit.

Pour plus d'informations, reportez-vous à Utilisation d'Oracle Virtual Private Database pour contrôler l'accès aux données.

Autorisation du jeu de données

Lorsque vous inscrivez un ensemble de données, si vous disposez de privilèges d'autorisation, vous pouvez indiquer que l'OCID de base de données doit être autorisé pour accéder à un ensemble de données. Afin de fournir l'autorisation OCID de base de données pour un ensemble de données, utilisez la procédure DBMS_CLOUD_LINK.GRANT_AUTHORIZATION pour indiquer les instances Autonomous Database autorisées à accéder à l'ensemble de données. Avant d'exécuter DBMS_CLOUD_LINK.GRANT_AUTHORIZATION, l'administrateur doit vous autoriser à exécuter cette procédure avec DBMS_CLOUD_LINK_ADMIN.GRANT_AUTHORIZE.

L'inscription du jeu de données avec l'autorisation requise spécifie l'accès au niveau de la base de données pour un jeu de données, en plus du contrôle d'accès de portée spécifié pour le jeu de données, comme suit :

  • Les bases de données qui se trouvent dans l'élément SCOPE indiqué et qui ont été autorisées avec DBMS_CLOUD_LINK.GRANT_AUTHORIZATION peuvent visualiser les lignes de l'ensemble de données.

  • Les bases de données comprises dans la valeur SCOPE indiquée mais qui n'ont pas été autorisées avec DBMS_CLOUD_LINK.GRANT_AUTHORIZATION ne peuvent pas visualiser les lignes d'ensemble de données. Dans ce cas, les consommateurs sans autorisation voient le jeu de données comme vide.

  • Les bases de données qui ne se trouvent pas dans l'élément SCOPE indiqué voient une erreur lors de la tentative d'accès à l'ensemble de données.

Octroi de l'accès aux liens cloud aux utilisateurs de base de données

L'utilisateur ADMIN accorde des privilèges aux utilisateurs de base de données pour inscrire des jeux de données. L'utilisateur ADMIN accorde également des privilèges aux utilisateurs de base de données pour accéder aux jeux de données enregistrés.

Lorsque l'utilisateur ADMIN accorde des privilèges d'inscription, il fournit une portée qui indique la portée maximale qu'un utilisateur peut fournir lorsqu'il inscrit un ensemble de données (dans la hiérarchie de portée). Les valeurs scope valides à utiliser avec DBMS_CLOUD_LINK_ADMIN.GRANT_REGISTER sont les suivantes :

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

Pour plus d'informations, reportez-vous à Portée de l'ensemble de données, contrôle d'accès et autorisation.

  1. En tant qu'utilisateur ADMIN, autorisez un utilisateur à inscrire des jeux de données dans une portée spécifiée.
    BEGIN
    DBMS_CLOUD_LINK_ADMIN.GRANT_REGISTER(
       username => 'DB_USER1',
       scope    => 'MY$REGION');
    END;
    /

    Cela indique que l'utilisateur DB_USER1 dispose de privilèges permettant d'inscrire des jeux de données dans une portée spécifiée, 'MY$REGION'.

    Un utilisateur peut interroger SYS_CONTEXT('USERENV', 'CLOUD_LINK_REGISTER_ENABLED') pour vérifier s'il est activé pour l'inscription des ensembles de données.

    Par exemple, la requête suivante :

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

    Renvoie 'YES' ou 'NO'.

    Pour plus d'informations, reportez-vous à GRANT_REGISTER Procédure.

  2. En tant qu'utilisateur ADMIN, autorisez un utilisateur à accéder aux ensembles de données inscrits.
    EXEC DBMS_CLOUD_LINK_ADMIN.GRANT_READ('LWARD');

    Cela permet à LWARD d'accéder aux ensembles de données inscrits disponibles pour l'instance Autonomous Database.

    Un utilisateur peut interroger SYS_CONTEXT('USERENV', 'CLOUD_LINK_READ_ENABLED') pour vérifier s'il est activé pour l'accès READ à un ensemble de données.

    Par exemple, la requête suivante :

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

    Renvoie 'YES' ou 'NO'.

    Pour plus d'informations, reportez-vous à GRANT_READ Procédure.

  3. Lors de l'inscription des données, vous pouvez définir le paramètre d'autorisation requis sur TRUE. Lorsque l'autorisation requise est TRUE, l'utilisateur ADMIN doit exécuter DBMS_CLOUD_LINK_ADMIN.GRANT_AUTHORIZE pour fournir l'autorisation d'appeler DBMS_CLOUD_LINK.GRANT_AUTHORIZATION. Utilisez DBMS_CLOUD_LINK.GRANT_AUTHORIZATION pour indiquer les détails d'autorisation.

    Pour plus d'informations, reportez-vous à Inscription d'un ensemble de données avec autorisation requise.

  4. Lorsque Database Vault est activé pour l'instance Autonomous Database et que la table ou la vue à inscrire auprès de liens cloud est protégée par un domaine, le propriétaire de la table ou de la vue doit y être autorisé en tant que propriétaire de domaine avant l'inscription.
    BEGIN
         DBMS_MACADM.ADD_AUTH_TO_REALM(
               realm_name   => 'myrealm',
               grantee      => 'object_owner',
               auth_option  => dbms_macutl.g_realm_auth_owner);
    END;
    /

    Si le domaine protégeant la table ou la vue est un domaine obligatoire, le schéma commun Autonomous Database nommé C##DATA$SHARE, qui est utilisé en interne comme schéma de connexion, doit être autorisé au domaine en tant que participant au domaine.

    Par exemple :

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

    Pour plus d'informations, reportez-vous à Utilisation d'Oracle Database Vault avec Autonomous Database.

Remarques concernant l'octroi de privilèges aux utilisateurs de base de données pour l'inscription des jeux de données :

  • Pour inscrire des ensembles de données ou voir des ensembles de données distants et y accéder, vous devez disposer du privilège approprié pour vous inscrire auprès de DBMS_CLOUD_LINK_ADMIN.GRANT_REGISTER ou pour lire des ensembles de données avec DBMS_CLOUD_LINK_ADMIN.GRANT_READ.

    Cela est également vrai pour l'utilisateur ADMIN. Toutefois, l'utilisateur ADMIN peut lui accorder des privilèges.

  • Les vues DBA_CLOUD_LINK_PRIVS et USER_CLOUD_LINK_PRIVS fournissent des informations sur les privilèges utilisateur. Pour plus d'informations, reportez-vous à Surveillance et visualisation des informations sur les liens cloud.

  • Un utilisateur peut exécuter la requête suivante pour vérifier s'il est activé pour l'authentification des jeux de données enregistrés et protégés :

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

Révoquer l'accès aux liens cloud pour les utilisateurs de base de données

L'utilisateur ADMIN peut révoquer l'inscription pour interdire à un utilisateur d'inscrire des jeux de données pour un accès distant. L'utilisateur ADMIN peut également révoquer des privilèges ou des utilisateurs de base de données pour accéder aux jeux de données enregistrés.

  1. En tant qu'utilisateur ADMIN, révoquez les privilèges d'un utilisateur pour inscrire des jeux de données.

    Exemple :

    EXEC DBMS_CLOUD_LINK_ADMIN.REVOKE_REGISTER('DB_USER1');

    Cette action révoque les privilèges permettant d'inscrire des jeux de données pour l'utilisateur, DB_USER1.

    L'exécution de DBMS_CLOUD_LINK_ADMIN.REVOKE_REGISTER n'a aucune incidence sur les ensembles de données déjà inscrits. Utilisez DBMS_CLOUD_LINK.UNREGISTER pour enlever l'accès à un ensemble de données inscrit.

    Pour plus d'informations, reportez-vous à Procédure REVOKE_REGISTER et à Procédure UNREGISTER.

  2. En tant qu'utilisateur ADMIN, révoquez l'accès aux ensembles de données inscrits.

    Exemple :

    EXEC DBMS_CLOUD_LINK_ADMIN.REVOKE_READ('LWARD');

    Cette action révoque l'accès aux ensembles de données de liens cloud pour l'utilisateur LWARD.

    Pour plus d'informations, reportez-vous à REVOKE_READ Procédure.

Inscrire un ensemble de données

Décrit les options et les étapes permettant d'inscrire une table ou d'afficher en tant qu'ensemble de données enregistré à partager avec les liens cloud.

Enregistrer ou annuler l'enregistrement d'un jeu de données

Vous pouvez enregistrer une table ou une vue dont vous êtes propriétaire en tant qu'ensemble de données enregistré. Lorsque vous souhaitez supprimer ou remplacer le jeu de données, vous devez le désinscrire. Après avoir enregistré un jeu de données, vous pouvez modifier les valeurs des attributs d'un jeu de données.

L'inscription d'ensemble de données définit un espace de noms et un nom à utiliser avec les liens cloud. Après l'inscription du jeu de données, ces valeurs indiquent ensemble le nom qualifié complet (FQN) pour l'accès distant et permettent aux liens cloud de gérer l'accessibilité du jeu de données.

Pour enregistrer un jeu de données :

  1. Obtenez les privilèges d'octroi d'inscription auprès de l'utilisateur ADMIN.
  2. Enregistrez un ou plusieurs jeux de données.

    Par exemple, en supposant qu'il existe un schéma CLOUDLINK sur votre instance Autonomous Database, vous pouvez inscrire deux objets, SALES_VIEW_AGG et SALES_ALL, et fournir des paramètres scope différents pour déterminer le mode d'accès aux objets.

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

    Les paramètres sont les suivants :

    • schema_name : nom du schéma (propriétaire de l'objet).

    • schema_object : nom de l'objet. Les objets valides sont :

      Remarque

      Les autres objets tels que les vues analytiques ou les synonymes ne sont pas pris en charge.
    • namespace : espace de noms fourni en tant que nom d'accès avec les liens cloud (une partie du nom qualifié complet de lien cloud).

      Une valeur NULL indique une valeur namespace générée par le système, unique pour l'instance Autonomous Database.

    • name : nom que vous indiquez pour l'accès avec les liens cloud (une partie du nom qualifié complet de lien cloud).

    • description : indique le texte décrivant les données.

    • scope : indique la portée. Vous pouvez utiliser l'une des variables : MY$REGION, MY$TENANCY ou MY$COMPARTMENT, ou indiquer des OCID.

      Pour plus d'informations, reportez-vous à Portée de l'ensemble de données, contrôle d'accès et autorisation.

    • auth_required : valeur booléenne indiquant si une autorisation au niveau de la base de données est requise pour l'ensemble de données, en plus du contrôle d'accès de portée. Lorsque cette option est définie sur TRUE, le jeu de données applique une étape d'autorisation supplémentaire. Pour plus d'informations, reportez-vous à Inscription d'un ensemble de données avec autorisation requise.

    • data_set_owner : la valeur de texte indique des informations sur la personne responsable de l'ensemble de données ou un contact pour les questions relatives à l'ensemble de données. Par exemple, vous pouvez indiquer une adresse électronique pour le propriétaire du jeu de données.

    Pour plus d'informations, reportez-vous à Procédure REGISTER.

    Dans cet exemple, une fois l'inscription terminée, la portée des deux objets inscrits est différente, en fonction du paramètre de portée que vous avez fourni avec DBMS_CLOUD_LINK.REGISTER :

    • MY$TENANCY : indique la portée au niveau de la location pour REGIONAL_SALES.SALES_AGG.

    • MY$COMPARTMENT : indique la portée de niveau de compartiment la plus restrictive dans la location pour TRUSTED_COMPARTMENT.SALES.

Vous pouvez mettre à jour certaines des valeurs des attributs d'un jeu de données après avoir enregistré un jeu de données. Pour plus d'informations, voir Mettre à jour les attributs d'enregistrement de jeu de données.

Si vous souhaitez révoquer l'accès distant à un jeu de données enregistré, annulez l'enregistrement du jeu de données.

Exemple :

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

Pour plus d'informations, reportez-vous à Procédure UNREGISTER.

Remarques concernant l'enregistrement ou l'annulation de l'enregistrement d'un jeu de données

Fournit des remarques pour l'enregistrement d'un ensemble de données avec DBMS_CLOUD_LINK.REGISTER et l'annulation de l'enregistrement d'un ensemble de données avec DBMS_CLOUD_LINK.UNREGISTER.

  • Après l'inscription d'un objet, les utilisateurs peuvent avoir besoin d'attendre jusqu'à dix (10) minutes pour accéder à l'objet avec des liens cloud.

  • Lorsque vous inscrivez un ensemble de données et que vous souhaitez que les destinataires d'une région distante accèdent à l'ensemble de données, vous devez effectuer des étapes supplémentaires pour rendre l'ensemble de données disponible dans une région distante. Pour plus d'informations, reportez-vous à Inscription ou annulation de l'inscription d'un ensemble de données dans une autre région.

  • Utilisez la procédure DBMS_CLOUD_LINK.UPDATE_REGISTRATION pour modifier les attributs d'un ensemble de données existant.

    Le temps d'attente de la mise à jour peut aller jusqu'à 10 minutes pour qu'une modification d'inscription soit propagée et accessible via les liens cloud. Ce délai peut avoir un impact sur l'exactitude des données dans les vues DBA_CLOUD_LINK_REGISTRATIONS et DBA_CLOUD_LINK_ACCESS.

  • Vous pouvez inscrire une table ou une vue qui réside dans le schéma d'un autre utilisateur lorsque vous disposez des privilèges READ WITH GRANT OPTION pour la table ou la vue.

  • Autonomous Database n'effectue pas de vérifications de validité hiérarchique au moment de l'inscription et les inscriptions en dehors de la portée ne seront jamais visibles ni accessibles.

    Voici un exemple de séquence :

    1. Un utilisateur avec la portée MY$COMPARTMENT inscrit un objet avec une portée qui indique un OCID de base de données individuel.

    2. Lorsqu'un utilisateur demande l'accès à l'ensemble de données inscrit, Autonomous Database effectue la vérification pour vérifier que l'OCID de base de données de la base de données d'où provient la demande figure dans la liste d'OCID indiquée avec scope lors de l'inscription de l'ensemble de données.

    3. Après cela, l'objet namespace.name sera repérable, visible et utilisable dans la base de données d'origine de la demande.

  • La propagation complète de DBMS_CLOUD_LINK.UNREGISTER peut prendre jusqu'à dix (10) minutes, après quoi les données peuvent être consultées à distance.

Enregistrer ou annuler l'enregistrement d'un jeu de données dans une autre région

Vous pouvez utiliser des liens cloud dans plusieurs régions, où la région source contient la base de données source de l'ensemble de données et où des régions distantes contiennent des clones actualisables de la base de données source.

La description de cloud-links-cross-region-refreshable-clone.png suit
Description de l'image cloud-links-cross-region-refreshable-clone.png

Pour utiliser des liens cloud avec un ensemble de données dans une autre région, procédez comme suit :

  1. Créez un clone actualisable inter-région de la base de données source dans une région distante.

    Pour plus d'informations sur l'ajout d'un clone actualisable inter-région, reportez-vous à Création d'un clone actualisable inter-locations ou inter-région.

  2. Sur la base de données source, enregistrez le jeu de données.

    Pour plus d'informations, reportez-vous à Inscription ou désinscription d'un ensemble de données.

  3. Actualisez le clone actualisable.

    Pour plus d'informations, reportez-vous à Actualisation d'un clone actualisable sur Autonomous Database.

  4. Sur le clone actualisable distant, enregistrez le jeu de données en utilisant les mêmes arguments que ceux utilisés pour inscrire le jeu de données dans la région source.

    Par exemple, en supposant qu'il existe un schéma CLOUDLINK sur votre instance Autonomous Database, une fois que vous avez inscrit SALES_ALL sur la base de données source, inscrivez SALES_ALL sur le clone actualisable :

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

    Les paramètres sont les suivants :

    • schema_name : nom du schéma (propriétaire de l'objet).

    • schema_object : nom de l'objet. Les objets valides sont :

      • Tables (y compris la portion de mémoire, externe ou hybride)
      • vues
      • Vues matérialisées
      Remarque

      Les autres objets tels que les vues analytiques ou les synonymes ne sont pas pris en charge.
    • namespace : espace de noms fourni en tant que nom d'accès avec les liens cloud (une partie du nom qualifié complet de lien cloud).

      Une valeur NULL indique une valeur namespace générée par le système, unique pour l'instance Autonomous Database.

    • name : nom que vous indiquez pour l'accès avec les liens cloud (une partie du nom qualifié complet de lien cloud).

    • description : indique le texte décrivant les données.

    • scope : indique la portée. Vous pouvez utiliser l'une des variables : MY$REGION, MY$TENANCY ou MY$COMPARTMENT, ou indiquer des OCID.

      Pour plus d'informations, reportez-vous à Portée de l'ensemble de données, contrôle d'accès et autorisation.

    • auth_required : valeur booléenne indiquant si une autorisation au niveau de la base de données est requise pour l'ensemble de données, en plus du contrôle d'accès de portée. Lorsque cette option est définie sur TRUE, le jeu de données applique une étape d'autorisation supplémentaire. Pour plus d'informations, reportez-vous à Inscription d'un ensemble de données avec autorisation requise.

    • data_set_owner : la valeur de texte indique des informations sur la personne responsable de l'ensemble de données ou un contact pour les questions relatives à l'ensemble de données. Par exemple, vous pouvez indiquer une adresse électronique pour le propriétaire du jeu de données.

    Pour plus d'informations, reportez-vous à Procédure REGISTER.

    Une fois l'inscription terminée sur le clone actualisable, la portée de l'objet inscrit est MY$COMPARTMENT : indique la portée de niveau de compartiment la plus restrictive pour mon compartiment dans ma location pour TRUSTED_COMPARTMENT.SALES.

Vous pouvez annuler l'inscription d'un ensemble de données distant uniquement dans les régions distantes, ou à la fois dans les régions distantes et dans la région source :

Pour désinscrire un ensemble de données dans une région distante et désactiver l'accès distant à l'ensemble de données, procédez comme suit :

  1. Sur le clone actualisable, désinscrivez l'ensemble de données.

    Exemple :

    BEGIN
       DBMS_CLOUD_LINK.UNREGISTER(
        namespace      => 'TRUSTED_COMPARTMENT', 
        name           => 'SALES');
    END;
    /
  2. Actualisez le clone actualisable.

    Pour plus d'informations, reportez-vous à Actualisation d'un clone actualisable sur Autonomous Database.

Pour annuler l'inscription d'un ensemble de données sur la base de données source et l'inscription de l'ensemble de données sur des clones actualisables de région distante, procédez comme suit :

  1. Sur le clone actualisable distant s'il n'y en a qu'un ou sur plusieurs clones actualisables des régions distantes s'il y en a plusieurs, désinscrivez l'ensemble de données.

    Exemple :

    BEGIN
       DBMS_CLOUD_LINK.UNREGISTER(
        namespace      => 'TRUSTED_COMPARTMENT', 
        name           => 'SALES');
    END;
    /
  2. Dans la base de données source, désinscrivez l'ensemble de données.

    Pour plus d'informations, reportez-vous à Inscription ou désinscription d'un ensemble de données.

  3. Actualisez les clones actualisables.

    Pour plus d'informations, reportez-vous à Actualisation d'un clone actualisable sur Autonomous Database.

Remarques relatives à l'enregistrement ou à l'annulation d'un jeu de données dans une région distante

Fournit des notes pour l'enregistrement d'un ensemble de données dans une région distante.

  • Lorsque vous inscrivez un ensemble de données sur un clone actualisable dans une région distante, l'appel de DBMS_CLOUD_LINK.REGISTER sur le clone de région distante doit utiliser les mêmes paramètres avec les mêmes valeurs que sur la base de données source, à l'exception du paramètre offload_targets.

    Par exemple, lorsque vous exécutez DBMS_CLOUD_LINK.REGISTER avec la portée définie sur MY$COMPARTMENT sur l'instance Autonomous Database source, exécutez à nouveau la procédure sur le clone actualisable inter-région avec la même valeur de paramètre de portée (MY$COMPARTMENT).

  • Si vous indiquez le paramètre offload_targets avec DBMS_CLOUD_LINK.REGISTER sur la source, vous devez omettre ce paramètre lors de l'inscription de l'ensemble de données sur le clone actualisable.

  • Après l'inscription d'un objet, les utilisateurs peuvent avoir besoin d'attendre jusqu'à dix (10) minutes pour accéder à l'objet avec des liens cloud.

  • Les actions suivantes nécessitent l'actualisation du clone actualisable :

    • Si vous ajoutez une stratégie VPD à l'ensemble de données de la source, vous devez actualiser le clone actualisable.

    • Si vous effectuez une autorisation ou une révocation pour l'ensemble de données sur la base de données source, vous devez actualiser le clone actualisable.

    Pour plus d'informations, reportez-vous à Actualisation d'un clone actualisable sur Autonomous Database.

Enregistrement d'un jeu de données avec autorisation requise

Lorsque vous inscrivez un ensemble de données, en plus de la portée, vous pouvez indiquer que l'autorisation au niveau de la base de données est requise pour accéder à un ensemble de données.

Par rapport à l'exemple précédent où vous avez défini auth_required sur FALSE, dans cet exemple, vous avez défini auth_required sur TRUE. Lorsque auth_required est défini sur TRUE, des étapes supplémentaires sont requises pour indiquer des bases de données à partir desquelles l'accès à l'ensemble de données est autorisé.

Remarque

Vous pouvez uniquement accorder une autorisation, comme indiqué dans ces étapes, si vous y êtes autorisé. L'utilisateur ADMIN accorde des privilèges d'autorisation avec DBMS_CLOUD_LINK_ADMIN.GRANT_AUTHORIZE.
  1. Utilisez DBMS_CLOUD_LINK.REGISTER pour inscrire des données avec l'autorisation requise.

    En supposant qu'il existe un schéma CLOUDLINK sur votre instance Autonomous Database, que vous inscrivez l'objet SALES_VIEW_AGG et que vous définissez auth_required sur TRUE, vous devez effectuer des étapes supplémentaires pour déterminer le mode d'accès à l'objet, en plus de définir la portée.

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

    Les paramètres sont les suivants :

    • schema_name : nom du schéma (propriétaire de l'objet).

    • schema_object : nom de l'objet. Les objets valides sont :

      • Tables (y compris la portion de mémoire, externe ou hybride)
      • vues
      • Vues matérialisées
      Remarque

      Les autres objets tels que les vues analytiques ou les synonymes ne sont pas pris en charge.
    • namespace : espace de noms fourni en tant que nom d'accès avec les liens cloud (une partie du nom qualifié complet de lien cloud).

      Une valeur NULL indique une valeur namespace générée par le système, unique pour l'instance Autonomous Database.

    • name : nom que vous indiquez pour l'accès avec les liens cloud (une partie du nom qualifié complet de lien cloud).

    • scope : indique la portée. Vous pouvez utiliser l'une des variables : MY$REGION, MY$TENANCY ou MY$COMPARTMENT, ou indiquer des OCID.

      Pour plus d'informations, reportez-vous à Portée de l'ensemble de données, contrôle d'accès et autorisation.

    • auth_required : valeur booléenne indiquant si une autorisation au niveau de la base de données est requise pour l'ensemble de données, en plus du contrôle d'accès de portée. Lorsque cette option est définie sur TRUE, le jeu de données applique une étape d'autorisation supplémentaire.

    • data_set_owner : la valeur de texte indique des informations sur la personne responsable de l'ensemble de données ou un contact pour les questions relatives à l'ensemble de données. Par exemple, vous pouvez indiquer une adresse électronique pour le propriétaire du jeu de données.

  2. Obtenez l'ID de la base de données à laquelle vous voulez accorder l'autorisation (pour permettre à la base de données d'accéder à l'ensemble de données).

    Sur le système, vous souhaitez accorder l'accès à l'ensemble de données :

    SELECT DBMS_CLOUD_LINK.GET_DATABASE_ID FROM DUAL:
  3. Utilisez l'ID de base de données obtenu pour accorder l'autorisation à un ensemble de données donné.

    Vous pouvez uniquement accorder l'autorisation et exécuter DBMS_CLOUD_LINK.GRANT_AUTHORIZATION, comme indiqué dans cette étape, si vous y êtes autorisé. L'administrateur accorde l'autorisation avec DBMS_CLOUD_LINK_ADMIN.GRANT_AUTHORIZE.

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

    Effectuez ces étapes plusieurs fois si vous souhaitez autoriser des bases de données supplémentaires.

Vous pouvez mettre à jour la valeur du paramètre auth_required après avoir inscrit un ensemble de données. Pour plus d'informations, voir Mettre à jour les attributs d'enregistrement de jeu de données.

Pour révoquer l'autorisation d'une base de données :

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

Pour plus d'informations, reportez-vous à :

Enregistrer un jeu de données avec des cibles de déchargement pour l'accès aux jeux de données

Lorsque vous inscrivez un ensemble de données, vous pouvez éventuellement décharger l'accès à l'ensemble de données sur des instances Autonomous Database qui sont des clones actualisables.

Utilisez le paramètre facultatif offload_targets avec DBMS_CLOUD_LINK.REGISTER pour indiquer que l'accès est déchargé pour les clones actualisables. La base de données source de chaque clone actualisable est l'instance Autonomous Database dans laquelle vous inscrivez l'ensemble de données (éditeur de données).

La valeur offload_targets est un document JSON qui définit des paires de valeurs de clé CLOUD_LINK_DATABASE_ID et OFFLOAD_TARGET :

  • CLOUD_LINK_DATABASE_ID est l'un des éléments suivants :

    • ID de base de données : indique un ID de base de données pour le consommateur de jeu de données dont la demande est déchargée vers le clone actualisable correspondant indiqué avec la valeur OFFLOAD_TARGET.

      Obtenez l'ID de base de données en exécutant DBMS_CLOUD_LINK.GET_DATABASE_ID. Pour plus d'informations, reportez-vous à Fonction GET_DATABASE_ID.

    • ANY : indique que toute demande du consommateur de jeu de données est déchargée vers la cible de déchargement correspondante. La demande d'ensemble de données d'un consommateur est acheminée vers la cible de déchargement correspondante.

      Si vous indiquez ANY sans indiquer d'ID de base de données, toutes les demandes d'ensemble de données des destinataires sont déchargées vers le clone actualisable indiqué avec la valeur OFFLOAD_TARGET.

      Si vous indiquez à la fois des ID de base de données et ANY, les demandes d'ensemble de données provenant de destinataires qui ne correspondent pas à un ID de base de données sont déchargées vers le clone actualisable indiqué avec la valeur OFFLOAD_TARGET.

  • OFFLOAD_TARGET est l'OCID d'une instance Autonomous Database en tant que clone actualisable.

La figure suivante illustre l'utilisation des cibles de déchargement.

Lorsqu'un destinataire d'ensemble de données demande l'accès à un ensemble de données que vous inscrivez auprès de offload_targets et que l'ID de base de données de l'instance Autonomous Database correspond à la valeur indiquée dans CLOUD_LINK_DATABASE_ID, l'accès est déchargé vers le clone actualisable identifié par OFFLOAD_TARGET dans le fichier JSON fourni.

Par exemple, l'exemple suivant présente un échantillon JSON avec trois paires de valeurs OFFLOAD_TARGET/CLOUD_LINK_DATABASE_ID :

{
  "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"
    }
  ]
}

Lorsqu'un destinataire d'ensemble de données demande l'accès à un ensemble de données inscrit auprès de offload_targets qui inclut le mot-clé ANY, l'accès est déchargé vers le clone actualisable identifié par OFFLOAD_TARGET dans le fichier JSON fourni (à l'exception des demandes des destinataires qui ont une entrée d'ID de base de données correspondante dans le fichier JSON fourni).

Par exemple, l'exemple suivant présente un échantillon JSON avec une paire de valeurs OFFLOAD_TARGET/CLOUD_LINK_DATABASE_ID explicite et une valeur ANY avec une valeur OFFLOAD_TARGET correspondante :

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

Pour enregistrer un ensemble de données et indiquer des cibles de déchargement, procédez comme suit :

  1. Obtenez l'OCID de clones actualisables pour lesquels vous voulez décharger l'accès au jeu de données. Les OCID de clone actualisable sont disponibles sur la console Oracle Cloud Infrastructure sur un clone actualisable.
    Remarque

    La création d'un clone actualisable peut prendre jusqu'à 10 minutes pour que le clone actualisable soit visible en tant que cible de déchargement. Cela signifie que vous devrez peut-être attendre jusqu'à 10 minutes après avoir créé un clone actualisable pour que le clone actualisable soit disponible pour l'inscription de déchargement de Cloud Links.
  2. Obtenez l'ID de base de données pour les instances Autonomous Database auxquelles accéder à l'ensemble de données à l'aide des données fournies par le clone actualisable.

    Sur le système auquel vous souhaitez accéder à l'ensemble de données à partir d'un clone actualisable, exécutez la commande suivante :

    SELECT DBMS_CLOUD_LINK.GET_DATABASE_ID FROM DUAL:
  3. Inscrivez un ensemble de données et indiquez le paramètre offload_targets.

    Par exemple, en supposant qu'il existe un schéma CLOUDLINK sur votre instance Autonomous Database, vous pouvez inscrire SALES_VIEW_AGG et indiquer les clones actualisables qui fournissent l'accès à l'ensemble de données :

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

    Les paramètres sont les suivants :

    • schema_name : nom du schéma (propriétaire de l'objet).

    • schema_object : nom de l'objet. Les objets valides sont :

      • Tables (y compris la portion de mémoire, externe ou hybride)
      • vues
      • Vues matérialisées
      Remarque

      Les autres objets tels que les vues analytiques ou les synonymes ne sont pas pris en charge.
    • namespace : espace de noms fourni en tant que nom d'accès avec les liens cloud (une partie du nom qualifié complet de lien cloud).

      Une valeur NULL indique une valeur namespace générée par le système, unique pour l'instance Autonomous Database.

    • name : nom que vous indiquez pour l'accès avec les liens cloud (une partie du nom qualifié complet de lien cloud).

    • scope : indique la portée. Vous pouvez utiliser l'une des variables : MY$REGION, MY$TENANCY ou MY$COMPARTMENT, ou indiquer des OCID.

      Pour plus d'informations, reportez-vous à Portée de l'ensemble de données, contrôle d'accès et autorisation.

    • auth_required : valeur booléenne indiquant si une autorisation au niveau de la base de données est requise pour l'ensemble de données, en plus du contrôle d'accès de portée. Lorsque cette option est définie sur TRUE, le jeu de données applique une étape d'autorisation supplémentaire. Pour plus d'informations, reportez-vous à Inscription d'un ensemble de données avec autorisation requise.

    • data_set_owner : la valeur de texte indique des informations sur la personne responsable de l'ensemble de données ou un contact pour les questions relatives à l'ensemble de données. Par exemple, vous pouvez indiquer une adresse électronique pour le propriétaire du jeu de données.

    • offload_targets : indique des OCID Autonomous Database de clones actualisables où l'accès aux ensembles de données est déchargé, à partir de l'instance Autonomous Database où l'ensemble de données est inscrit.

      Pour chaque consommateur de jeu de données, l'un des éléments suivants peut correspondre pour décharger la demande vers un clone actualisable :

      • Lorsqu'il existe une correspondance avec la valeur de cloud_link_database_id indiquée, c'est-à-dire que les valeurs correspondent à l'ID de base de données du destinataire, l'accès est déchargé vers le clone actualisable identifié par l'OCID indiqué dans offload_target.

      • Lorsque le mot-clé ANY est indiqué, s'il n'y a pas de correspondance avec la valeur d'un élément cloud_link_database_id indiqué, l'accès est déchargé vers le clone actualisable identifié par l'entrée ANY par l'OCID indiqué dans l'élément offload_target correspondant.

    Pour plus d'informations, reportez-vous à :

Mettre à jour les attributs d'enregistrement du jeu de données

Après avoir enregistré un jeu de données, vous pouvez mettre à jour certains attributs de jeu de données. Vous ne pouvez pas mettre à jour le nom de schéma, l'objet de schéma, l'espace de noms ou les attributs de nom.

Pour mettre à jour des attributs de jeu de données :

  1. L'utilisateur qui a inscrit un ensemble de données peut mettre à jour ses attributs avec DBMS_CLOUD_LINK.UPDATE_REGISTRATION.

    Si vous ne disposez pas des privilèges requis pour mettre à jour les attributs de jeu de données, vous devez obtenir les privilèges d'octroi de registre auprès de l'utilisateur ADMIN.

    Pour plus d'informations, reportez-vous à Octroi de l'accès aux liens cloud aux utilisateurs de base de données.

  2. Mettez à jour un ou plusieurs attributs pour un ensemble de données.

    Par exemple, utilisez DBMS_CLOUD_LINK.UPDATE_REGISTRATION pour mettre à jour les attributs description, scope et auth_required de l'ensemble de données dans l'espace de noms REGIONAL_SALES avec le nom 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;
    /

    Les paramètres requis sont les suivants :

    • namespace : espace de noms de l'ensemble de données que vous avez fourni lors de l'inscription de l'ensemble de données.

    • name : nom de l'ensemble de données que vous avez fourni lors de l'inscription de l'ensemble de données.

    Vous trouverez ci-dessous la liste des paramètres facultatifs. Si NULL est transmis pour une valeur de paramètre facultative, l'attribut n'est pas modifié.

    • description : indique le texte mis à jour pour décrire les données.

    • scope : indique la portée. Vous pouvez utiliser l'une des variables suivantes : MY$REGION, MY$TENANCY ou MY$COMPARTMENT, ou indiquer des OCID.

      Pour plus d'informations, reportez-vous à Portée de l'ensemble de données, contrôle d'accès et autorisation.

    • auth_required : valeur booléenne qui indique si une autorisation de niveau base de données est requise pour l'ensemble de données, en plus du contrôle d'accès de portée. Lorsque cette valeur est définie sur TRUE, l'ensemble de données applique une étape d'autorisation supplémentaire. Pour plus d'informations, reportez-vous à Inscription d'un ensemble de données avec autorisation requise.

    • data_set_owner : la valeur de texte indique des informations sur la personne responsable de l'ensemble de données ou un contact pour les questions sur l'ensemble de données. Par exemple, vous pouvez indiquer une adresse électronique pour le propriétaire du jeu de données.

    • offload_targets : indique des OCID Autonomous Database de clones actualisables dans lesquels l'accès aux ensembles de données est déchargé, à partir de l'instance Autonomous Database où l'ensemble de données est inscrit. Pour plus d'informations, reportez-vous à Inscription d'un ensemble de données avec des cibles de déchargement pour l'accès à l'ensemble de données.

    Vous ne pouvez pas mettre à jour les attributs schema_name ou schema_object.

    Pour plus d'informations, reportez-vous à Procédure UPDATE_REGISTRATION.

Lorsqu'un ensemble de données est inscrit dans un ou plusieurs clones actualisables inter-région, toute modification apportée à l'inscription dans la base de données source doit être propagée vers les régions distantes.

Pour propager les modifications vers des clones actualisables inter-région, procédez comme suit :

  • Si un fournisseur de portlets dispose de N clones actualisables inter-région dans une région, par exemple dans la région A, exécutez DBMS_CLOUD_LINK.UPDATE_REGISTRATION sur exactement un clone actualisable dans la région A.

  • Si le même fournisseur dispose de M clones actualisables inter-région dans une autre région distante, par exemple dans la région B, exécutez DBMS_CLOUD_LINK.UPDATE_REGISTRATION sur exactement un clone actualisable dans la région B.

Pour mettre à jour des attributs lorsqu'un jeu de données est enregistré dans un ou plusieurs clones actualisables inter-région, procédez comme suit :

  1. Dans la base de données source, mettez à jour l'inscription du jeu de données.

  2. Sur un clone actualisable distant dans la région distante s'il n'existe qu'une seule région distante, ou sur un clone actualisable distant dans chaque région distante s'il existe des clones actualisables répliqués dans plusieurs régions, mettez à jour l'inscription de l'ensemble de données avec les mêmes valeurs que celles utilisées pour mettre à jour la base de données source, à l'exception du paramètre offload_targets.

    Dans une région distante donnée, vous n'avez besoin d'exécuter DBMS_CLOUD_LINK.UPDATE_REGISTRATION que sur un seul clone actualisable de cette région (si plusieurs clones actualisables sont associés au même ensemble de données, vous n'avez besoin d'exécuter la procédure qu'une seule fois pour propager les modifications apportées à tous les clones actualisables d'une région distante).

  3. Actualisez les clones actualisables.

    Pour plus d'informations, reportez-vous à Actualisation d'un clone actualisable sur Autonomous Database.

Rechercher des ensembles de données et utiliser des liens cloud

Un utilisateur disposant d'un accès en lecture aux liens cloud peut rechercher des ensembles de données disponibles pour une instance Autonomous Database, et accéder aux ensembles de données inscrits et les utiliser avec ses requêtes.

Une fois que l'utilisateur ADMIN a exécuté GRANT_READ, il peut rechercher et utiliser des liens cloud.

  1. Recherchez les ensembles de données disponibles sur votre instance Autonomous Database.

    Par exemple, recherchez tous les jeux de données contenant la chaîne "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"}]

    Les paramètres sont les suivants :

    • search_string : chaîne à rechercher. La casse de la chaîne de recherche n'est pas respectée.

    • search_result : document JSON incluant les valeurs d'espace de noms, de nom et de description de l'ensemble de données.

    Pour plus d'informations, reportez-vous à Procédure FIND.

    La procédure DBMS_CLOUD_LINK.FIND fournit le nom de domaine qualifié complet que vous pouvez utiliser avec les liens cloud. Dans ce cas, FOREST.TREE_DATA.

  2. Utilisez la vue DBA_CLOUD_LINK_ACCESS pour répertorier les ensembles de données disponibles :
    SELECT * FROM DBA_CLOUD_LINK_ACCESS;
    
    NAMESPACE            NAME
    ---------            -------------- 
    FOREST               TREE_DATA 
    REGIONAL_SALES       SALES_AGG
    TRUSTED_COMPARTMENT  SALES
  3. Utilisez la procédure DBMS_CLOUD_LINK.DESCRIBE pour obtenir plus de détails sur un ensemble de données enregistré.
    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. Utilisez l'ensemble de données enregistré dans une requête.
    SELECT * FROM FOREST.TREE_DATA@cloud$link;
    Remarque

    L'inscription d'un ensemble de données auprès de DBMS_CLOUD_LINK.REGISTER peut prendre jusqu'à 10 minutes pour que l'ensemble de données soit visible et accessible.
Les liens cloud prennent en charge les synonymes privés et publics. Par exemple, vous pouvez définir et utiliser un synonyme pour 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;

Pour plus d'informations, reportez-vous à CREATE SYNONYM.

Utiliser les options de consommateur des liens cloud

Vous pouvez définir la correspondance de nom de service à utiliser pour accéder aux données à partir d'une base de données de consommateur et activer la mise en cache sur un consommateur d'ensemble de données pour les résultats d'une requête ou pour un fragment de requête qui accède aux données de lien cloud.

Définir la correspondance de nom de service de base de données pour les destinataires de liens cloud

Vous pouvez définir la correspondance de nom de service à utiliser lorsque les destinataires de liens cloud accèdent aux données à partir d'un propriétaire d'ensemble de données.

Les liens cloud s'appuient sur les ressources de base de données de l'instance Autonomous Database qui est le producteur de l'ensemble de données, ou sur les ressources d'un clone actualisable, pour accéder aux données partagées. Par défaut, la connectivité distante permettant aux destinataires d'accéder aux données Cloud Links utilise le service de base de données MEDIUM.

Utilisez DBMS_CLOUD_LINK_ADMIN.ADD_SERVICE_MAPPING pour définir la correspondance de service de base de données pour un destinataire. Dans cette procédure, vous indiquez un ID de base de données ou le mot-clé ANY pour indiquer la correspondance de service consommateur. Par exemple, la figure suivante illustre une mise en correspondance entre le consommateur A et le service HIGH, le consommateur B et le service MEDIUM, le consommateur C et le service LOW et une mise en correspondance entre ANY et le service TP, ce qui signifie que tous les autres consommateurs accèdent aux liens cloud à l'aide du service TP.



Pour plus d'informations sur les caractéristiques des services de base de données, reportez-vous à Noms de service de base de données pour Autonomous Database.

Pour définir le service de base de données à utiliser pour un destinataire Cloud Links, procédez comme suit :

  1. Obtenez l'ID de la base de données pour laquelle vous voulez définir un mappage de service.

    Sur la base de données consommateur, exécutez GET_DATABASE_ID pour obtenir l'ID de base de données du consommateur. Exemples :

    SELECT DBMS_CLOUD_LINK.GET_DATABASE_ID FROM DUAL:

    Pour plus d'informations, reportez-vous à Fonction GET_DATABASE_ID.

  2. Sur l'instance Autonomous Database du propriétaire de l'ensemble de données, indiquez une correspondance de service.

    Effectuez cette étape sur l'instance Autonomous Database du propriétaire de l'ensemble de données (c'est-à-dire sur la base de données du fournisseur).

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

    Où la valeur du paramètre database_id correspond à l'ID de base de données obtenu à l'étape 1.

    Indiquez la valeur ANY pour database_id afin d'utiliser la valeur service_name indiquée avec toutes les bases de données de destinataire qui n'ont pas de valeur service_name associée à leur valeur database_id. Autrement dit, tout élément database_id dont service_name n'a pas été défini avec DBMS_CLOUD_LINK_ADMIN.ADD_SERVICE_MAPPING.

    Pour plus d'informations, reportez-vous à Procédure ADD_SERVICE_MAPPING.

    Seuls l'utilisateur ADMIN et les schémas dotés du rôle PDB_DBA peuvent exécuter DBMS_CLOUD_LINK_ADMIN.ADD_SERVICE_MAPPING.

  3. Vérifiez les ID de base de données et le mappage de service en répertoriant les mappages de service Cloud Links.

    Exemple :

    SELECT * FROM  DBA_CLOUD_LINK_SERVICE_MAPPINGS;

    Pour plus d'informations, reportez-vous à DBA_CLOUD_LINK_SERVICE_MAPPINGS View.

Remarques relatives à la définition et à la modification des mappages de service :

  • Les mappages de service prennent effet au moment de l'établissement des connexions. Si les mappages de service d'un consommateur particulier sont modifiés, les nouveaux mappages ne prennent effet que pour les nouvelles sessions du consommateur.

  • Tout mappage de service configuré dans un propriétaire d'ensemble de données pour un destinataire spécifique est respecté même si l'accès du destinataire est déchargé vers un clone actualisable. Le clone actualisable doit être actualisé à un point dans le temps après l'heure à laquelle les mappages de service ont été configurés dans le propriétaire du jeu de données. Notez que le déchargement vers un clone actualisable est configuré avec l'argument offload_targets lors de l'inscription du jeu de données.

    Pour plus d'informations, reportez-vous à Inscription d'un ensemble de données avec des cibles de déchargement pour l'accès à l'ensemble de données.

  • Utilisez la procédure DBMS_CLOUD_LINK_ADMIN.REMOVE_SERVICE_MAPPING pour enlever une correspondance de service pour un élément database_id spécifié.

    Après l'exécution de DBMS_CLOUD_LINK_ADMIN.REMOVE_SERVICE_MAPPING, un destinataire utilise le service de base de données MEDIUM par défaut ou le service service_name que vous indiquez si vous exécutez DBMS_CLOUD_LINK_ADMIN.ADD_SERVICE_MAPPING avec la valeur database_id ANY. Pour plus d'informations, reportez-vous à Procédure REMOVE_SERVICE_MAPPING.

Définir la correspondance de nom de service de base de données pour les destinataires de liens cloud dans une région distante

Un ensemble de données inscrit dans une région source est accessible à l'aide de liens cloud à partir d'une région distante lorsque vous créez un clone actualisable inter-région dans la région distante.

Dans ce cas, les mises en correspondance de service pour les destinataires de la région distante doivent être ajoutées deux fois, dans la base de données source et dans le clone actualisable de la région distante.

Procédez comme suit pour définir les mises en correspondance de service pour les destinataires de liens cloud dans une région distante.

  1. Créez un clone actualisable inter-région de la base de données source (le clone actualisable est un clone du propriétaire de l'ensemble de données Cloud Links dans la région distante).

    Pour plus d'informations, reportez-vous à Création d'un clone actualisable inter-locations ou inter-région.

  2. Enregistrez le jeu de données.

    Pour plus d'informations, reportez-vous à Inscription d'un ensemble de données.

  3. Ajoutez les mappages de service au propriétaire du jeu de données.
  4. Actualisez le clone actualisable.

    Pour plus d'informations, reportez-vous à Actualisation d'un clone actualisable sur Autonomous Database.

  5. Sur le clone actualisable distant, enregistrez le jeu de données en utilisant les mêmes arguments que ceux utilisés pour enregistrer le jeu de données dans la région source (c'est-à-dire, utilisez les mêmes arguments que ceux utilisés à l'étape 2).
  6. Sur le clone actualisable distant, ajoutez les mappages de service en utilisant les mêmes arguments que ceux utilisés dans la région source (c'est-à-dire, utilisez les mêmes arguments que ceux utilisés à l'étape 3).

Lorsqu'un destinataire de la région distante accède aux données de liens cloud, l'accès utilise les mêmes mises en correspondance de service que celles que vous avez ajoutées dans la base de données propriétaire de l'ensemble de données de la région source.

Activation de la mise en cache pour un destinataire de lien cloud

Vous pouvez activer la mise en mémoire cache sur un consommateur d'ensemble de données pour les résultats d'une requête ou pour un fragment de requête qui accède aux données de Cloud Link.

Pour activer la mise en cache sur un consommateur de jeu de données, utilisez le conseil RESULT_CACHE avec l'option SHELFLIFE. Avec l'option SHELFLIFE, vous indiquez une valeur indiquant la durée, en secondes, pendant laquelle un résultat de requête est mis en mémoire cache. Une fois l'intervalle SHELFLIFE dépassé, le résultat mis en cache est marqué comme non valide. Tant que le résultat mis en mémoire cache est valide, une requête extrait les données mises en mémoire cache de la base de données du destinataire, ce qui évite un aller-retour vers la base de données du propriétaire de l'ensemble de données.

Utilisez le conseil RESULT_CACHE avec l'option SHELFLIFE lorsque l'ensemble de données est statique ou lorsque le consommateur peut tolérer des résultats obsolètes. La valeur de SHELFLIFE permet au consommateur de jeu de données Cloud Link de contrôler l'heure, en secondes, à laquelle les données du cache sont valides (le degré acceptable d'intégrité).

Si le résultat de la requête est volumineux et ne tient pas dans la mémoire, vous pouvez utiliser le conseil RESULT_CACHE avec l'option SHELFLIFE et l'option TEMP pour indiquer que le résultat doit être écrit sur le disque dans le tablespace temporaire.

Pour mettre en cache les données de liaison cloud avec le conseil RESULT_CACHE, procédez comme suit :

  1. Dans une requête, indiquez le conseil RESULT_CACHE avec l'option SHELFLIFE.

    Exemples :

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

    Cette valeur RESULT_CACHE indique une valeur SHELFLIFE de 120. Cela indique que le résultat doit être mis en mémoire cache pendant 120 secondes. Au bout de 120 secondes, le résultat mis en cache est marqué comme non valide.

    La valeur SHELFLIFE doit être un entier positif. La valeur maximale de SHELFLIFE est 4294967295.

  2. Si le résultat de la requête est volumineux et ne tient pas dans la mémoire, utilisez les options SHELFLIFE et TEMP pour indiquer que le résultat doit être écrit sur le disque dans le tablespace temporaire.
    SELECT /*+ RESULT_CACHE (TEMP=true SHELFLIFE=360) */ * FROM FOREST.TREE_DATA@cloud$link;

Pour plus d'informations sur l'utilisation du cache de résultats avec Autonomous Database, reportez-vous à RESULT_CACHE_MODE.

Reportez-vous à RESULT_CACHE Conseil pour plus d'informations sur RESULT_CACHE avec SHELFLIFE.

Reportez-vous à DBMS_RESULT_CACHE pour plus d'informations sur les procédures de gestion du cache de résultats et d'invalidation des objets dans le cache de résultats.

Surveillance et affichage des informations sur les liens cloud

Autonomous Database fournit des vues qui vous permettent de surveiller et d'auditer les liens cloud.

Visualiser Description
Vues V$CLOUD_LINK_ACCESS_STATS et GV$CLOUD_LINK_ACCESS_STATS

Permet de suivre l'accès à chaque ensemble de données inscrit sur l'instance Autonomous Database. Ces vues permettent de suivre le temps écoulé, le temps CPU, le nombre de lignes extraites et des informations supplémentaires sur les ensembles de données enregistrés. Vous pouvez utiliser les informations de ces vues pour auditer l'accès et l'utilisation des jeux de données Cloud Links.

Vues DBA_CLOUD_LINK_REGISTRATIONS et ALL_CLOUD_LINK_REGISTRATIONS

Permet de répertorier les détails des ensembles de données inscrits sur une instance Autonomous Database.

Vues DBA_CLOUD_LINK_ACCESS et ALL_CLOUD_LINK_ACCESS

Permet d'extraire les détails des ensembles de données enregistrés auxquels une base de données est autorisée à accéder.

DBA_CLOUD_LINK_AUTHORIZATIONS Vue

Fournit des informations sur les bases de données autorisées à accéder à quels jeux de données. Cela s'applique aux ensembles de données où le paramètre auth_required est TRUE.

Vues DBA_CLOUD_LINK_PRIVS et USER_CLOUD_LINK_PRIVS

Fournit des informations sur les privilèges propres au lien cloud, REGISTER, READ ou AUTHORIZE, accordés à tous les utilisateurs ou à l'utilisateur en cours.

DBA_CLOUD_LINK_SERVICE_MAPPINGS Vue

Affiche les détails de toutes les correspondances de service pour les bases de données consommateur Cloud Links. Chaque mise en correspondance de service se compose d'un ID de base de données Cloud Link et d'un service de base de données.

Définition d'une stratégie de base de données privée virtuelle pour sécuriser un ensemble de données inscrit

En définissant des stratégies de base de données privée virtuelle (VPD) pour un ensemble de données inscrit, vous pouvez fournir un contrôle d'accès de lien cloud affiné de sorte que seul un sous-ensemble de données (lignes) soit visible pour des sites distants spécifiques.

Oracle Virtual Private Database (VPD) est une fonctionnalité de sécurité qui vous permet de contrôler l'accès aux données de manière dynamique au niveau ligne pour les utilisateurs et les applications en appliquant des filtres sur le même ensemble de données.

Tout utilisateur disposant d'un accès en lecture aux liens cloud peut accéder aux jeux de données enregistrés et les utiliser s'ils sont dans la portée indiquée lors de l'inscription du jeu de données. Si le paramètre d'autorisation supplémentaire requis est défini pour le jeu de données, l'accès provient d'une base de données autorisée. Chaque accès distant est effectué dans le contexte de l'instance Autonomous Database distante accédant à l'ensemble de données inscrit (sur la base de données dans laquelle l'ensemble de données a été inscrit).

Utilisez la fonction DBMS_CLOUD_LINK.GET_DATABASE_ID sur le système distant pour obtenir l'ID unique de la base de données. En définissant une stratégie VPD sur la base de données qui a inscrit un ensemble de données, vous pouvez désormais utiliser l'identificateur de la base de données distante en tant que règle SYS_CONTEXT pour fournir un contrôle plus précis. Vous pouvez définir des règles pour les bases de données distantes accédant à votre ensemble de données inscrites et limiter l'accès au-delà de ce qui est possible en indiquant une portée de lien cloud.

Prenons un exemple où REGIONAL_SALES.SALES_AGG est rendu disponible au niveau de la location. Si vous souhaitez restreindre l'accès à toutes les bases de données à l'exception d'une base de données spécifique, en autorisant uniquement l'accès complet à la base de données indiquée, vous pouvez ajouter une stratégie VPD sur l'ensemble de données inscrit.

Exemples :

  1. Obtenez l'ID de base de données de lien cloud unique pour l'instance Autonomous Database où vous voulez fournir un accès complet.
    DECLARE
         DB_ID NUMBER;
     BEGIN
         DB_ID := DBMS_CLOUD_LINK.GET_DATABASE_ID;
         DBMS_OUTPUT.PUT_LINE('Database ID:' || DB_ID);
     END;
     /
  2. Créez une stratégie VPD sur la base de données qui a enregistré le jeu de données en autorisant uniquement l'accès complet à la base de données spécifique dont vous avez obtenu l'identificateur sur la base de données en question à l'étape 1.
    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;
    /

    Pour plus d'informations, reportez-vous à DBMS_RLS.

  3. Enregistrez la stratégie VPD pour le jeu de données inscrit afin de limiter l'accès complet à la base de données identifiée à l'étape 1 uniquement.
    
    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;
    /

    Pour plus d'informations, reportez-vous à DBMS_RLS.

Remarques relatives aux liens cloud

Fournit des remarques et des restrictions concernant l'utilisation des liens cloud.

  • Le nombre de jeux de données que vous pouvez enregistrer est limité à 4096.

    Chaque instance Autonomous Database ne peut pas inscrire plus de 4096 ensembles de données. Cette limite s'applique à chaque instance Autonomous Database, quel que soit le nombre d'OCPU (si votre base de données utilise des OCPU) ou la taille de stockage de l'instance. La limite est une valeur fixe et le fait de définir le nombre d'ECPU sur une valeur supérieure ne vous permet pas d'enregistrer davantage de jeux de données.

  • Vous pouvez inscrire un objet dans un autre schéma si vous disposez du privilège READ WITH GRANT OPTION sur l'objet.

  • Pour enregistrer des jeux de données ou consulter et accéder à des jeux de données distants, vous devez disposer du privilège approprié pour enregistrer ou lire des jeux de données. Cela est également vrai pour ADMIN, mais ADMIN peut s'accorder ce privilège.

  • Pour utiliser DBMS_CLOUD_LINK.REGISTER ou DBMS_CLOUD_LINK.UPDATE_REGISTRATION, vous devez disposer du privilège d'exécution sur le package DBMS_CLOUD_LINK, en plus du privilège d'inscription affecté à DBMS_CLOUD_LINK_ADMIN.GRANT_REGISTER. Seuls l'utilisateur ADMIN et les schémas avec PDB_DBA disposent de ce privilège par défaut.

  • Si vous supprimez et recréez une table qui a été enregistrée, vous devez la réenregistrer pour l'accès distant.

  • Seuls l'utilisateur ADMIN et les utilisateurs dotés du rôle PDB_DBA sont autorisés à accéder aux vues suivantes :

    • DBA_CLOUD_LINK_ACCESS

    • DBA_CLOUD_LINK_REGISTRATIONS

    • DBA_CLOUD_LINK_AUTHORIZATIONS

    • DBA_CLOUD_LINK_PRIVS

    Pour plus d'informations, reportez-vous à DBMS_CLOUD_LINK Vues.

  • Pour accéder aux données distantes enregistrées, la base de données distante doit être ouverte. Si la base de données distante est fermée ou en mode restreint, vous ne pourrez pas accéder aux données et une erreur Oracle sera renvoyée.

  • Il existe un maximum de quatre liens de base de données ouverts par session. Le dépassement de cette limite peut entraîner ORA-02020 ou ORA-12545.

  • Si le cache de résultats est activé, comme le comportement par défaut dans Autonomous Database avec la charge globale d'entrepôt de données, vous devez vous assurer que le cache de résultats n'est pas utilisé lorsque des données en temps réel sont requises.

  • Lorsque vous mettez à jour votre type de licence de Gratuit à Payant, vous devez réinscrire les ensembles de données Cloud Links. Pour plus d'informations, reportez-vous à Mise à jour d'une instance Toujours gratuit vers la version payante avec Autonomous Database.

  • La connectivité distante Cloud Links utilise par défaut le service de base de données MEDIUM. Vous pouvez modifier la valeur par défaut avec DBMS_CLOUD_LINK_ADMIN.ADD_SERVICE_MAPPING en utilisant ANY comme valeur pour DATABASE_ID. Vous pouvez modifier le service de base de données d'un destinataire avec DBMS_CLOUD_LINK_ADMIN.ADD_SERVICE_MAPPING en indiquant DATABASE_ID. Pour plus d'informations, reportez-vous à Définition de la correspondance de nom de service de base de données pour les destinataires de liens cloud.

    Vous pouvez voir les connexions distantes en tant qu'utilisateur C##DATA$SHARE dans V$SESSION et les vues de liens cloud V$CLOUD_LINK_ACCESS_STATS et vues GV$CLOUD_LINK_ACCESS_STATS fournissent plus de détails sur les connexions distantes.

  • Toutes les interfaces sont sensibles à la casse, sauf indication contraire, comme suit :

    • Tout ce que vous saisissez qui existe dans la base de données, par exemple les noms d'utilisateur et les noms de table, est significatif et doit être saisi en majuscules.
    • Les variables prédéfinies, par exemple les valeurs de portée prédéfinies, doivent être saisies en majuscules.
    • Tout ce que vous spécifiez pour la configuration des liens cloud, par exemple les espaces de noms ou les noms des tables dans un espace de noms, doit être indiqué tel qu'il a été saisi. Par exemple, si vous définissez un espace de noms en tant que trees, vous devez placer l'espace de noms entre guillemets doubles, en tant que "trees", lorsque vous y accédez avec SQL.
  • Vous pouvez partager des liens cloud lorsqu'un ensemble de données réside sur une instance Autonomous Database en mode Lecture seule. Pour plus d'informations, reportez-vous à Utilisation de liens cloud à partir d'une instance Autonomous Database en lecture seule.

  • La création d'un clone actualisable peut prendre jusqu'à 10 minutes pour que le clone actualisable soit visible en tant que cible de déchargement. Cela signifie que vous devrez peut-être attendre jusqu'à 10 minutes après avoir créé un clone actualisable pour que le clone actualisable soit disponible pour l'inscription de déchargement de Cloud Links.

    Pour plus d'informations, reportez-vous à Inscription d'un ensemble de données avec des cibles de déchargement pour l'accès à l'ensemble de données et à Création d'un clone actualisable pour une instance Autonomous Database.

Utilisation de liens cloud à partir d'une instance Autonomous Database en lecture seule

Vous pouvez partager des liens cloud lorsqu'un ensemble de données réside sur une instance Autonomous Database en lecture seule.

Pour partager des liens cloud à partir d'une instance Autonomous Database en mode lecture seule, procédez comme suit :
  1. Modifiez le mode de base de données en lecture/écriture.
  2. Lorsque la base de données est en mode lecture/écriture, procédez comme suit pour enregistrer un ensemble de données.
    1. Accorder l'accès aux liens cloud aux utilisateurs de base de données
    2. Inscrire ou désinscrire un jeu de données
  3. Une fois que vous avez inscrit des jeux de données, faites passer la base de données en mode lecture seule.