Transcript Clase 18 - Entornos concurrentes

IBD
Clase 18
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.
2
IBD - CLASE 18
UNLP - Facultad de Informática
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.
3
IBD - CLASE 18
UNLP - Facultad de Informática
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)
4
IBD - CLASE 18
UNLP - Facultad de Informática
Entornos concurrentes
T0 READ( a )
a := a – 50
WRITE( a )
READ( b )
b := b + 50
WRITE( b )


T1 READ( a )
temp := a * 0.1
a := a – temp
WRITE( a )
READ( b )
b := b + temp
WRITE( b )
Resolver T0, T1 o T1, T0 se respeta A+B
Ahora bien, T0 T1 <> T1 T0
5
IBD - CLASE 18
UNLP - Facultad de Informática
Entornos concurrentes
READ(A)
A := A – 50
READ(A)
A := A – 50
WRITE(A)
READ(A)
TEMP := A * 0.1
A := A – TEMP
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)
READ(B)
WRITE(A)
READ(B)
B := B + 50
WRITE(B)
B := B + TEMP
WRITE(B)
A + B se conserva
6
A + B no se conserva
IBD - CLASE 18
UNLP - Facultad de Informática
Entornos concurrentes

7
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
UNLP - Facultad de Informática
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
8
IBD - CLASE 18
UNLP - Facultad de Informática
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
9
IBD - CLASE 18
UNLP - Facultad de Informática
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
10
IBD - CLASE 18
UNLP - Facultad de Informática
Entornos concurrentes

Conclusiones

El programa debe conservar la consistencia

Sólo las instrucciones READ y WRITE son
importantes y deben considerarse.
11
IBD - CLASE 18
UNLP - Facultad de Informática
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.
12
IBD - CLASE 18
UNLP - Facultad de Informática
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.
13
IBD - CLASE 18
UNLP - Facultad de Informática
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)
14
IBD - CLASE 18
UNLP - Facultad de Informática
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)
15
IBD - CLASE 18
UNLP - Facultad de Informática
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
16
IBD - CLASE 18
UNLP - Facultad de Informática
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.
17
IBD - CLASE 18
UNLP - Facultad de Informática
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.
18
IBD - CLASE 18
UNLP - Facultad de Informática
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)
19
IBD - CLASE 18
UNLP - Facultad de Informática
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.
20
IBD - CLASE 18
UNLP - Facultad de Informática
Entornos concurrentes

Métodos de control de concurrencia

Bloqueo

Basado en hora de entrada
21
IBD - CLASE 18
UNLP - Facultad de Informática
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)
22
IBD - CLASE 18
UNLP - Facultad de Informática
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
23
IBD - CLASE 18
UNLP - Facultad de Informática
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)

24
IBD - CLASE 18
UNLP - Facultad de Informática
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)
25
IBD - CLASE 18
UNLP - Facultad de Informática
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)

26
Una de las dos debe retroceder, liberando
sus datos.
IBD - CLASE 18
UNLP - Facultad de Informática
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

27
IBD - CLASE 18
UNLP - Facultad de Informática
Control de Concurrencia

Conclusiones

Si lo datos se liberan pronto  se evita
posible Deadlock

Si los datos se mantienen bloqueados 
se evita inconsistencia.
28
IBD - CLASE 18
UNLP - Facultad de Informática
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
29
IBD - CLASE 18
UNLP - Facultad de Informática
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
30
IBD - CLASE 18
UNLP - Facultad de Informática
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
•
•

31
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
UNLP - Facultad de Informática
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)}
32
IBD - CLASE 18
UNLP - Facultad de Informática
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.
33
IBD - CLASE 18
UNLP - Facultad de Informática
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.
34
IBD - CLASE 18
UNLP - Facultad de Informática
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....
35
IBD - CLASE 18
UNLP - Facultad de Informática
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.
36
IBD - CLASE 18
UNLP - Facultad de Informática
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.
37
IBD - CLASE 18
UNLP - Facultad de Informática
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.
38
IBD - CLASE 18
UNLP - Facultad de Informática
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)
39
IBD - CLASE 18
UNLP - Facultad de Informática
Seguridad e Integridad

Seguridad: protección contra intentos
malintencionados para modificar datos
 Nivel físico
 Nivel humano
 Nivel SO
 Red
 DBMS
40
IBD - CLASE 18
UNLP - Facultad de Informática
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)
41
IBD - CLASE 18
UNLP - Facultad de Informática
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
42
IBD - CLASE 18
UNLP - Facultad de Informática
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.
43
IBD - CLASE 18
UNLP - Facultad de Informática
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
44
IBD - CLASE 18
UNLP - Facultad de Informática
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
45
IBD - CLASE 18
UNLP - Facultad de Informática