Mediante los enlaces a la nube, un propietario de datos registra una tabla o vista para el acceso remoto de un público seleccionado, según lo definido por el propietario de los datos. Los datos se ponen a disposición de aquellos con acceso otorgado en el momento del registro. No se necesitan más acciones para configurar Cloud Links, y quien se supone que debe ver y acceder a sus datos puede detectar y trabajar con los datos.

La implantación de enlaces en la nube aprovecha los mecanismos de acceso de Oracle Cloud Infrastructure para que los datos sean accesibles en un ámbito específico. Ámbito indica quién puede acceder a los datos de forma remota. El ámbito se puede definir en varios niveles, incluso en la región en la que reside la base de datos, en arrendamientos individuales o en compartimentos. Además, puede especificar que la autorización para acceder a un juego de datos esté limitada a una o más instancias de Autonomous Database.

Al crear una o más clonaciones de refrescamiento entre regiones a partir de la instancia de Autonomous Database de origen (propietario del juego de datos), puede utilizar enlaces en la nube para compartir datos en varias regiones.

Los enlaces en la nube simplifican en gran medida el uso compartido de tablas o vistas en las instancias de Autonomous Database, en comparación con los mecanismos de enlace de base de datos tradicionales. Con Cloud Links puede detectar datos sin necesidad de configurar enlaces de base de datos complejos. Autonomous Database proporciona acceso transparente mediante SQL e implanta la aplicación de privilegios con el ámbito de enlaces en la nube y otorgando autorización a instancias individuales de Autonomous Database.

Cloud Links presenta los conceptos de espacios de nombres regionales y nombres de datos que se hacen accesibles de forma remota. Esto es similar a las tablas de Oracle existentes en las que hay una tabla, por ejemplo "EMP" que reside en un espacio de nombres (esquema), por ejemplo "LWARD". Solo puede haber un LWARD.EMP en la base de datos. Los enlaces en la nube proporcionan un espacio de nombres y un nombre similares en un nivel regional, que no están enlazados a una sola base de datos, pero se aplican a muchas instancias de Autonomous Database como se especifica con el ámbito y, opcionalmente, con la autorización de la base de datos.

Por ejemplo, puede registrar un juego de datos en el espacio de nombres FOREST y, por motivos de seguridad o para facilitar la nomenclatura, puede proporcionar un espacio de nombres y un nombre que no sean los nombres de objeto y esquema originales. En este ejemplo, TREE_DATA es el nombre visible del juego de datos registrado y no es necesario que este nombre sea el nombre de la tabla de origen. Además del espacio de nombres y el nombre, la palabra clave cloud$link indica a la base de datos que debe resolver el origen como un enlace en la nube.

Para acceder a un juego de datos registrado, incluya el espacio de nombres, el nombre y la palabra clave cloud$link en la cláusula FROM de una sentencia SELECT:

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

Opcionalmente, puede especificar que el acceso a un juego de datos de una o más bases de datos se descargue en una clonación de refrescamiento. Cuando se muestra una instancia de Autonomous Database de consumidor en la lista de descarga de un juego de datos, el acceso al juego de datos se dirige a la clonación de refrescamiento.

Existen varios conceptos y términos que se pueden utilizar al trabajar con enlaces en la nube:

• Juego de datos registrados (juego de datos): identifica una tabla o vista que se ha activado para el acceso remoto en una instancia de Autonomous Database. Un juego de datos registrado también indica quién tiene permiso para acceder al juego de datos (su ámbito). El registro de juegos de datos define un espacio de nombres y un nombre para su uso con enlaces de nube. Después del registro del juego de datos, estos valores especifican conjuntamente el nombre completo (FQN) para el acceso remoto y permiten que los enlaces de nube gestionen la accesibilidad del juego de datos.

• Propietario de juego de datos: especifique un propietario de juego de datos para proporcionar un punto de contacto para preguntas sobre un juego de datos.

• Ámbito: especifica quién y desde dónde se permite a un usuario acceder a un juego de datos registrado. Consulte Ámbito de juego de datos, control de acceso y autorización para obtener más información sobre el ámbito.

• OCID (identificador de Oracle Cloud): identifica un arrendamiento, compartimento o base de datos específicos. El ámbito de un juego de datos registrado se puede expresar en términos de OCID. Consulte Identificadores de recursos para obtener más información.

