Optimización de Consultas Distribuidas (DBLinks) mediante el uso de Hints
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), unHASH UNIQUE(eliminación de duplicados) y múltiplesHASH JOINsobre unos 78,620 registros.El
HASH JOIN OUTERocurre localmente. Es decir, después de procesar los 78k registros locales y traer la data remota por la red, el servidor local intenta mezclarlos.
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.
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.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.
