Bases de Datos Avanzadas. Dra. Elzbieta Malinowski G. Bases de datos relacionales: repaso y profundización de conceptos Parte 2

Transcripción

1 Bases de Datos Avanzadas Dra. Elzbieta Malinowski G. Bases de datos relacionales: repaso y profundización de conceptos Parte 2

2 Mejoramiento del desempeño de BDs (1) Uso de diferentes nombres: mejoramiento del desempeño, ajuste, optimización Objetivo: revisión de la estructura física de la base de datos y las aplicaciones con el fin de mejorar los aspectos de rendimiento/espacio Algunos autores distinguen ajuste y optimización como dos diferentes actividades Ajuste: diferentes acciones sobre la estructura física de la base de datos, ej., tamaño de caché, fragmentación, reconstrucción de los índices, etc. Optimización: diferentes acciones sobre las consultas, transacciones, aplicaciones, procedimientos, etc. Nosotros usamos término ajuste distinguiendo los elementos sobre los cuales se realizan las acciones de ajuste CI-2803 Dra Elzbieta Malinowski G. 2

3 Mejoramiento del desempeño de BDs (2) Ajuste de aplicaciones (optimización), por ejemplo: Cambio en los métodos de acceso (índices, tipos de join, etc.) Cambio en las sentencias de SQL Uso de optimizadores de consultas Ajuste de base de datos, por ejemplo: Modificaciones al diseño Cambio de tipo de datos Restricciones Jerarquía de almacenamiento Ajuste de parámetros del sistema, por ejemplo: Cambios en tamaño de caché de datos y de la bitácora, parámetros de checkpoint, tipo de aislamiento, procesos de respaldo, etc. Procesamiento paralelo CI-2803 Dra Elzbieta Malinowski G. 3

4 Mejoramiento del desempeño de BDs (3) Se consideran los mismos parámetros que durante diseño físico: Tiempo de respuesta Aprovechamiento de espacio Productividad de transacciones (throughput) Se puede adicionalmente considerar otros parámetros, como por ejemplo: Disponibilidad de BD Accesos concurrentes a BD CI-2803 Dra Elzbieta Malinowski G. 4

5 Mejoramiento del desempeño de BDs (4) Puede existir una variedad de metas principales, por ejemplo: Acceder el mínimo número de bloques de datos como se guardan los datos en el disco, cual es el tamaño del bloque, cuantos índices es necesario leer, etc. Mantener más bloques posibles en la memoria cual es tamaño de buffer, como se maneja la distribución de buffers para datos, índices, procedimientos almacenados, etc. Compartir el código de aplicación cuantos clientes acceden la misma aplicación, procedimientos almacenados versus servidores de aplicación, etc. Leer y escribir los datos lo más rápido posible maneja el sistema prefetching y preflushing, que políticas de manejo de buffer (también de sistema de recuperación) se usan, etc. CI-2803 Dra Elzbieta Malinowski G. 5

6 Mejoramiento del desempeño de BDs (5) Existe una variedad de metas principales (cont.): Asegurar que el usuario no espere por los recursos como se manejan los accesos concurrentes, a que nivel se usan los candados, son los niveles de aislamiento establecidos correctamente, etc. Realizar respaldo y tareas de mantenimiento de sistema minimizando el impacto sobre el desempeño de BD Se requiere muchos conocimientos sobre Los conceptos generales de base de datos La estructura de la base de datos particular Las aplicaciones Las características de la DBMS usada CI-2803 Dra Elzbieta Malinowski G. 6

7 Mejoramiento del desempeño de BDs (6) Se recopila la información sobre la estructura (del catálogo) y el uso (estadísticas) de la base de datos, ej: Tamaño de tablas Tipo de datos Frecuencia de emisión de la consulta/transacción Tiempo de ejecución de la consulta/transacción Tamaño de tablas de índice Espacio libre en páginas Rendimiento de dispositivos de E/S Niveles de aislamiento Candados Interbloqueos CI-2803 Dra Elzbieta Malinowski G. 7

8 Mejoramiento del desempeño de BDs (7) Ejemplo: Oracle provee diferentes opciones para obtener y analizar la información sobre desempeño y/o problemas de la BD: Archivos de diagnóstica: Alert log file: bitácora cronológica de mensajes y errores para detectar problemas Background process trace file: el archivo que contiene la especificación del error ocurrido en el proceso de background User trace file: solicitados por los usuarios para desplegar la información sobre la utilización de los recursos Wait events: especificación de procesos esperando recursos, por ejemplo, esperando los buffers CI-2803 Dra Elzbieta Malinowski G. 8

9 Mejoramiento del desempeño de BDs (8) Ejemplo (cont.): Catálogo - permite obtener las estadísticas después de ejecutar el comando ANALYZE Se puede consultar diferentes vistas, como DBA_TABLES, DBA_TAB_COLUMNS, DBA_CLUSTER, DBA_INDEXES, etc. Vistas especiales de desempeño (vistas tipo V$): guardan las estadísticas referentes a la sesión y la BD activa en este momento Otras La vista V$STATNAME especifica las estadísticas catalogadas en Oracle ( 180) Se agrupan de acuerdo al tópico sobre el cual se considera realizar el ajuste: actividades generales, de log buffer, locking, db buffer cache, etc. CI-2803 Dra Elzbieta Malinowski G. 9

10 Ajuste de aplicaciones de BDRs (1) Se necesita considerar junto el ajuste de índices y el ajuste de las transacciones/consultas Se analiza la consulta con respecto a su formulación y a la presencia de índices Si existe un optimizador de consultas, se analizan reglas empleadas por este optimizador y el plan de ejecución creado Problemas con aplicaciones: Consultas duran mucho debido a falta de índices Ciertos índices no se utilicen Ciertos índices causen excesivo trabajo adicional Consulta hace demasiados accesos al disco CI-2803 Dra Elzbieta Malinowski G. 10

