Uso de Hints de Paralelismo en grandes volúmenes de datos

Uso de Hints de Paralelismo en grandes volúmenes de datos

   abril 27, 2026       Luis Felipe

---

Bajo el ecosistema de Oracle Database, es habitual lidiar con procesos que manejan millones de registros (Batch, ETL o reportes pesados). Cuando el tiempo de respuesta es fundamental, el procesamiento en paralelo se convierte en nuestra mejor herramienta.

Sin embargo, el Optimizador de Oracle (CBO) no siempre elige el paralelismo de forma automática. En este post, veremos cómo forzarlo correctamente y qué consideraciones debemos tener.

Cuando usamos un hint de paralelismo, Oracle divide una tarea grande en piezas más pequeñas. Un Query Coordinator (QC) coordina a varios procesos esclavos (Parallel Execution Servers) que trabajan simultáneamente.

La forma más común de implementarlo es a través del hint /*+ PARALLEL(alias, degree) */. El degree o grado define cuántos procesos esclavos vamos a solicitar.

SELECT /*+ PARALLEL(ventas, 4) */ 
       producto_id, SUM(monto)
FROM fact_ventas ventas
GROUP BY producto_id;

En este caso, estamos solicitando 4 procesos esclavos para escanear la tabla y realizar la agregación.

Este es un punto donde muchos fallan. Para que un INSERT funcione realmente rápido, debemos combinar el paralelismo con el Direct Path Load mediante el hint APPEND. Esto hace que Oracle escriba directamente al final de la tabla, saltándose el Buffer Cache y generando mucho menos Redo Log.

ALTER SESSION ENABLE PARALLEL DML;

INSERT /*+ APPEND PARALLEL(destino, 8) */ INTO table_final destino
SELECT /*+ PARALLEL(origen, 8) */ * FROM table_staging origen;
COMMIT;

Para confirmar que el hint está funcionando, debemos generar el plan de ejecución (EXPLAIN PLAN). Debemos identificar las siguientes operaciones:

• PX COORDINATOR: El proceso principal que une los resultados.
• PX SEND / PX RECEIVE: Indica que los datos se están moviendo entre procesos esclavos.
• PX BLOCK ITERATOR: Oracle ha dividido la tabla en bloques para los esclavos.
• LOAD AS SELECT (HIGH WATER MARK): Indica que el APPEND y el paralelismo de escritura están activos.

Si el plan de ejecución muestra estas líneas (comenzando con "PX"), el paralelismo se está aplicando correctamente.

Este plan de ejecución representa una carga de datos de alto rendimiento (Full Parallel Stack) que utiliza el paralelismo tanto para leer como para escribir. En lugar de procesar los datos fila por fila, el (PX Coordinator) divide la tarea entre 4 procesos esclavos que filtran los duplicados simultáneamente y realizan una inserción directa al disco (Direct Path Load), saltándose la memoria intermedia y escribiendo los datos al final de la tabla de forma masiva. Además, el plan incluye el mantenimiento de índices en paralelo, lo que evita que la base de datos se ralentice al actualizar los índices después de la carga, garantizando la máxima velocidad posible y un uso mínimo de los logs de transacciones.

IMPORTANTE:

No se debe abusar del paralelismo. Aquí mis recomendaciones:

1. Costo de CPU: Cada proceso paralelo consume CPU. Si el servidor tiene 8 núcleos y lanzas un PARALLEL 32, causarás una degradación general del sistema.
2. Uso de Memoria: El paralelismo utiliza la PGA de forma intensiva para los ordenamientos y joins. Asegúrate de tener suficiente PGA_AGGREGATE_TARGET.
3. Tablas pequeñas: No utilices este hint en tablas de pocos registros. El tiempo que le toma a Oracle gestionar los procesos esclavos será mayor que la ganancia de velocidad.

El uso de hints de paralelo es fundamental para grandes volúmenes, pero un grado de paralelismo mal calculado puede afectar a todos los usuarios. ¡Úsalo con cautela y siempre verifica tu plan de ejecución!

Read More

Optimización de Consultas Distribuidas (DBLinks) mediante el uso de Hints

Optimización de Consultas Distribuidas (DBLinks) mediante el uso de Hints

   abril 15, 2026       Luis Felipe

---

En la administración de bases de datos Oracle, es común trabajar con entornos distribuidos. Sin embargo, las consultas a través de un Database Link (DBLink) suelen ser un dolor de cabeza para el rendimiento. El optimizador a menudo decide traer los datos de la tabla remota para procesarlos localmente, lo que satura la red y eleva los tiempos de respuesta.

Por defecto, Oracle asume que el sitio local (donde lanzas la consulta) debe ser el "maestro". Si tienes una tabla local de 100 filas y una remota de 10 millones, el optimizador podría intentar traerse los 10 millones de filas por la red para hacer el JOIN en tu instancia local.

Para controlar este comportamiento, contamos con una herramienta poderosa: el hint DRIVING_SITE.

El hint /*+ DRIVING_SITE(alias) */ obliga a Oracle a ejecutar la consulta en el nodo donde reside la tabla especificada. Esto permite que los filtros y join se realicen en el sitio remoto, enviando a nuestra base de datos únicamente el resultado final.

Revisemos el siguiente plan de ejecución, donde el optimizador decide procesar todo en el servidor local:

Al observar el plan, podemos identificar por qué esta consulta es una candidata crítica para el uso de DRIVING_SITE:

• La operación raíz (SELECT STATEMENT) se ejecuta en la instancia local. Esto confirma que el servidor local está actuando como el nodo maestro, asumiendo toda la carga de procesamiento y coordinación.

