Caso de Estudio Relación PROFESOR(id, nom, deptid) - 200 páginas, 1000 filas (5 filas/página) - 50 deps  20 profesores/dep en promedio - Índices: Clustered.

Slides:



Advertisements
Presentaciones similares
Nombre de las asignaturas que tienen más créditos que "Seguridad Vial". Usando consultas anidadas: SELECT Nombre AS NOMBRE_ASIGNATURA FROM ASIGNATURA.
Advertisements

COMP 234 Prof. Carlos Rodríguez Sánchez
Sesión 2 Programación Estructurada
Optimización del rendimiento de las consultas
Integrantes Alex Olivera Jaime Salas Miguel Valenzuela ProfesoraPilar Pardo Fecha26/10/2012.
Consultas anidadas.
MÉTODOS DE CLASIFICACION
PROGRAMACION DE ESTRUCTURAS DE DATOS IV. MÉTODOS DE ORDENAMIENTO.
S.Q.L. (Lenguaje de Consulta Estructurada)
Características Objeto Relacionales en Oracle
EXPLAIN PLAN Cómo leer los resultados del EXPLAIN PLAN
Universidad del Cauca – FIET – Departamento de Sistemas CAPITULO 2 Restringiendo y Ordenando Datos.
Ecuaciones diferenciales de 1er orden :
Evaluación y Optimización de Consultas Láminas seleccionadas de las láminas de la Prof. María Esther Vidal.
Métodos para realizar la operación de reunión (join) Francisco Moreno.
PL/SQL Francisco Moreno Universidad Nacional.
Programación de Computadores
Universidad del Cauca – FIET – Departamento de Sistemas CAPITULO 5 Agregando Datos Usando Funciones de Grupo.
“Optimización de sentencias MySQL” jueves 26 de septiembre de 2013.
1 John Freddy Duitama U.de.A. Facultad de Ingeniería Optimización Algebraica. Profesor: John Freddy Duitama Muñoz. Facultad de Ingeniería. U.de.A. Profesor:
SQL: Lenguaje de Interrogación Estructurado
Subconsultas Avanzadas
Administración de Bases de Datos
Unidad V: Estimación de
ESTRUCTURAS DE CONTROL
Diseño geodésico II II semestre, 2014
CAPITULO 4 Despliegue de Datos Desde Múltiples Tablas
CONSULTAS SENCILLAS A LA BASE DE DATOS
EXPLAIN PLAN Cómo leer los resultados del EXPLAIN PLAN
MERCADO DE FACTORES PRODUCTIVOS Parte II TEMA VIII.
Expresiones algebraicas equivalentes
Más ejemplos en SQL Francisco Moreno. S sn snombre situacion ciudad S1 Salazar 20 Londres S2 Jaramillo 10 París S3 Bernal30 París S4 Caicedo 20 Londres.
Ecuaciones cuadráticas
Ingeniería Agrícola en Competencias de Caballos de Paso Fino Obed Acevedo Tecnología Mecánico-Agrícola UPR Mayaguez 1er Semestre
MUESTREO ALEATORIO SIMPLE SIN REEMPLAZO (“mas”)
JOIN EN MYSQL Bueno en esta presentación mostrare cosas acerca de los usos de la sentencia JOIN en mysql , mediante esta presentación planeo mostrar los.
HINTS ¿Cómo afectar el plan de ejecución? Por defecto, el SGBD tomará en cuenta el camino de ejecución (Execution Path) determinado por el optimizador.
SQL es el lenguaje de comunicación entre el programa cliente y programa servidor; Oracle es un programa servidor, en el que está la base de datos propiamente.
Laboratorio # 4 Tabla en Excel de Acciones de Compañías de Alta Tecnología Prof. Nelliud D. Torres CEIG-1000.
OPTIMIZACION DEL DESEMPEÑO DE ERROR
Prof. Evelyn Dávila Adams Oficina E-202
Unidad 6. Tema 4. Lenguaje de consultas SQL
NUMEROS ALEATORIOS. La idea es hallar un generador que sea fácil de implementar en la computadora, que sea rápido y que no ocupe mucho espacio memoria,
Administración de Base de Datos Procesamiento y Optimización de Consultas Prof Mercy Ospina Torres Prof Renny A. Hernandez
6 Triggers ORACLE - II Bases de datos II I-2014 Universidad del Cauca Ing. Wilson Ortega Bases de datos II I-2014 Universidad del Cauca Ing. Wilson Ortega.
Estructuras de Decisión en Visual Basic 6.0
COSTOS Y PRESUPUESTOS Cel
Administración de Base de Datos Procesamiento y Optimización de Consultas Prof Mercy Ospina Torres Prof Renny A. Hernandez
INTEGRACION DE LAS TECNOLOGIAS DE LA INFORMACION Y COMUNICACION Implementación de base de datos (Lenguaje de manipulación de datos) Ing. Linda Masias Morales.
Bases de datos II Universidad del Cauca Ing. Wilson Ortega.
Administración de Base de Datos Manejo de memoria (Parte II) Prof Mercy Ospina Torres
Administración de Base de Datos Procesamiento y Optimización de Consultas Prof Mercy Ospina Torres Prof Renny A. Hernandez
DLM Transact SQL Sesión II Recuperación de información.
Resultados de Intervención (t0 – t1) Programa de Educación Financiera 2012 Departamento de Estudios y Evaluación Subdirección de Procesos y Soporte Julio.
Editado y adaptado por hjalmar hernandez. Creación original de la universidad Francisco Gavidia.
Una base de datos, a fin de ordenar la información de manera lógica, posee un orden que debe ser cumplido para acceder a la información de manera coherente.
Interfaz de C++ Builder Cuando usted inicia C++ Builder, espera ver una solo ventana para desarrollar sus aplicaciones; pero C++ Builder le presenta un.
Arquitectura de Computadoras (Taller) Semestre II de 2008.
DML Transact SQL Sesión VI Trabajando con subconsultas.
Optimización de Consultas Distribuidas. ÍNDICE Definiciones básicas Modelo de costo Estadísticas de la base de datos Optimización centralizada de consultas.
La siguiente presentación tiene como objetivo mostrarte la manera en que puedes poner el índice en tu proyecto de estadía.
Algebra relacional Integrantes: Víctor Sergio López Sainz. Francisco Javier centeno. Verdín Carlos Omar.
DML Transact SQL Sesión III Agrupando y resumiendo información.
Selección Condicionada de Filas Uso de la cláusula WHERE La cláusula WHERE restringe las columnas que retorna una consulta según la condición que se imponga.
Taller introducción a los conceptos básicos de Estadística PRIMERA PARTE 2016 Propósito: Introducir algunos conceptos básicos de Estadística por medio.
CAMBIAR EL ALTO Y ANCHO DE LAS DIAPOSITIVAS" Cambiar el tamaño de la diapositiva a estándar o a pantalla panorámica En versiones anteriores de PowerPoint,
SQL: Structured Query Language
CONSULTAS SQL POSTGRES.
EXPLAIN PLAN Cómo leer los resultados del EXPLAIN PLAN
Otros temas sobre cachés
Transcripción de la presentación:

Caso de Estudio Relación PROFESOR(id, nom, deptid) páginas, 1000 filas (5 filas/página) - 50 deps  20 profesores/dep en promedio - Índices: Clustered B+ sobre deptid Hash sobre id -Peso de id: 1 (de hecho id es la CP) -nom no es CA

Caso de Estudio Relación CUR_PROF(profid, crscod, semestre) páginas, filas (10 filas/página) - La relación abarca 4 semestres  2500 filas/semestre - Índices: Clustered B+ sobre semestre Hash sobre profid - Peso de profid: 10 (10 filas por profesor en CUR_PROF) CF hacia PROFESOR

Caso de Estudio Sea la consulta: SELECT DISTINCT P.id, P.nom FROM profesor AS P, cur_prof AS C WHERE P.id = C.profid AND C.semestre = 'F2015' AND P.deptid = 'CS'; Condición de join Selecciones Proyección Nota: En los ejemplos que siguen se hace caso omiso del ordenamiento que usualmente conlleva una operación DISTINCT.

Caso de Estudio Sean las expresiones algebraicas equivalentes a la consulta anterior: a)  id,nom (  deptid = ‘CS’  semestre = ‘F2015’ (PROFESOR ⋈ id = profid CUR_PROF)) b)  id,nom (  deptid = ‘CS’ (PROFESOR) ⋈ id = profid  semestre = ‘F2015’ (CUR_PROF)) c)  id,nom (  semestre = ‘F2015’ (  deptid = ‘CS’ (PROFESOR) ⋈ id = profid CUR_PROF)) d)  id,nom (  deptid = ‘CS’ (PROFESOR ⋈ id = profid  semestre = ‘F2015’ (CUR_PROF)))

