clase 18 entornos concurrentes

IBD

Clase 18

UNLP - Facultad de InformáticaIBD - CLASE 182

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.



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.



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)



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



READ(A)A := A – 50WRITE(A)

READ(A)TEMP := A *

0.1A := A – TEMPWRITE(A)

READ(B)B := B + 50WRITE(B)

READ(B)B := B + TEMPWRITE(B)

A + B se conserva

READ(A)A := A – 50

READ(A)TEMP := A *

0.1A := A – TEMPWRITE(A)

READ(B)WRITE(A)READ(B)B := B + 50WRITE(B)

B := B + TEMPWRITE(B)

A + B no se conserva



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



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



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



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



Conclusiones

El programa debe conservar la consistencia

Sólo las instrucciones READ y WRITE son importantes y deben considerarse.



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.



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.


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)



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)



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



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.



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.



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)



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.



Métodos de control de concurrencia

Bloqueo

Basado en hora de entrada



BloqueoCuando 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)



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


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)



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)



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.



Protocolo de BloqueoEl Problema de la actualización perdida

(graficar) -> Deadlock

Problema de la dependencia no confirmada (graficar)

Problema del análisis inconsistente (graficar) -> Deadlock



Conclusiones

Si lo datos se liberan pronto se evita posible Deadlock

Si los datos se mantienen bloqueados se evita inconsistencia.



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



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



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



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)}



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


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.



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



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.


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.


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.


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)



Seguridad: protección contra intentos malintencionados para modificar datos Nivel físico Nivel humano Nivel SO Red DBMS



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)



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



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.



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



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

clase 18 entornos concurrentes

Documents