Control de Concurrencia. Control de Concurrencia. Operaciones Conflictivas. AIslamiento (+ Consistencia) Control de Concurrencia

Transcripción

1 Control de Concurrencia Objetivo Forzar el aislamiento de transacciones conflictivas mediante la exclusión mutua. Preservar la consistencia de la BD mediante la ejecución adecuada de las transacciones. Resolver los conflictos de escritura simultánea y de lecto-escritura simultáneas. Control de Concurrencia AIslamiento (+ Consistencia) Control de Concurrencia Base de Datos compuesta por ítems de datos Transacción read/write de ítems de datos de la BD Operaciones Conflictivas Plan de ejecución (schedule): desarrollo en el tiempo de la ejecución de transacciones concurrentes ejecución intercalada de sentencias de las transacciones. Un schedule mantiene el orden de las operaciones dentro de cada transacción. Dos operaciones de un plan de ejecución son conflictivas si satisfacen las siguientes condiciones: (1) Pertenecen a diferentes transacciones (2) Intentan acceder al mismo ítem (3) Una o las dos operaciones intentan escribir sobre el ítem 1

2 Operaciones Conflictivas Dos transacciones que acceden al mismo ítem intercaladas de manera que producen un resultado incorrecto. X Y 40 X X - N; X X + M; Y Y + N; X=40 Y=85 N=2 M=3 X fue sobreescrito!! Los valores correctos debieron ser:, X=41, Y=87 o bien, X=41, Y=87 Problemas típicos de la concurrencia Actualización perdida (Lost Update Problem) Análisis (sumario) Inconsistente o Lectura no Repetible (Unrepeatable Read Problem) Lectura Sucia o Fantasma (Dirty Read Problem) Actualización Perdida X X 2*Y commit X Y; commit X = Y = Trans-1, Trans-2 X=5 Trans-2, Trans-1 X= -5 No necesariamente las diferentes ejecuciones seriales arrojan el mismo resultado!! 2

3 A=4 X=4 Y=8 N=2 Análisis Inconsistente : X X - N; Y Y + N; : Suma 0; read_item(a); Suma suma + A; suma sum + X; suma suma + Y; El análisis inconsistente ocurre por utilizar registros en distinto estado de actualización!! utiliza X actualizado e Y sin actualizar suma Lectura Sucia o Fantasma : X X - N; : N=2 Falla!! X X- N; 0 0 Al fallar, el valor X=2 virtualmente nunca existió!! leyó un valor fantasma Plan de Ejecución de Transacciones Serializabilidad de Transacciones el resultado de la ejecución concurrente de dos o más transacciones debe ser igual al que se hubiese obtenido de una ejecución serial (no concurrente) Si hay N transacciones ejecutándose concurrentemente N! ejecuciones seriales posibles 3

4 Serializabilidad Idea: cuáles operaciones pueden intercambiarse en un plan de ejecución? Las siguientes NO, pues el resultado cambia!!: Acciones de la misma transacción Acciones en diferentes transacciones sobre el mismo ítem, cuando al menos una de las acciones es write Serializabilidad de los Planes de Ejecución Serial Un plan es serial si para cada transacción participante, todas las operaciones se realizan consecutivamente en el plan (no hay intercalado de sentencias). Serializable Un plan es serializable si es equivalente a cualquier plan serial de las mismas transacciones. Conflictos Planes conflicto-equivalentes: Tienen el mismo conjunto de acciones, y Cada par de acciones conflictivas están ordenadas de la misma forma Un plan es conflicto-serializable si es conflicto-equivalente a un plan serial 4

5 Bloqueos (locks) Cerrojo que crea una zona de exclusión en determinados ítems de datos. El tamaño del bloqueo define la granularidad: fina (nivel de datos) gruesa (BD) Cerrojo: variable asociada a cada ítem de dato Describe el estado de un ítem con respecto a las operaciones que pueden realizarse sobre él Cerrojo binario: Locked/Unlocked Cerrojo multimodo: ReadLock / WriteLock / Unlocked Tres operaciones read_lock(x) write_lock(x) unlock(x) Cada ítem de dato puede estar en cualquiera de los tres estados. Bloqueos (locks) Granularidad Afecta significativamente el nivel de concurrencia Afecta significativamente el desempeño del control de concurrencia Ejemplos de granularidad de ítems: Un campo de un registro de una BD. Un registro de la BD. Un bloque de disco. Un archivo completo. Toda la BD. Los locks se almacenan en una tabla del sistema. Pueden promover (upgrade lock): ReadLock WriteLock Pueden ser degradados (downgrade lock): WriteLock ReadLock Granularidad 5