11 Ajuste de aplicaciones de BDRs (2) Soluciones: Introducir nuevos índices de acuerdo a las características de los datos Eliminar índices no usados Reestructurar los índices con más frecuencia sin afectar el rendimiento del sistema en horas de su uso Modificar la expresión de la consulta Aprovechar, ayudar (hints o forzar) o desactivar el optimizador de consulta Muchos otros de acuerdo a particularidades de la DBMS empleada CI-2803 Dra Elzbieta Malinowski G. 11

12 Índices (1) Índices son las estructuras auxiliares de acceso a los datos Se usan para acelerar la recuperación de registros en respuesta a ciertas condiciones de búsqueda No afectan la ubicación física de los registros en el disco Contienen valores ordenados del campo de indexación y la(s) dirección(es) de registro(s) que contiene(n) dichos valor(es) Hacen más lentas las operaciones de INSERT, UPDATE o DELETE sobre el campo indexado Se puede distinguir varios grupos de categorías de índices (diferentes tipos de índices pueden pertenecer a varias categorías): Ordenamiento del archivo de datos: Índice primario (clustering): el archivo de datos está ordenado Índice secundario (non-clustering): el archivo de datos no está ordenado CI-2803 Dra Elzbieta Malinowski G. 12

13 Categorías (cont.) Índices (2) Número de atributos para la indización: Simple llave: solo se usa un atributo como llave de indización Múltiple llave: se usa dos o más atributos para la llave de indización Repetición de valores: Índice único: no se permite la repetición de los valores en la tabla de índice Índice no único: se permite la repetición de los valores en la tabla de índice Densidad de los índices: Índice escaso (sparse): tiene la entrada de índice solo para algunos valores de búsqueda (normalmente que representan primer registro del bloque) Índice denso: tiene la entrada de índice para cada valor de búsqueda que existe en el archivo de datos. CI-2803 Dra Elzbieta Malinowski G. 13

14 Índices (3) Categorías (cont.) Niveles de índices Índice de un nivel: el índice representado en la forma de un arreglo Índice de multinivel: el índice que contiene varios niveles formando la estructura de árbol de búsqueda. Estructura de datos usada Índice tipo árboles B Índices bitmap CI-2803 Dra Elzbieta Malinowski G. 14

15 Estructura del índice B+ a) Nodos internos b) Nodos hoja Índices tipo árbol B (1) Ejemplo CI-2803 Dra Elzbieta Malinowski G. 15

16 Índices tipo árbol B (2) Todas DBMSs usan los árboles B+ Es la estructura por defecto cuando se crea un índice Más valores se guarda en cada nodo, menos niveles tiene el árbol Menos niveles del árbol, menos lecturas al disco para encontrar la dirección del registro de datos Se recomienda tener las páginas grandes (8KB) para tener menos niveles de árbol Búsqueda Se lee los niveles de árbol para encontrar la dirección de dato Se lee el registro que contiene el dato CI-2803 Dra Elzbieta Malinowski G. 16

17 Inserción Índices tipo árbol B (3) DBMS revisa las páginas de índice hasta encontrar el valor de la llave mayor que nuevo valor a insertar Se aplica el shift de todos los datos en la página para encontrar el campo de grabar el valor nuevo Se copia el valor nuevo Si el valor nuevo no cabe en la página, se aplica el proceso de splitting : Se parte el nodo hoja en dos redistribuyendo los valores entre las dos páginas Se añade el puntero en el nodo al nivel intermedio Se pretende evitar el proceso de splitting en cascada en los niveles más alto del árbol (se hace el split, a veces innecesario, en los niveles intermedios en los nodos casi llenos ) El proceso de splitting puede afectar el tiempo de ejecución de las sentencias que cambian los valores de los datos CI-2803 Dra Elzbieta Malinowski G. 17

18 Borrado - dos opciones Índices tipo árbol B (4) El proceso reverso de inserción La versión de Microsoft/Oracle de marcar el registro como borrado sin su eliminación física peligro de inesperado crecimiento del índice Reconstrucción Las operaciones de INSERT, DELETE y UPDATE pueden afectar la estructura del árbol desperdiciando innecesariamente el espacio o fragmentándolo (colocando los valores de la llave de índice en páginas no continuas) Se pueden usar las opciones de REBUILD: en realidad puede no reconstruirse todo el árbol, solo se revisa cuales nodos se puede unir (depende de la DBMS) DROP: reconstruye todo el índice recomendado para bulk insert o en ambiente de muchas inserciones de datos CI-2803 Dra Elzbieta Malinowski G. 18

19 Índices tipo bitmap (1) Los índices tipo árboles B no son recomendados cuando la selectividad (el número de valores distintos entre número total de valores) sobre la llave de indización es baja Ejemplos: género, estado civil En estos casos es mejor usar el índice llamado bitmap El índice bitmap puede ser visto como una matriz donde cada fila corresponde a la dirección (i.e., a rowid) del registro y cada columna corresponde a valores diferentes del valor de la llave Si el bit tiene valor 1, esto significa que el registro contiene el valor correspondiente de la llave CI-2803 Dra Elzbieta Malinowski G. 19

20 Índices tipo bitmap (2) Ejemplo ID Name Gender Marital status Region 10 John M Married West 20 Marie F Single Central 30 Max M Divorced West 40 Ana F Single West 50 Lucy F Married Central Bitmap on gender F M Bitmap on martial status M S D CREATE BITMAP INDEX GenderBitmapIdx ON Employee(Gender); CREATE BITMAP INDEX MaritalStatusBitmapIdx ON Employee(MaritalStatus); CI-2803 Dra Elzbieta Malinowski G. 20

