30543992 Guia Para La Optimizacion de Consultas

7/31/2019 30543992 Guia Para La Optimizacion de Consultas

1/49

Gua para la Optimizacin de Consultasen una Base de Datos Relacional Utilizando

SQL

UNIVERSIDAD AUTONOMA GABRIEL RENEMORENO

FACULTAD DE CIENCIAS EXACTAS YTECNOLOGIA

Carrera de Ingeniera Informtica

Elaborado por: Ubaldo PrezFerreira

Proyecto de Grado

Proyecto de Grado para optar al Ttulo de:Licenciatura en Ingeniera Informtica

Santa Cruz de la Sierra Bolivia


2/49

Temario

Parte I. Perfil del Proyecto. Antecedentes.

Justificacin. Objetivos. Parte II: Fundamentos Tericos.

Modelo de Datos Relacional. Lenguajes Relacionales. Sistemas de Gestin de Base de Datos Relacionales. Conceptos del Procesamiento de Consultas. El Optimizador de Consultas.

Parte III: Propuesta y Aplicacin de la Gua para la Optimizacin deConsultas. Descripcin de la Gua Propuesta

Consideraciones Previa para el Uso de la Gua. Paso 1. Generar y analizar el Plan de Ejecucin. Paso 2. Reescribir la consulta SQL. Paso 3. Crear y Gestionar Indices. Paso 4. Ajuste al Esquema de la Base de Datos.

Aplicacin de la Gua Propuesta Consideraciones Previa para el Uso de la Gua.

Ejemplo 1. Ejemplo 2. Ejemplo 3.

Conclusiones y Recomendaciones.


3/49

Parte I - Perfil del Proyecto

Antecedentes

Justificacin

Objetivos

Antecedentes

Justificacin

Objetivos

En las Aplicacin Productiva, existe la posibilidad de encontraralgunas 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 estn fuertemente cargados.

Las Consultas SQL que generan este tipo de problema, se lasdenomina COSTOSAS o INEFICIENTES.

Y por supuesto estos problemas son la causa de:Malestar entre los usuarios y/o clientes.Mala imagen corporativa, etc.


4/49


Que hacer cuando se presenta unaConsulta SQL costosa?

Antecedentes

Justificacin

Objetivos

Antecedentes

Justificacin

Objetivos

Por donde empezar?, si no secuenta con pasos biendefinidos, resolver el problema

de una Consulta SQL costosa,puede tomar horas de trabajo.

Es as, que se propone unaGua para resolver elproblema de las ConsultasSQL costosas.


5/49


Objetivo principal.

Disear una Gua para la Optimizacin deConsultas en una Base de Datos Relacionalutilizando SQL .

Objetivos Especficos.

Describir las Fases del Proceso de Optimizacin de

Consultas. Detallar los componentes y funcionamiento de un

Optimizador de Consultas.

Exponer el contenido de un Plan de Ejecucin.

Detallar las reglas para evitar formular Consultas SQLcostosas.

Detallar las reglas para Crear y Gestionar ndices.

Explicar el contenido de las Estadsticas del Catalogode Base de Datos.

Antecedentes

Justificacion

Objetivos

Antecedentes

Justificacion

Objetivos


6/49

Parte II - Fundamentos Tericos

ModeloRelacional

LenguajesRelacional

Sistema deBase de Datos

El Proceso deOptimizacinde Consultas

El Optimizador

de Consultas

ModeloRelacional

LenguajesRelacional



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 DECONJUNTOS, 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 esteModelo es una Relacin (R).

04/26/10 07:13 PM


7/49


ModeloRelacional

LenguajesRelacional



El Optimizador

de Consultas

ModeloRelacional

LenguajesRelacional



El Optimizador

de Consultas

Una Relacin R, es representada como una Tabla.

A1 An

V1 Vn

Tupla, conjunto de valores t1tm,

ti=(v1,,vn) / v1 A1 vn An

Atributo, papel que desempea D en R.Grado (n)

Car

din

alid

ad

(m).

ESQUEMA

INST

ANC

IA

Restricciones de Integridad sobre las Relaciones.