• Registro de datos: con el registro de datos, un usuario hace que una tabla o vista esté disponible para el acceso remoto, sujeto a las restricciones de acceso impuestas por ámbito y, opcionalmente, sujeto a un paso de autorización adicional. Puede permitir el acceso remoto con enlaces a la nube en una tabla o vista almacenada en la base de datos o en datos almacenados en el almacén de objetos.

• Detección de datos: un juego de datos registrado se puede detectar mediante consultas de texto de la base de datos. La detección solo muestra un juego de datos si hay un privilegio para acceder al juego de datos. Puede buscar un juego de datos registrado por nombre o por descripción.

• Descripción de datos: permite a un usuario recuperar una descripción o metadatos para una tabla o vista que está disponible como juego de datos registrado.

• Destinos de descarga: si lo desea, puede especificar uno o más destinos de descarga. Los destinos de descarga son clonaciones de refrescamiento que proporcionan juegos de datos de enlaces en la nube a instancias de Autonomous Database especificadas. Al especificar un destino de descarga, puede dedicar una instancia de Autonomous Database para proporcionar juegos de datos para separar la producción del desarrollo, para el rendimiento, para garantizar la seguridad o por otros motivos. Consulte Uso de clonaciones de refrescamiento con Autonomous Database para obtener más información.

Cualquier acceso a un juego de datos registrado mediante enlaces en la nube se registra con fines de auditoría. El log incluye el arrendamiento, el compartimento o la base de datos a los que se ha accedido al juego de datos, la cantidad de datos a los que se ha accedido e información adicional. Las vistas V$CLOUD_LINK_ACCESS_STATS y GV$CLOUD_LINK_ACCESS_STATS muestran información de auditoría.

• Ámbito de juego de datos, control de acceso y autorización
  Los enlaces en la nube utilizan mecanismos de acceso de Oracle Cloud Infrastructure para que los juegos de datos registrados sean accesibles y para proteger los datos con restricciones de acceso.

El usuario ADMIN otorga privilegios a los usuarios de la base de datos para registrar juegos de datos. El usuario ADMIN también otorga privilegios a los usuarios de la base de datos para acceder a los juegos de datos registrados.

1. Como usuario ADMIN, permita que un usuario registre juegos de datos en un ámbito especificado.

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

   Especifica que el usuario DB_USER1 tiene privilegios para registrar juegos de datos en un ámbito especificado, 'MY$REGION'.

   Un usuario puede consultar SYS_CONTEXT('USERENV', 'CLOUD_LINK_REGISTER_ENABLED') para comprobar si están activados para registrar juegos de datos.

   Por ejemplo, la siguiente consulta:

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

   Devuelve 'YES' o 'NO'.

   Consulte el procedimiento GRANT_REGISTER para obtener más información.

2. Como usuario ADMIN, permita que un usuario acceda a los juegos de datos registrados.

   EXEC DBMS_CLOUD_LINK_ADMIN.GRANT_READ('LWARD');

   Esto permite a LWARD acceder a juegos de datos registrados que están disponibles para la instancia de Autonomous Database.

   Un usuario puede consultar SYS_CONTEXT('USERENV', 'CLOUD_LINK_READ_ENABLED') para comprobar si está activado para el acceso READ a un juego de datos.

   Por ejemplo, la siguiente consulta:

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

   Devuelve 'YES' o 'NO'.

   Consulte el procedimiento GRANT_READ para obtener más información.

3. Durante el registro de datos, puede definir el parámetro de autorización necesaria en TRUE. Cuando la autorización necesaria es TRUE, el usuario ADMIN debe ejecutar DBMS_CLOUD_LINK_ADMIN.GRANT_AUTHORIZE para proporcionar autorización para llamar a DBMS_CLOUD_LINK.GRANT_AUTHORIZATION. Utilice DBMS_CLOUD_LINK.GRANT_AUTHORIZATION para especificar los detalles de autorización.

   Consulte Registro de un juego de datos con autorización necesaria para obtener más información.

4. Cuando la instancia de Autonomous Database tiene Database Vault activado y la tabla o vista que se va a registrar con enlaces de nube está protegida por un dominio, el propietario de la tabla o vista debe estar autorizado para el dominio como propietario de dominio antes del registro.

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

   Si el dominio que protege la tabla o vista es un dominio obligatorio, el esquema común de Autonomous Database denominado C##DATA$SHARE, que se utiliza internamente como esquema de conexión, debe estar autorizado al dominio como participante del dominio.

   Por ejemplo:

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

   Consulte Uso de Oracle Database Vault con Autonomous Database para obtener más información.

