IBD Clase 18.

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

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

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

T0 READ( a ) T1 READ( a ) a := a – temp := a * 0.1 WRITE( a ) a := a – temp READ( b ) WRITE( a ) b := b 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 Al ppio incializar A=100 y B=100, A+B=200 Luego de T0 -> A+B=200 (se conserva) Luego de T1 -> A+B=200 (se conserva) Se conserva A+B en T0,T1 ó T1,T0 IBD - CLASE 18 UNLP - Facultad de Informática

READ(A) A := A – 50 TEMP := A * 0.1 A := A – TEMP WRITE(A) READ(B) WRITE(A) READ(B) B := B + 50 WRITE(B) B := B + TEMP A + B no se conserva READ(A) A := A – 50 WRITE(A) TEMP := A * 0.1 A := A – TEMP READ(B) B := B + 50 WRITE(B) B := B + TEMP A + B se conserva Al ppio incializar A=100 y B=100, A+B=200 Luego de T0 y T1 A+B<>200 No se conserva IBD - CLASE 18 UNLP - Facultad de Informática

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

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

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

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

Conclusiones El programa debe conservar la consistencia Sólo las instrucciones READ y WRITE son importantes y deben considerarse. IBD - CLASE 18 UNLP - Facultad de Informática

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

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 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) IBD - CLASE 18 UNLP - Facultad de Informática

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

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

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

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

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

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

Métodos de control de concurrencia Bloqueo Basado en hora de entrada IBD - CLASE 18 UNLP - Facultad de Informática

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

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

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

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) Algunos sistemas volveran a iniciar esta transacción desde el ppio, bajo la suposición de que las condiciones que causaron Deadlock probablemente no existirán. Otros sistemas simplemente regresan un código de excepción “víctima de bloqueo mortal” hacia la aplicación. El primer enfoque es preferible desde el punto de vista del programador. IBD - CLASE 18 UNLP - Facultad de Informática

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

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

Conclusiones Si lo datos se liberan pronto  se evita posible Deadlock Si los datos se mantienen bloqueados  se evita inconsistencia. IBD - CLASE 18 UNLP - Facultad de Informática

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

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 El protocolo de dos fases es el más utilizado comercialmente Algunos datos: Mucho uso de exclusivo, provoca serie Si se utiliza la idea de aumento entonces se logra mayor paralelismo. IBD - CLASE 18 UNLP - Facultad de Informática

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

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

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 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. Si una transacción falla y modificó datos que concurrentemente estaban usando otras transacciones, entonces todas deben retroceder IBD - CLASE 18 UNLP - Facultad de Informática

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

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

Interbloqueos Como evitar los deadlock (interbloqueo) Prevención
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 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. Que significa costo mínimo Ultima que empezó La que haya hecho menos trabajo La que haya hecho menos escrituras La que tenga prioridad más baja 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) Violar las protecciones de inconsistencia es por ejemplo dejar un saldo negativo cuando no se permite, o que se borra una tupla y queda otra colgada. IBD - CLASE 18 UNLP - Facultad de Informática

Seguridad: protección contra intentos malintencionados para modificar datos Nivel físico Nivel humano Nivel SO Red DBMS Violar las protecciones de inconsistencia es por ejemplo dejar un saldo negativo cuando no se permite, o que se borra una tupla y queda otra colgada. IBD - CLASE 18 UNLP - Facultad de Informática

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) Seguridad suele hacer referencia a la proteción contra los accesos malintencionados, Integridad hace referencia a evitar la pérdida accidental de consistencia. IBD - CLASE 18 UNLP - Facultad de Informática

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

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

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

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 Tipos de autorizaciones que puede dar el DBA 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) IBD - CLASE 18 UNLP - Facultad de Informática

IBD Clase 18.

Presentaciones similares

Presentación del tema: "IBD Clase 18."— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

IBD Clase 18.

Presentaciones similares

Presentación del tema: "IBD Clase 18."— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback