GuíA Para La OptimizacióN De Consultas

“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

Es muy común encontrar en una Aplicación Productiva consultas SQL, que al momento de ejecutarse, generen problemas en el SBD, tales como:

-Elevada carga del CPU (>99%)-Bloquean procesos de trabajo durante largo tiempo. -Leen muchos bloques de datos a la memoria intermedia (Paginamiento)-Los discos están fuertemente cargados (>50%).

Las consultas 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.Mala imagen corporativa, etc.


¿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.

La Guía propuesta es una alternativa para resolver el problema de las Consultas SQL costosas.


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





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).


Modelo Relacional





Modelo Relacional





Una Relación R , es representada como una Tabla de dos dimensiones n columnas x m filas.

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)

Car

din

alid

ad (

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.


R1

R2

Modelo Relacional





Modelo Relacional





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

R3

L


Modelo Relacional





Modelo Relacional





Operaciones adicionales

Estas operaciones pueden ser expresadas sobre la base de las primeras cinco

Operaciones Básicas del Algebra Relacional

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 de Consulta Procedimental y consiste de una colección de operaciones de alto nivel que operan

sobre Relaciones


A B C

aaa 111 234

R1 bbb 222 213

ccc 123 234

X Y

R2 aa uu

bb ss

Modelo Relacional





Modelo Relacional





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”(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


Modelo Relacional





Modelo Relacional





Árbol Algebraico. Las operaciones del Algebra Relacional, 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.


Modelo Relacional





Modelo Relacional





Lenguaje SQL (Structure Query Languaje). Es un lenguaje Relacional Comercial NO Procedimental, al igual que el Algebra Relacional opera sobre relaciones. El resultado de una consulta en SQL es, por supuesto, una nueva relación.

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


Modelo Relacional





Modelo Relacional





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


Modelo Relacional





Modelo Relacional





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


Modelo Relacional





Modelo Relacional






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.

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





Modelo Relacional






El Optimizador SYBASE (Adaptive Server Enterprice -ASE), esta basado en costos, creado en 1979 para el SGBD SYSTEM R.

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 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..








Paso 1

Generar el Plan de Ejecución

Paso 2

Reescribir la Consulta

¿Reescribir la

Consulta?

Paso 1


Paso 3

Crear y Gestionar Índices

¿Ajustar y/o Crear

Índices?

Paso 1


Paso 4

Ajustar el Esquema de la BD

¿Ajustar el Esquema de

BD

Paso 1


SINO

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




Paso 1.

Paso 2.

Paso 3.

Paso 4.




Paso 1.

Paso 2.

Paso 3.

Paso 4.


Paso 1. Generar el Plan de Ejecución

Parte Descripción

1 Una copia de la sentencia SELECT.

2 Costo Estimado. Un valor que representa el coste estimado de los recursos de la consulta

3 Numero de filas estimadas a retornar

4 Tiempo de ejecución (min, seg, ms).

5 El orden en que se accede a las tablas durante la ejecución.

6 Cómo filtra las filas la cláusula WHERE y si el filtrado se

realiza a través de un índice o se hace de manera

secuencial

7 El método utilizado para leer la tabla de la manera más eficiente, incluyendo el tipo de método de asociación (Join).

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 .

Generar el Plan de Ejecución es relativamente fácil, lo más importante es ANALIZAR la informacion que proporciona.

Antes de GENERAR el Plan de Ejecución verificar que las Estadísticas de las Tablas no sean Obsoletas. De lo contrario actualice.




Paso 1.

Paso 2.

Paso 3.

Paso 4.




Paso 1.

Paso 2.

Paso 3.

Paso 4.


Dos métodos de accesos a los Datos.

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

)

Cuando exista un FULL TABLE SCAN, la consulta tiene una alta probabilidad de ser costosa a mayor cantidad de datos.




Paso 1.

Paso 2.

Paso 3.

Paso 4.




Paso 1.

Paso 2.

Paso 3.

Paso 4.


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




Paso 1.

Paso 2.

Paso 3.

Paso 4.




Paso 1.

Paso 2.

Paso 3.

Paso 4.


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”)


FROM customer

WHERE customer_num = ANY

( SELECT customer_num

FROM orders

WHERE order_date = “20/01/1989”)


FROM customer

WHERE EXISTS

( SELECT FROM ORDERS

WHERE customer.customer_num = orders.customer_num

AND order_date = “20/01/1989”)


FROM customer, orders


AND order_date = “20/01/1989”


FROM customer

WHERE (SELECT COUNT() FROM orders


AND order_date = “20/01/1989”)>0


FROM customer

WHERE “20/01/1989” IN

(SELECT order_date

FROM orders

WHERE customer.customer_num = orders.customer_nu ).


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.




Paso 1.

Paso 2.

Paso 3.

Paso 4.




Paso 1.

Paso 2.

Paso 3.

Paso 4.


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




Paso 1.

Paso 2.

Paso 3.

Paso 4.




Paso 1.

Paso 2.

Paso 3.

Paso 4.


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




Paso 1.

Paso 2.

Paso 3.

Paso 4.




Paso 1.

Paso 2.

Paso 3.

Paso 4.


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.

Los índices en una tabla como regla de oro no mas de 5.

La probabilidad de que el Optimizador seleccione índice incorrecto aumenta con la cantidad de índices.




Paso 1.

Paso 2.

Paso 3.

Paso 4.




Paso 1.

Paso 2.

Paso 3.

Paso 4.


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.




Paso 1.

Paso 2.