6 Bloqueos (locks) Los bloqueos sobre ítems de datos pueden combinarse limitadamente S-locks (compartidos/shared) para lecturas: slock(x) ( ReadLock(x)) X-locks (exclusivos) para escrituras: xlock(x) ( WriteLock(x)) bloqueo solicitado Bloqueo en el ítem - S X - Ok Ok Ok S Ok Ok --- X Ok Compatibilidad de bloqueos Control de Concurrencia: Estrategias Los DBMSs no verifican la serializabilidad Muy ineficiente o impracticable!! (estrategia reparadora) Las transacciones arriban continuamente Se requieren innumerables undo Debería ir probando todas las combinaciones Solución: protocolos (estrategia preventiva) Se puede garantizar la serializabilidad de los planes de ejecución si cada transacción sigue el protocolo y éste es forzado por el procesador de transacciones. Grafos de Precedencia : : X:= X - N; Y:=Y + N; X:= X + M; : : X:= X - N; X:= X + M; Y:=Y + N; : : X:= X + M; X:= X - N; Y:=Y + N; : : X X - N; Y Y- P X X + M; Y Y + N; 6

7 Grafo de Serializabilidad Un nodo para cada transacción T i Un arco de T i a T j si hay una operación de T i que precede y entra en conflicto con una de T j Teorema: Un plan de ejecución es serializable por conflictos si y sólo si su grafo de serializabilidad es acíclico. Locks no evitan todos los problemas read_lock(y); unlock(y); Desbloquea demasiado pronto!! write_lock(x); X X+Y; unlock(x); Ejecutadas según un plan concurrente, con cerrojos read_lock(x); unlock(x); write_lock(y); Y X+Y; unlock(y); Resultado: X=50, Y=50 ciclo en el grafo No-serializable! Y X Protocolo de Bloqueo en 2 Fases (P2F) Se dice que una transacción sigue el protocolo de dos fases si TODOS los bloqueos (fase de crecimiento) preceden al primer desbloqueo (fase de decrecimiento) 7

8 Protocolo de Bloqueo en 2 Fases (P2F) Básico: cuando una transacción devuelve un ítem, ya no puede bloquear ningún otro Cantidad de bloqueos Punto de bloqueo bloquea desbloquea BEGIN Fase 1 crecimiento Fase 2 decrecimiento END duración de la transacción Ejemplo: Dos transacciones read_lock(y); unlock(y); write_lock(x); X X+Y; unlock(x); read_lock(x); unlock(x); write_lock(y); Y X+Y; unlock(y); Ejecutadas según un plan serial S1:, Valores iniciales X=20, Y=30 Resultado: X=50, Y=80 Ejemplo: Dos transacciones según el P2F read_lock(y); write_lock(x); unlock(y); X X+Y; unlock(x); read_lock(x); write_lock(y); unlock(x); Y X+Y; unlock(y); y siguen el P2F Cualquier plan de ejecución de y será serializable La concurrencia es limitada por la necesidad de arbitrar requerimientos de ambas transacciones 8

9 Variaciones del P2F P2F Conservativo : Bloquea TODOS los ítems que necesita ANTES de comenzar la ejecución, predeclarando su conjunto de ítems de lectura y escritura Si uno o más ítems están siendo bloqueados por otra transacción, la transacción que lo requiere ESPERA No se produce Deadlock, pero es muy restrictivo P2F Estricto: Una transacción no desbloquea sus ítems de escritura (WriteLocks) hasta que alcanza el commit o bien aborta No está libre de deadlocks pero garantiza la recuperabilidad del plan (Plan estricto: una transacción no puede leer/escribir X hasta que la última transacción que haya usado X haya llegado al commit o abortado) Es la versión más popular Protocolo de Bloqueo en 2 Fases (P2F) Estricto bloquea Cantidad de bloqueos desbloqueo BEGIN Período de uso del ítem END duración de la transacción Protocolo de Bloqueo en 2 Fases (P2F) Componentes Esenciales Lock Manager: Administra los bloqueos sobre los ítems de datos. Lock table: La utiliza el Lock Manager para almacenar los siguientes datos: o La Base de Datos requiere que todas las transacciones estén bien formadas Debe bloquear los ítems de datos, antes de leerlos o escribirlos. No bloquea un ítem sobre el que ya tiene un bloqueo ni intenta desbloquear un ítem libre. 9