Puede registrar una tabla o ver su propiedad como un juego de datos registrado. Cuando desee eliminar o sustituir el juego de datos, debe anular su registro.

1. Obtenga privilegios de registro de otorgamiento del usuario ADMIN.

   Consulte Otorgamiento de acceso a enlaces de nube para usuarios de base de datos para obtener más información.

2. Registre uno o más juegos de datos.

   Por ejemplo, suponiendo que haya un esquema CLOUDLINK en la instancia de Autonomous Database, puede registrar dos objetos, SALES_VIEW_AGG y SALES_ALL, y proporcionar parámetros scope diferentes para determinar cómo se accede a los objetos.

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

   Los parámetros son:

   • schema_name: es el nombre del esquema (el propietario del objeto).

   • schema_object: es el nombre del objeto. Los objetos válidos son:

     • Tablas (incluidas las pilas, externas o híbridas)
     • vistas
     • Vistas Materializadas
     • Tablas en la nube (consulte Uso de tablas en la nube para almacenar información de registro y diagnóstico para obtener más información).
     Nota
     
     No están soportados otros objetos, como las vistas analíticas o los sinónimos.

   • namespace: es el espacio de nombres que proporciona como nombre para el acceso con enlaces a la nube (una parte del FQN de enlace a la nube).

     Un valor NULL especifica un valor namespace generado por el sistema, único para la instancia de Autonomous Database.

   • name: es el nombre que proporciona para acceder a los enlaces de nube (una parte del FQN de enlace de nube).

   • scope: especifica el ámbito. Puede utilizar una de las variables: MY$REGION, MY$TENANCY o MY$COMPARTMENT o especificar uno o más OCID.

     Consulte Ámbito de juego de datos, control de acceso y autorización para obtener más información.

   • auth_required: valor booleano que especifica si la autorización de nivel de base de datos es necesaria para el juego de datos, además del control de acceso de ámbito. Cuando se define en TRUE, el juego de datos aplica un paso de autorización adicional. Consulte Registro de un juego de datos con autorización necesaria para obtener más información.

   • data_set_owner: el valor de texto especifica información sobre la persona responsable del juego de datos o un contacto para preguntas sobre el juego de datos. Por ejemplo, puede proporcionar una dirección de correo electrónico para el propietario del juego de datos.

   Consulte Procedimiento REGISTER para obtener más información.

   Una vez finalizado el registro, el ámbito de estos dos objetos registrados es diferente, según el parámetro de ámbito:

   • MY$TENANCY: especifica el ámbito de nivel de arrendamiento para REGIONAL_SALES.SALES_AGG.

   • MY$COMPARTMENT: especifica el ámbito de nivel de compartimento más restrictivo para mi compartimento dentro de mi arrendamiento para TRUSTED_COMPARTMENT.SALES.

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

• Notas para registrar o anular el registro de un juego de datos
  Proporciona notas para registrar un juego de datos con DBMS_CLOUD_LINK.REGISTER y anular el registro de un juego de datos con DBMS_CLOUD_LINK.UNREGISTER.

Puede utilizar enlaces a la nube en varias regiones, donde la región de origen contiene la base de datos de origen del juego de datos y una o más regiones remotas contienen clonaciones de refrescamiento de la base de datos de origen.

Para utilizar enlaces a la nube con un juego de datos en una región diferente:

1. Cree una clonación de refrescamiento entre regiones de la base de datos origen en una región remota.

   Consulte Creación de una clonación de refrescamiento entre arrendamientos o entre regiones para obtener información sobre la adición de una clonación de refrescamiento entre regiones.

2. En la base de datos de origen, registre el juego de datos.

   Consulte Registro o anulación del registro de un juego de datos para obtener más información.

3. Refresque la clonación de refrescamiento.

   Consulte Refrescamiento de una clonación de refrescamiento en Autonomous Database para obtener más información.