Una Llave Primaria (PK), es un atributo o un conjunto deatributos, que sirven para identificar una fila una relacin. No se

permiten valores NULOS en PK.

Una Llave Foranea (PF), es uno o mas atributos comunes entre

dos Relaciones.04/26/10 07:13 PM


8/49


ModeloRelacional

LenguajesRelacional



El Optimizador

de Consultas

ModeloRelacional

LenguajesRelacional



El Optimizador

de Consultas

Operaciones adicionalesEstas operaciones puedenser expresadas sobre labase de las primeras cinco

Operaciones Bsicas

Seleccin ( )

Proyeccin (

)Producto Cartesiano ( )

Unin ()

Diferencia (-)

Interseccin ()

Reunin con predicado(|X|p)

Reunin natural (|X|)

Divisin ( )

Operaciones Unarias

Operaciones Binarias

El Algebra Relacional: Es un lenguaje PROCEDIMENTAL, y consisteen un conjunto de operaciones de alto nivel que operan sobre

Relaciones


9/49


A B C

aaa 111 234

R1bbb 222 213

ccc 123 234

X Y

R2aa uu

bb ss

ModeloRelacional

LenguajesRelacional



El Optimizador

de Consultas

ModeloRelacional

LenguajesRelacional



El Optimizador

de Consultas

Expresin Algebraica. Las operaciones del Algebra Relacional,son formuladas dentro de una Expresin Algebraica; las mismas queespecifican la manera en que los datos deben ser recuperados de lasRelaciones.

A,B,X ( X=aa (R1XR2))

El resultado de una ExpresinAlgebraica es uma nueva Relacin

Aplicando laExpresin Algebraica

A B X

aaa 111aa

bbb 222aa

ccc 123aa


10/49


ModeloRelacional

LenguajesRelacional



El Optimizador

de Consultas

ModeloRelacional

LenguajesRelacional



El Optimizador

de Consultas

rbol Algebraico. Las Expresiones Algebraicas, pueden serrepresentada 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 Bsica utilizada por los SGBD.


11/49


ModeloRelacional

LenguajesRelacional



El Optimizador

de Consultas

ModeloRelacional

LenguajesRelacional



El Optimizador

de Consultas

Lenguaje SQL (Structure Query Languaje). Implementado

en la mayora de los SGBD, es un lenguaje NOPROCEDIMENTAL, al igual que el Algebra Relacional opera sobreRelaciones

La mayora de las operaciones del Algebra relacional pueden serformuladas en el SQL.

La Estructura Bsica de una expresin en SQL esta compuesta detres clusulas:

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


12/49


ModeloRelacional

LenguajesRelacional



El Optimizador

de Consultas

ModeloRelacional

LenguajesRelacional



El Optimizador

de Consultas

Sistema de Gestin de Bases de Datos (SGBD). Es el

conjunto de Programas que permiten: Definir yManipularla informacin que contienen las Bases deDatos, entre otras tareas que realiza como ser:Autorizaciones, Seguridad, Recuperacin


13/49


ModeloRelacional

LenguajesRelacional



El Optimizador

de Consultas

ModeloRelacional

LenguajesRelacional



El Optimizador

de Consultas

Programa deAplicacin

Esquema de

BD

Consulta de Usaurio

Tabla deAutorizacion

Adm. de Accesos

Concurrente

Compilador

LDD

Procesador

de

Consultas

Gestor

De

Base de Datos

Gestor

de

Archivos

Datos + Index

Diccionario

de Datos

CompiladorLMD

Lenguaje SQL

Control de

Acceso


14/49


ModeloRelacional

LenguajesRelacional



El Optimizador

de Consultas

ModeloRelacional

LenguajesRelacional



El Optimizador

de Consultas

El Proceso de Optimizacin de Consultas

Datos + Index

Diccionario

de Datos

Traductor(Parser)

rbolRelacional

Plan deEjecucin

Consulta

SQL

Resultado de laConsulta

Optimizadorde Consulta

Motor deEjecucion

Reglas de Transformacin de Expresiones

Estadsticas de las Relaciones.

