Oracle REST Data Services (ORDS) 23.1 ya está disponible

Oracle anunció hoy la disponibilidad de Oracle REST Data Services (ORDS) 23.1. ORDS es una herramienta que sirve de puente entre HTTPS y las bases de datos Oracle, proporcionando una API REST de gestión de bases de datos que incluye SQL Developer Web, una puerta de enlace PL/SQL, SODA para REST y la capacidad de publicar servicios web RESTful para interactuar con los datos y los procedimientos almacenados en la base de datos.

Este es el primer producto relacionado con bases de datos liberado en el año 2023, pero pronto tendremos novedades como ser SQL Developer 23.2 y Oracle Database 23c!

Descarga e Información Adicional

La página de descarga de ORDS ya fue actualizada a la versión 23.1, y adicionalmente se puede utilizar el link para descargar la ultima versión en forma directa.

Otros links útiles son:

• Documentación (todavía no está actualizada a la version 23.1).
• Release Notes (incluye lista de bugs resueltos en la versión).
• Foro de ORDS en Oracle Community.
• Documentación de Oracle Database Actions (SQL Developer Web).

¿Qué hay de nuevo en ORDS 23.1?

Esta es la lista de mejoras y nuevas funcionalidades en ORDS 23.1:

• Actualizaciones de componentes:
• JDBC/UCP 21.10.0.0.230302
• Apache Commons FileUpload 1.5
• antlr4-runtime 4.11.1
• Oracle Mongo DB Listener 230302.1319
• Database API - Exportar e importar aplicaciones APEX.
• Database Actions: Sign-In/Out optimizado.
• Database Actions: Exportar REST workshop y Esquema.
• Database Actions: Soporte de Multilingual Engine (MLE) en Oracle Database 23c.
• ORDS: Soporte extendido para AutoREST con JSON Relational Duality Views en Oracle Database 23c.
  

Como verán, ya incluye un par de características para incorporar nuevas funcionalidades que estarán disponibles en Oracle Database 23c.

Cloud Links en Autonomous Database

En el día de ayer Oracle introdujo una nueva funcionalidad que permite acceder remotamente en forma sencilla a datos disponibles en bases de datos autónomas sin necesidad de crear database links entre ellas. Esta nueva funcionalidad se llama Cloud Links y permite "publicar" en una base de datos autónoma un objeto en particular, el cual puede ser accedido por otras bases de datos autónomas.

¿Cómo se crea un Cloud Link?

Asumamos que tenemos un sistema con una tabla de Empleados y una vista vEmpleados que muestra toda la información de la tabla excepto la columna salario, como mostramos a continuación:

Nuestro objetivo es permitir a otras bases de datos autónomas acceder a las mismas.

Otorgando Permisos

El primer paso es otorgarle (con el usuario ADMIN de ADB) permiso al usuario dueño de los objetos que queremos compartir para poder "registrar" objetos en Cloud Link. Esto se hace utilizando el procedimiento "GRANT_REGISTER" del paquete "DBMS_CLOUD_LINK_ADMIN". En nuestro ejemplo, le daremos permiso al usuario DEMOLINK que es el dueño de los objetos que deseamos compartir:

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

En el parámetro Scope puede tener los valores "MY$COMPARTMENT" (sólo el compartimento), "MY$TENANCY" (solo la Tenancy) o "MY$REGION" (la región) los cuales definen el público potencial de los Cloud Links que podrá crear el usuario.

Adicionalmente, debemos otorgar permiso al usuario para ejecutar el paquete de administración de Cloud Links:

GRANT EXECUTE ON DBMS_CLOUD_LINK TO DEMOLINK;

Registrando un Objeto

Una vez otorgados estos permisos, y conectados con el usuario dueño de los objetos que queremos compartir, tenemos que registrar los mismos en Cloud Link usando la siguiente sintaxis:

BEGIN
   DBMS_CLOUD_LINK.REGISTER(
    schema_name => 'DEMOLINK',
    schema_object  => 'EMPLEADOS',
    namespace   => 'RRHH', 
    name        => 'EMPLEADOS',
    description => 'Detalle de Empleados.',
    scope       => 'MY$COMPARTMENT' );
END;
/
BEGIN
   DBMS_CLOUD_LINK.REGISTER(
    schema_name => 'DEMOLINK',
    schema_object  => 'VEMPLEADOS',
    namespace   => 'RRHH', 
    name        => 'RESUMEN_EMPLEADOS',
    description => 'Resumen de Empleados.',
    scope       => 'MY$TENANCY' );
END;
/

Debemos proporcionar los siguientes datos al momento de "registrar" un objeto en Cloud Links:

• Schema_name: Nombre del esquema del objeto que deseamos compartir.
• Schema_obect: Nombre del objeto que deseamos compartir.
• Namespace: Es un nombre que agrupa objetos disponibles en Cloud Links. En este caso, usaremos RRHH para referirnos a la información de Recursos Humanos a la que pertenecen tanto la tabla como la vista de empleados.
• Name: Es el nombre que queremos utilizar para compartir el objeto, no tiene por que coincidir.
• Description: Descripción del objeto compartido.
• Scope: Define el alcance con el cual se comparte el objeto. Puede ser "MY$COMPARTMENT" (sólo el compartimento), "MY$TENANCY" (solo la Tenancy) o "MY$REGION" (la región) o usar directamente un OCID (identificador de Oracle Cloud).