4. En la clonación de refrescamiento remota, registre el juego de datos con los mismos argumentos que utilizó para registrar el juego de datos en la región de origen.

   Por ejemplo, suponiendo que haya un esquema CLOUDLINK en la instancia de Autonomous Database, después de registrar SALES_ALL en la base de datos de origen, registre SALES_ALL en la clonación de refrescamiento:

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

   Los parámetros son:

   • schema_name: es el nombre del esquema (el propietario del objeto).

   • schema_object: es el nombre del objeto. Los objetos válidos son:

     • Tablas (incluidas las pilas, externas o híbridas)
     • vistas
     • Vistas Materializadas
     Nota
     
     No están soportados otros objetos, como las vistas analíticas o los sinónimos.

   • namespace: es el espacio de nombres que proporciona como nombre para el acceso con enlaces a la nube (una parte del FQN de enlace a la nube).

     Un valor NULL especifica un valor namespace generado por el sistema, único para la instancia de Autonomous Database.

   • name: es el nombre que proporciona para acceder a los enlaces de nube (una parte del FQN de enlace de nube).

   • scope: especifica el ámbito. Puede utilizar una de las variables: MY$REGION, MY$TENANCY o MY$COMPARTMENT o especificar uno o más OCID.

     Consulte Ámbito de juego de datos, control de acceso y autorización para obtener más información.

   • auth_required: valor booleano que especifica si la autorización de nivel de base de datos es necesaria para el juego de datos, además del control de acceso de ámbito. Cuando se define en TRUE, el juego de datos aplica un paso de autorización adicional. Consulte Registro de un juego de datos con autorización necesaria para obtener más información.

   • data_set_owner: el valor de texto especifica información sobre la persona responsable del juego de datos o un contacto para preguntas sobre el juego de datos. Por ejemplo, puede proporcionar una dirección de correo electrónico para el propietario del juego de datos.

   Consulte Procedimiento REGISTER para obtener más información.

   Una vez finalizado el registro en la clonación de refrescamiento, el ámbito del objeto registrado es MY$COMPARTMENT: especifica el ámbito de nivel de compartimento más restrictivo para mi compartimento dentro de mi arrendamiento para TRUSTED_COMPARTMENT.SALES.

• Notas para registrar o anular el registro de un juego de datos en una región remota
  Proporciona notas para registrar un juego de datos en una región remota.

Opcionalmente, al registrar un juego de datos, además del ámbito, puede especificar que la autorización de nivel de base de datos es necesaria para acceder a un juego de datos.

1. Utilice DBMS_CLOUD_LINK.REGISTER para registrar datos con la autorización necesaria.

   Suponiendo que haya un esquema CLOUDLINK en la instancia de Autonomous Database y que registre el objeto SALES_VIEW_AGG y defina auth_required en TRUE, además de definir el ámbito, debe realizar pasos adicionales para determinar cómo se accede al objeto.

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

   Los parámetros son:

   • schema_name: es el nombre del esquema (el propietario del objeto).

   • schema_object: es el nombre del objeto. Los objetos válidos son:

     • Tablas (incluidas las pilas, externas o híbridas)
     • vistas
     • Vistas Materializadas
     Nota
     
     No están soportados otros objetos, como las vistas analíticas o los sinónimos.

   • namespace: es el espacio de nombres que proporciona como nombre para el acceso con enlaces a la nube (una parte del FQN de enlace a la nube).

     Un valor NULL especifica un valor namespace generado por el sistema, único para la instancia de Autonomous Database.

   • name: es el nombre que proporciona para acceder a los enlaces de nube (una parte del FQN de enlace de nube).

   • scope: especifica el ámbito. Puede utilizar una de las variables: MY$REGION, MY$TENANCY o MY$COMPARTMENT o especificar uno o más OCID.

     Consulte Ámbito de juego de datos, control de acceso y autorización para obtener más información.

   • auth_required: valor booleano que especifica si la autorización de nivel de base de datos es necesaria para el juego de datos, además del control de acceso de ámbito. Cuando se define en TRUE, el juego de datos aplica un paso de autorización adicional.

   • data_set_owner: el valor de texto especifica información sobre la persona responsable del juego de datos o un contacto para preguntas sobre el juego de datos. Por ejemplo, puede proporcionar una dirección de correo electrónico para el propietario del juego de datos.

2. Obtenga el ID de la base de datos a la que desea otorgar autorización (para permitir que la base de datos acceda al juego de datos).

   En el sistema que desea otorgar acceso al juego de datos:

   SELECT DBMS_CLOUD_LINK.GET_DATABASE_ID FROM DUAL:

3. Utilice el ID de base de datos obtenido para otorgar autorización a un juego de datos especificado.

   Solo puede otorgar autorización y ejecutar DBMS_CLOUD_LINK.GRANT_AUTHORIZATION, como se muestra en este paso, si está autorizado. El administrador otorga autorización con DBMS_CLOUD_LINK_ADMIN.GRANT_AUTHORIZE.

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

   Realice estos pasos varias veces si desea autorizar bases de datos adicionales.

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

Opcionalmente, al registrar un juego de datos, puede descargar el acceso al juego de datos en una o más instancias de Autonomous Database que sean clonaciones de refrescamiento.

Utilice el parámetro offload_targets opcional con DBMS_CLOUD_LINK.REGISTER para especificar que el acceso se descarga para refrescar las clonaciones. La base de datos de origen de cada clonación de refrescamiento es la instancia de Autonomous Database en la que registra el juego de datos (editor de datos).

El valor offload_targets es un documento JSON que define uno o más pares de valores de clave CLOUD_LINK_DATABASE_ID y OFFLOAD_TARGET:

• CLOUD_LINK_DATABASE_ID es uno de los siguientes:

  • Un ID de base de datos: especifica un ID de base de datos para el consumidor del juego de datos cuya solicitud se descarga en la clonación de refrescamiento correspondiente especificada con el valor OFFLOAD_TARGET.

    Obtenga el ID de base de datos ejecutando DBMS_CLOUD_LINK.GET_DATABASE_ID. Consulte Función GET_DATABASE_ID para obtener más información.

  • ANY: especifica que cualquier solicitud del consumidor del juego de datos se descarga en el destino de descarga correspondiente. La solicitud de juego de datos de un consumidor se enrutará al destino de descarga correspondiente.

    Si especifica ANY sin especificar identificadores de base de datos, todas las solicitudes de juego de datos de los consumidores se descargan en la clonación de refrescamiento especificada con el valor OFFLOAD_TARGET.

    Si especifica tanto los ID de base de datos como ANY, las solicitudes de juegos de datos de los consumidores que no coinciden con un ID de base de datos se descargan en la clonación de refrescamiento especificada con el valor OFFLOAD_TARGET.

• OFFLOAD_TARGET es el OCID de una instancia de Autonomous Database que es una clonación de refrescamiento.

En la siguiente figura, se muestra el uso de destinos de descarga.

Cuando un consumidor de juego de datos solicita acceso a un juego de datos que se registra con offload_targets y el ID de base de datos de la instancia de Autonomous Database coincide con el valor especificado en CLOUD_LINK_DATABASE_ID, el acceso se descarga en la clonación de refrescamiento identificada con OFFLOAD_TARGET en el JSON proporcionado.

Por ejemplo, a continuación se muestra un ejemplo de JSON con tres pares de valores 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"
    }
  ]
}

Cuando un consumidor de juego de datos solicita acceso a un juego de datos que se registra con offload_targets que incluye la palabra clave ANY, el acceso se descarga en la clonación de refrescamiento identificada con OFFLOAD_TARGET en el JSON proporcionado (excepto las solicitudes de los consumidores que tienen una entrada de ID de base de datos coincidente en el JSON proporcionado).

Por ejemplo, a continuación se muestra un ejemplo de JSON con un par de valores OFFLOAD_TARGET/CLOUD_LINK_DATABASE_ID explícito y un valor ANY con un valor OFFLOAD_TARGET correspondiente:

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

Para registrar un juego de datos y especificar destinos de descarga, realice lo siguiente:

1. Obtenga el OCID para una o más clonaciones de refrescamiento en las que desea descargar el acceso al juego de datos. Los OCID de clonación de refrescamiento están disponibles en la consola de Oracle Cloud Infrastructure en una clonación de refrescamiento.
   Nota
   
   Puede tardar hasta 10 minutos después de crear una clonación de refrescamiento para que la clonación de refrescamiento esté visible como destino de descarga. Esto significa que puede que tenga que esperar hasta 10 minutos después de crear una clonación de refrescamiento para que la clonación de refrescamiento esté disponible para el registro de descarga de enlaces en la nube.
2. Obtenga el ID de base de datos para una o más instancias de Autonomous Database a las que desea acceder al juego de datos mediante los datos proporcionados por la clonación de refrescamiento.

   En el sistema al que desea acceder al juego de datos desde una clonación de refrescamiento, ejecute el comando:

   SELECT DBMS_CLOUD_LINK.GET_DATABASE_ID FROM DUAL:

