La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

IBD Clase 18. UNLP - Facultad de InformáticaIBD - CLASE 18 2 Entornos concurrentes Existen varias razones para permitir la concurrencia (aunque es más.

Presentaciones similares


Presentación del tema: "IBD Clase 18. UNLP - Facultad de InformáticaIBD - CLASE 18 2 Entornos concurrentes Existen varias razones para permitir la concurrencia (aunque es más."— Transcripción de la presentación:

1 IBD Clase 18

2 UNLP - Facultad de InformáticaIBD - 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.

3 UNLP - Facultad de InformáticaIBD - 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.

4 UNLP - Facultad de InformáticaIBD - 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)

5 UNLP - Facultad de InformáticaIBD - 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

6 UNLP - Facultad de InformáticaIBD - CLASE 18 6 Entornos concurrentes 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

7 UNLP - Facultad de InformáticaIBD - 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

8 UNLP - Facultad de InformáticaIBD - 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

9 UNLP - Facultad de InformáticaIBD - 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

10 UNLP - Facultad de InformáticaIBD - CLASE 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

11 UNLP - Facultad de InformáticaIBD - CLASE Entornos concurrentes Conclusiones El programa debe conservar la consistencia Sólo las instrucciones READ y WRITE son importantes y deben considerarse.

12 UNLP - Facultad de InformáticaIBD - CLASE 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.

13 UNLP - Facultad de InformáticaIBD - CLASE 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.

14 UNLP - Facultad de InformáticaIBD - CLASE 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)

15 UNLP - Facultad de InformáticaIBD - CLASE 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)

16 UNLP - Facultad de InformáticaIBD - CLASE 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

17 UNLP - Facultad de InformáticaIBD - CLASE 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.

18 UNLP - Facultad de InformáticaIBD - CLASE 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.

19 UNLP - Facultad de InformáticaIBD - CLASE 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)

20 UNLP - Facultad de InformáticaIBD - CLASE 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.

21 UNLP - Facultad de InformáticaIBD - CLASE Entornos concurrentes Métodos de control de concurrencia Bloqueo Basado en hora de entrada

22 UNLP - Facultad de InformáticaIBD - CLASE 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)

23 UNLP - Facultad de InformáticaIBD - CLASE 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

24 UNLP - Facultad de InformáticaIBD - CLASE 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)

25 UNLP - Facultad de InformáticaIBD - CLASE 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)

26 UNLP - Facultad de InformáticaIBD - CLASE 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.

27 UNLP - Facultad de InformáticaIBD - CLASE 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

28 UNLP - Facultad de InformáticaIBD - CLASE Control de Concurrencia Conclusiones Si lo datos se liberan pronto se evita posible Deadlock Si los datos se mantienen bloqueados se evita inconsistencia.

29 UNLP - Facultad de InformáticaIBD - CLASE 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

30 UNLP - Facultad de InformáticaIBD - CLASE 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

31 UNLP - Facultad de InformáticaIBD - CLASE 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

32 UNLP - Facultad de InformáticaIBD - CLASE 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)}

33 UNLP - Facultad de InformáticaIBD - CLASE 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.

34 UNLP - Facultad de InformáticaIBD - CLASE 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.

35 UNLP - Facultad de InformáticaIBD - CLASE 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....

36 UNLP - Facultad de InformáticaIBD - CLASE 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 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.

37 UNLP - Facultad de InformáticaIBD - CLASE 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.

38 UNLP - Facultad de InformáticaIBD - CLASE 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.

39 UNLP - Facultad de InformáticaIBD - CLASE 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)

40 UNLP - Facultad de InformáticaIBD - CLASE Seguridad e Integridad Seguridad: protección contra intentos malintencionados para modificar datos Nivel físico Nivel humano Nivel SO Red DBMS

41 UNLP - Facultad de InformáticaIBD - CLASE 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)

42 UNLP - Facultad de InformáticaIBD - CLASE 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

43 UNLP - Facultad de InformáticaIBD - CLASE 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.

44 UNLP - Facultad de InformáticaIBD - CLASE 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

45 UNLP - Facultad de InformáticaIBD - CLASE 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


Descargar ppt "IBD Clase 18. UNLP - Facultad de InformáticaIBD - CLASE 18 2 Entornos concurrentes Existen varias razones para permitir la concurrencia (aunque es más."

Presentaciones similares


Anuncios Google