IBD

1. IBD Clase 18

2. Entornos concurrentes • Existen varias razones para permitir la concurrencia (aunque es más sencillo que las transacciones se ejecuten secuencialmente): • Una transacción consiste de varios pasos. Algunos pasos implican operaciones de E\S, otros implican operaciones de CPU. IBD - CLASE 18

3. Entornos concurrentes • Las operaciones de E\S se pueden realizar en paralelo con el procesamiento de CPU. Se puede explotar este paralelismo y ejecutar varias transacciones en paralelo. • Se aumenta la productividad del sistema, hay menos dispositivos desocupados. • Se mejora el tiempo de respuesta promedio de una transacción. IBD - CLASE 18

4. Entornos concurrentes • Varias transacciones ejecutándose simultáneamente compartiendo recursos. • Deben evitarse problemas de consistencia de datos • Transacciones correctas, en ambientes concurrente pueden llevar a fallos • Se necesita un mecanismo de control de concurrencia, para asegurar que las transacciones concurrentes no interfieran entre sí (destruyendo la consistencia de la BD) IBD - CLASE 18

5. Entornos concurrentes T0 READ( a ) T1 READ( a ) a := a – 50 temp := a * 0.1 WRITE( a ) a := a – temp READ( b ) WRITE( a ) b := b + 50 READ( b ) WRITE( b ) b := b + temp WRITE( b ) • Resolver T0, T1 o T1, T0 se respeta A+B • Ahora bien, T0 T1 <> T1 T0 IBD - CLASE 18

6. READ(A) A := A – 50 WRITE(A) READ(A) TEMP := A * 0.1 A := A – TEMP WRITE(A) READ(B) B := B + 50 WRITE(B) READ(B) B := B + TEMP WRITE(B) A + B se conserva READ(A) A := A – 50 READ(A) TEMP := A * 0.1 A := A – TEMP WRITE(A) READ(B) WRITE(A) READ(B) B := B + 50 WRITE(B) B := B + TEMP WRITE(B) A + B no se conserva Entornos concurrentes IBD - CLASE 18

7. Entornos concurrentes • Problemas de Concurrencia • Una transacción correcta por si misma, puede producir resultado incorrecto por interferencia con otra transacción • Tres posibles problemas: • El problema de la actualización perdida • El problema de la dependencia no confirmada • El problema del análisis inconsistente IBD - CLASE 18

8. Entornos concurrentes • El Problema de la actualización perdida (graficar) • La Transacción A recupera la tupla t en el tiempo t1 • La Transacción B recupera la misma tupla t en el tiempo t2 • La Transacción A actualiza la tupla t en el tiempo t3 • La Transacción B actualiza la misma tupla t en el tiempo t4 • La actualización de la Transacción A se pierde en t4 IBD - CLASE 18

9. Entornos concurrentes • Problema de la dependencia no confirmada (graficar) • Una Transacción recupera o actualiza una tupla actualizada por otra Transacción (aún no finalizada) • La Transacción B actualiza la tupla t en el tiempo t1 • La Transacción A recupera la tupla t en el tiempo t2 • La Transacción B deshace la actualización de la tupla t en el tiempo t3 (undo) • La Transacción A está operando bajo suposición falsa IBD - CLASE 18

10. Entornos concurrentes • Problema del análisis inconsistente (graficar) • La Transacción A acumula saldos de 3 cuentas (c1,c2,c3) • La Transacción B transfiere $10 de c3 a c1 y se confirma, antes de que A acumule el saldo de la cuenta c3 • Si A finaliza con éxito, produce inconsistencia en la BD IBD - CLASE 18

11. Entornos concurrentes • Conclusiones • El programa debe conservar la consistencia • Sólo las instrucciones READ y WRITE son importantes y deben considerarse. IBD - CLASE 18

12. Entornos concurrentes • La secuencia de ejecución de transacciones se denominan planificación. Representa el orden cronológico en el cual se ejecutan las instrucciones del sistema. • Planificación secuencial: consiste de una secuencia de instrucciones de varias transacciones, en la cual las instrucciones pertenecientes a una única transacción están juntas. IBD - CLASE 18

13. Entornos concurrentes • Cuando se ejecutan concurrentemente varias transacciones, la planificación no tiene por qué ser secuencial. Son posibles muchas más secuencias de ejecución, puesto que varias instrucciones de distintas transacciones se pueden intercalar. IBD - CLASE 18