21 Índices tipo bitmap (3) El índice bitmap provee más ventajas para las columnas con la cardinalidad más pequeña, o sea, para las columnas donde el valor de la división de número de valores distintos entre el número de registros es pequeño (menos que 0.01) Ejemplos: Género Estado civil Provincias en CR El índice bitmap puede acelerar la respuesta a la consulta que contiene múltiples condiciones CI-2803 Dra Elzbieta Malinowski G. 21

22 Índices tipo bitmap (4) SELECT ID FROM Employees WHERE gender = F AND (marital status = Single OR marital status = Married ) AND region = Central ID Name Gender Marital status Region 10 John M Married West 20 Marie F Single Central 30 Max M Divorced West 40 Ana F Single West 50 Lucy F Married Central gender = F status = Single status = Married region = Central F S M Central AND 1 OR 0 AND 1 = CI-2803 Dra Elzbieta Malinowski G. 22

23 Índices tipo bitmap (5) Sin embargo, el índice bitmap no debería ser usado en los sistemas donde Los datos indizados se modifican frecuentemente (alto costo en reconstrucción del índice) Los campos de indización tienen alto cardinalidad, por ejemplo las llaves candidatas como número de empleado Además, no es recomendable combinar índices B y bitmap ya que La búsqueda en árboles B devuelve una lista de ROWID en el orden de la llave de indización La búsqueda por medio de índices bitmap devuelve la lista de ROWID de acuerdo al almacenamiento Para usar estas listas en AND, OR o NOT, se requiere pasos extra de conversión CI-2803 Dra Elzbieta Malinowski G. 23

24 Índices de múltiple columnas (1) Llamados también compuestos Se usan cuando las consultas se refieren frecuentemente a las mismas columnas por medio del operador AND Porque no usar varios índices sobre columnas individuales? Ejemplo: crear índices en la columnas de número de departamento y la edad para seleccionar los empleados que trabajan en departamento 4 y tienen 59 años En teoría funciona ya que se supone que una DBMS Encuentra ROWID para empleados de departamento 4 Encuentra ROWID para empleado con 59 años Hace la intersección entre los dos conjuntos de ROWID Recupera los registros que cumplen las dos condiciones Sin embargo, la mayoría de los DBMS solo usa uno de los índices y recupera los registros para verificar si se cumple la segunda condición CI-2803 Dra Elzbieta Malinowski G. 24

25 Índices de múltiple columnas (2) Como resultado se debe evitar over indexing y en cambio, se debe crear los índices sobre múltiples columnas CREATE INDEX employee_dep_age ON Employee(DepNo, Age) El orden de las columnas usado en la cláusula WHERE debe ser el mismo que usado para los índices compuestos CI-2803 Dra Elzbieta Malinowski G. 25

26 Joins (1) La sentencia con join puede usar el formato viejo SELECT * FROM Table1, Table2 WHERE Table1.column1 = Table2.column1 AND /* otras condiciones */ O formato nuevo de ANSI SELECT * FROM Table1 JOIN Table2 ON Table1.column1 = Table2.column1 WHERE /* otras condiciones */ CI-2803 Dra Elzbieta Malinowski G. 26

27 Joins (2) Anteriormente se aplicaba la regla de indexar todos los atributos que participaban en la operación join Conforme mejoran las DBMSs se incluyen diferentes opciones de join y se necesita más conocimiento para proveer las mejores condiciones a una DBMS con el fin que ésta puede seleccionar la mejor estrategia para el join La mayoría de las DBMSs usa entre dos a tres tipos de join: nested-loop, sort-merge y hash CI-2803 Dra Elzbieta Malinowski G. 27

28 Nested-loop join Joins (3) Se basa en dos ciclos anidados que recorren las dos tablas Como en DBMS el costo es relacionado con la lectura de bloques, se puede presentar un pseudo-código de la siguiente forma: for (each block in Table1) { /* outer loop */ for (each block in Table2) { /* inner loop */ for (each row in Table1-block) { /* no importante para el costo */ for (each row in Table2-block) { if (join columns matches) pass else fail } } } } Considerando el número de bloques de Table1 = n y Table2 = m, en total se lee n+ n*m bloques Sin embargo, si la tabla presente en inner loop cabe toda en el cache de DBMS, solo se ocupa n+m lecturas de bloque. Porque? CI-2803 Dra Elzbieta Malinowski G. 28

29 Nested-loop join (cont.) Joins (4) Si existe la expresión de restricción (where Table1.column = <literal>) poner la restricción primero para reducir la cantidad de tuplas para join. La tabla con la restricción debe estar en el ciclo externo Resumen: Cuando las tablas difieren en el tamaño, la más pequeña debe ser usada en el ciclo interno (inner loop) o la que tiene mejor índice Usar la tabla con restricción como outer Tener índices para una de las tablas (del ciclo interno) puede ayudar Tener índices para las dos tablas no es importante porque siempre una de las dos tablas tiene que estar en el ciclo externo Las expresiones restrictivas son evaluadas primero para dimsminur la cantidad de tuplas en resultados intermedios Este tipo de estrategia de join se utiliza en la mayoría de las consultas CI-2803 Dra Elzbieta Malinowski G. 29

30 Sort-merge join Joins (5) Conocido también como merge scan o merge join Se puede describir en la siguiente manera: sort (Table1) sort (Table2) get first row (Table1) get first row (Table2) for (until no more rows in tables) { If (join-column in Table1 < join-column in Table2) get next row in (Table1) elseif (join-column in Table1 > join-column in Table2) getnextrowin (Table2) else { pass get next row in (Table1) get next row in (Table2) }} Se supone que no existen los duplicados en ninguna de las tablas CI-2803 Dra Elzbieta Malinowski G. 30