Medidas de Costos.

Ordenes Join.

Seleccin del Plan Optimo


15/49

Parte III Propuesta y Aplicacin de la Gua

Consideraciones Previa

Descripcin delos Pasos deGua

Aplicacin dela GuaPropuesta




La Gua es una herramienta de propsito general, en algunos casospuede ser muy compleja o muy simple.

Consideraciones para el uso de Gua.

No esta orientada a un SGBD en particular

La Gua debe ser vista como una herramienta mas en el proceso deOptimizacin de Consultas.

La Gua puede ser utilizada este o no poblada la Base de Datos.

La gua esta orientado a cierto de tipo de usuarios como ser:Administradores de Base de Datos, Diseadores de Base deDatos y Programadores de Aplicaciones.

La gua esta fundamentada en la Optimizacin de Rendimientos deSistemas propuesta por SAP.


16/49








Paso 1

Generar el Plan de Ejecucin

Paso 2

Reescribir la Consulta

Reescribir la

Consulta?

Paso 1


Paso 3

Crear y Gestionar ndices

Ajustar y/oCrear

ndices?

Paso 1


Paso 4

Ajustar el Esquema de la BD

Ajustar elEsquema de

BD

Paso 1


SINO

SI

SI

NO

NO

Estadsticas Obsoletas?

Anlisis del Plan de Ejecucin

Orientar al uso de INDICESExistentes?

Crear INDICES?

Ajustar los Existentes

Desnormalizar

Adicionar Atributos Derivados

Contin

ua

l l d j i l d l i l l


17/49




Paso 1.

Paso 2.

Paso 3.

Paso 4.




Paso 1.

Paso 2.

Paso 3.

Paso 4.


Paso 1. Generar el Plan de Ejecucin

Entre otros, el Plan de Ejecucin muestra el orden lgico en la cual seacceden a las tablas y el mtodo de acceso que utiliza para leer cada tabla .

Verificar que las Estadsticas de las Tablas no sean Obsoletas.Actualizar las Estadsticas puede llevar horas de trabajo.

Los SGBD proporcionan una herramienta llamada SHOWPLAN,que muestra al usuario un detalle del Plan de Ejecucin:

Cual es el tiempo de ejecucin de la consulta (ms, seg, min)?Cuntas tuplas se estima recuperar?

Cul es el costo de la consulta (interno SGBD)?

Se consider los INDICES EXISTENTE en cada tabla o se estrealizando un FULL TABLE SCAN?

Se utilizan tablas temporales para procesar la consulta ?

Cuales son los rdenes de JOIN que utiliza el optimizador pararesolver la consulta ?


18/49




Paso 1.

Paso 2.

Paso 3.

Paso 4.




Paso 1.

Paso 2.

Paso 3.

Paso 4.


Acceso Index Scan

0.00

0.20

0.40

0.60

0.80

1.00

1.20

n100

n500

0

n500

00

n100

000

n200

000

n500

000

n100

0000

n200

0000

Cantidad de Tuplas

Tie

mpo(min)

Acceso Full Table Scan

0.00

20.00

40.00

60.00

80.00

100.00

120.00

140.00

160.00

180.00

200.00

n100

n500

0

n500

00

n100

000

n200

000

n500

000

n100

0000

n200

0000

Cantidad de Tuplas

T

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


19/49




Paso 1.

Paso 2.

Paso 3.

Paso 4.




Paso 1.

Paso 2.

Paso 3.

Paso 4.


Planes de Ejecucin para diferentes SGBD.

Motor de Base deDatos

Plan de Ejecucin Anlisis del Plan de Ejecucin

INFORMIX 1. SELECT statement2. INDEX PATH3. INDEX KEY: idx_customer

4. LOWER INDEX FILTER:( customer_num=101)

La lnea dos indica que INFORMIX accedemediante un ndice. La lnea tres indicaque el ndice utilizado en idx_customer, lalnea cuatro indica que se utiliz el campocustomer_num como filtro

ORACLE 1. SELECT statement2. TABLE ACCES BY INDEX ROWID

customer_num=1013. INDEX UNIQUE SCAN idx_customer

