Tesis de Grado en Ingenieria Informatica

1. “ Guía para la Optimización de Consultas en una Base de Datos Relacional Utilizando SQL” UNIVERSIDAD AUTONOMA GABRIEL RENE MORENO FACULTAD DE CIENCIAS EXACTAS Y TECNOLOGIA Carrera de Ingeniería Informática Elaborado por: Ubaldo Pérez Ferreira Proyecto de Grado Proyecto de Grado para optar al Título de: Licenciatura en Ingeniería Informática Santa Cruz de la Sierra – Bolivia

6. Parte II - Fundamentos Teóricos Modelo Relacional Lenguajes Relacional Sistema de Base de Datos El Proceso de Optimización de Consultas El Optimizador de Consultas El Modelo de Datos Relacional (MDR) fue propuesto por Codd en 1970 . El MDR, esta fundamentado en la teoría matemática de conjuntos, de ahí, su potencial. Los conjuntos en el MDR son denominados Dominios (D). Un Dominio es un conjunto de valores escalares del mimo tipo. La única herramienta de estructura de datos usada por el MDR es una Relación (R) .

8. Parte II - Fundamentos Teóricos Modelo Relacional Lenguajes Relacional Sistema de Base de Datos El Proceso de Optimización de Consultas El Optimizador de Consultas Un Lenguaje de Consulta Relacional sirve para que el usuario solicite información de la Base de Datos Relacional. Normalmente son de alto nivel, es decir con alguna similitud al lenguaje natural, lo que permite que sea fácil de aprender y de manipular por cualquier usuario L R1 R2 R3

10. Parte II - Fundamentos Teóricos Modelo Relacional Lenguajes Relacional Sistema de Base de Datos El Proceso de Optimización de Consultas El Optimizador de Consultas Expresión Algebraica . Las operaciones del Algebra Relacional, usualmente están incluidas dentro de una Expresión Algebraica; las mismas que especifican la manera en que los datos requeridos deben ser recuperados de las Relaciones.  A,B,X (  X=“aa” (R1 XR2)) El resultado de una Expresión Algebraica es uma nueva Relación Aplicando la Expresión Algebraica ss bb uu aa R2 Y X 234 123 ccc 213 222 bbb R1 234 111 aaa C B A aa 123 ccc aa 222 bbb aa 111 aaa X B A

11. Parte II - Fundamentos Teóricos Modelo Relacional Lenguajes Relacional Sistema de Base de Datos El Proceso de Optimización de Consultas El Optimizador de Consultas Árbol Algebraico . Las operaciones del Algebra Relacional, pueden ser representada en su totalidad en un Árbol Algebraico.  A,B,X (  X=“aa” (R1 XR2)) R1 R2  X=“aa”  A,B,X X 1ro. Producto Cartesiano 2do. Seleccionar las tuplas con X=“aa” 3ro. Proyectar A,B,X Lectura de abajo hacia arriba Herramienta Básica utilizada por los SGBD.

13. Parte II - Fundamentos Teóricos Modelo Relacional Lenguajes Relacional Sistema de Base de Datos El Proceso de Optimización de Consultas El Optimizador de Consultas Un Sistema de Gestión de Bases de Datos (SGBD o DBMS ‘Database Management System”) es el conjunto de programas que permiten Definir, Manipular y Utilizar la información que contienen las Bases de Datos, entre otras tareas (Autorizaciones, Seguridad,…) SGBD

14. Parte II - Fundamentos Teóricos Modelo Relacional Lenguajes Relacional Sistema de Base de Datos El Proceso de Optimización de Consultas El Optimizador de Consultas Programa de Aplicación Esquema de BD Consulta de Usaurio Tabla de Autorizacion Adm. de Accesos Concurrente Compilador LDD Procesador de Consultas Gestor De Base de Datos Gestor de Archivos Datos + Index Diccionario de Datos Compilador LMD Lenguaje SQL Control de Acceso