31 Sort-merge join (cont.) Joins (6) Considerando: Table1 ocupa n bloques y Table2 m bloques Costo para tablas ordenadas: n+m Costo para tablas no ordenadas: n+ n*log 2 n + m+ m*log 2 m Ideal para las tablas que ya están ordenadas con respecto al mismo atributo de join Solo se necesita un pase por cada una de las tablas Su ejecución es más compleja que nested-loop join pero puede dar mejores resultados La DBMS puede escoger este tipo de join cuando solo existe la operación de join sin ninguna restricción y suficiente memoria Ignora la existencia de los índices Sin embargo: algunas DBMSs (ej. Sybase) requieren una activación explícita de esta opción o reservación de suficiente espacio para ordenamiento (ej. Oracle en el parámetro SORT_AREA_SIZE) CI-2803 Dra Elzbieta Malinowski G. 31

32 Hash join Joins (7) Existen diferentes técnicas de acuerdo al tamaño de las tablas Si una tabla cabe entera en le memoria: for each row in Table1 produce a hash asign the hash to hash bucket for each in Table2 produce hash if the hash is already in the hash bucket apply join Costo: n+m Si las tablas son grandes se aplica hybrid hash: for each row in Table1 produce a hash asign the hash to hash bucket on disk for each in Table2 produce hash asign the hash to hash bucket on disk for each hash bucket with the same hash value of Table1 and Table2 apply join Costo 3*(n+m) CI-2803 Dra Elzbieta Malinowski G. 32

33 Joins (8) Hash join (cont.) Funciona mejor en la condiciones de equi-join sin las expresiones de restricción y cuando las tablas son grandes Ignora índices CI-2803 Dra Elzbieta Malinowski G. 33

34 Joins (9) El tipo de la estrategia para join que selecciona una DBMS depende de índices, tamaño de las tablas y factor de selectividad El implementador puede forzar uso de diferentes tipos de joins, por ejemplo, por medio de Hints in Oracle SELECT /*+ USE_MERGE (Table1 Table2) */ * FROM Table1, Table2 WHERE Table1.column1 = Table2.column1 Opciones en Microsoft SELECT * FROM Table1, Table2 WHERE Table1.column1 = Table2.column1 OPTION (HASH JOIN) CI-2803 Dra Elzbieta Malinowski G. 34

35 Joins (10) Three-way joins join aplicado a tres o más tablas, ej. SELECT * FROM Table1, Table2, Table3 WHERE Table1.column = Table2.column1 AND Table2.column1 = Table3.column1 La estrategia es join Table1 y Table2 y después join el resultado con Table3 Cuando hay muchas tablas (5 o más) las DBMS pueden tener dificultades con la selección de una estrategia adecuada Añadiendo la condición redundante de join puede mejorar esta selección ya que se presenta a la DBMS todas opciones de hacer join (usa esta opción cuando optimizadores no son buenos): AND Table1.column1 = Table3.column1 La pregunta pendiente en cual orden presentar las tablas debe ser deducida en base de la explicación presentada para two-way join CI-2803 Dra Elzbieta Malinowski G. 35

36 Joins (11) Outer join da como resultado todas las tuplas que tienen valores comunes en el atributo de join y los demás tuplas que están en el relación especificada en la cláusula de outer join (left o right) SELECT Table1.column1 FROM Table1 LEFT OUTER JOIN Table2 ON Table1.column1 = Table2.column1 Se requiere posicionar en el ciclo externo la tabla para la cual se requiere obtener todas las tuplas, o sea, Table1 Esto impide usar las estrategias de por ejemplo poner la tabla más pequeña en el ciclo interno CI-2803 Dra Elzbieta Malinowski G. 36

37 Joins (12) Outer join se ejecuta más rápido que su equivalente sentencia con UNION ALL SELECT Table1.column1 FROM Table1, Table2 WHERE Table1.column1 = Table2.column1 UNION ALL SELECT Table1.column1 FROM Table1 WHERE Table1.column1 NOT IN (SELECT Table2.column1 FROM Table2) CI-2803 Dra Elzbieta Malinowski G. 37

38 Modificaciones de consultas (1) En muchas ocasiones se puede mejorar el desempeño del sistema transformando las sentencias SQL en otras sentencias equivalentes Para esto se necesita buen conocimiento de SQL y de forma como éstas se ejecutan en la DBMS usada Las siguientes recomendaciones fueron dadas después de ejecutar diferentes consultas en 8 DBMSs: IBM DB2 Universal Database 7.2 IBM Informix Dynamic Server 9.3 Ingres II 2.5 Interbase 6.0 Microsoft SQL Server 2000 MySQL 3.23 Oracle 9i Sybase ASE 12.5 CI-2803 Dra Elzbieta Malinowski G. 38

39 Simple búsqueda Modificaciones de consultas (2) El tiempo de validar las condiciones depende del tipo de dato, operadores usados y la existencia de funciones, por ejemplo Las comparaciones con INTEGER son más rápidas que con DECIMAL o FLOAT La comparación <> es más lenta que < AND >= WHERE UPPER (column1) = BRENES se puede expresar como WHERE column1 = BRENES or column1 = Brenes Si hay varias condiciones poner primero las comparaciones de igualdad con campos numéricos, siguen con campos alfanuméricos y después las comparaciones de desigualdad, por ejemplo, SELECT * FROM Table 1 WHERE column1 = 5 AND column2 = 77.2 AND column3 = Brenes AND column4 < 117 AND column4 > column5 CI-2803 Dra Elzbieta Malinowski G. 39

40 Modificaciones de consultas (3) Simple búsqueda (cont.) Si hay varias operaciones AND seguidas poner como primera la menos compleja o que más probable da valor falso (excepto en Oracle evalua desde la derecha hacia la izquierda con optimizador basado en costo) Con la primera condición en falso la DBMS normalmente no evalúa otras expresiones de la condición Con varias operaciones OR poner la expresión que más probable da valor verdadera como primera (excepto en Oracle) Transformar NOT por la forma positiva. Ej. WHERE NOT (column1 > 5) equivale a WHERE column1 <= 5 Aplicar reglas de DeMorgan si necesario NOT (A AND B) = (NOT A) OR (NOT B) NOT (A OR B) = (NOT A) AND (NOT B) CI-2803 Dra Elzbieta Malinowski G. 40