En el ejemplo anterior, registramos la tabla Empleados para que esté disponible en el mismo compartimento que la base de datos autónoma (usando MY$COMPARTMENT) y registramos la vista (que no contiene el salario) para que esté disponible en toda la Tenancy.

Una vez registrados los objetos, puede tardar hasta diez minutos para que los mismos estén disponibles para las otras bases de datos. Podemos consultar las registraciones disponibles usando la siguiente vista:

SELECT * FROM DBA_CLOUD_LINK_REGISTRATIONS;

¿Cómo se Accede a un Cloud Link?

Definir quién puede acceder a objetos

Para poder acceder a objetos compartidos mediante Cloud Link, es necesario darle permiso al usuario deseado mediante la siguiente sintaxis:

EXEC DBMS_CLOUD_LINK_ADMIN.GRANT_READ('READLINK');

En este caso, le permitimos al usuario READLINK acceder a los Cloud Links que esten disponibles en su Compartimiento / Tenancy / Región.

Accediendo a los objetos

Una vez hemos autorizado al usuario a acceder a Cloud Links, podemos consultar los mismos usando la siguiente sintaxis:

SELECT [* | columna1, columna 2] FROM <Namespace>.<Name>@cloud$link;

En nuestro caso, la sintaxis sería:

SELECT * FROM RRHH.EMPLEADOS@cloud$link;

Lo cual devuelve lo siguiente:

Como vemos, en la base de datos donde queremos consultar el Cloud Link no debemos definir ningún Database Link ni conocer nada en particular del recurso al que queremos acceder, solo debemos saber su namespace y nombre y estar dentro del Compartimento, Tenancy o Región donde el mismo fue compartido conectados con un usuario que puede acceder a Cloud Links.

A considerar...

Hay varias cosas a considerar al utilizar Cloud Links, pero las más importantes a tener en cuenta son:

• Los Cloud Links son de sólo lectura, por lo que si debemos modificar datos tenemos que seguir usando Database Links.
• Si se borra y vuelve a crear una tabla que está publicada con Cloud Link, hay que volver a registrar la misma aunque se vuelva a crear con el mismo nombre.

Documentación

La documentación de Cloud Links incluye todos los pasos necesarios para utilizar los mismos.

APEX 22.2 Patchset Bundle #4 ya está disponible!

Este conjunto de patchsets agrupado bajo el número de patch 34628174 fue liberado el día de hoy y está disponible sólo desde la página de soporte de Oracle en este link.

Se puede consultar la lista de fixes incluidos en el patchset bundle en este link.

La versión base de Oracle APEX 22.2 puede ser descargada aquí.

Long Term Backups en Autonomous Database

Antes de comenzar a explicar esta excelente funcionalidad que ha sido agregada a las Bases de Datos Autónomas de OCI, es importante mencionar como me enteré de la misma. Al querer crear una base de datos ATP para unas pruebas, me encontré con la siguiente sección:

Esta nueva área de Anuncios al crear una base de datos autónoma me resultó por demás de interesante, ya que permite conocer las mejoras implementadas ADB sin necesidad de leer mis artículos trimestrales sobre mejoras a ADB.Así fue como me enteré de la posibilidad de generar copias de backups adicionales con una política de retención mayor, lo cual vamos a explicar en detalle a continuación.

Para que Necesitamos Long Term Backups 

La política de backups automáticos de Oracle Autonomous Database permite mantener backups por 60 días, tiempo más que suficiente para poder recuperar nuestra base de datos ante una pérdida de datos causada por un desastre, por la falla de hardware, error humano o hasta un ataque deliberado. 

Adicionalmente, en el mundo moderno las organizaciones deben cumplir con normas y regulaciones impuestas por los gobiernos o por criterios de buenas prácticas, las cuales pueden requerir mantener la información por períodos de tiempo mucho mas extensos que los sesenta dias que ofrece ADB.

Creación de Long Term Backups

La creación de backups de tipo Long Term se configura en la sección de backups de nuestra base de datos autónoma, donde veremos un nuevo botón "Crear copia de seguridad a largo plazo":

La imagen nos permite ver, adicionalmente, un backup automático realizado el dia 9 de marzo de 2023, el cual tiene fecha de caducidad el 8 de mayo al cumplirse los 60 días de retención.

Al presionar dicho botón es posible configurar un backup con un periodo de retención más extenso, entre 3 meses y 10 años. En este ejemplo elegimos configurarlo para que se mantenga por 6 meses (en realidad se traduce a 180 días):

Adicionalmente, si seleccionamos la opción "Programar copia de seguridad a largo plazo" podemos definir una la fecha y hora para realizar la copia (si no se hace inmediatamente luego de presionar Crear), así como también elegir si queremos realizar la misma una única vez o forma periódica, como podemos ver a continuación:

Al presionar "Crear" la base de datos pasa a un estado de actualización donde se genera una agenda para la copia de seguridad, la cual queda registrada en la sección "Solicitudes de Trabajo":

En la sección de información de la base de datos autónoma podemos ver cuándo se ejecutará la próxima copia de seguridad de tipo Long Term y a la vez editar o eliminar el programa en caso de que hayamos agendado para una ejecución recurrente:

Como ver las copias de seguridad Long Term

Una vez que la copia de seguridad de tipo Long term se generó, la veremos en la sección correspondiente a los backups. Desde allí podemos modificar la retención de cada una de estas copias (aumentarla o reducirla de ser necesario), eliminar la copia (ambas tareas no son posibles con las copias de seguridad automáticas) o clonar la base de datos usando como fuente este backup:

No todo lo que reluce es oro...

Esta funcionalidad no está disponible (al menos por el momento) en las bases de datos creadas con Always Free, como vemos en la imagen a continuación, donde la opción de programar un Backup de tipo Long Term no está habilitada:

Información Adicional

La documentación sobre esta nueva funcionalidad está disponible aquí.

Zero Downtime Migration 21.4 disponible

Zero Downtime Migration es una herramienta diseñada y desarrollada por Oracle que permite migrar bases de datos Oracle a Oracle Cloud. La ultima versión de la misma. Oracle ZDM 21.4, fue anunciada hace un par de semanas por Oracle.

Con ZDM existen dost tipos posibles de migración (física y lógica) y dos formas de realizar la misma (online u offline), siendo el destino de la migración una Base de datos Exadata (On-Premise, Exadata Database Service en infraestructura dedicada o Database Service en Cloud@Customer), una base de datos Autónoma (en infraestructura dedicada o compartida) o una DB en DB Systems, como podemos ver a continuación:

Nuevas Características

La versión 21.4 posee algunas importantes mejoras, que procederemos a compartir a continuación.

Imagen Gentileza Ricardo Gonzalez - Product Manager Oracle Database Cloud Migration 

Mejoras en la Migración Física

• Redo Apply Catch Up (para trabajos de migración en pausa): es posible indicarle a ZDM para revisar en forma periódica el estado de aplicación de Redo una vez que la base de datos Standby ha sido creada. De esta forma la migración se reanuda una vez que se detecta que ha finalizado la aplicación  de Redo en la base de datos destino. Esta opción se configura mediante el parámetro ZDM_APPLY_LAG_MONITORING_INTERVAL.

• Reanudar después de un cambio manual de Data Guard: en caso de un cambio manual iniciado por el usuario, se le puede indicar a ZDM que reconozca la operación, marque el cambio como completado y reanude el trabajo de migración con el resto del flujo de trabajo automatizado.

• Tamaño de sección de RMAN configurable: el tamaño de sección de Recovery Manager para copias de seguridad se puede configurar manualmente a través de un nuevo parámetro, ZDM_RMAN_SECTION_SIZE.

• Deshabilitar Compresión y Encriptación para el backup de RMAN: es posible indicarle a ZDM que no utilice compresión ni encripación en migraciones On-Premise
• Actualización post-migración del archivo de Zonas Horarias: se puede habilitar una nueva tarea posterior a la migración (a través del parámetro ZDM_TGT_UPGRADE_TIMEZONE) que indica a ZDM que actualice el archivo de zona horaria de la base de datos de destino.

Mejoras en la Migración Lógica

• Migración separada de datos y metadatos: Un nuevo flujo de trabajo de migración permite realizar la exportación normal de los datos y una importación por etapas para los metadatos. Esto permite el manejo de la creación de los USUARIOS y PERFILES y luego el manejo de la creación de METADATOS, finalizando con la importación de DATOS. Este nuevo flujo permite modificar en destino el nivel de permisos (GRANT) otorgado a los usuarios o la modificación de de atributos objetos y segmentos.

• Compatibilidad con tablas con tipos de datos XML: Ahora es posible convertir los datos XML almacenados como CLOBS a un almacenamiento binario (BLOB) en forma automática. Se puede indicar en forma individual que daos tienen que ser convertidos, exportados y migrados a la base de datos destino.

• Migración sin Sudo: ZDM ahora tiene un nuevo complemento de autenticación, que le permite migrar bases de datos por parte de usuarios sin privilegios elevados (usuario "oracle") para acceder tanto al nodo de origen como al de destino.
• Ubicación de Wallet: un nuevo parámetro WALLET_SOURCEADMIN permite indicar la ubicación del directorio que contiene el archivo cwallet.sso que contiene la contraseña del usuario administrador de base de datos.

• Nueva Guía de Mejores Prácticas: Recomendaciones para planificar una migración lógica. Disponible en este link.

• Otras Mejoras: manejo mejorado de errores de Data Pump, compatibilidad con URL pre-autenticadas de almacenamiento de objetos en OCI, perfiles de inicio y reinicio automáticos para microservicios de Oracle GoldenGate.

Links Útiles

A continuación algunos links útiles de Zero Downtime Migration:

• Página del Producto.
• Documentación.
• ZDM 21.4 Release Notes.
• Resumen Técnico.