ibd clase 18. unlp - facultad de informáticaibd - clase 18 2 entornos concurrentes existen varias...
TRANSCRIPT
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.
UNLP - Facultad de InformáticaIBD - CLASE 183
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.
UNLP - Facultad de InformáticaIBD - CLASE 184
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)
UNLP - Facultad de InformáticaIBD - CLASE 185
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
UNLP - Facultad de InformáticaIBD - CLASE 186
Entornos concurrentes
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
UNLP - Facultad de InformáticaIBD - CLASE 187
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
UNLP - Facultad de InformáticaIBD - CLASE 188
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
UNLP - Facultad de InformáticaIBD - CLASE 189
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
UNLP - Facultad de InformáticaIBD - CLASE 1810
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
UNLP - Facultad de InformáticaIBD - CLASE 1811
Entornos concurrentes
Conclusiones
El programa debe conservar la consistencia
Sólo las instrucciones READ y WRITE son importantes y deben considerarse.
UNLP - Facultad de InformáticaIBD - CLASE 1812
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.
UNLP - Facultad de InformáticaIBD - CLASE 1813
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.
UNLP - Facultad de InformáticaIBD - CLASE 1814
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)
UNLP - Facultad de InformáticaIBD - CLASE 1815
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)
UNLP - Facultad de InformáticaIBD - CLASE 1816
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
UNLP - Facultad de InformáticaIBD - CLASE 1817
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.
UNLP - Facultad de InformáticaIBD - CLASE 1818
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.
UNLP - Facultad de InformáticaIBD - CLASE 1819
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)
UNLP - Facultad de InformáticaIBD - CLASE 1820
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.
UNLP - Facultad de InformáticaIBD - CLASE 1821
Entornos concurrentes
Métodos de control de concurrencia
Bloqueo
Basado en hora de entrada
UNLP - Facultad de InformáticaIBD - CLASE 1822
Control de Concurrencia
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)
UNLP - Facultad de InformáticaIBD - CLASE 1823
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
UNLP - Facultad de InformáticaIBD - CLASE 1824
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)
UNLP - Facultad de InformáticaIBD - CLASE 1825
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)
UNLP - Facultad de InformáticaIBD - CLASE 1826
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.
UNLP - Facultad de InformáticaIBD - CLASE 1827
Control de Concurrencia
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
UNLP - Facultad de InformáticaIBD - CLASE 1828
Control de Concurrencia
Conclusiones
Si lo datos se liberan pronto se evita posible Deadlock
Si los datos se mantienen bloqueados se evita inconsistencia.
UNLP - Facultad de InformáticaIBD - CLASE 1829
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
UNLP - Facultad de InformáticaIBD - CLASE 1830
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
UNLP - Facultad de InformáticaIBD - CLASE 1831
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
UNLP - Facultad de InformáticaIBD - CLASE 1832
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)}
UNLP - Facultad de InformáticaIBD - CLASE 1833
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.
UNLP - Facultad de InformáticaIBD - CLASE 1834
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.
UNLP - Facultad de InformáticaIBD - CLASE 1835
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....
UNLP - Facultad de InformáticaIBD - CLASE 1836
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.
UNLP - Facultad de InformáticaIBD - CLASE 1837
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.
UNLP - Facultad de InformáticaIBD - CLASE 1838
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.
UNLP - Facultad de InformáticaIBD - CLASE 1839
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)
UNLP - Facultad de InformáticaIBD - CLASE 1840
Seguridad e Integridad
Seguridad: protección contra intentos malintencionados para modificar datos Nivel físico Nivel humano Nivel SO Red DBMS
UNLP - Facultad de InformáticaIBD - CLASE 1841
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)
UNLP - Facultad de InformáticaIBD - CLASE 1842
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
UNLP - Facultad de InformáticaIBD - CLASE 1843
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.
UNLP - Facultad de InformáticaIBD - CLASE 1844
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
UNLP - Facultad de InformáticaIBD - CLASE 1845
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