15. Parte II - Fundamentos Teóricos Modelo Relacional Lenguajes Relacional Sistema de Base de Datos El Proceso de Optimización de Consultas El Optimizador de Consultas El Proceso de Optimización de Consultas Datos + Index Diccionario de Datos Traductor (Parser) Árbol Relacional Plan de Ejecución Consulta SQL Resultado de la Consulta Optimizador de Consulta Motor de Ejecucion Reglas de Transformación de Expresiones Estadísticas de las Relaciones. Medidas de Costos.

16. Parte II - Fundamentos Teóricos An á lisis de la Consulta Selección de Caminos de Accesos Selección de Ordenes JOIN Uso de Tablas Temporales Selección del Plan de Ejecución Fases del Optimizador ASE Modelo Relacional Lenguajes Relacional Sistema de Base de Datos El Proceso de Optimización de Consultas El Optimizador de Consultas El Optimizador SYBASE (Adaptive Server Enterprice -ASE) , esta basado en costos, creado en 1979 para el SGBD SYSTEM R.

17. Parte III – Propuesta y Aplicación de la Guía Consideraciones Previa Descripción de los Pasos de Guía Aplicación de la Guía Propuesta La Guía es una herramienta de propósito general, en algunos casos puede ser muy compleja o muy simple. Consideraciones. No esta orientada a un SGBD en particular La Guía debe ser vista como una herramienta m a s en el proceso de Optimización de Consultas. La Guía puede ser utilizada este o no poblada la Base de Datos. La guía esta orientado a cierto de tipo de usuarios como ser: Administradores de Base de Datos, Diseñadores de Base de Datos y Programadores de Aplicaciones..

18. Parte III – Propuesta y Aplicación de la Guía Consideraciones Previa Descripción de los Pasos de Guía Aplicación de la Guía Propuesta Paso 1 Generar el Plan de Ejecución Paso 2 Reescribir la Consulta ¿Reescribir la Consulta? Paso 1 Generar el Plan de Ejecución Paso 3 Crear y Gestionar Índices ¿Ajustar y/o Crear Índices? Paso 1 Generar el Plan de Ejecución Paso 4 Ajustar el Esquema de la BD ¿Ajustar el Esquema de BD Paso 1 Generar el Plan de Ejecución SI NO SI SI NO NO Estadísticas Obsoletas? Análisis del Plan de Ejecución Expresiones SARG Orientar al uso de INDICES Existentes? Crear INDICES? Ajustar los Existentes Desnormalizar Adicionar Atributos Derivados Continua

