Bases de datos II Universidad del Cauca Ing. Wilson Ortega

Introducción El procesamiento de consultas hace referencia a la serie de actividades implicadas en la extracción de datos de una base de datos Los pasos básicos son: 1. Análisis y traducción 2. Optimización 3. Evaluación

Pasos de procesamiento Los usuario no siempre escriben la consulta de la forma óptima

Medidas del coste de una consulta Diferentes recursos Accesos a disco Tiempo de CPU En sistemas de bases de datos distribuidos o paralelos, el coste de la comunicación En grandes sistemas de bases de datos, los accesos a disco (que se miden como el número de transferencias de bloques de disco) son normalmente el coste más importante

Optimización de consultas Dada una consulta, suele haber gran variedad de métodos para calcular la respuesta. Es responsabilidad del sistema transformar la consulta tal y como la introdujo el usuario en una consulta equivalente que pueda calcularse de manera más eficiente. La evaluación de las consultas complejas implica muchos accesos a disco. Merece la pena asignar una cantidad considerable de procesamiento a la elección de un método que minimice esos accesos. La estrategia que escoja el sistema de bases de datos para la evaluación de una operación depende del tamaño de cada relación y de la distribución de los valores dentro de las columnas. Se almacenan estadísticas para cada relación. El primer paso para la selección de una estrategia de procesamiento de consultas es la búsqueda de una expresión del álgebra relacional que sea equivalente a la expresión dada y que se estime menos costosa de ejecutar.

Plan de ejecución en Oracle Cada vez que se ejecuta una sentencia Oracle crea un plan de ejecución de la sentencia. Un plan de ejecución define la forma en que oracle busca o graba los datos. Por ejemplo, va a usar o no los indices en una sentencia Si no definimos nuestra propia tabla se usa la tabla PLAN_TABLE EXPLAIN PLAN [SET STATEMENT_ID = 'text'] FOR sentencia; DELETE PLAN_TABLE; EXPLAIN PLAN FOR SELECT * FROM T_PEDIDOS WHERE CODPEDIDO = 5; DELETE PLAN_TABLE; EXPLAIN PLAN FOR SELECT * FROM T_PEDIDOS WHERE CODPEDIDO = 5; SELECT SUBSTR (LPAD(' ', LEVEL-1) || OPERATION || ' (' || OPTIONS || ')',1,30 ) "OPERACION", OBJECT_NAME "OBJETO" FROM PLAN_TABLE START WITH ID = 0 CONNECT BY PRIOR ID=PARENT_ID; SELECT SUBSTR (LPAD(' ', LEVEL-1) || OPERATION || ' (' || OPTIONS || ')',1,30 ) "OPERACION", OBJECT_NAME "OBJETO" FROM PLAN_TABLE START WITH ID = 0 CONNECT BY PRIOR ID=PARENT_ID;

Recomendaciones de optimización Crear índices sobre columnas lo más selectivas posibles Limitar los accesos a tablas remotas Utilizar la cláusula UNION ALL en lugar de UNION siempre que sea posible. UNION remueve los duplicados Considerar en algunos casos alternativas al Join (consultas anidadas, cláusula exists) Las condiciones (tanto de filtro como de join) deben ir siempre en el orden en que esté definido el índice (si existen índices estudiar la posibilidad de añadirlos) Para chequeos, siempre es mejor crear restricciones (constraints) que disparadores (triggers)

Recomendaciones de optimización Tener en cuenta que al crear un restricción de tipo PRIMARY KEY o UNIQUE, se crea automáticamente un índice sobre esa columna Utilizar siempre que sea posible las mismas consultas. La segunda vez que se ejecuta una consulta, se ahorrará mucho tiempo de parsing y optimización, así que se debe intentar utilizar las mismas consultas repetidas veces. Revisar las consultas periodicamente, puede no sean ya optimas debido al constante cambio en el tamaño de las tablas, la distribución de los valores, el esquema etc.

Recomendaciones de optimización Las consultas más utilizadas deben encapsularse en procedimientos almacenados. El plan de ejecucón queda almacenado. Los filtros de las consultas deben ser lo más específicos y concretos posibles. Es mucho más específico poner WHERE campo = 'a' que WHERE campo LIKE '%a%‘ Es muy recomendable utilizar siempre consultas que filtren por la clave primaria u otros campos indexados

Recomendaciones de optimización Evitar la condiciones IN ( SELECT…) sustituyéndolas por joins: cuando se utiliza un conjunto de valores en la clausula IN, se traduce por una condición compuesta con el operador OR. Esto es lento, ya que por cada fila debe comprobar cada una de las condiciones simples. Cuando se hace una consulta usando joins, el orden en que se ponen las tablas en el FROM influye en el plan de ejecución. Aquellas tablas que retornan más filas deben ir en las primeras posiciones, mientras que las tablas con pocas filas deben situarse al final de la lista de tablas

Recomendaciones de optimización Si en la cláusula WHERE se utilizan campos indexados como argumentos de funciones, el índice quedará desactivado. Una consulta cualificada con la cláusula DISTINCT debe ser ordenada por el servidor aunque no se incluya la cláusula ORDER BY Para comprobar si existen registros para cierta condición, no se debe hacer un SELECT COUNT(*) FROM X WHERE xxx, sino que se hace un SELECT 1 FROM X WHERE xxx.

Recomendaciones de optimización Si vamos a realizar una operación de inserción, borrado o actualización masiva, es conveniente desactivar los índices, ya que por cada operación individual se actualizarán los datos de cada uno de los índices. Una vez terminada la operación, volvemos a activar los índices para que se regeneren La mejor optimización es contar con una base de datos bien diseñada

Bibliografía Fundamentos de Bases de Datos. 4ta edición. A. Silberschatz