La lnea dos indica que se especifica queel acceso es va ndice y ademsutilizando el filtro customer_num=101, lalnea tres indica que el ndice utilizado esel idx_customer.

SQL SERVER 1. SELECT statement2. CLUSTER INDEX SEEK (idx_customer)3. SEEK:( customer_num=@101

La lnea dos se indica que se utiliza elndice idx_customer, la lnea tres indicaque la busque utilizo el filtrocustomer_num=@101.

DB/2 1. SELECT statement2. FETCH customer_num=1013. SORT4. IXSCAN INDEX idx_customer

La lnea dos indica que se utilizo el filtrocustomer_num=101, la lnea tres indicaque el ndice esta ordenado, y en la lneacuatro se ndica que se utiliza el ndiceidx_customer.

SELECT *

FROM Customer WHERE customer_num = 101

Volver


20/49




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, sinembargo, esto implica una estrategia de acceso diferente.


21/49




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 Pequea Cantidad de Datos.R2. Usar los Campos Indexados en la Clusula WHERE

campo indexado = expresin

R3. Si existen ndices Compuestos, Utilice los Primeros Campos.

Si se tiene un ndice compuesto con los campos A, B y CWHERE A=1

WHERE A>=12 AND A


22/49




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 SubstringWHERE 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 Clusula 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 Clusula WHERE.

SELECT * FROM customer

WHERE UPERCASE(fname)=MARIO CLAROSVolver


23/49




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 bsquedas de informacin.

Si los ndices proporcionan celeridad, por qu no indexar todas lascolumnas?.

Mediante el uso de ndices se evita el FULL TABLE SCAN.

Tipos de Indices.

ndices Primario, son creados sobre loscampos llaves primaria.ndices Secundarios, son creados sobre

los campos llaves forneas, o sobreatributos con alta selectividad.

Actualizar, borrar e insertar datos sobre una columna indexadaconsume ms tiempo.

Si hay muchos ndices, existe la probabilidad de que el Optimizadorseleccione ndice incorrecto.

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


24/49




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 camposdefinidos como PK ya estn indexados, pero se deben investigar aquelloscampos 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 Mltiples 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 comondice, evite los valores NULL.

R5. Atributos en la clusula ORDER BY. Si existen atributos queaparecen frecuentemente en la clusula ORDER BY, deben creados como indicescompuestos.


25/49




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

La selectividad de un atributo es:

nmero de valores distintos/nmero 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 SolaColumna. Cuando se va a crear un ndice compuesto, debe valorarse si laselectividad de ese ndice va a ser considerablemente mayor con varias columnas

que con una.

Volver


26/49




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 desnormalizacin hace que la implementacin sea ms compleja.

La desnormalizacin hace que se sacrifique la flexibilidad. La desnormalizacin puede hacer que los accesos a datos sean ms

rpidos, pero hace que las actualizaciones sean lentas.

Al realizar el diseo lgico se recomienda llegar, al menos, hasta la3FN, para obtener un esquema con una estructura consistente y sinredundancias.

Pero, a menudo, sucede que las BD Normalizadas no proporcionanla mxima eficiencia a las Consultas SQL. Por lo tanto, hay que

volver atrs y desnormalizar, sacrificando los beneficios de lanormalizacin para mejorar las Consultas.


27/49




Paso 1.

Paso 2.

Paso 3.

Paso 4.




Paso 1.

Paso 2.

Paso 3.

Paso 4.


Reglas para la Desnormalizacin de Relaciones. R1. Introducir atributos Derivados.

R2. Combinar Relaciones de 1:1

R3. Duplicar Atributos no Clave en Relaciones de 1:N paraReducir los Joins.

R4. Tablas de Referencias.

R5. Duplicar Llaves Forneas en Relaciones de 1:N paraReducir los Joins.

R6. Duplicar Atributos en Relaciones de N:M para Reducir losJoins.

R7. Introducir Grupos Repetitivos.

Volver


28/49




Paso 1.

Paso 2.

Paso 3.

Paso 4.




Paso 1.

Paso 2.

Paso 3.

Paso 4.


Introducir atributos Derivados.

Volver


29/49




Paso 1.

Paso 2.

Paso 3.

Paso 4.




Paso 1.

Paso 2.

Paso 3.

Paso 4.


Duplicar Atributos no Clave en Relaciones de 1:N para Reducir

los Joins.

Volver


30/49




Paso 1.

Paso 2.

Paso 3.

Paso 4.




Paso 1.

Paso 2.

Paso 3.

Paso 4.


Tabla de Referencia.

Volver


31/49




Paso 1.

Paso 2.

Paso 3.

Paso 4.




Paso 1.

Paso 2.

Paso 3.

Paso 4.


Duplicar Llaves Forneas en Relaciones de 1:N para Reducir los

Joins.

Volver


32/49




Paso 1.

Paso 2.

Paso 3.

Paso 4.




Paso 1.

Paso 2.

Paso 3.

Paso 4.


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

Volver


33/49








Esquema de la BD Valores.

NombreTabla

Tamao de la tabla(Bytes)

Numero de Filas Tamao 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 nullprimary 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),