31. Parte III – Propuesta y Aplicación de la Guía Consideraciones Previa Descripción de los Pasos de Guía Aplicación de la Guía Propuesta Esquema de la BD Valores. inv_header inv_detalle tiene 1 N create table inv_header ( nro_tran serial not null primary key , nro_doc integer not null , fecha date not null , … create table inv_detalle ( nro_tran integer not null , ing_egr char(1) not null , orden integer not null , cod_tv smallint not null , nro_valor integer … foreign key (nro_tran) references inv_header, primary key (nro_tran,ing_egr,orden,cod_tv,nro_valor), 95.21 3,840,140 26 inv_detalle 2.20 36,162 64 inv_header Tamaño de la Tabla (Mbyte) Numero de Filas Tamaño de la tabla (Bytes) Nombre Tabla

32. Parte III – Propuesta y Aplicación de la Guía Consideraciones Previa Descripción de los Pasos de Guía Aplicación de la Guía Propuesta Ejemplo 1. Ejemplo 2. Ejemplo 3. Optimización Consulta Nro. 1. QUERY: ------ select * from inv_header where nro_tran=100 or nro_tran=300 Estimated Cost: 2 Estimated # of Rows Returned: 2 1) inv_header: SEQUENTIAL SCAN Filters: (inv_header.nro_tran = 100 OR inv_header.nro_tran = 300 ) select * from inv_header where nro_tran=100 or nro_tran=300 Resultado Tiempo: 4.1 min. Método de Acceso: FULL TABLE SCAN Listar el detalle de valores de las transacciones numero 100 y 300. Análisis Existe un índice sobre el campo nro_tran, sin embargo no fue utilizado, esto debido a que la cláusula WHERE no es SARGABLE. PASO 1.

33. Parte III – Propuesta y Aplicación de la Guía Consideraciones Previa Descripción de los Pasos de Guía Aplicación de la Guía Propuesta Ejemplo 1. Ejemplo 2. Ejemplo 3. Optimización Consulta Nro. 1. QUERY: ------ select * from inv_header where nro_tran=1 union select * from inv_header where nro_tran=300 Estimated Cost: 2 Estimated # of Rows Returned: 2 1) inv_header: INDEX PATH (1) Index Keys: nro_tran Lower Index Filter: inv_header.nro_tran = 100 Union Query: ------------ 1) inv_header: INDEX PATH (1) Index Keys: nro_tran Lower Index Filter: inv_header.nro_tran = 300 Solución. Reescribir la consulta, para que la cláusula WHERE sea SARGABLE, se utilizo la Regla 9 del paso 2. select * from inv_header where nro_tran=100 union select * from inv_header where nro_tran=300 Resultado. Tiempo: 0.01 min. Método de Acceso: INDEX PATH PASO 2. PASO 1.

34. Parte III – Propuesta y Aplicación de la Guía Consideraciones Previa Descripción de los Pasos de Guía Aplicación de la Guía Propuesta Ejemplo 1. Ejemplo 2. Ejemplo 3. Optimización Consulta Nro. 2. QUERY: ------ select * from inv_detalle where cod_tv=2 and nro_valor=700021 Estimated Cost: 2 Estimated # of Rows Returned: 1 1) inv_detalle: SEQUENTIAL SCAN Filters: (inv_detalle.cod_tv = 2 AND inv_detalle.nro_valor = 700021 ) select * from inv_detalle where cod_tv=2 and nro_valor=700021 Listar el detalle de movimiento de la factura numero 700021 . Resultado. Tiempo: 8.3 min. Método de Acceso: FULL TABLE SCAN Análisis No existe un índice sobre los campos cod_tv y nro_valor, esta situación hace que el SGBD se decida por un acceso FULL TABLE SCAN. PASO 1.

35. Parte III – Propuesta y Aplicación de la Guía Consideraciones Previa Descripción de los Pasos de Guía Aplicación de la Guía Propuesta Ejemplo 1. Ejemplo 2. Ejemplo 3. Optimización Consulta Nro. 2. QUERY: ------ select * from inv_detalle where cod_tv=2 and nro_valor=700021 Estimated Cost: 2 Estimated # of Rows Returned: 1 1) informix.inv_detalle: INDEX PATH (1) Index Keys: cod_tv nro_valor Lower Index Filter: (informix.inv_detalle.cod_tv = 2 AND informix.inv_detalle.nro_valor = 700021 ) Análisis. Se observa que la cláusula WHERE es de tipo SARGABLE, sin embargo la tabla inv_detalle no cuenta con los índices adecuado. Solución. Se procedió a crear un índice: CREATE INDEX idx_inv_detalle1 ON inv_detalle(cod_tv,nro_valor) . Resultado. Tiempo: 0.01 min. Método de Acceso: INDEX PATH PASO 3. PASO 1.

36. Parte III – Propuesta y Aplicación de la Guía Consideraciones Previa Descripción de los Pasos de Guía Aplicación de la Guía Propuesta Ejemplo 1. Ejemplo 2. Ejemplo 3. Optimización Consulta Nro. 3. QUERY: ------ select inv_detalle.* from inv_header,inv_detalle where inv_header.nro_tran=inv_detalle.nro_tran and year(fecha)="2004" and month(fecha)="01" Estimated Cost: 4 Estimated # of Rows Returned: 1 1) inv_header: SEQUENTIAL SCAN Filters: (YEAR(inv_header.fecha )=2004 AND MONTH(inv_header.fecha )=1 ) 2) informix.inv_detalle: INDEX PATH (1) Index Keys: nro_tran ing_egr orden cod_tv nro_valor Lower Index Filter: inv_detalle.nro_tran=inv_header.nro_tran NESTED LOOP JOIN select inv_detalle.* from inv_header,inv_detalle where inv_header.nro_tran=inv_detalle.nro_tran and year(fecha)="2004" and month(fecha)="01" Listar el detalle de movimiento de valores correspondiente al mes de enero del 2004. Resultado Tiempo: 10.4 min. Método de Acceso: FULL TABLE SCAN Análisis Se observa que la tabla inv_detalle no tiene el indice adecuado, razón por la cual el SGDB elige el FULL TABLE SCAN. PASO 1.

37. Parte III – Propuesta y Aplicación de la Guía Consideraciones Previa Descripción de los Pasos de Guía Aplicación de la Guía Propuesta Ejemplo 1. Ejemplo 2. Ejemplo 3. Optimización Consulta Nro. 3. QUERY: ------ select inv_detalle.* from inv_header,inv_detalle where inv_header.nro_tran=inv_detalle.nro_tran and year(fecha)="2004" and month(fecha)="01" Estimated Cost: 4 Estimated # of Rows Returned: 1 1) inv_header: SEQUENTIAL SCAN Filters: ( YEAR(inv_header.fecha )=2004 AND MONTH(inv_header.fecha )= 1 ) 2) informix.inv_detalle: INDEX PATH (1) Index Keys: nro_tran ing_egr orden cod_tv nro_valor Lower Index Filter: inv_detalle.nro_tran=inv_header.nro_tran NESTED LOOP JOIN Solución. Se creo el índice en la tabla inv_header utilizando el campo fecha. CREATE INDEX idx_inv_header1 ON inv_header(fecha) Resultado. Tiempo: 10.4 min. Método de Acceso: FULL TABLE SCAN Análisis El plan no varia ni en tiempo y ni en el tipo de acceso, pese a que se creo el índice. El problema esta en la presencia de funciones en la cláusula WHERE. PASO 3. PASO 1.

38. Parte III – Propuesta y Aplicación de la Guía Consideraciones Previa Descripción de los Pasos de Guía Aplicación de la Guía Propuesta Ejemplo 1. Ejemplo 2. Ejemplo 3. Optimización Consulta Nro. 3. QUERY: ------ select inv_detalle.* from inv_header,inv_detalle where inv_header.nro_tran=inv_detalle.nro_tran and fecha between &quot;01/01/2004&quot; and &quot;31/01/2004&quot; Estimated Cost: 4 Estimated # of Rows Returned: 1 1) inv_header: INDEX PATH (1) Index Keys: fecha Lower Index Filter: inv_header.fecha >= 01/01/2004 Upper Index Filter: inv_header.fecha <= 31/01/2004 2) inv_detalle: INDEX PATH (1) Index Keys: nro_tran ing_egr orden cod_tv nro_valor Lower Index Filter: inv_detalle.nro_tran = inv_header.nro_tran NESTED LOOP JOIN Solución. Reescribir la consulta, para que la cláusula WHERE sea SARGABLE, se utilizo la Regla 11 del paso 2. select inv_detalle.* from inv_header,inv_detalle where inv_header.nro_tran=inv_detalle.nro_tran and fecha between &quot;01/01/2004&quot; and &quot;31/01/2004&quot; Resultado. Tiempo: 0.01 min. Método de Acceso: INDEX PATH PASO 2. PASO 1.

41. MUCHAS GRACIAS.

42. MUCHAS GRACIAS.

43. Parte II - Fundamentos Teóricos Modelo Relacional Lenguajes Relacional Sistema de Base de Datos El Proceso de Optimización de Consultas El Optimizador de Consultas Estadísticas de la Base de Datos. Además, se utiliza información acerca de los índices Volver

44. Parte II - Fundamentos Teóricos Modelo Relacional Lenguajes Relacional Sistema de Base de Datos El Proceso de Optimización de Consultas El Optimizador de Consultas Medidas de Costos . El costo de un Plan de Ejecución se hace en función de la cantidad de CPU utilizada y de la cantidad de páginas de disco rescatadas . b.1. Búsqueda Lineal (Full Table Scan o Table Scan) b.2. Índice Primario, igualdad en la clave . b.3. Índice Secundario, igualdad . Volver La mas costosa La mas eficiente +/- eficiente

45. Parte II - Fundamentos Teóricos Modelo Relacional Lenguajes Relacional Sistema de Base de Datos El Proceso de Optimización de Consultas El Optimizador de Consultas Reglas de Equivalencias de Expresiones. Una regla de equivalencia permite transformar una expresion E1 en la otra E2, mientras se preserva la equivalencia . Aplicando las Reglas Volver

46. Parte II - Fundamentos Teóricos Modelo Relacional Lenguajes Relacional Sistema de Base de Datos El Proceso de Optimización de Consultas El Optimizador de Consultas Se analiza cada tabla con el fin de reconocer los SARG (Search Argument-able, argumentos de búsqueda) Análisis de la Consulta. Un SARG limita el número de filas que satisfacen la consulta. (Atributos selectivos) x , y pertenecen a la misma tabla, z es foráneo. Volver x + 2 = 20 x = 20 - 2 x LIKE '%tern' x LIKE 'pat%' x NOT IN (4, 5, 6) x IN (4, 5, 6) x = y x = z x = 4 OR y = 5 x > 25 x IS NOT NULL x IS NULL x <> 10 x = 10 Expresion Non SARG Expresiones SARG

47. Parte II - Fundamentos Teóricos Modelo Relacional Lenguajes Relacional Sistema de Base de Datos El Proceso de Optimización de Consultas El Optimizador de Consultas Es hacer calzar las cláusulas SARG con los índices existentes en la BD, además compara los costos versus un FULL TABLE SCAN . Selección de Índices. ASE usa las estadísticas de distribución de datos de las Estadísticas de la BD, para estimar el costo de los caminos de acceso. Volver El objetivo general es calzar un SARG con un índice para evitar un FULL TABLE SCAN .

48. Parte II - Fundamentos Teóricos Modelo Relacional Lenguajes Relacional Sistema de Base de Datos El Proceso de Optimización de Consultas El Optimizador de Consultas … FROM Tabla1, Tabla2,Tablan Selección de Ordenes JOIN. La cláusula FROM no dicta el orden en el cual las tablas deben ser procesadas . Se evalúa todas las permutaciones razonables y se estima el costo total en términos de tiempo de E/S. Volver El escenario de costo en el peor caso para un join es el que implementa un FULL TABLE SCAN en ambas tablas . 99.999% 148512 20922789888000 16 99.7% 11088 3628800 10 98.3% 6048 362880 9 92.5% 3024 40320 8 73.3% 1344 5040 7 30% 504 720 6 Ahorro Método Optimizado N! Número de Tablas

49. Parte II - Fundamentos Teóricos Modelo Relacional Lenguajes Relacional Sistema de Base de Datos El Proceso de Optimización de Consultas El Optimizador de Consultas Dado que las tablas temporales producen un procesamiento adicional y consumo de E/S el optimizador debe decidir si debe crear o no estas tablas. Uso de Tablas Temporales. Para el caso de la cláusula GROUP BY, siempre se debe crear una tabla temporal para realizar el agrupamiento. Para el caso de la cláusula DISTINCT, se debe crear una tabla que ordene los valores y elimine los duplicados. Si existe un índice único no es necesario. Para el caso de la cláusula ORDER BY, la utilización de una tabla dependerá de los índices sobre la tabla. Volver

50. Parte II - Fundamentos Teóricos Modelo Relacional Lenguajes Relacional Sistema de Base de Datos El Proceso de Optimización de Consultas El Optimizador de Consultas Sin embargo, no siempre el Optimizador seleccione el mejor Plan. Selección del Plan de Ejecución. De todos los Planes generados por ASE, la selección del Plan de Ejecución Optimo, esta determinado por la solución que tenga el menor costo estimado. ¿Se consideró los índices existentes en cada tabla o se está realizando un FULL TABLE SCAN? ¿Se utilizan tablas temporales para procesar la consulta ? ¿Cuales son los órdenes de JOIN que utiliza el optimizador para resolver la consulta ? ASE y los demás Optimizadores, proporciona una herramienta llamada SHOWPLAN, que devuelve al usuario un detalle del plan de ejecución , en la cual se puede verificar que: Volver