17 de agosto de 2012. Hace ya varios años tuve la oportunidad de participar en un importante proyecto de Business  Intelligence en IBERIA LAE, ahora llamada IAG, utilizando tecnología Oracle. Recuerdo que una  consulta aparentemente sencilla consumía demasiados recursos de máquina y tardaba mucho  tiempo en ejecutarse, más de lo razonable. Un colaborador de Oracle nos ofreció una solución que  por aquel entonces me impresionó mucho, y logró reducir el tiempo al orden de minutos, lo que antes se contaba por horas. Algunas versiones nuevas de Oracle han salido desde entonces, cambiando enormemente la  tecnología, y dotando al sistema de nuevas técnicas para mejorar el rendimiento de las consultas,  pero lo esencial que subyace al problema no ha cambiado sustancialmente. Empecemos por indicar que el tipo de consulta utilizada era una consulta correlacionada. Este tipo  de consultas eran y siguen siendo muy costosas en tiempo y hacen un consumo intensivo de los  recursos de máquina disponibles ya que se debe ejecutar una consulta para cada registro  recuperado de otra consulta. Ni qué decir tiene que cuanto mayor es el volumen de estas tablas, más costosa es la consulta, y no es precisamente una relación lineal. Y las tablas que teníamos que  gestionar tenían muchos, muchos registros. No es recomendable el uso de este tipo de consultas y,  siempre que sea posible, se deberían evitar. No es propósito comentar qué es una consulta correlacionada. En internet hay muchísimos artículos  técnicos que hablan sobre ello, por lo que supondré a partir de ahora que el lector sabe de qué  hablamos. La solución aportada para mejorar el rendimiento era la utilización de SQL dinámico. Básicamente  SQL dinámico consiste en la construcción en una cadena de caracteres en tiempo de ejecución de  una consulta SQL. Para esta construcción se puede utilizar toda la capacidad de PL/SQL, incluido  los cursores y parámetros en la consulta, implementados a través de variables host. Tampoco es propósito aquí comentar qué es SQL dinámico, o mejor, "construcción dinámica de  consultas SQL", internet también está lleno de artículos técnicos que hablan del tema, simplemente  comentar que frecuentemente se indica que el motivo principal para utilizar SQL dinámico es porque  en tiempo de ejecución no se conoce con exactitud la consulta SQL deseada. Pero también se puede utilizar para mejorar el rendimiento, como ha sido nuestro caso. Pero ¡ojo!, SQL dinámico no supone "per sé" una mejora en el rendimiento, hay que aplicar técnicas  específicas para lograrlo. El truco aquí consiste en conocer algunos de los pasos que Oracle hace para ejecutar una consulta.  Veamos: 1. Un análisis sintáctico, en el que se determina si la consulta contiene la palabras clave  adecuadas, como SELECT, FROM, WHERE ... etc.  2. Un análisis semántico, en el que se accede a las tablas del diccionario para comprobar que el  resto de la consulta está bien construida, es decir, que existen las tablas indicadas, que existen  los campos indicados y que éstos corresponden a las tablas que aparecen en la consulta, no  hay ambigüedades, etc. 3. La creación de un árbol de posibles planes de ejecución, cada uno de ellos con su coste  asociado. 4. La generación del plan de ejecución con el menor coste calculado. 5. Enlazar el plan de ejecución elegido con los elementos físicos de la base de datos:  tablespaces, datafiles, redologs, etc. 6. Ejecución de la consulta y extracción de las filas.  Como podemos ver el trabajo que subyace en la ejecución de una consulta es bastante grande, a  esto se le llama la fase de "parse" (en inglés viene a ser algo así como analizar o redistribuir). A  nosotros nos parece que lanzar una consulta no es gran cosa porque en la mayoría de los casos  enviamos la consulta al motor de base de dato y en muy pocos segundos tenemos la respuesta, pero las operaciones que tiene que realizar el motor de base de datos pueden ser muy costosas en  consumo de recursos de máquina. En el caso de las consultas correlacionadas se tiene que ejecutar, para cada registro recuperado de  la consulta más externa, una nueva consulta. Y en realidad para el motor de base de datos es una  nueva consulta porque cambia un contenido, que es precismente el valor que corresponda del  registro en curso de la consulta exterior. Y todo esto con el coste que conlleva. Y sí, en determinadas circunstancias hay consultas o requerimientos funcionales que van a necesitar incluso millones de operaciones parse para el mismo tipo de consultas, ya sea por consultas  correlacionadas o mediante procedimientos PL/SQL, con lo que la penalización del rendimiento va a  ser en muchos casos intolerable. La idea para mejorar el rendimiento consiste en evitarnos todas las operaciones "parse" de la  consulta interior. Para ello la consulta correlacionada de implementa en un procedimiento PL/SQL a  través de cursores y se utilizará el paquete dbms_sql, que proporciona una interfaz para el suso de  SQL dinámico. No voy a explicar aquí el uso de dbms_sql, ni "Native Dynamic SQL" como alternativa a ese paquete,  Ni tampoco voy a exponer largas cantidades de código, quien esté interesado ya sabe, Internet.  Simplemente comentar que la técnica básica es generar en un string la consulta interna, los datos del registro en curso de la consulta  externa se implementan mediante variables host. Se realiza el "parse", ¡una sola vez! mediante dbms_sql.parse y se enlazan las variables  mediante dbms_sql.bind_variable. La ejecución de la consulta se realiza mediante dbms_sql.execute.  Con esto la mejora del rendimiento es sustancial. Existen otras técnicas pero la indicada aquí es todavía viable y muy usada (por quien la  conozca, claro). SQL dinámco proporciona herramientas que nos ayudan a hacer un trabajo que realmente aporte valor. Sin embargo en el mundo de la  informática abundan ejemplos de utilización de SQL dinámico simplemente para generar  una consulta y ejecutarla, sin dotar al sistema del más mínimo valor añadido. Por esto, a mi me gusta pensar que  SQL dinámico, el cual aporta  realmente valor, no es lo mismo que  "generación dinámica de consultas  SQL". Hay una sutil diferencia,  quien lo quiera entender, pues bien,  y si no, también. Por último, recomendar un par de  libros que seguro serán de gran  ayuda. Proyecto de expresión y espacio para la tecnología, cultura, empresa, estética y humanidades en general Información legal  Oracle con SQL dinámico como método para mejorar el rendimiento ÚLTIMAS ENTRADAS INFORMÁTICA Las v’s de los datos (I). Volatilidad. Introducción a la programación para dispositivos móviles. La eterna presencia del fantasma del número mágico. Introducción Ver todas las entradas BUSINESS ADMINISTRATION La carrera profesional también se gestiona. Orientación al servicio informático: Una relación gana-gana. Cuadrante mágico para plataformas ETL y BI. Introducción Ver todas las entradas PSICOLOGÍA El miembro fantasma. Criterios diagnósticos. Psicología científica, básica y aplicada. Introducción Ver todas las entradas FOTOGRAFÍA Galería fotos de Córdoba. Introducción Ver todas las entradas AJEDREZ IX torneo media hora, ciudad Ávila. I open ciudad de Jaca. Torneos en Mislata - Valencia. Introducción Ver todas las entradas MERCADOS BURSÁTILES Elliot, Fibo y el 61,8%. 1 año del juego de las tres carteras. Señal TCM en Telefónica. Introducción Ver todas las entradas MISCELÁNEO RABASCO-MENDÍVIL recital piano cuatro manos. Ciclo de conferencias del CEC. Ética radical, la puerta de Texas y la tía Norica. Introducción Ver todas las entradas