34/49





Ejemplo 1.

Ejemplo 2.

Ejemplo 3.




Ejemplo 1.

Ejemplo 2.

Ejemplo 3.

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

Mtodo de Acceso: FULL TABLE SCAN

Listar el detalle de valores de lastransacciones numero 100 y 300.

Anlisis

Existe un ndice sobre el campo nro_tran, sinembargo no fue utilizado, esto debido a quela clusula WHERE no es SARGABLE.

PASO 1.


35/49





Ejemplo 1.

Ejemplo 2.

Ejemplo 3.




Ejemplo 1.

Ejemplo 2.

Ejemplo 3.


QUERY:------

select * from inv_header where nro_tran=1

union


Estimated Cost: 2

Estimated # of Rows Returned: 21) 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

Solucin.

Reescribir la consulta, para que laclusula WHERE sea SARGABLE, seutilizo la Regla 9 del paso 2.

select * from inv_header where nro_tran=100union


Resultado.

Tiempo: 0.01 min.

Mtodo de Acceso: INDEX PATH

PASO 2.PASO 1.


36/49





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

Resultado.

Tiempo: 8.3 min.


Anlisis

No existe un ndice sobre los campos cod_tvy nro_valor, esta situacin hace que elSGBD se decida por un acceso FULL

TABLE SCAN.

PASO 1.

li i d l G


37/49





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 )

Anlisis.Se observa que la clusula WHERE esde tipo SARGABLE, sin embargo latabla inv_detalle no cuenta con losndices adecuado.

Solucin.

Se procedi a crear un ndice:

CREATE INDEX idx_inv_detalle1ON inv_detalle(cod_tv, nro_valor).

Resultado.

Tiempo: 0.01 min.

Mtodo de Acceso: INDEX PATH

PASO 3.

PASO 1.

P t III P t A li i d l G


38/49





Ejemplo 1.

Ejemplo 2.

Ejemplo 3.




Ejemplo 1.

Ejemplo 2.

Ejemplo 3.


QUERY:

------

select inv_detalle.* from inv_header,inv_detallewhere inv_header.nro_tran=inv_detalle.nro_tran

and year(fecha)="2004" and month(fecha)="01"

Estimated Cost: 4


1) inv_header: SEQUENTIAL SCAN