10 Operaciones de Bloqueo Componentes básicos del bloqueo binario: LOCK obtenido no Repetir If LOCK (X) = 0 (*el ítem está desbloqueado*) Then LOCK (X) 1 (*bloquearlo*) obtenido si Else Begin esperar (hasta que LOCK (X) = 0 y el Lock Manager active la transacción) Hasta obtenido = si End; Operaciones de Bloqueo Componentes básicos del bloqueo binario: UNLOCK LOCK (X) 0 (*desbloquea el ítem*) If existe alguna transacción esperando por X Then activar una y adjudicarle el ítem; Operaciones de Bloqueo Componentes básicos del bloqueo multimodo: READLOCK obtenido no Repetir If LOCK (X) = unlocked Then Begin LOCK (X) read-locked #reads (X) 1 obtenido si; End Else If LOCK (X) read-locked Then #reads (X) #reads (X) +1 obtenido si Else Begin esperar (hasta que LOCK (X) = unlocked y el Lock Manager active la transacción) End Hasta obtenido = si End; 10

11 Operaciones de Bloqueo Componentes básicos del bloqueo multimodo: WRITELOCK obtenido no Repetir If LOCK (X) = unlocked Then Begin LOCK (X) Write-locked ; #writes (X) 1; obtenido si; End Else Begin esperar (hasta que LOCK (X) = unlocked y el Lock Manager active la transacción) Hasta obtenido = si End; Operaciones de Bloqueo Componentes básicos del bloqueo multimodo: UNLOCK If LOCK (X) = write-locked Then Begin LOCK (X) unlocked ; activar una de las transacciones que esperan si hay alguna End Else If LOCK (X) read-locked Then Begin #reads (X) #reads (X) -1 If #reads (X) = 0 Then Begin LOCK (X) = unlocked ; Activar alguna transacción en espera si la hay End End; Abrazo Mortal (deadlock) Dos o más transacciones esperan indefinidamente que otra devuelva un ítem de dato. read_lock(y); write_lock(x); no puede espera!! read_lock(x); write_lock(y); no puede espera!! 11

12 Abrazo Mortal (deadlock) e Inanición (livelock) Para prevenir deadlocks P2F conservativo Timestamping las transacciones más jóvenes son abortadas Detección de deadlocks Grafo espera-por Selección de una víctima Recomienzo cíclico Livelock: una transacción no puede obtener los recursos que necesita por un período de tiempo indefinido, mientras las otras avanzan normalmente Estrategia first-come-first-served Equivalencia y Serializabilidad por Vistas Equivalencia: Para cada ítem X, si T i lee el valor inicial de X en P 1, T i debe leer también el valor inicial de X en P 2. Para cada lectura de X por T i en P 1, si el valor leído por T i es escrito por T j, T i debe también leer el valor de X producido por T j en P 2. Para cada ítem X, si la última escritura de X fue ejecutada por T i en P 1, la misma transacción debe escribir el valor final de X en P 2. Equivalencia y Serializabilidad por Vistas Un plan S es serializable por vistas (view serializable) si es equivalente por vistas a un esquema serial. Ofrece una definición menos restrictiva de plan de ejecución que la serializabilidad por conficto: Cada plan conflicto-serializable es serializable por vistas. 12

13 Serializabilidad Semántica Algunas aplicaciones pueden producir planes correctos aunque no sean serializables ni por conflicto ni por vistas. Ejemplo: Débito/Crédito (Suma y resta se vuelven conmutativas) X:=X-10; Y:=Y+10; Y:=Y-20; read_item(z); Z:+Z+20; write_item(z); X:=X-10; Y:=Y+10; Y:=Y-20; read_item(z); Z:+Z+20; write_item(z); Métodos para Serializabilidad Multi-version: se aguardan los valores viejos de los ítems de datos cuando estos son actualizados. Timestamps: son identificadores únicos de las transacciones, generados por el sistema. Las transacciones se ordenan por este identificador para lograr la serializabilidad. Protocolos: cuando cada transacción adhiere a un protocolo, se garantiza la serializabilidad de todos los planes en los cuales participen esas transacciones bloqueos. Control de Concurrencia Pesimista Verifica antes de modificar la BD, bloqueando datos antes de leerlos o escribirlos, o chequeando timestamps. Transacciones en SQL 92 Start Transaction No hay una sentencia explícita Implícitamente comienza por una sentencia SQL End Transaction Si ocurre COMMIT o ROLLBACK Automáticamente con AUTOCOMMIT cuando se completa la sentencia SQL 13

14 Estableciendo Propiedades SET TRANSACTION [READ ONLY READ WRITE] ISOLATION LEVEL [READ UNCOMMITTED SERIALIZABLE REPEATABLE READ READ COMMITTED] Niveles de Aislamiento Read Uncommitted Puede ver cambios no comprometidos de otras transacciones Lectura sucia, Lectura no-repetible Recomendada solamente para funciones estadísticas Read Committed Puede ver cambios comprometidos de otras transacciones No hay lectura sucia, pero es posible la lectura norepetible Aceptable para consultas o soporte a las decisiones Repeatable Read No hay lectura sucia ni no-repetible Puede exhibir el fenómeno fantasma Serializable Niveles de aislamiento 14

