Monitorización y diagnóstico de consultas en Denodo

«La consulta va lenta» es la frase que más veces he escuchado sobre cualquier capa de virtualización, y la que menos información aporta por sí sola. En Denodo, antes de tocar nada, hay que mirar el plan de ejecución: es la única forma de saber si el problema está en el origen de datos, en una operación intermedia como un JOIN o un GROUP BY, o en la propia caché.

Qué registra Virtual DataPort de cada consulta

Cada consulta que pasa por VDP queda anotada en el log de consultas del servidor, con un conjunto de columnas pensado para poder reconstruir después qué pasó exactamente. Entre las más útiles para diagnóstico están el identificador de sesión y de consulta, el usuario que la lanzó, la hora de inicio y fin, la duración total, el tiempo de espera antes de empezar a ejecutarse, el propio VQL, el número de filas devueltas, si la consulta llegó a completarse, si usó caché o no, y la interfaz de acceso (JDBC, ODBC, un servicio REST, etc.) desde la que llegó.

Ese log es el primer sitio al que conviene mirar cuando alguien dice «esto va lento»: muchas veces la duración larga no es tiempo de ejecución real, sino tiempo de espera en cola por concurrencia, y eso se ve directamente en el campo correspondiente sin necesidad de abrir ninguna herramienta gráfica.

La herramienta de diagnóstico y monitorización

Para ir más allá del log, Denodo ofrece una herramienta de diagnóstico y monitorización (DMT) pensada para observar el estado del servidor en tiempo real, además del propio Denodo Monitor para análisis histórico. Desde la herramienta de administración de Virtual DataPort también se puede consultar, tras ejecutar una consulta, su traza de ejecución: una representación en árbol donde cada nodo corresponde a una operación del plan (acceso a un origen, un join, una agregación…) con sus propios tiempos y propiedades.

Qué mirar dentro de un nodo del plan

Un método simple para aislar el problema

Cuando el origen del problema no es evidente a simple vista, conviene descartar posibilidades en orden en lugar de mirar el plan entero de golpe. Primero, comprobar si el cuello de botella está en el propio cliente que consume los resultados, ejecutando la consulta con CONTEXT('cache_return_query_results' = 'false') para que Denodo procese la consulta sin que el tiempo de recogida de resultados en el cliente distorsione la medición. Segundo, si se sospecha del origen de datos, lanzar el mismo SQL directamente contra ese origen con un cliente JDBC y comparar tiempos. Y por último, si el problema está dentro de Denodo, revisar en la traza qué nodos intermedios concentran el tiempo: operaciones como JOIN, GROUP BY, SEMIJOIN o FLATTEN son las candidatas habituales cuando el coste no viene de fuera.

Buenas prácticas al monitorizar

• Mira primero el log de consultas: distingue en segundos si el tiempo se fue en espera por concurrencia o en ejecución real.
• Usa DESC QUERYPLAN antes de lanzar consultas pesadas para verificar que los filtros se delegan donde esperas.
• Compara siempre contra el origen con un cliente JDBC directo antes de asumir que el problema es de Denodo.
• Presta atención a «swapping» y «memory limit reached» en la traza: son señales claras de que el problema es de recursos, no de plan de consulta.
• Si vas a automatizar alertas sobre consultas lentas, apóyate en las columnas del log de consultas en lugar de reinventar tu propio sistema de captura.

Ninguna de estas herramientas sustituye al conocimiento del modelo de datos: la traza te dice dónde se va el tiempo, pero decidir si ese join debería delegarse en origen, cachearse o reescribirse sigue siendo trabajo de quien diseñó la vista. Lo que sí cambia es que, con esta información delante, dejas de adivinar.