3. Registre un juego de datos y especifique el parámetro offload_targets.

   Por ejemplo, suponiendo que haya un esquema CLOUDLINK en la instancia de Autonomous Database, puede registrar SALES_VIEW_AGG y especificar las clonaciones de refrescamiento que proporcionan acceso al juego de datos:

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

   Los parámetros son:

   • schema_name: es el nombre del esquema (el propietario del objeto).

   • schema_object: es el nombre del objeto. Los objetos válidos son:

     • Tablas (incluidas las pilas, externas o híbridas)
     • vistas
     • Vistas Materializadas
     Nota
     
     No están soportados otros objetos, como las vistas analíticas o los sinónimos.

   • namespace: es el espacio de nombres que proporciona como nombre para el acceso con enlaces a la nube (una parte del FQN de enlace a la nube).

     Un valor NULL especifica un valor namespace generado por el sistema, único para la instancia de Autonomous Database.

   • name: es el nombre que proporciona para acceder a los enlaces de nube (una parte del FQN de enlace de nube).

   • scope: especifica el ámbito. Puede utilizar una de las variables: MY$REGION, MY$TENANCY o MY$COMPARTMENT o especificar uno o más OCID.

     Consulte Ámbito de juego de datos, control de acceso y autorización para obtener más información.

   • auth_required: valor booleano que especifica si la autorización de nivel de base de datos es necesaria para el juego de datos, además del control de acceso de ámbito. Cuando se define en TRUE, el juego de datos aplica un paso de autorización adicional. Consulte Registro de un juego de datos con autorización necesaria para obtener más información.

   • data_set_owner: el valor de texto especifica información sobre la persona responsable del juego de datos o un contacto para preguntas sobre el juego de datos. Por ejemplo, puede proporcionar una dirección de correo electrónico para el propietario del juego de datos.

   • offload_targets: especifica uno o más OCID de Autonomous Database de clonaciones de refrescamiento en las que se descarga el acceso a los juegos de datos de la instancia de Autonomous Database en la que se registra el juego de datos.

     Para cada consumidor de juego de datos, una de las siguientes opciones puede coincidir para descargar la solicitud en una clonación de refrescamiento:

     • Cuando hay coincidencia con el valor de la cloud_link_database_id especificada, es decir, los valores coinciden con el identificador de base de datos del consumidor, el acceso se descarga en la clonación de refrescamiento identificada por el OCID especificado en offload_target.

     • Cuando se especifica la palabra clave ANY, si no hay ninguna coincidencia con el valor de un cloud_link_database_id especificado, el acceso se descarga en la clonación de refrescamiento identificada con la entrada ANY por el OCID especificado en el offload_target correspondiente.

   Consulte Procedimiento REGISTER para obtener más información.

   Consulte Uso de clonaciones de refrescamiento con Autonomous Database para obtener más información.

Puede compartir enlaces de nube cuando un juego de datos reside en una instancia de Autonomous Database de solo lectura.

1. Cambie el modo de base de datos al modo de lectura y escritura.
   Para obtener más información, consulte Cambio del modo de funcionamiento de Autonomous Database a lectura/escritura o restringido.
2. Con la base de datos en modo de lectura/escritura, realice los pasos para registrar un juego de datos.
   1. Otorgar acceso a enlaces de nube para usuarios de base de datos
   2. Registro o anulación del registro de un juego de datos
3. Después de registrar uno o más juegos de datos, cambie la base de datos al modo de solo lectura.
   Para obtener más información, consulte Cambio del modo de funcionamiento de Autonomous Database a lectura/escritura o restringido.

Un usuario al que se le otorgue acceso para leer enlaces en la nube puede buscar juegos de datos disponibles para una instancia de Autonomous Database y puede acceder a juegos de datos registrados y utilizarlos con sus consultas.

1. Busque los juegos de datos disponibles en la instancia de Autonomous Database.

   Por ejemplo, busque todos los juegos de datos que contengan la cadena, "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"}]

   Los parámetros son:

   • search_string: cadena que se va a buscar. La cadena de búsqueda no es confidencial.

   • search_result: documento JSON que incluye los valores de espacio de nombres, nombre y descripción del juego de datos.

   Consulte Procedimiento FIND para obtener más información.

   El procedimiento DBMS_CLOUD_LINK.FIND proporciona el FQN que puede utilizar con enlaces a la nube. En este caso, FOREST.TREE_DATA.