PROFESORCUR_PROF ⋈ id = profid  deptid = ‘CS’  semestre = ‘F2015’  id,nom PROFESOR CUR_PROF ⋈ id = profid  deptid = ‘CS’  id,nom semestre = ‘F2015’ a) b) Árboles para los planes de ejecución

PROFESORCUR_PROF ⋈ id = profid  deptid = ‘CS’  id,nom  semestre = ‘F2015’ PROFESORCUR_PROF ⋈ id = profid  deptid = ‘CS’  id,nom  semestre = ‘F2015’ c) d) Árboles para los planes de ejecución

Caso de Estudio a) Supóngase una memoria (M) de 52 páginas. Costo del join con block nested: F PROFESOR + F CUR_PROF *  F PROFESOR /(M-2)  = *  200/(52-2)  = 4200 (páginas) El resultado del join serán filas, aproximadamente 3000 páginas (ya que cada fila de PROFESOR es el doble del tamaño de cada fila de CUR_PROF)

Caso de Estudio El costo de escribir el resultado de la selección y de la proyección, proceso que se hace conjuntamente (pipelining) con el join, es: (  x 3000) donde  es un factor* entre 0 y 1 que indica el total de páginas resultantes. Este costo es el mismo para todos los planes. * Factor de reducción debido a la restricción y proyección finales.

Caso de Estudio b) Con block nested: Primero se hacen las selecciones: -Dado que hay 1000 profesores en 50 departamentos, el tamaño de  deptid = ‘CS’ (PROFESOR) es  20 filas, o sea, 4 páginas -Como el peso de semestre en CUR_PROF es 2500, entonces el tamaño de  semestre = ‘F2015’ (CUR_PROF) es 250 páginas

Caso de Estudio -Costo de las selecciones: como en ambas relaciones hay índice clustered B+ sobre deptid y semestre respectivamente, el costo total de las selecciones es: = 258 Acceso índice de PROFESOR Acceso índice de CUR_PROF Páginas resultantes de PROFESOR Páginas resultantes de CUR_PROF

Caso de Estudio Como la relación  deptid = ‘CS’ (PROFESOR) es tan pequeña, se puede mantener en memoria y a medida que se va generando la la relación  semestre = ‘F2015’ (CUR_PROF) se va haciendo el join; por lo tanto, no se requieren accesos adicionales: Costo total: 258 (páginas)

Caso de Estudio c) Se hace la selección sobre PROFESOR usando el índice clustered sobre deptid, esto genera una relación de 4 páginas (20 filas) que cabe en memoria como en el caso b), el costo es: = 6 Acceso índice de PROFESOR Páginas resultantes de PROFESOR

Caso de Estudio Para aprovechar el índice unclustered sobre profid en CUR_PROF se usará en este caso un index nested. La selección anterior genera 20 filas; cada una se espera haga join con 10 filas en promedio de CUR_PROF. Por lo tanto, se requiere: accesos: costo de búsqueda de cada profesor en el índice sobre profid en CUR_PROF - 10 accesos adicionales por cada fila de PROFESOR dado que el índice es unclustered. O sea:

Caso de Estudio Costo join: (1.2) * (20) = 24 (10) * (20) = Costo total: = 230 (páginas) Costo de usar el índice Páginas leídas de CUR_PROF

Caso de Estudio d) Primero la selección sobre CUR_PROF: El costo de  semestre = ‘F2015’ (CUR_PROF) es: = 252 páginas como en el caso b) y desde ya (y solo con esta selección inicial) pierde con el caso c)… Acceso índice de CUR_PROF Páginas resultantes de CUR_PROF

Caso de Estudio Conclusión: En este caso la mejor opción fue la c) pero habría que evaluar otras alternativas (sort merge join, hash join, etc.) en general en cada una de las opciones…