14. Control de Concurrencia • Seriabilidad • La ejecución concurrente de varias transacciones debe generar el mismo resultado que la ejecución en serie de las mismas. • La ejecución de un conj. de transacciones es correcta cuando es seriable (produce el mismo resultado que una ejecución serial de las mismas transacciones, ejecutando una a la vez) IBD - CLASE 18

15. Control de Concurrencia • Seriabilidad • 1. Las transacciones individuales son tomadas como correctas (se da por hecho que transforman un estado correcto de BD en otro estado correcto) • 2. Es correcta la ejecución de una transacción a la vez en cualquier orden serial • 3. Una ejecución intercalada es correcta cuando equivale a alguna ejecución serial (es seriable) IBD - CLASE 18

16. Control de Concurrencia • Seriabilidad • Dado un conj. de transacciones, a cualquier ejecución de ellas (intercaladas o no) se le llama Plan • La ejecución de una transacción a la vez, sin intercalado, constituye un Plan Serial • Un Plan no serial es intercalado • Dos planes son equivalentes cuando garantizan que producirán el mismo resultado independientemente del estado inicial de la BD • Un Plan es correcto, cuando equivale a un Plan Serial IBD - CLASE 18

17. Control de Concurrencia • Si una transacción Ti falla, es necesario deshacer el efecto de dicha transacción para asegurar atomicidad • Es necesario asegurar también que toda transacción Tj que dependa de Ti (Tj lee datos que ha escrito Ti) se aborte también. • Planificación recuperable: aquella en la que para todo par de transacciones Ti y Tj, tales que Tj lee elem. de datos que ha escrito antes Ti, la operación comprometer de Ti aparece antes que la de Tj. IBD - CLASE 18

18. Entornos concurrentes • Conflicto en planificaciones serializables: • I1, I2 instrucciones de T1 y T2 • Si operan sobre datos distintos. NO hay conflicto. • Si operan sobre el mismo dato • I1 = READ(Q) = I2, no importa el orden de ejecución • I1 = READ(Q), I2 = WRITE(Q) depende del orden de ejecución (I1 leerá valores distintos) • I1 = WRITE(Q), I2 = READ(Q) depende del orden de ejecución (I2 leerá valores distintos) • I1 = WRITE(Q) = I2, depende el estado final de la BD • I1, I2 están en conflicto si actúan sobre el mismo dato y al menos una es un write. IBD - CLASE 18

19. Entornos concurrentes • Una Planificación S se transforma en una S´ mediante intercambios de instrucciones no conflictivas, entonces S y S´ son equivalentes en cuanto a conflictos. • S´ es serializable en conflictos si existe S/ son equivalentes en cuanto a conflictos y S es planificable serie. • Pruebas de seriabilidad • Algoritmo para determinar seriabilidad de conflictos: grafo dirigido (grafo de precedencia) IBD - CLASE 18