2. Utilice la vista DBA_CLOUD_LINK_ACCESS para mostrar los juegos de datos disponibles:

   SELECT * FROM DBA_CLOUD_LINK_ACCESS;
   
   NAMESPACE            NAME
   ---------            -------------- 
   FOREST               TREE_DATA 
   REGIONAL_SALES       SALES_AGG
   TRUSTED_COMPARTMENT  SALES

3. Utilice el procedimiento DBMS_CLOUD_LINK.DESCRIBE para obtener más información sobre un juego de datos registrado.

   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. Utilizar el juego de datos registrado en una consulta.

   SELECT * FROM FOREST.TREE_DATA@cloud$link;

   Nota
   
   Puede tardar hasta 10 minutos después de registrar un juego de datos en DBMS_CLOUD_LINK.REGISTER para que el juego de datos sea visible y accesible.

Puede activar el almacenamiento en caché en un consumidor de juegos de datos para los resultados de una consulta o para un fragmento de consulta que accede a los datos de Cloud Link.

1. En una consulta, especifique la indicación RESULT_CACHE con la opción SHELFLIFE.

   Por ejemplo:

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

   Este valor RESULT_CACHE especifica un valor SHELFLIFE de 120. Esto indica que el resultado se debe almacenar en caché en la memoria durante 120 segundos. Después de 120 segundos, el resultado almacenado en caché se marca como no válido.

   El valor SHELFLIFE debe ser un entero positivo. El valor máximo de SHELFLIFE es 4294967295.

2. Si el resultado de la consulta es grande y no cabe en la memoria, utilice las opciones SHELFLIFE y TEMP para indicar que el resultado se debe escribir en el disco del tablespace temporal.

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

El usuario ADMIN puede revocar el registro para impedir que un usuario registre juegos de datos para el acceso remoto. El usuario ADMIN también puede revocar privilegios o usuarios de base de datos para acceder a los juegos de datos registrados.

1. Como usuario ADMIN, revoque los privilegios de un usuario para registrar juegos de datos.

   Por ejemplo:

   EXEC DBMS_CLOUD_LINK_ADMIN.REVOKE_REGISTER('DB_USER1');

   Esto revoca los privilegios para registrar juegos de datos para el usuario, DB_USER1.

   La ejecución de DBMS_CLOUD_LINK_ADMIN.REVOKE_REGISTER no afecta a los juegos de datos que ya están registrados. Utilice DBMS_CLOUD_LINK.UNREGISTER para eliminar el acceso de un juego de datos registrado.

   Consulte Procedimiento REVOKE_REGISTER y Procedimiento UNREGISTER para obtener más información.

2. Como usuario ADMIN, revoque el acceso a los juegos de datos registrados.

   Por ejemplo:

   EXEC DBMS_CLOUD_LINK_ADMIN.REVOKE_READ('LWARD');

   Esto revoca el acceso a los juegos de datos de enlaces en la nube para el usuario LWARD.

   Consulte el procedimiento REVOKE_READ para obtener más información.

Autonomous Database proporciona vistas que le permiten supervisar y auditar enlaces en la nube.

1. Obtenga el ID de base de datos de Cloud Link único para la instancia de Autonomous Database en la que desea proporcionar acceso completo.

   DECLARE
        DB_ID NUMBER;
    BEGIN
        DB_ID := DBMS_CLOUD_LINK.GET_DATABASE_ID;
        DBMS_OUTPUT.PUT_LINE('Database ID:' || DB_ID);
    END;
    /

2. Cree una política de VPD en la base de datos que registró el juego de datos permitiendo solo el acceso completo a la base de datos específica cuyo identificador obtuvo en la base de datos en cuestión en el paso 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;
   /

   Consulte DBMS_RLS para obtener más información.

3. Registre la política de VPD del juego de datos registrado para limitar el acceso completo solo a la base de datos identificada en el paso 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;
   /

   Consulte DBMS_RLS para obtener más información.

Proporciona notas y restricciones para utilizar enlaces en la nube.