41 Modificaciones de consultas (4) Simple búsqueda (cont.) Transformar OR en IN o modificar OR e IN en BETWEEN, por ejemplo WHERE column1 = 5 OR column1 = 6 equivale a WHERE column1 IN (5,6) WHERE column1 IN (1,2,3,4,5) equivale a WHERE column1 BETWEEN 1 AND 5 Cambiar la operación de conjuntos sobre la misma tabla (UNION) por la condición con OR, por ejemplo, SELECT * FROM Table1 WHERE column1 = 5 UNION SELECT * FROM Table1 WHERE column2 = 5 equivale a SELECT DISTINCT * FROM Table1 WHERE column1 = 5 OR column2 = 5 Sin embargo, muchos optimizadores no usan índices cuando ven OR, entonces la primera versión aunque pasa dos veces por la misma tabla puede resultar mejor CI-2803 Dra Elzbieta Malinowski G. 41

42 ORDER BY Modificaciones de consultas (5) Muchas DBMSs usan la misma estrategia para ORDER BY que para GROUP BY, DISTINCT y UNION El tiempo de ejecución de ORDER BY depende de Número de tuplas seleccionadas Número de columnas especificadas en ORDER BY El tamaño de las columnas Los experimentos demostraron que tiempo de ejecución crece en forma de progresión geométrica con respecto al número de tuplas, ej., si se aumenta número de tuplas 10 veces, el tiempo de ejecución crece 20 veces Solución: usar más procesadores o memoria El aumento en número de columnas especificadas afecta más el tiempo de ejecución que aumento en el tamaño de las columnas Solución: concatenar varias columnas CI-2803 Dra Elzbieta Malinowski G. 42

43 ORDER BY (cont.) Modificaciones de consultas (6) Cuando se usa el campo de ordenamiento tipo VARCHAR, los campos definidos con más posiciones (aunque en realidad ocupan solo una parte) empeoran el tiempo de ejecución Se puede evitar el uso de ORDER BY y obtener los datos ordenados cuando: El archivo se guarda como ordenado (ej., clusters) Se tiene índice primario en el campo requerido como ordenado (suponiendo que DBMS lo usa) Se tiene DISTINCT en el campo requerido como ordenado y hay valores duplicados No se debe confundir ordenar un archivo con indexar Se puede usar los índices para obtener el resultado ordenado pero se ocupa incluir la cláusula WHERE, ej. de un truco para columna tipo char SELECT * FROM Table1 WHERE column1 >= ORDER BY column1 CI-2803 Dra Elzbieta Malinowski G. 43

44 GROUP BY Modificaciones de consultas (7) Similar situación al uso de ORDER BY. Adicionalmente: Usar pocas columnas para agrupamiento No utilizar la llave primaria en la cláusula no existe ningún agrupamiento Si se utiliza GROUP BY sin ninguna función de agregación (o de conjunto), se puede reemplazarlo por DISTINCT. Ej. SELECT column1 FROM Table1 GROUP BY column1 equivale a SELECT DISTINCT column1 FROM Table1 Cuando se puede, especifique condición en la cláusula WHERE en lugar de usar HAVING. Ej. SELECT column1 FROM Table1 WHERE column2 = 5 GROUP BY column1 HAVING column1 > 6 equivale a SELECT column1 FROM Table1 WHERE column2 = 5 AND column1 > 6 GROUP BY column1 CI-2803 Dra Elzbieta Malinowski G. 44

45 GROUP BY (cont.) Modificaciones de consultas (8) Índices pueden mejorar el tiempo de ejecución, sin embargo las operaciones de join y condiciones en WHERE tienen más alta prioridad que GROUP BY. Ej. SELECT column1 FROM Table1 WHERE column2 = 55 GROUP BY column1 No se utiliza el índice para la column1 porque está definido para toda la Table1 y la condición WHERE selecciona solo una parte de la tabla GROUP BY utiliza el índice si las columnas de agrupamiento aparecen en el mismo orden que las columnas de índice. Ej. si la column1 está indexada, la siguiente consulta se ejecuta más rápido que sin ningún índice: SELECT column1 FROM Table1 GROUP BY column1 CI-2803 Dra Elzbieta Malinowski G. 45

46 Modificaciones de consultas (9) Funciones de conjuntos (agregaciones) MIN/MAX usan el índice si la función está por si sola en SELECT, ej. SELECT MIN (column1) FROM Table1 Si se requiere varias funciones, se consigue mejor tiempo de ejecución separándolas en consultas individuales. Ej. SELECT MIN (column1), MAX (column1) FROM Table1 es mejor escribir como SELECT MIN (column1) FROM Table1 SELECT MAX (column1) FROM Table1 COUNT usa el índice si referencia solo una columna (o *) y no existen otras cláusulas después de FROM. Ej. SELECT COUNT (column1) FROM Table1 SUM o AVG no representan mejoría en tiempo de ejecución en la presencia de índices CI-2803 Dra Elzbieta Malinowski G. 46

47 Modificaciones de consultas (10) Sub-consultas (subqueries) la cláusula SELECT con otro SELECT anidado Puede ser de dos tipos: Anidados: cuando el SELECT interno no se refiere a la(s) columna(s) de la(s) tabla(s) del ciclo externo SELECT P.NumProy FROM Proyecto P WHERE P.NumProy IN (SELECT T.NumP FROM Trabaja_En) Correlacionados: cuando el SELECT interno utiliza columna(s) de la(s) tabla(s) del ciclo externo SELECT E.Apellido FROM Empleado E WHERE E.NSS IN (SELECT D.NSSE FROM Dependiente D WHERE D.NSSE=E.NSS) CI-2803 Dra Elzbieta Malinowski G. 47