15 Implementación de Niveles de Aislamiento Read Uncommitted sin S-locks Read Committed S-locks pueden ser levantados en cualquier momento X-locks con el P2F estricto Repeatable Read P2F estricto sobre todos los datos Serializable P2F estricto sobre todos los datos e índices Tuplas Fantasma o Si una transacción bloquea tuplas de una relacion, por ej. Con el atributo X=25, y luego se insertan nuevas tuplas en la relación con X=25 para algunas transacciones este puede ser un comportamiento no serializable. o Estas tuplas se llaman fantasmas o Los fantasmas pueden ser evitados estableciendo un lock exclusivo en TODA la relación, antes de insertar tuplas limita el grado de concurrencia. o El programador puede elegir el nivel de aislamiento en SQL, para permitir o evitar este fenómeno. Locks en Índices o Cuando se actualiza una relación (archivo) actualización de los índices asociados o Nuevamente locks para asegurar serializabilidad. o Árboles-B la raíz puede ser alterada por cualquier actualización actualizaciones concurrentes no pueden ser manejadas con locks!! 15

16 Locks en Árboles-B Idea Establecer un bloqueo exclusivo en un nodo si existe la posibilidad de que sea actualizado. Bloquear todo el camino hacia la base. Desbloquear el camino desde la base al nodo, tan pronto como se haya actualizado. Protocolo de árbol Problemas con los Bloqueos Los bloqueos evitan la no-serializabilidad. Resultan demasiado estrictos en algunos casos, limitando innecesariamente el grado de concurrencia enfoque pesimista. Otras estategias se desempeñan mejor si las transacciones no entran en conflicto con frecuencia enfoque optimista. Optimismo vs pesimismo Enfoque Pesimista mejor en situaciones de alto conflicto: Menor cantidad de abortos. Menor tiempo de procesamiento. Enfoque Optimista mejor en situaciones de bajo conflicto (por ej. muchas transacciones de solo lectura). Mayor grado de concurrencia. En la práctica soluciones híbridas. 16

17 Timestamps (Marcas de Tiempo) Asocia un número único a cada transacción timestamp (marca o estampado de tiempo fecha de nacimiento de la transacción). Las transacciones son ejecutadas en forma intercalada pero simulando su ejecución según su fecha de nacimiento (las mas jóvenes primero). No hay bloqueos no puede producirse deadlock. Cada dato que es accedido adquiere una marca, si la operación es posible. Plan de Ejecución basado en Marcas de Tiempo Si una transacción T: Intenta leer un ítem de la BD escrito por una transacción no comprometida esperar hasta que alcance el commit o aborte. Intenta leer un ítem que ha sido actualizado por una transacción más joven (> timestamp!!) rollback. Intenta actualizar un ítem que ha sido actualizado o leído por una transacción más joven rollback. Rollback recomienzo de T con un nuevo timestamp Actualización física no puede ejecutarse (por conflicto) no se ejecuta ninguna de las operaciones de la transacción (atomicidad) reinicio no requiere rollback pues no hay datos físicamente actualizados. Plan de Ejecución basado en Marcas de Tiempo El sistema debe conocer, para cada ítem de dato, la marca de tiempo de la transacción más joven que leyó o actualizó el ítem valores de sincronización. r(x) - timestamp de la transacción más joven que ejecutó read(x) w(x) - timestamp de la transacción más joven que ejecutó write(x) 17

18 Marcas de Tiempo: Mecanismo Para cada transacción T, con timestamp t(t): T intenta ejecutar READ(Xi) if t(t) >= w(xi) then r(xi) max(t(t), r(xi)) else reiniciar T T intenta ejecutar WRITE(Xj) if t(t) >= r(xj) & t(t) >= w(xj) then w(xj) t(t) else reiniciar T Marcas de Tiempo: Act. Perdida Revisitado Transacción A Leer X tiempo t1 t2 Transacción B Leer X Actualizar X t3 t4 Actualizar X Si A es más joven que B, t(a) > t(b) La actualización de B en t4 fallará porque en t3 w(x) t(a) y t(a) > t(b) B se reinicia. Si A es más antigua que B t(a) < t(b) A debería reiniciarse en t3 porque en t2 r(x) t(b) y t(b) > t(a) Livelock y deadlock no ocurren con marcas de tiempo pero el reinicio reiterado es un problema. Bibliografía Date, C.: An Introduction to Database Systems. 7º edición. Addison Wesley Elmasri, R., Navathe, S.: Fundamentals of Database Systems. Addison Wesley Silberschatz, A., Korth, H, Sudarshan, S.: Database System Concepts. McGraw Hill