martes, 3 de noviembre de 2026

Oracle Database 19c, Release Update, Auditoría Obligatoria para DML directos de SYS sobre AUD$ y FGA_LOG$

 




Hola gente.

El nuevo release de Oracle Database 19c, RU 19.33, trae algunos cambios interesantes, que precisa que tengamos en cuenta de ahora en adelante.

Este es el primero que quiero darles a conocer y que pueden ver el detalle en la imagen.

Toda acción sobre las tablas de auditoría de la base de datos realizada por el usuarios SYS ahora son auditadas obligatoriamente.

En Oracle Database 19.33, si las tablas SYS.AUD$ y SYS.FGA_LOG$ crecen considerablemente y necesitas eliminar registros históricos, puedes realizar una purga controlada, pero debes utilizar los mecanismos oficiales de Oracle y no ejecutar DELETE o TRUNCATE directamente sobre las tablas.

La nueva auditoría obligatoria ORA$MANDATORY no impide que se administren los registros históricos. Su propósito es registrar las operaciones DML directas realizadas por SYS sobre esas tablas.

La ejecución de DBMS_AUDIT_MGMT también es una actividad auditable obligatoriamente en Oracle 19c.

Por tanto, la purga administrativa puede generar su propia evidencia en Unified Auditing.

Eso no implica que la tabla de auditoría unificada sea inmutable o que sus registros deban conservarse indefinidamente: su retención también se administra mediante el paquete oficial.

#Oracle19c #security #RU19.33 #Auditoria

Oracle AI Database 26ai introduce una nueva característica a nivel de lenguaje de programación SQL: Streaming Windowing Table Functions


El Release Update 23.26.4, nos trae consigo, 4 nuevas funciones de ventanas de tiempo que nos permiten agrupar datos por intervalos fijos sin superposición, por ejemplo para poder obtener las ventas por hora; ventanas deslizantes, para monitoreo de transacciones; ventanas acumulativas para poder calcular ventas acumuladas y sesiones separadas por inactividad, para monitorear la actividad de usuarios.

Veamos el primer caso.

Observen la estructura de la siguiente tabla:

 SQL> desc transacciones_stream
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------
 ID_TRANSACCION                            NOT NULL NUMBER
 ID_CLIENTE                                         NUMBER
 FECHA_EVENTO                                       TIMESTAMP(6)
 MONTO                                              NUMBER(12,2)

En esta tabla tenemos la siguiente información:

Contenido del artículo

Ahora usemos la primera función de ventana de tiempo llamada TUMBLE, para poder determinar las transacciones que ocurrieron cada 10 minutos.

SQL> SELECT window_start,
       window_end,
       COUNT(*) AS operaciones,
       SUM(monto) AS total
FROM TUMBLE(
    transacciones_stream,
    COLUMNS(fecha_evento),
    INTERVAL '10' MINUTE
)
GROUP BY window_start, window_end
ORDER BY window_start; 

Resultado obtenido:

Contenido del artículo

Con esta consulta, hemos agrupado las transacciones en intervalos consecutivos de 10 minutos y calculado su monto total.

Las ventanas sin registros no aparecen automáticamente.

Caso de uso: consolidar transacciones financieras, métricas de aplicaciones o eventos de auditoría por intervalos regulares.

Segundo caso.

HOP: ventanas deslizantes

Objetivo: calcular las transacciones de los últimos 20 minutos, iniciando una nueva ventana cada 10 minutos.

SQL> SELECT window_start,
       window_end,
       COUNT(*) AS operaciones,
       SUM(monto) AS total
FROM HOP(
    transacciones_stream,
    COLUMNS(fecha_evento),
    INTERVAL '10' MINUTE,
    INTERVAL '20' MINUTE
)
GROUP BY window_start, window_end
ORDER BY window_star;

Obtenemos como resultado:

Contenido del artículo

También aparecerán ventanas anteriores o posteriores que contengan registros.

Una misma transacción puede participar en varias ventanas. Por eso, los totales de ventanas superpuestas no deben sumarse como si fueran períodos independientes.

Caso de uso: detectar aumentos de transacciones, actividad anómala, picos de consumo o potenciales fraudes en intervalos móviles.

Ahora veamos el tercer caso.

CUMULATE: acumulados progresivos

Objetivo: generar ventanas acumulativas que crezcan cada 10 minutos, hasta alcanzar un máximo de 30 minutos.

SQL> SELECT window_start,
       window_end,
       COUNT(*) AS operaciones,
       SUM(monto) AS total
FROM CUMULATE(
    transacciones_stream,
    COLUMNS(fecha_evento),
    INTERVAL '10' MINUTE,
    INTERVAL '30' MINUTE
)
GROUP BY window_start, window_end
ORDER BY window_start;

Resultado obtenido

Contenido del artículo

La ventana se reinicia después de alcanzar su duración máxima.

Caso de uso: seguimiento de objetivos comerciales, consumo acumulado, volumen transaccional y métricas operativas.

Ahora vamos al último caso.

SESSIONS: detectar sesiones de actividad por cliente

Objetivo: identificar grupos de transacciones de un mismo cliente separados por períodos de inactividad superiores a 10 minutos.

 SELECT id_cliente,
       window_start,
       window_end,
       COUNT(*) AS operaciones,
       SUM(monto) AS total
FROM SESSIONS(
    transacciones_stream
      PARTITION BY id_cliente,
    COLUMNS(fecha_evento),
    INTERVAL '10' MINUTE
)
GROUP BY id_cliente,
         window_start,
         window_end
ORDER BY id_cliente, window_start;

Obtenemos como resultado:

Contenido del artículo

Con nuestros datos, el cliente 100 presenta dos grupos de actividad: uno con operaciones a las 09:02 y 09:07, otro con operaciones a las 09:18 y 09:40 que forman sesiones separadas por inactividad. En concreto, aparecen tres sesiones para ese cliente, porque entre 09:07 y 09:18 transcurren 11 minutos.

La función determina las sesiones independientemente por id_cliente.

Cómo se hace en 19c y como lo podemos hacer ahora en 26ai

Contenido del artículo

La ventaja es la declaratividad: Oracle se encarga de asignar los registros a las ventanas, reduciendo la cantidad de SQL necesario.

Hay una distinción arquitectónica importante: estas funciones trabajan sobre filas disponibles para la consulta en modo batch. No constituyen por sí solas un motor de procesamiento continuo de eventos.