guía para la optimización de consultas
TRANSCRIPT
“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
Temario
• Parte I. Perfil del Proyecto.– Antecedentes.– Justificación.– Objetivos.
• Parte II: Fundamentos Teóricos.– Modelo de Datos Relacional.– Lenguajes Relacionales.– Sistemas de Gestión de Base de Datos Relacionales.– Conceptos del Procesamiento de Consultas.– El Optimizador de Consultas.
• Parte III: Propuesta y Aplicación de la Guía para la Optimización de Consultas.
– Descripción de la Guía Propuesta• Consideraciones Previa para el Uso de la Guía.• Paso 1. Generar y analizar el Plan de Ejecución.• Paso 2. Reescribir la consulta SQL.• Paso 3. Crear y Gestionar Indices.• Paso 4. Ajuste al Esquema de la Base de Datos.
– Aplicación de la Guía Propuesta• Consideraciones Previa para el Uso de la Guía.• Ejemplo 1. • Ejemplo 2.• Ejemplo 3.
• Conclusiones y Recomendaciones.
Parte I - Perfil del Proyecto
Antecedentes
Justificación
Objetivos
Antecedentes
Justificación
Objetivos
En las Aplicación Productiva, existe la posibilidad de encontrar algunas Consultas SQL, que al momento de ejecutarse, generen problemas en el SBD, tales como:
-Elevada carga del CPU -Bloquean procesos de trabajo durante largo tiempo. -Leen muchos bloques de datos a la memoria intermedia (Paginamiento)-Los discos están fuertemente cargados.
Las Consultas SQL que generan este tipo de problema, se las denomina “COSTOSAS” o “INEFICIENTES”.
Y por supuesto estos problemas son la causa de:Malestar entre los usuarios y/o clientes.Mala imagen corporativa, etc.
Parte I - Perfil del Proyecto
¿Que hacer cuando se presenta una Consulta SQL costosa?
Antecedentes
Justificación
Objetivos
Antecedentes
Justificación
Objetivos
¿Por donde empezar?, si no se cuenta con pasos bien definidos, resolver el problema de una Consulta SQL costosa, puede tomar horas de trabajo.
Es así, que se propone una Guía para resolver el problema de las Consultas SQL costosas.
Parte I - Perfil del Proyecto
Objetivo principal.• Diseñar una Guía para la Optimización de
Consultas en una Base de Datos Relacional utilizando SQL .
Objetivos Específicos.– Describir las Fases del Proceso de Optimización
de Consultas.– Detallar los componentes y funcionamiento de un
Optimizador de Consultas. – Exponer el contenido de un Plan de Ejecución.– Detallar las reglas para evitar formular Consultas
SQL costosas.– Detallar las reglas para Crear y Gestionar índices.– Explicar el contenido de las Estadísticas del
Catalogo de Base de Datos.
Antecedentes
Justificacion
Objetivos
Antecedentes
Justificacion
Objetivos
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
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 Edgar Frank, Codd en 1970.
Este Modelo, se fundamenta en la TEORIA MATEMATICA 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 este Modelo es una Relación (R).
04/11/23 04:59 PM
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
Modelo Relacional
Lenguajes Relacional
Sistema de Base de Datos
El Proceso de Optimización de Consultas
El Optimizador de Consultas
Una Relación R , es representada como una Tabla.
A1 … An
…
V1 … Vn
…
Tupla, conjunto de valores t1…tm,
ti=(v1,…,vn) / v1 A1 … vn An
Atributo, papel que desempeña D en R.Grado (n) C
ard
inal
idad
(m
).
ESQUEMA
INSTANCIA
Restricciones de Integridad sobre las Relaciones.
Una Llave Primaria (PK), es un atributo o un conjunto de atributos, que sirven para identificar una fila una relación. No se permiten valores NULOS en PK.
Una Llave Foranea (PF), es uno o mas atributos comunes entre dos Relaciones.
04/11/23 04:59 PM
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
Modelo Relacional
Lenguajes Relacional
Sistema de Base de Datos
El Proceso de Optimización de Consultas
El Optimizador de Consultas
Operaciones adicionales
Estas operaciones pueden ser expresadas sobre la base de las primeras cinco
Operaciones Básicas
Selección ( )
Proyección ()
Producto Cartesiano ()
Unión ()
Diferencia (-)
Intersección ()
Reunión con predicado(|X|p)
Reunión natural (|X|)
División ()
Operaciones Unarias
Operaciones Binarias
El Algebra Relacional: Es un lenguaje PROCEDIMENTAL, y consiste en un conjunto de operaciones de alto nivel que operan sobre
Relaciones
Parte II - Fundamentos Teóricos
A B C
aaa 111 234
R1 bbb 222 213
ccc 123 234
X Y
R2 aa uu
bb ss
Modelo Relacional
Lenguajes Relacional
Sistema de Base de Datos
El Proceso de Optimización de Consultas
El Optimizador de Consultas
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, son formuladas dentro de una Expresión Algebraica; las mismas que especifican la manera en que los datos deben ser recuperados de las Relaciones.
A,B,X( X=“aa”(R1XR2))
El resultado de una Expresión Algebraica es uma nueva Relación
Aplicando la Expresión Algebraica
A B X
aaa 111 aa
bbb 222 aa
ccc 123 aa
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
Modelo Relacional
Lenguajes Relacional
Sistema de Base de Datos
El Proceso de Optimización de Consultas
El Optimizador de Consultas
Árbol Algebraico. Las Expresiones Algebraicas, pueden ser representada en su totalidad en un Árbol Algebraico.
A,B,X( X=“aa”(R1XR2))
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.
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
Modelo Relacional
Lenguajes Relacional
Sistema de Base de Datos
El Proceso de Optimización de Consultas
El Optimizador de Consultas
Lenguaje SQL (Structure Query Languaje). Implementado en la mayoría de los SGBD, es un lenguaje NO PROCEDIMENTAL, al igual que el Algebra Relacional opera sobre Relaciones
La mayoría de las operaciones del Algebra relacional pueden ser formuladas en el SQL.
La Estructura Básica de una expresión en SQL esta compuesta de tres cláusulas:
SELECT A1, A2,...,An // Que atributos
FROM r1, r2,...,rm // De que relaciones
WHERE P // Que tuplas
[GROUP BY A1, A2,...,An] // Agrupador
[HAVING PG] // Predicado para el grupo
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
Modelo Relacional
Lenguajes Relacional
Sistema de Base de Datos
El Proceso de Optimización de Consultas
El Optimizador de Consultas
Sistema de Gestión de Bases de Datos (SGBD). Es el conjunto de Programas que permiten: Definir y Manipular la información que contienen las Bases de Datos, entre otras tareas que realiza como ser: Autorizaciones, Seguridad, Recuperación
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
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
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
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.
Ordenes Join.
Selección del Plan Optimo
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
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 para el uso de Guía.
No esta orientada a un SGBD en particular
La Guía debe ser vista como una herramienta mas 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.
La guía esta fundamentada en la “Optimización de Rendimientos de Sistemas” propuesta por SAP.
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
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
SINO
SI
SI
NO
NO
Estadísticas Obsoletas?
Análisis del Plan de Ejecución
Orientar al uso de INDICES Existentes?
Crear INDICES?
Ajustar los Existentes
Desnormalizar
Adicionar Atributos Derivados
Continua
Parte III – Propuesta y Aplicación de la Guía
Consideraciones Previa
Descripción de los Pasos de Guía
Paso 1.
Paso 2.
Paso 3.
Paso 4.
Aplicación de la Guía Propuesta
Consideraciones Previa
Descripción de los Pasos de Guía
Paso 1.
Paso 2.
Paso 3.
Paso 4.
Aplicación de la Guía Propuesta
Paso 1. Generar el Plan de Ejecución
Entre otros, el Plan de Ejecución muestra el orden lógico en la cual se acceden a las tablas y el método de acceso que utiliza para leer cada tabla .
Verificar que las Estadísticas de las Tablas no sean Obsoletas. Actualizar las Estadísticas puede llevar horas de trabajo.
Los SGBD proporcionan una herramienta llamada SHOWPLAN, que muestra al usuario un detalle del Plan de Ejecución:
¿Cual es el tiempo de ejecución de la consulta (ms, seg, min)?
¿Cuántas tuplas se estima recuperar?
¿Cuál es el costo de la consulta (interno SGBD)?
¿Se consideró los INDICES EXISTENTE 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 ?
Parte III – Propuesta y Aplicación de la Guía
Consideraciones Previa
Descripción de los Pasos de Guía
Paso 1.
Paso 2.
Paso 3.
Paso 4.
Aplicación de la Guía Propuesta
Consideraciones Previa
Descripción de los Pasos de Guía
Paso 1.
Paso 2.
Paso 3.
Paso 4.
Aplicación de la Guía Propuesta
Acceso Index Scan
0.00
0.20
0.40
0.60
0.80
1.00
1.20
Cantidad de Tuplas
Tie
mp
o (
min
)
Acceso Full Table Scan
0.0020.0040.0060.0080.00
100.00120.00140.00160.00180.00200.00
n100
n500
0
n500
00
n100
000
n200
000
n500
000
n100
0000
n200
0000
Cantidad de Tuplas
Tie
mp
o (
min
)
Si existe un acceso FULL TABLE SCAN, en una consulta, esta tiene la probabilidad de ser costosa a mayor cantidad de datos.
Full Table Scan Vs. Index Scan
Full Table Scan Index Scan
Parte III – Propuesta y Aplicación de la Guía
Consideraciones Previa
Descripción de los Pasos de Guía
Paso 1.
Paso 2.
Paso 3.
Paso 4.
Aplicación de la Guía Propuesta
Consideraciones Previa
Descripción de los Pasos de Guía
Paso 1.
Paso 2.
Paso 3.
Paso 4.
Aplicación de la Guía Propuesta
Planes de Ejecución para diferentes SGBD.
Motor de Base de Datos
Plan de Ejecución Análisis del Plan de Ejecución
INFORMIX 1. SELECT statement2. INDEX PATH3. INDEX KEY: idx_customer4. LOWER INDEX FILTER: ( customer_num=101)
La línea dos indica que INFORMIX accede mediante un índice. La línea tres indica que el índice utilizado en idx_customer, la línea cuatro indica que se utilizó el campo customer_num como filtro
ORACLE 1. SELECT statement2. TABLE ACCES BY INDEX ROWID customer_num=1013. INDEX UNIQUE SCAN idx_customer
La línea dos indica que se especifica que el acceso es vía índice y además utilizando el filtro customer_num=101, la línea tres indica que el índice utilizado es el idx_customer.
SQL SERVER 1. SELECT statement2. CLUSTER INDEX SEEK (idx_customer)3. SEEK:( customer_num=@101
La línea dos se indica que se utiliza el índice idx_customer, la línea tres indica que la busque utilizo el filtro customer_num=@101.
DB/2 1. SELECT statement2. FETCH customer_num=1013. SORT4. IXSCAN INDEX idx_customer
La línea dos indica que se utilizo el filtro customer_num=101, la línea tres indica que el índice esta ordenado, y en la línea cuatro se índica que se utiliza el índice idx_customer.
SELECT *
FROM Customer WHERE customer_num = 101
Volver
Parte III – Propuesta y Aplicación de la Guía
Consideraciones Previa
Descripción de los Pasos de Guía
Paso 1.
Paso 2.
Paso 3.
Paso 4.
Aplicación de la Guía Propuesta
Consideraciones Previa
Descripción de los Pasos de Guía
Paso 1.
Paso 2.
Paso 3.
Paso 4.
Aplicación de la Guía Propuesta
Paso 2. Reescribir la Consulta.
SELECT DISTINCT fname
FROM customer
WHERE customer_num IN
(SELECT customer_num
FROM orders
WHERE order_date = “20/01/1989”)
SELECT DISTINCT fname
FROM customer
WHERE customer_num = ANY
( SELECT customer_num
FROM orders
WHERE order_date = “20/01/1989”)
SELECT DISTINCT fname
FROM customer
WHERE EXISTS
( SELECT FROM ORDERS
WHERE customer.customer_num = orders.customer_num
AND order_date = “20/01/1989”)
SELECT DISTINCT fname
FROM customer, orders
WHERE customer.customer_num = orders.customer_num
AND order_date = “20/01/1989”
SELECT DISTINCT fname
FROM customer
WHERE (SELECT COUNT() FROM orders
WHERE customer.customer_num = orders.customer_num
AND order_date = “20/01/1989”)>0
SELECT DISTINCT fname
FROM customer
WHERE “20/01/1989” IN
(SELECT order_date
FROM orders
WHERE customer.customer_num = orders.customer_nu ).
SELECT DISTINCT fname
FROM customer
WHERE “20/01/1989” = ANY
(SELECT order_date
FROM orders
WHERE customer.customer_num = orders.customer_num)
SELECT fname
FROM customer, orders
WHERE order_date=“20/01/1989”
AND P.customer_num = S.customer_num
GROUP BY fname
El SQL permite escribir una consulta de diferentes maneras, sin embargo, esto implica una estrategia de acceso diferente.
Parte III – Propuesta y Aplicación de la Guía
Consideraciones Previa
Descripción de los Pasos de Guía
Paso 1.
Paso 2.
Paso 3.
Paso 4.
Aplicación de la Guía Propuesta
Consideraciones Previa
Descripción de los Pasos de Guía
Paso 1.
Paso 2.
Paso 3.
Paso 4.
Aplicación de la Guía Propuesta
Reglas para evitar escribir Consultas SQL costosas.R1. Transferir Pequeña Cantidad de Datos.
R2. Usar los Campos Indexados en la Cláusula WHERE
campo indexado = expresión
R3. Si existen Índices Compuestos, Utilice los Primeros Campos.
Si se tiene un índice compuesto con los campos A, B y C
WHERE A=1
WHERE A>=12 AND A<=15
WHERE A=1 AND B<5
Usa el índice
WHERE B=10
WHERE C=212
WHERE B>=12 AND C=15
No usa el índice
R4. Evitar el Uso de la Cláusula NOT IN R5. Evitar Expresiones Regulares Difíciles en la Cláusula WHERE.
WHERE fname LIKE “*sen*”
WHERE total_price - 10 = 200 * (13/100) = 36
Parte III – Propuesta y Aplicación de la Guía
Consideraciones Previa
Descripción de los Pasos de Guía
Paso 1.
Paso 2.
Paso 3.
Paso 4.
Aplicación de la Guía Propuesta
Consideraciones Previa
Descripción de los Pasos de Guía
Paso 1.
Paso 2.
Paso 3.
Paso 4.
Aplicación de la Guía Propuesta
Reglas para evitar escribir Consultas SQL costosas.
R12. Usar Tablas Temporales para Agilizar la Consulta.
R6. Evitar no Iniciar una Serie de Substring
WHERE fname[4,2]=“SC”
R7. Evitar Joins de Cadenas Largas
WHERE TABLA1.nombre=TABLA2.nombre
R8. Evitar Subconsulta Correlativas.
SELECT item FROM A
WHERE item IN (SELECT item FROM B WHERE B.num=50).
R9. Uso de la Cláusula UNION para Eliminar el Full Table Scan.
R10. Aplicar Criterios Sobre uno de los Lados del Join.
R11. Evitar el Uso de Funciones en la Cláusula WHERE.
SELECT * FROM customer
WHERE UPERCASE(fname)=”MARIO CLAROS”Volver
Parte III – Propuesta y Aplicación de la Guía
Consideraciones Previa
Descripción de los Pasos de Guía
Paso 1.
Paso 2.
Paso 3.
Paso 4.
Aplicación de la Guía Propuesta
Consideraciones Previa
Descripción de los Pasos de Guía
Paso 1.
Paso 2.
Paso 3.
Paso 4.
Aplicación de la Guía Propuesta
Paso 3. Crear y Gestionar Índices.
Los INDICES se utilizan para agilizar las búsquedas de información.
¿Si los índices proporcionan celeridad, por qué no indexar todas las columnas?.
Mediante el uso de índices se evita el FULL TABLE SCAN.
Tipos de Indices.
Índices Primario, son creados sobre los campos llaves primaria.Índices Secundarios, son creados sobre los campos llaves foráneas, o sobre atributos con alta selectividad.
Actualizar, borrar e insertar datos sobre una columna indexada consume más tiempo.
Si hay muchos índices, existe la probabilidad de que el Optimizador seleccione índice incorrecto.
Los índices en una tabla como regla de oro no mas de 5.
Parte III – Propuesta y Aplicación de la Guía
Consideraciones Previa
Descripción de los Pasos de Guía
Paso 1.
Paso 2.
Paso 3.
Paso 4.
Aplicación de la Guía Propuesta
Consideraciones Previa
Descripción de los Pasos de Guía
Paso 1.
Paso 2.
Paso 3.
Paso 4.
Aplicación de la Guía Propuesta
Reglas para crear índices.
R1. Campos Indexados en Criterios de Consultas. Los campos definidos como PK ya están indexados, pero se deben investigar aquellos campos que se incluyen en muchas consultas
R2. Joins con Campos Indexados. Si existe un JOIN entre dos o mas tablas, los campos comunes obligatoriamente deben ser creados como índices.
R3. Usar Índices de Múltiples Campos Cuando sea Necesario. usar índices sobre campos sustitutos, en lugar de tener índices con campos
compuesto.
R4. Evitar Valores Nulos en un Índices. Si un atributo es definido como índice, evite los valores NULL.
R5. Atributos en la cláusula ORDER BY. Si existen atributos que aparecen frecuentemente en la cláusula ORDER BY, deben creados como indices compuestos.
Parte III – Propuesta y Aplicación de la Guía
Consideraciones Previa
Descripción de los Pasos de Guía
Paso 1.
Paso 2.
Paso 3.
Paso 4.
Aplicación de la Guía Propuesta
Consideraciones Previa
Descripción de los Pasos de Guía
Paso 1.
Paso 2.
Paso 3.
Paso 4.
Aplicación de la Guía Propuesta
Reglas para crear índices.
R6. Usar Índices Selectivos. Se deben indexar aquellos campos con alta SELECTIVIDAD.
La selectividad de un atributo es:
número de valores distintos/número de tuplas de la tabla.
1000 registros, y una columna indexada de la tabla tiene 950 valores diferentes, la selectividad del índice es 0.95 (950/1000).
La mejor selectividad es 1 (llaves primarias)
R7. Índices Compuestos Vs. Varios Índices con una Sola Columna. Cuando se va a crear un índice compuesto, debe valorarse si la selectividad de ese índice va a ser considerablemente mayor con varias columnas que con una.
Volver
Parte III – Propuesta y Aplicación de la Guía
Consideraciones Previa
Descripción de los Pasos de Guía
Paso 1.
Paso 2.
Paso 3.
Paso 4.
Aplicación de la Guía Propuesta
Consideraciones Previa
Descripción de los Pasos de Guía
Paso 1.
Paso 2.
Paso 3.
Paso 4.
Aplicación de la Guía Propuesta
Paso 4. Ajustar el Esquema de la Base de Datos.
Sin embargo hay que tener en cuenta los siguientes factores:
• La desnormalización hace que la implementación sea más compleja.
• La desnormalización hace que se sacrifique la flexibilidad.
• La desnormalización puede hacer que los accesos a datos sean más rápidos, pero hace que las actualizaciones sean lentas.
Al realizar el diseño lógico se recomienda llegar, al menos, hasta la 3FN, para obtener un esquema con una estructura consistente y sin redundancias.
Pero, a menudo, sucede que las BD Normalizadas no proporcionan la máxima eficiencia a las Consultas SQL. Por lo tanto, hay que volver atrás y desnormalizar, sacrificando los beneficios de la normalización para mejorar las Consultas.
Parte III – Propuesta y Aplicación de la Guía
Consideraciones Previa
Descripción de los Pasos de Guía
Paso 1.
Paso 2.
Paso 3.
Paso 4.
Aplicación de la Guía Propuesta
Consideraciones Previa
Descripción de los Pasos de Guía
Paso 1.
Paso 2.
Paso 3.
Paso 4.
Aplicación de la Guía Propuesta
Reglas para la Desnormalización de Relaciones. • R1. Introducir atributos Derivados.
• R2. Combinar Relaciones de 1:1
• R3. Duplicar Atributos no Clave en Relaciones de 1:N para Reducir los Joins.
• R4. Tablas de Referencias.
• R5. Duplicar Llaves Foráneas en Relaciones de 1:N para Reducir los Joins.
• R6. Duplicar Atributos en Relaciones de N:M para Reducir los Joins.
• R7. Introducir Grupos Repetitivos.
Volver
Parte III – Propuesta y Aplicación de la Guía
Consideraciones Previa
Descripción de los Pasos de Guía
Paso 1.
Paso 2.
Paso 3.
Paso 4.
Aplicación de la Guía Propuesta
Consideraciones Previa
Descripción de los Pasos de Guía
Paso 1.
Paso 2.
Paso 3.
Paso 4.
Aplicación de la Guía Propuesta
Introducir atributos Derivados.
Volver
Parte III – Propuesta y Aplicación de la Guía
Consideraciones Previa
Descripción de los Pasos de Guía
Paso 1.
Paso 2.
Paso 3.
Paso 4.
Aplicación de la Guía Propuesta
Consideraciones Previa
Descripción de los Pasos de Guía
Paso 1.
Paso 2.
Paso 3.
Paso 4.
Aplicación de la Guía Propuesta
Duplicar Atributos no Clave en Relaciones de 1:N para Reducir los Joins.
Volver
Parte III – Propuesta y Aplicación de la Guía
Consideraciones Previa
Descripción de los Pasos de Guía
Paso 1.
Paso 2.
Paso 3.
Paso 4.
Aplicación de la Guía Propuesta
Consideraciones Previa
Descripción de los Pasos de Guía
Paso 1.
Paso 2.
Paso 3.
Paso 4.
Aplicación de la Guía Propuesta
Tabla de Referencia.
Volver
Parte III – Propuesta y Aplicación de la Guía
Consideraciones Previa
Descripción de los Pasos de Guía
Paso 1.
Paso 2.
Paso 3.
Paso 4.
Aplicación de la Guía Propuesta
Consideraciones Previa
Descripción de los Pasos de Guía
Paso 1.
Paso 2.
Paso 3.
Paso 4.
Aplicación de la Guía Propuesta
Duplicar Llaves Foráneas en Relaciones de 1:N para Reducir los Joins.
Volver
Parte III – Propuesta y Aplicación de la Guía
Consideraciones Previa
Descripción de los Pasos de Guía
Paso 1.
Paso 2.
Paso 3.
Paso 4.
Aplicación de la Guía Propuesta
Consideraciones Previa
Descripción de los Pasos de Guía
Paso 1.
Paso 2.
Paso 3.
Paso 4.
Aplicación de la Guía Propuesta
Duplicar Atributos en Relaciones de N:M para Reducir los Joins.
Volver
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
Consideraciones Previa
Descripción de los Pasos de Guía
Aplicación de la Guía Propuesta
Esquema de la BD Valores.
NombreTabla
Tamaño de la tabla(Bytes)
Numero de Filas Tamaño de la Tabla(Mbyte)
inv_header 64 36,162 2.20
inv_detalle 26 3,840,140 95.21
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),
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 "01/01/2004" and "31/01/2004"
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 "01/01/2004" and "31/01/2004"
Resultado.
Tiempo: 0.01 min.
Método de Acceso: INDEX PATH
PASO 2. PASO 1.
Conclusiones
Conclusiones
Recomendaciones.
Conclusiones
Recomendaciones.
Los pasos de la presente Guía proporcionan un marco de referencia para poder encarar el problema de rendimiento de consultas SQL costosas.
Los pasos de la Guía pueden ser utilizado en cualquier momento, porque el Proceso de Optimización es:
Dinámico, no siempre se aplica la misma solución.
Continuo, no tiene una fecha de finalización.
Impredecible, no se sabe con certeza cuando se presentará un problema de rendimiento de consulta.
Debe primar el criterio y la experiencia para el uso de la presente Guía.
Recomendaciones
Conclusiones
Recomendaciones.
Conclusiones
Recomendaciones.
El bajo rendimiento de las consultas no siempre es atribuible a la forma como fue formulada la consulta y/o la falta índice. Otros factores pueden contribuir:
•Capacidad de Hardware reducida,
•Comunicaciones deficientes,
•Mala Configuración de la Instancia del SGBD
Utilice herramientas automatizadas para Optimizar Consultas, como por ejemplo:
http://www.quest.com/es/
MUCHAS GRACIAS.
MUCHAS GRACIAS.
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
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
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
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 se mide 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
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
Modelo Relacional
Lenguajes Relacional
Sistema de Base de Datos
El Proceso de Optimización de Consultas
El Optimizador de Consultas
Reglas de Transformación de Expresiones. Una regla de equivalencia permite transformar una expresion E1 en la otra E2, mientras se preserva la equivalencia .
Aplicando las Reglas
Volver
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
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.
Número de Tablas N! Método Optimizado Ahorro
6 720 504 30%
7 5040 1344 73.3%
8 40320 3024 92.5%
9 362880 6048 98.3%
10 3628800 11088 99.7%
16 20922789888000 148512 99.999%
Volver
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
Modelo Relacional
Lenguajes Relacional
Sistema de Base de Datos
El Proceso de Optimización de Consultas
El Optimizador de Consultas
Sin embargo, NO SIEMPRE SE ELIGE EL MEJOR PLAN!!!!!!
Selección del Plan de Ejecución.
La selección del Plan de Ejecución Optimo, esta determinado por la solución que tenga el menor costo estimado.
Volver
…
Costo1 Costo2Coston