48 Modificaciones de consultas (11) Existen tres posibilidades de procesamiento: Flattening (aplanar): transformar la consulta en join y después procesar join (subqueries anidadas y correlacionadas) In-to-out (de dentro a fuera): para cada tupla en la consulta interna, hacer búsqueda en la consulta externa (subqueries anidadas) Out-to-in (de afuera a dentro): para cada tupla en la consulta externa, hacer búsqueda en la consulta interna (subqueries anidadas y correlacionadas) CI-2803 Dra Elzbieta Malinowski G. 48

49 Modificaciones de consultas (11) Flattening (subqueries anidadas y correlacionadas): SELECT * FROM Table1 WHERE Table1.column1 IN /* = ANY */ (SELECT Table2.column1 FROM Table2 WHERE Table2.column2 = 3) se puede escribir como SELECT Table1.* FROM Table1, Table2 WHERE Table1.column1 = Table2.column1 AND Table2.column2 = 3 Diferencia en ejecución Nested loop for join Nested loop for subqueries (out-to-in) for (each row in Table1) { for (each row in Table 1) { for (each row in Table2) { for (each row in Table2) { if match add to matchlist }} if match EXIT loop }} Revisa todas combinaciones Necesita encontrar solo el primer match CI-2803 Dra Elzbieta Malinowski G. 49

50 Modificaciones de consultas (12) In-to-out (subqueries anidadas) SELECT * FROM Table1 WHERE Table1.column1 IN (SELECT Table2.column1 FROM Table2 WHERE Table2.column2 = 3) Ejecución: Evalúa la consulta interna (where Table2.column2 = 3) Ordena el conjunto resultante con respecto a Table2.column1 y elimina los duplicados Para cada valor del conjunto revisa le igualdad con Table1.column1 (importante tener índices para este campo) CI-2803 Dra Elzbieta Malinowski G. 50

51 Modificaciones de consultas (13) Out-to-in (subqueries anidadas y correlacionadas) SELECT * SELECT * FROM Table1 FROM Table1 WHERE Table1.column1 IN WHERE EXISTS (SELECT Table2.column1 (SELECT * FROM Table2 FROM Table2 WHERE Table2.column2 = 3) WHERE Table1.column1 = Table2.column1) Ejecución: for (each row in Table 1) { for (each row in Table2) { if match EXIT loop } } CI-2803 Dra Elzbieta Malinowski G. 51

52 Modificaciones de consultas (14) Subqueries resumen: Estrategias de ejecución de subqueries pueden variar de acuerdo a la DBMS Usando flattening permitimos a optimizador buscar la mejor estrategia Usando subqueries limitamos el número de estrategias disponible para evaluar pero podemos lograr menos iteraciones En general DBMSs actuales enfocan más en mejorar la ejecución (rendimiento) durante las operaciones de join que en sub-consultas CI-2803 Dra Elzbieta Malinowski G. 52

53 Optimizadores de consultas (1) Transforman la consulta original en la versión alternativa que mejora el tiempo de ejecución de acuerdo a las reglas especificas Basados en heurísticas: se modifica el árbol canónico de la consulta usando las reglas de transformación de álgebra relacional a expresiones equivalentes Basados en costo: se seleccionan las estrategias de ejecución de la consulta (empleo de diferentes tipos de join, de índices, orden de las tablas, etc.) que minimizan el costo, i.e., el número de bloques que se necesita leer del disco Difieren en la selección de elementos para considerar Se necesita conocer las reglas usadas por el optimizador de consulta especifico para afinar la consulta y disminuir su tiempo de ejecución CI-2803 Dra Elzbieta Malinowski G. 53

54 Optimizadores de consultas (2) En DBMSs se pueden consultar los resultados de optimización por medio de los comandos o usando gráficos Oracle: EXPLAIN PLAIN (requiere la existencia de Plan_table), SQLTRACE Microsoft: SHOWPLAN Si se usa el optimizador basado en costo, es recomendable antes actualizar las estadísticas del catálogo CI-2803 Dra Elzbieta Malinowski G. 54

55 Stored procedures SP (1) Stored procedure tiene dos carácterísticas: Se guarda en la BD (stored) Contiene código de procedimiento (procedure) SP puede tener parámetros, definir y manejar variables, devolver valores, incluir código de 3GL y también operaciones de SQL Cuando se crea SP se guarda su versión parseada en la BD y la información sobre su existencia, objetos que usa, derechos, etc. en el catálogo del sistema Cuando se ejecuta SP por primera vez, se hace la precompilación y se crea el plan de ejecución CI-2803 Dra Elzbieta Malinowski G. 55

56 Stored procedures SP (2) Las invocaciones posteriores pueden usar este plan sin la necesidad de crear un plan nuevo. Sin embargo, Siempre se necesita revisar las dependencias (algunos objetos pueden ser borrados o modificados) Uso de los parámetros puede obligar cambiar el plan de ejecución Si no hay espacio en el caché, se necesita volver a pre-compilar SP SP se crea cuando la consulta es frecuentemente usada (por muchos usuarios de la BD) CI-2803 Dra Elzbieta Malinowski G. 56

57 Stored procedures SP (2) Ventajas Menos tráfico de redes: el usuario inicia la ejecución y obtiene resultado. Cuál es la diferencia ejecutando una aplicación que hace lo miso que SP? Se guarda en el servidor en forma precompilada: el análisis sintáctico y validación se hace solo una vez Se puede compartir entre diferentes aplicaciones: no se ocupa la propagación de modificaciones Se facilita el control de acceso: se puede asignar derechos de acceso y manipulación de la misma forma como para los otros objetos de la BD Se guarda la información en el catálogo: la información sobre el nombre, estructura, parámetros y resultados se puede acceder del catálogo CI-2803 Dra Elzbieta Malinowski G. 57