• Hay un límite de 4096 en el número de conjuntos de datos que puede registrar.

  Cada instancia de Autonomous Database no puede registrar más de 4096 juegos de datos. Este límite se aplica a todas las instancias de Autonomous Database, independientemente del número de ECPU (OCPU si la base de datos utiliza OCPU) o del tamaño de almacenamiento de la instancia. El límite es un valor fijo y la configuración del recuento de ECPU en un valor mayor no permite registrar más juegos de datos.

• Puede registrar un objeto en otro esquema si tiene el privilegio READ WITH GRANT OPTION en el objeto.

• Para registrar juegos de datos o ver y acceder a juegos de datos remotos, debe haber otorgado el privilegio adecuado para registrar o leer juegos de datos. Esto también es cierto para ADMIN; sin embargo, ADMIN puede otorgar este privilegio a sí mismo.

• Para utilizar DBMS_CLOUD_LINK.REGISTER, debe tener el privilegio de ejecución en el paquete DBMS_CLOUD_LINK, además del privilegio de registro asignado con DBMS_CLOUD_LINK_ADMIN.GRANT_REGISTER. Solo el usuario ADMIN y los esquemas con PDB_DBA tienen este privilegio por defecto.

• Si borra y vuelve a crear una tabla registrada, debe volver a registrar la tabla para el acceso remoto.

• Solo el usuario ADMIN y los usuarios con el rol PDB_DBA tienen privilegios para acceder a las siguientes vistas:

  • DBA_CLOUD_LINK_ACCESS

  • DBA_CLOUD_LINK_REGISTRATIONS

  • DBA_CLOUD_LINK_AUTHORIZATIONS

  • DBA_CLOUD_LINK_PRIVS

  Consulte DBMS_CLOUD_LINK Views para obtener más información.

• El acceso a los datos remotos registrados requiere que la base de datos remota esté abierta. Si la base de datos remota está cerrada o en modo restringido, no podrá acceder a los datos y se devolverá un error de Oracle.

• Hay un límite de un máximo de cuatro enlaces de base de datos abiertos por sesión. Si se supera este límite, se puede producir ORA-02020 o ORA-12545.

• Si la caché de resultados está activada, como el comportamiento por defecto en Autonomous Database con la carga de trabajo de Data Warehouse, debe asegurarse de que la caché de resultados no se utiliza cuando se necesitan datos en tiempo real.

• Al actualizar el tipo de licencia de Gratuito a Pagado, debe volver a registrar los juegos de datos de Enlaces en la nube. Consulte Actualización de una instancia siempre gratis a una cuenta de pago con Autonomous Database para obtener más información.

• La conectividad remota de Cloud Links utiliza el servicio MEDIUM y esto no se puede cambiar. Puede ver las conexiones remotas como usuario C##DATA$SHARE en V$SESSION y las vistas de enlaces en la nube V$CLOUD_LINK_ACCESS_STATS y las vistas GV$CLOUD_LINK_ACCESS_STATS proporcionan más detalles sobre las conexiones remotas.

• Todas las interfaces distinguen entre mayúsculas y minúsculas, a menos que se indique lo contrario, de la siguiente manera:

  • Todo lo que introduzca que exista en la base de datos, por ejemplo, nombres de usuario y nombres de tabla, es significativo y se debe introducir con letras mayúsculas.
  • Variables predefinidas, por ejemplo, los valores de ámbito predefinidos se deben introducir en mayúsculas.
  • Cualquier cosa que especifique para la configuración de enlaces en la nube, por ejemplo, espacios de nombres o nombres de tablas en un espacio de nombres, se debe especificar como se ha introducido. Por ejemplo, si define un espacio de nombres como trees, debe incluir el espacio de nombres entre comillas dobles, como "trees", al acceder a él con SQL.

• Puede compartir enlaces de nube cuando un juego de datos reside en una instancia de Autonomous Database en modo de solo lectura. Consulte Uso de enlaces de nube de una instancia de Autonomous Database de solo lectura para obtener más información.

• Puede tardar hasta 10 minutos después de crear una clonación de refrescamiento para que la clonación de refrescamiento esté visible como destino de descarga. Esto significa que puede que tenga que esperar hasta 10 minutos después de crear una clonación de refrescamiento para que la clonación de refrescamiento esté disponible para el registro de descarga de enlaces en la nube.

  Consulte Registro de un juego de datos con destinos de descarga para el acceso al juego de datos y Creación de una clonación de refrescamiento para una instancia de Autonomous Database para obtener más información.