20. Entornos concurrentes • Conjunto de vértices (transacciones de la planificación) • Cto de aristas ( Ti  Tj / • Ti ejecuta un write(q) antes que Tj un read(q) • Ti ejecuta un write(q) antes que Tj un write(q) • Ti ejecuta un read(q) antes que Tj un write(q) • Si el grafo tiene ciclos la planificación no es serializable en conflictos. IBD - CLASE 18

21. Entornos concurrentes • Métodos de control de concurrencia • Bloqueo • Basado en hora de entrada IBD - CLASE 18

22. Control de Concurrencia • Bloqueo • Cuando una Transacción deba asegurarse que algún objeto sobre el que tenga interés (una tupla) no cambiará mientras lo use, adquiere un Bloqueo sobre ese objeto • Dos tipos de Bloqueos: • Exclusivos (de escritura) • Compartidos (de lectura) IBD - CLASE 18

23. Control de Concurrencia • Bloqueo • Si la Transacción A pone un bloqueo exclusivo Lock_e(dato) sobre la tupla t -> se rechaza el pedido de cualquier otra transacción para un bloqueo de cualquier tipo sobre t • Si la Transacción A pone un bloqueo compartido Lock_c(dato) sobre la tupla t: • se rechaza el pedido de cualquier otra transacción para un bloqueo exclusivo sobre t • se acepta el pedido de cualquier otra transacción para un bloqueo compartido sobre t IBD - CLASE 18

24. Control de Concurrencia • Protocolo de Bloqueo • Una Transacción que desea recuperar una tupla t, primero debe adquirir un bloqueo compartido sobre t • Una Transacción que desea actualizar una tupla t, primero debe adquirir un bloqueo exclusivo sobre t • Si el bloqueo pedido por una Transacción B se rechaza porque conflictúa con un bloqueo de la Transacción A , entonces B pasa a espera hasta que se libere el bloqueo de A • Las transacciones piden lo que necesitan. • Los bloqueos pueden ser compatibles y existir simultáneamente (compartidos) IBD - CLASE 18

25. Control de Concurrencia • Deadlock (“Abrazo Mortal”) • Situación en la que dos o más transacciones se encuentran en estado simultáneo de espera • Si ocurre Deadlock el sistema lo debe detectar y romper • La detección implica descubrir un ciclo en el grafo de espera (el grafo de “quién está esperando a quién”) • La ruptura implica seleccionar una transacción bloqueada mortalmente como víctima y deshacerla (liberando así su bloqueo) IBD - CLASE 18

26. Control de Concurrencia • Deadlock lock_e(b) Read(b) b := b + 50 write(b) lock_c(a) read(a) lock_c(b) lock_e(a) • Una de las dos debe retroceder, liberando sus datos. IBD - CLASE 18

27. Control de Concurrencia • Protocolo de Bloqueo • El Problema de la actualización perdida (graficar) -> Deadlock • Problema de la dependencia no confirmada (graficar) • Problema del análisis inconsistente (graficar) -> Deadlock IBD - CLASE 18

28. Control de Concurrencia • Conclusiones • Si lo datos se liberan pronto  se evita posible Deadlock • Si los datos se mantienen bloqueados  se evita inconsistencia. IBD - CLASE 18

29. Control de Concurrencia • Es posible que haya una secuencia de transacciones que soliciten un bloqueo en modo compartido sobre elemento de datos y que cada una de ellas libere el bloqueo poco después de que sea concedido, de forma de que otra transacción T1 nunca obtenga el bloqueo en modo exclusivo. La transacción T1 nunca progresa (Inanición) • Para evitar inanición, cuando la transacción Ti pide un bloqueo sobre un elem. de datos Q en un modo particular M, se concede el bloqueo siempre que: • No exista otra transacción que posea un bloqueo sobre Q en un modo que conflictúe con M • No exista otra transacción que esté esperando un bloqueo sobre Q y que lo haya solicitado antes que Ti IBD - CLASE 18

30. Control de Concurrencia • Protocolos de bloqueo • Dos fases • Requiere que las transacciones hagan bloqueos en dos fases: • Crecimiento: se obtienen datos (una transacción puede obtener bloqueos pero no puede liberar ningún bloqueo) Decrecimiento: se liberan los datos (una transacción puede liberar bloqueos pero no puede obtener ningún bloqueo nuevo.) • Como se consideran operaciones • Fase crecimiento: se piden bloqueos en orden: compartido, exclusivo. No se liberan bloqueos • Fase decrecimiento: se liberan bloqueos o se pasa de exclusivo a compartido (conversiones de bloqueos). • Garantiza seriabilidad (secuencialidad) en conflictos, pero no evita situaciones de bloqueos. • Mucho bloqueo exclusivo provoca serie IBD - CLASE 18

31. Control de Concurrencia • Protocolo basado en hora de entrada • El orden de ejecución se determina por adelantado, no depende de quien llega primero • A cada transacción Ti del sistema se le asocia una hora de entrada fija única. El sistema de Base de Datos asigna una hora de entrada antes de que la transacción Ti empiece su ejecución. • C/transacción recibe una HDE • Hora del servidor • Un contador (contador lógico que se incrementa después de asignar una nueva hora de entrada) • Si HDE(Ti) < HDE(Tj), Ti es anterior y se ejecuta primero IBD - CLASE 18

32. Control de Concurrencia • Las operaciones READ y WRITE que pueden entrar en conflicto se ejecutan y eventualmente fallan por HDE. • Algoritmo de ejecución: • Ti Solicita READ(Q) • HDE(Ti) < HW(Q): rechazo (Ti necesita leer un valor de Q que ya fue sobreescrito. Ti retrocede y la operación READ se rechaza porque el valor que debía leer Ti, ya lo sobreescribió otra transacción ) • HDE(Ti)  HW(Q): ejecuta y se establece HR(Q)=Max{HDE(Ti), HR(Ti)} IBD - CLASE 18

33. Control de Concurrencia • Ti solicita WRITE(Q) • HDE(Ti) < HR(Q): rechazo (Q fue utilizado por otra transaccion anteriomente y supuso que no cambiaba) • HDE(Ti) < HW(Q): rechazo (se intenta escribir un valor viejo, obsoleto) • HDE(Ti) > [HW(Q) y HR(Q)]: ejecuta y HW(Q) se establece con HDE(Ti). • Si Ti falla, y se rechaza entonces puede recomenzar con una nueva hora de entrada. IBD - CLASE 18

34. Recuperación en caso de fallos • Consideraciones del protocolo basado en bitácora • Existe un único buffer de datos compartidos y uno para la bitácora • C/transacción tiene un área donde lleva sus datos • El retroceso de una transacción puede llevar al retroceso de otras transacciones • Retroceso en cascada • Falla una transacción  pueden llevar a abortar otras • Puede llevar a deshacer gran cantidad de trabajo. IBD - CLASE 18

35. Recuperación en caso de fallos • Puede ocurrir que falle Ti, y que Tj deba retrocederse, pero que Tj ya terminó. Como actuar? • Protocolo de bloqueo de dos fases: los bloqueos exclusivos deben conservarse hasta que Ti termine. • HDE, agrega un bit, para escribir el dato, además de lo analizado, revisar el bit si está en 0 proceder, si está en 1 la transacción anterior no termino, esperar.... IBD - CLASE 18

36. Recuperación en caso de fallos • Bitácora • Idem sistemas monousuarios • Como proceder con checkpoint • Colocarlo cuando ninguna transacción esté activa. Puede que no exista el momento. • Checkpoint<L> L lista de transacciones activa al momento del checkpoint. • Ante un fallo • UNDO y REDO según el caso. • Debemos buscar antes del Checkpoint solo aquellas transacciones que estén en la lista. IBD - CLASE 18

37. Interbloqueos • Como evitar los deadlock (interbloqueo) • Prevenirlos (evitarlos) • Detectarlos (recuperarlos) • Prevención • Tomar todos los datos que se necesitan • Si hay éxito  la transacción prosigue • No hay éxito  la transacción espera • Posible inanición (se puede mejorar con prioridades) • Ordenar los datos parcialmente, se obtienen en orden o nada • HDE puede manejar prioridades para evitar inanición. IBD - CLASE 18

38. Interbloqueos • Detección: Algoritmo • Detecta el bloqueo • Genera un grafo de pedidos de datos, si encuentra ciclo  deadlock • Corrige: Selección de la víctima • Elección: costo mínimo • La última que empezó, la que haya realizado menos trabajo, la que haya realizado menos escrituras, la de menor prioridad • Retroceder hasta donde? • Evitar inanición de la transacción retrocedida. IBD - CLASE 18

39. Seguridad e Integridad • Integridad: protección ante pérdidas accidentales de consistencia • Problemas durante el procesamiento de transacciones. • Control de concurrencia • Anomalías causadas por la distribución de datos sobre varias computadoras • Error lógico en una transacción que viola protecciones de inconsistencia (Ej: saldo negativo no permitido) IBD - CLASE 18

40. Seguridad e Integridad • Seguridad:protección contra intentos malintencionados para modificar datos • Nivel físico • Nivel humano • Nivel SO • Red • DBMS IBD - CLASE 18

41. Seguridad e Integridad • Nivel de seguridad físico • Protección del equipo ante problemas naturales, fallo de energía, etc. • Protección del HD contra robos, borrados, daños físicos • Protección de la red contra daños físicos • Soluciones • Replicar el hardware (discos espejos, múltiples accesos a la red (varios cables)) • Seguridad física (policia) IBD - CLASE 18

42. Seguridad e Integridad • Nivel de seguridad Humano • Protejerse ante robo de password. Distintas políticas. • Cambiar frecuentemente la password • No usar accesos guest • Auditar datos, ver que no use siempre las mismas password. • Nivel de seguridad de SO • Protección contra logins invalidos • Validar la cantidad de intentos de login • Protección de acceso a nivel de archivos IBD - CLASE 18

43. Seguridad e Integridad • Nivel de seguridad de Red • Cada sitio debe asegurar que se comunica con sitios autorizados • Los links deben protegerse contra robos y modificación de mensajes • Mecanismos de identificación y cifrado de mensajes. IBD - CLASE 18

44. Seguridad e Integridad • Nivel de BD • Asumir la seguridad en todos los niveles anteriores • Usos específicos de la BD • Las autorizaciones de usuarios pueden ser sobre archivos, relaciones, o parte de estos. • Cada usuario debe tener su autorización para leer y/o escribir solo parte de los datos IBD - CLASE 18

45. Seguridad e Integridad • Seguridad tema del DBA a nivel BD • Autorizaciones a usuarios • Lectura/escritura • Agregar, modificar o borrar datos • Crear índices • Alterar o eliminar relaciones (poco probable) • Modificar el esquema de recursos en la BD (poco probable) • Cifrado de datos • “ocultar” datos para que no sean visibles IBD - CLASE 18