58 Sin embargo: Store procedures SP (3) Solo se puede guardar el número establecido de SP en el cache (ej. Informix permite 16 SP) Se crea el plan de ejecución en la primera llamada de SP (si se usan parámetros, el plan puede no ser el más adecuado) Si SP no está en el cache, debe precompilarse (traducir al sintaxis de compilador usado) en su primera ejecución Puede durar más que una sentencia SQL precompilada debido a sobrecarga, ej. búsqueda de SP, control de privilegios, etc. CI-2803 Dra Elzbieta Malinowski G. 58

59 Transacciones (1) Transacción ejecución del programa o sentencia SQL que acceda o cambia el contenido de la BD dejándola en estado consistente Sin embargo, debido a la ejecución concurrente de las transacciones, la consistencia puede perderse Se pueden presentar diferentes problemas debido a las operaciones de READ (o SELECT) y WRITE (UPDATE, DELETE o INSERT) CI-2803 Dra Elzbieta Malinowski G. 59

60 Transacciones (2) Cuatro tipos de problemas son bien conocidos: Thelostupdateproblem: una transacción sobrescribe el valor de la otra; la dependencia write write entre las dos transacciones Dirty read: una transacción lee el valor de la otra mientras la última aborta su ejecución; la dependencia write read entre las dos transacciones Unrepeatable read una transacción lee el valor varias veces mientras otra transacción lo modifica; la dependencia read-write entre las dos transacciones Phantom tuplas - una transacción lee el valor de varias tuplas mientras otra transacción inserta o borra los registros. CI-2803 Dra Elzbieta Malinowski G. 60

61 Transacciones (3) En la búsqueda de soluciones para evitar los problemas anteriores se establecieron las características llamadas ACID que las transacciones deben cumplir: Atomicidad: se ejecuta toda o no se hace nada (sin permitir enviar el mensaje de error) Consistencia: el nuevo estado de la BD cumple con todas las restricciones establecidas (suponiendo que el estado de la BD es consistente antes de ejecutar la transacción) Isolation (aislamiento): un programa que se ejecuta bajo la protección de la transacción en un ambiente concurrente tiene que comportarse como si fuera ejecutada en un ambiente de usuario simple Durability (permanencia): los resultados de la ejecución exitosa de la transacción quedan grabados en forma permanente CI-2803 Dra Elzbieta Malinowski G. 61

62 Transacciones (4) Para asegurar las características ACID se implementaron sistemas de: Control de concurrencia para característica I y C Recuperación para características A, C y D Cuales de estas características requiere adicionalmente la participación del programador? Además, se estableció los estados por los cuales debe pasar una transacción CI-2803 Dra Elzbieta Malinowski G. 62

63 Control de concurrencia (1) La idea de aislamiento originó el concepto de transacciones serializables cuando el resultado de la ejecución de dos o más transacciones concurrentes produce el mismo resultado que su ejecución en serie (secuencial) Para asegurar seriabilidad de las transacciones se establecieron las siguientes reglas: La transacción T no sobrescribe los valores sucios (modificados por otra transacción) de otras transacciones; previene lost update Las escrituras de la transacción T no pueden ser leídas por otras transacciones hasta que la primera no envía COMMIT y la transacción T no puede leer los valores sucios de otras transacciones; previene dirty read Otras transacciones no escriben sobre ningún dato leído por la transacción T hasta que ésta no haga COMMIT; previene unrepeatable read CI-2803 Dra Elzbieta Malinowski G. 63

64 Control de concurrencia (2) Se procedió en diferentes direcciones: Crear un plan de ejecución de todas las transacciones y establecer si existen las dependencias que producen inconsistencias (n transacciones - n! formas de ordenarlas!!!) Dejar las transacciones ejecutarse y verificar posteriormente si el plan produce transacciones serializables (problema de posible cancelación de ejecución?) Implementar los métodos que garanticen la seriabilidad La última dirección dio origen a los protocolos de control de concurrencia: Basado en candados: Tipos de candados: S, X, IS, IX, SIX Tipos de protocolo: 2 phase-locking básico, estricto, conservativo con las fases de expansión y encogimiento, de ganularidad múltiple, y otros Basado en estampillas de tiempo: Tipo de estampillas: TS_transaction, TS_read, TS_write. Tipos de protocolo: ordenamiento por marca de tiempo, multiversiones, y otros CI-2803 Dra Elzbieta Malinowski G. 64

65 Protocolo two-phase locking Protocolos basados en candados establecen las reglas de compatibilidad y el orden de solicitud/liberación de candados: 2PL: S X Compatibilidad de candados S + - X - - NO WAIT versus WAIT políticas Fases de crecimiento y encogimiento para diferentes tipos 2PL time time time Begin Commit Begin Commit Begin Commit Trans. Trans. Trans. Trans. Trans. Trans. Básico Estricto Conservativo Algunos sistemas comerciales incluyen otros candados, por ejemplo U para modificación (update) que puede coexistir solo con candados S CI-2803 Dra Elzbieta Malinowski G. 65

66 Niveles de aislamiento (1) Determinan el tipo del problema de concurrencia que el sistema puede tolerar para la ejecución de la transacción En consecuencia, delegan al programador la responsabilidad sobre la consistencia de la BD y posibilidades de recuperación Sirven para establecer: Lo sensible que será aplicación a los cambios realizados por otras transacciones Cuando tiempo tendrá que mantener la transacción los candados para protegerse de los cambios realizados por los otros Número de transacciones concurrentes admitido al sistema CI-2803 Dra Elzbieta Malinowski G. 66