• Noten la operación REMOTE. Aquí, Oracle está "succionando" datos desde el DBLink hacia el servidor local. El plan estima solo 1 fila, pero en entornos reales, si esa tabla remota tiene millones de registros, la red se convertirá en un cuello de botella insoportable mientras el servidor local espera los paquetes.

• El servidor local ya está trabajando intensamente. Está realizando un WINDOW SORT (funciones analíticas), un HASH UNIQUE (eliminación de duplicados) y múltiples HASH JOIN sobre unos 78,620 registros.

• El HASH JOIN OUTER ocurre localmente. Es decir, después de procesar los 78k registros locales y traer la data remota por la red, el servidor local intenta mezclarlos.

Este es el plan de ejecución después de aplicar el hint. Observen cómo la arquitectura del plan cambia drásticamente:

A diferencia del plan anterior, la operación raíz ahora es REMOTE. Esto confirma que el servidor local ha dejado de ser el "maestro" para delegar toda la lógica y coordinación al nodo donde reside la tabla más pesada.

Las operaciones de SORT GROUP BY y HASH JOIN se ejecutan ahora en el sitio remoto. La data se filtra, se une y se agrupa antes de viajar, asegurando que por la red solo se envíe el resultado final ya procesado.

Al ejecutar la consulta donde viven los datos, Oracle puede utilizar el PARTITION RANGE ITERATOR y los índices locales (INDEX RANGE SCAN). Esto evita escaneos completos innecesarios y aprovecha la arquitectura física diseñada para esa tabla.

IMPORTANTE: El hint DRIVING_SITE será ignorado si utilizas funciones PL/SQL locales en la consulta (ej. una función que creaste en tu esquema local aplicada a una columna remota). Oracle necesita que todo lo necesario para procesar el bloque esté disponible en el sitio remoto donde ocurre la ejecución.

Como administradores de bases de datos, nuestro trabajo no es solo hacer que las consultas funcionen, sino que lo hagan de forma eficiente. El uso de DRIVING_SITE transforma una consulta que podría durar minutos (o colapsar la red) en una que responde en milisegundos, simplemente moviendo la inteligencia del procesamiento al lugar correcto.

Read More

Resolviendo el error ORA-1652: unable to extend temp segment by 128 in tablespace TEMP

Resolviendo el error ORA-1652: unable to extend temp segment by 128 in tablespace TEMP

   abril 09, 2026       Luis Felipe

---

El error ORA-1652 es uno de los incidentes más temidos por los DBAs. La reacción más común suele ser añadir más archivos de datos (Tempfiles), pero la experiencia demuestra que el aumento en el consumo de espacio temporal es debido a un proceso o consulta ineficiente.

Cuando el error ocurre, el espacio en TEMP se libera automáticamente al fallar la sesión, borrando los registros en las vistas de tiempo real. Para investigar, debemos consultar el historial de sesiones activas (ASH) para encontrar el pico máximo de consumo de cada consulta.

SELECT 
    sql_id,
    user_id,
    program,
    round(MAX(temp_space_allocated)/1024/1024/1024,2) AS max_temp_gb,
    MIN(sample_time) AS inicio,
    MAX(sample_time) AS fin
FROM v$active_session_history
WHERE temp_space_allocated > 0
  AND sql_id IS NOT NULL
--Aqui colocamos la fecha y hora relacionada al error ORA-1652  
  AND sample_time BETWEEN TO_TIMESTAMP('08/04/2026 08:00', 'DD/MM/YYYY HH24:MI') 
                      AND TO_TIMESTAMP('08/04/2026 08:30', 'DD/MM/YYYY HH24:MI')
GROUP BY sql_id, user_id, program
ORDER BY max_temp_gb DESC;

En nuestro caso, encontramos que el SQL_ID 85v0ju71vfphg alcanzó un pico de 370 GB. Al revisar el reporte AWR (Automatic Workload Repository), la sección "Top SQL with Top Events" reveló lo siguiente:

• Evento: direct path write temp

• Wait Class: User I/O

• Top Row Source: HASH JOIN / HASH GROUP BY

¿Por qué una consulta necesitaría tanto espacio? Al obtener el plan con DBMS_XPLAN.DISPLAY_AWR, detectamos dos problemas críticos:

1. MERGE JOIN CARTESIAN: El motor intentó realizar un producto cartesiano (unir cada fila con todas las filas de otra tabla) debido a una condición de unión mal definida con una tabla. Esto multiplicó exponencialmente el set de datos intermedio.

2. SORT UNIQUE: El uso de UNION (en lugar de UNION ALL) obligó a un ordenamiento masivo para eliminar duplicados de un set de datos que ya estaba inflado por el cartesiano.

Para solucionar esto, el primer paso es auditar la lógica de las uniones (JOINs): asegurar que todas las tablas tengan su predicado de unión correspondiente en el WHERE o en la cláusula ON.

Si la lógica es correcta pero el optimizador sigue eligiendo un cartesiano por un error de estimación en las estadísticas, podemos intervenir usando el hint /*+ NO_CARTESIAN */. Asimismo, evaluamos cambiar UNION por UNION ALL si sabemos que los resultados de ambas consultas son disjuntos o si los duplicados son aceptables.

El ORA-1652 no se resuelve simplemente asignando más disco. Antes de ampliar, identifica el pico (ASH), confirma el evento (AWR) y audita la lógica (Plan de Ejecución). Optimizar el código es, en la gran mayoría de los casos, la forma más eficiente y profesional de resolver este error.

Read More