Filters: (YEAR(inv_header.fecha )=2004 ANDMONTH(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

select inv_detalle.* from inv_header,inv_detallewhere inv_header.nro_tran=inv_detalle.nro_tran


Listar el detalle de movimiento de valorescorrespondiente al mes de enero del 2004.

Resultado

Tiempo: 10.4 min.


Anlisis

Se observa que la tabla inv_detalle notiene el indice adecuado, razn por la

cual el SGDB elige el FULL TABLESCAN.

PASO 1.



39/49





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


Estimated Cost: 4

Estimated # of Rows Returned: 11) inv_header: SEQUENTIAL SCAN

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

Solucin.Se creo el ndice en la tabla inv_headerutilizando el campo fecha.

CREATE INDEX idx_inv_header1 ONinv_header(fecha)

Resultado.Tiempo: 10.4 min.


Anlisis

El plan no varia ni en tiempo y ni enel tipo de acceso, pese a que se creoel ndice. El problema esta en lapresencia de funciones en la clusulaWHERE.

PASO 3. PASO 1.



40/49





Ejemplo 1.

Ejemplo 2.

Ejemplo 3.




Ejemplo 1.

Ejemplo 2.

Ejemplo 3.

Optimizacin 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


1) inv_header: INDEX PATH

(1) Index Keys: fecha

Lower Index Filter: inv_header.fecha >= 01/01/2004

Upper Index Filter: inv_header.fecha


41/49

Conclusiones

Conclusiones

Recomendacione

s.

Conclusiones

Recomendacione

s.

Los pasos de la presente Gua proporcionan un marco de

referencia para poder encarar el problema de rendimientode consultas SQL costosas.

Los pasos de la Gua pueden ser utilizado en cualquiermomento, porque el Proceso de Optimizacin es:

Dinmico, no siempre se aplica la misma solucin.

Continuo, no tiene una fecha de finalizacin.

Impredecible, no se sabe con certeza cuando sepresentar un problema de rendimiento de consulta.

Debe primar el criterio y la experiencia para el uso de lapresente Gua.

R d i


42/49

Recomendaciones

Conclusiones

Recomendacione

s.

Conclusiones

Recomendacione

s.

El bajo rendimiento de las consultas no siempre es

atribuible a la forma como fue formulada la consulta y/ola falta ndice. Otros factores pueden contribuir:

Capacidad de Hardware reducida,

Comunicaciones deficientes,

Mala Configuracin de la Instancia del SGBD

Utilice herramientas automatizadas para OptimizarConsultas, como por ejemplo:

http://www.quest.com/es/
http://www.quest.com/es/http://www.quest.com/es/http://www.quest.com/es/http://www.quest.com/es/


43/49

MUCHAS GRACIAS.


44/49

MUCHAS GRACIAS.

Parte II Fundamentos Tericos


45/49


ModeloRelacional

LenguajesRelacional



El Optimizador

de Consultas

ModeloRelacional

LenguajesRelacional



El Optimizador

de Consultas

Estadsticas de la Base de Datos.

Adems, se utiliza informacin acerca de los ndices

Volver



46/49


ModeloRelacional

LenguajesRelacional



El Optimizador

de Consultas

ModeloRelacional

LenguajesRelacional



El Optimizador

de Consultas

Medidas de Costos.

El costo se mide en funcin de la cantidad de CPUutilizada y de la cantidad de pginas de discorescatadas.

b.1. Bsqueda 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



47/49


ModeloRelacional

LenguajesRelacional



El Optimizador

de Consultas

ModeloRelacional

LenguajesRelacional



El Optimizador

de Consultas

Reglas de Transformacin de Expresiones.Una regla de equivalencia permite transformar una expresion E1en la otra E2, mientras se preserva la equivalencia .

Aplicando las Reglas

Volver



48/49


ModeloRelacional

LenguajesRelacional



El Optimizador

de Consultas

ModeloRelacional

LenguajesRelacional



El Optimizador

de Consultas

FROM Tabla1, Tabla2,Tablan

Seleccin de Ordenes JOIN.

La clusula FROM no dicta el orden en el cual las tablas deben serprocesadas .

Se evala todas las permutaciones razonables y se estima el costo

total en trminos de tiempo de E/S.

Nmero de Tablas N! Mtodo 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



49/49


ModeloRelacional

LenguajesRelacional



El Optimizador

de Consultas

ModeloRelacional

LenguajesRelacional



El Optimizadorde Consultas

Sin embargo,NO SIEMPRE SE ELIGE EL MEJOR PLAN!!!!!!

Seleccin del Plan de Ejecucin.

La seleccin del Plan de Ejecucin Optimo, esta determinado por la

solucin que tenga el menor costo estimado.

Volver

Costo1 Costo2 Coston

Documents

30543992 Guia Para La Optimizacion de Consultas