67 Niveles de aislamiento (2) De acuerdo a SQL estándar existen 4 tipos de niveles de aislamiento: Read uncommited Read commited Repeatable read Serializable Se puede establecer por medio del comando: SET TRANSACTION ISOLATION LEVEL [nombre del nivel] CI-2803 Dra Elzbieta Malinowski G. 67

68 Niveles de aislamiento (3) Read uncommited (browse): El nivel más bajo que asegura más alto nivel de concurrencia No existen los candados S Se usan los candados largos de X y el protocolo 2PL con respecto a la operación write en algunos especificaciones SQL estándar y muchos sistemas no permiten de todo hacer modificaciones en este nivel de aislamiento (READ ONLY) Transacción puede leer los registros modificados por otras transacciones que todavía no hicieron COMMIT, o sea mientras otras transacciones los modifican Se puede dar problema de dirty read Cuando usarla: en los análisis, revisión de la situación general, Internet, donde no importa la precisión de los datos CI-2803 Dra Elzbieta Malinowski G. 68

69 Niveles de aislamiento (4) Read commited (cursor stability): Existen candados de lectura cortos que pueden ser liberados antes de que la transacción termina (no se sigue 2PL) Candados de escritura se liberan al final de la transacción (2PL estricto) Otras transacciones pueden leer el dato que su transacción lee también, pero tienen que esperar para modificarlos Se asegura que una operación nunca va a leer datos que otra aplicación ha modificado pero no ha confirmado todavía Se evita problemas de dirty read y lost update Pueden darse los problemas de unrepeatable read o tuplas fantasmas Se usa cuando la transacción no requiere volver leer los mismos datos de nuevo, por ejemplo, las transacciones con solo una sentencia de SQL Es el nivel más usado por defecto en mayoría de los DBMSs CI-2803 Dra Elzbieta Malinowski G. 69

70 Niveles de aislamiento (5) Repeatable read: Existen candados de lectura y escritura siguiendo el protocolo de 2PL estricto (liberación al final de la transacción) Ningún usuario podrá modificar los datos visitados por su transacción mientras la misma esté pendiente Se evita problemas de dirty read, lost update y unrepeatable read Puede darse el problema de tuplas fantasmas ya que los candados no se establecen en el nivel de la tabla (se ponen en nivel de tupla o bloque) Ej. SELECT * FROM Table1 UPDATE Table1 SET column2 = 10 WHERE column1 = 5 SET column1 = 5 WHERE column1 = 8 Si la transacción contiene la condición sobre una tuple simple, no se dan tuplas fantasmas CI-2803 Dra Elzbieta Malinowski G. 70

71 Niveles de aislamiento (6) Serializable: Da el más bajo nivel de concurrencia Es el nivel por defecto de SQL estándar DBMS tiene que poner candados en el nivel de la tabla o usar los protocolos de concurrencia basados en diferentes granularidades o candados de rango Existen candados de lectura y escritura siguiendo el protocolo de 2PL Muchos sistemas usan los candados en nivel de tabla o candados sobre los índices cuales se usan para ejecutar la transacción Cuando usar: en aplicaciones críticas por ejemplo haciendo reporte bancario de todas las cuentas CI-2803 Dra Elzbieta Malinowski G. 71

72 Niveles de aislamiento (7) Resumen de niveles de concurrencia y problemas Isolation level Lost update Dirty read Unrepeatable read Phantom Read uncommitted Read committed No Yes Yes Yes No No Yes Yes Repeatable No No No Yes read Serializable No No No No CI-2803 Dra Elzbieta Malinowski G. 72

73 Granularidad de candados (1) Granularidad se refiere al tamaño del área bloqueada Toda DB, tabla, página (bloque), registro (tupla), columna Candados a nivel de registro Permiten acceso a más transacciones Pueden darse los problemas de consistencia de los datos (tuplas fantasmas) Pueden producir más grande overhead debido a más alto número de las solicitudes de candados y su liberación Candados a nivel de tabla Evitan los problemas de inconsistencia de los datos Disminuyen overhead Disminuyen el nivel de concurrencia Muchas DBMSs son capaces de cambiar la granularidad de candado considerando el nivel de aislamiento y el tipo de operación ejecutada CI-2803 Dra Elzbieta Malinowski G. 73

74 Granularidad de candados (2) Escalamiento - el acto de DBMS de cambiar varios candados (potenciales o reales) en un simple candado de más granularidad, por ejemplo, de candado de página a tabla durante la operación de full scan Candados de intensión el candado explícito en nivel más bajo de jerarquía indica el candado de intensión en el nivel más alto El programador no tiene control sobre los candados de intensión El programador puede solicitar explícitamente diferentes granos y tipos de candados (no es parte de SQL estándar) CI-2803 Dra Elzbieta Malinowski G. 74

75 Interbloqueos (deadlocks) (1) Los interbloqueos ocurren cuando dos o más transacciones esperan la liberación de candados de cada una de ellas Ejemplo: T1 SLOCK(Y); READ(Y); XLOCK(X); T2 SLOCK(X); READ(X); XLOCK(Y); CI-2803 Dra Elzbieta Malinowski G. 75

76 Interbloqueos (deadlocks) (2) Los interbloqueos se debe evitar Haciendo los candados exclusivos desde el principio de la transacción (uso de sentencias de dummy UPDATE or LOCK) Asegurándose que todas las transacciones adquieren locks sobre los datos en el mismo orden, ejemplo primero sobre dato A, después sobre dato B, etc. Incluyendo una parte en la aplicación que define acciones cuando ocurre un error de interbloqueo en su sistema CI-2803 Dra Elzbieta Malinowski G. 76

77 LO MISMO SE DESGASTA UN SER HUMANO PARA TRIUNFAR QUE PARA SER UN FRACASADO Miquel Ángel Cornejo CI-2803 Dra Elzbieta Malinowski G. 77