Paso 3.

Paso 4.




Paso 1.

Paso 2.

Paso 3.

Paso 4.


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. Elección de la Primera Columna en un Índice Compuesto. La primera columna de un índice compuesto debería ser la columna más selectiva y también debería ser la más usada.

R8. Í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




Paso 1.

Paso 2.

Paso 3.

Paso 4.




Paso 1.

Paso 2.

Paso 3.

Paso 4.


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.




Paso 1.

Paso 2.

Paso 3.

Paso 4.




Paso 1.

Paso 2.

Paso 3.

Paso 4.


Reglas para la Desnormalización de Relaciones. • R1. Introducir atributos Derivados.

• Un atributo representa un valor que se puede obtener a partir del valor de uno o varios atributos, que no necesariamente deben pertenecer a la misma relación.

• R2. Combinar Relaciones de 1:1

• Unir en una sola tabla

• R3. Duplicar Atributos no Clave en Relaciones de 1:N para Reducir los Joins.

• Si un campo no llave de una tabla T1, es consultado frecuentemente a partir otra tabla T2, ese campo debe ser adicionado a la tabla T2.

• R4. Tablas de Referencias.




Paso 1.

Paso 2.

Paso 3.

Paso 4.




Paso 1.

Paso 2.

Paso 3.

Paso 4.


Reglas para la Desnormalización de Relaciones.

• R5. Duplicar Llaves Foráneas en Relaciones de 1:N para Reducir los Joins.

• Colocar los atributos llaves foráneas en las tablas involucradas en la consulta.

• R6. Duplicar Atributos en Relaciones de N:M para Reducir los Joins.

• Colocar en la relación M:N, los atributos mas relevante de las demás tablas involucras.

• R7. Introducir Grupos Repetitivos.

Volver








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),





Ejemplo 1.

Ejemplo 2.

Ejemplo 3.




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.





Ejemplo 1.

Ejemplo 2.

Ejemplo 3.




Ejemplo 1.

Ejemplo 2.

Ejemplo 3.

Optimización Consulta Nro. 1. QUERY:

------

select * from inv_header where nro_tran=1

union


Estimated Cost: 2


1) inv_header: INDEX PATH

(1) Index Keys: nro_tran

Lower Index Filter: inv_header.nro_tran = 100

Union Query:

------------


(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.


union


Resultado.

Tiempo: 0.01 min.

Método de Acceso: INDEX PATH

PASO 2. PASO 1.





Ejemplo 1.

Ejemplo 2.

Ejemplo 3.




Ejemplo 1.

Ejemplo 2.

Ejemplo 3.


QUERY:

------

select *

from inv_detalle

where cod_tv=2 and nro_valor=700021

Estimated Cost: 2


1) inv_detalle: SEQUENTIAL SCAN

Filters: (inv_detalle.cod_tv = 2 AND

inv_detalle.nro_valor = 700021 )

select * from inv_detalle


Listar el detalle de movimiento de la factura numero 700021.

Resultado.

Tiempo: 8.3 min.


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.





Ejemplo 1.

Ejemplo 2.

Ejemplo 3.




Ejemplo 1.

Ejemplo 2.

Ejemplo 3.


QUERY:

------

select *

from inv_detalle


Estimated Cost: 2


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.


PASO 3.

PASO 1.





Ejemplo 1.

Ejemplo 2.

Ejemplo 3.




Ejemplo 1.

Ejemplo 2.

Ejemplo 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



Filters: (YEAR(inv_header.fecha )=2004 AND

MONTH(inv_header.fecha )=1 )


(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




Listar el detalle de movimiento de valores correspondiente al mes de enero del 2004.

Resultado

Tiempo: 10.4 min.


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.





Ejemplo 1.

Ejemplo 2.

Ejemplo 3.




Ejemplo 1.

Ejemplo 2.

Ejemplo 3.


------




Estimated Cost: 4



Filters: (YEAR(inv_header.fecha )=2004 AND

MONTH(inv_header.fecha )=1 )


(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.


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.





Ejemplo 1.

Ejemplo 2.

Ejemplo 3.




Ejemplo 1.

Ejemplo 2.

Ejemplo 3.


------



and fecha between "01/01/2004" and "31/01/2004"

Estimated Cost: 4



(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.



and fecha between "01/01/2004" and "31/01/2004"

Resultado.

Tiempo: 0.01 min.


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.


Modelo Relacional





Modelo Relacional





Estadísticas de la Base de Datos.

Además, se utiliza información acerca de los índices

Volver


Modelo Relacional





Modelo Relacional





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


Modelo Relacional





Modelo Relacional





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


Modelo Relacional





Modelo Relacional





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)

Expresiones SARG Expresion Non SARG

x = 10 x <> 10

x IS NULL x IS NOT NULL

x > 25 x = 4 OR y = 5

x = z x = y

x IN (4, 5, 6) x NOT IN (4, 5, 6)

x LIKE 'pat%' x LIKE '%tern'

x = 20 - 2 x + 2 = 20

x , y pertenecen a la misma tabla, z es foráneo.

Volver


Modelo Relacional





Modelo Relacional





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.


Modelo Relacional





Modelo Relacional





…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

El escenario de costo en el peor caso para un join es el que implementa un FULL TABLE SCAN en ambas tablas .


Modelo Relacional





Modelo Relacional





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


Modelo Relacional





Modelo Relacional





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

GuíA Para La OptimizacióN De Consultas

Technology

Transcript of GuíA Para La OptimizacióN De Consultas