El documento trata sobre el procesamiento de transacciones y la seguridad en las bases de datos. Explica las propiedades ACID que deben cumplir las transacciones, los métodos para controlar la concurrencia como bloqueos, marcas de tiempo y validación, y cómo estos métodos resuelven problemas como lecturas sucias, lecturas no repetibles y fantasmas. También cubre temas como protocolos de bloqueo, niveles de aislamiento y prevención de interbloqueos.
1. Base de Datos: PROCESAMIENTO DE TRANSACCIONES Y SEGURIDAD EN LAS BD Profesor: MSC. Luis Serna Jherry
2.
3. Procesamiento de Transacciones “ El problema de la modificación perdida” tiempo Transacción A Transacción B Traer R ($250) Traer R ($250) Actualizar R=R-20 ($230) Actualizar R=R-30 ($220)
4.
5.
6.
7.
8. Procesamiento de Transacciones 2 retiros de 20 y 30 tiempo Transacción A Transacción B Begin transaction Leer R ($250) Begin transaction esperar Actualizar R=R-20 ($230) esperar Commit esperar Traer R ($230) Actualizar R=R-30 ($200) commit
9. Procesamiento de Transacciones tiempo Incluyendo transferencia de R a P Transacción A Transacción B Leer R ($250) Actualizar R= R-20 ($230) Leer R ($230) Leer P ($600) Actualizar R=R-30 ($200) Actualizar P = P+20 ($620) Leer P ($620) Actualizar P = P+30 ($650)
10.
11. Transición de Estados de una Transacción Read/write endTransaction Abort Abort Commit Confirmada Parcialmente confirmada Activa Fallida Terminada
12.
13.
14.
15.
16.
17.
18. Planes y sus Grafos de Precedencia tiempo T1 T2 X PLAN A En T1 se transfieren reservas de un avión a otro En T2 simplemente se reserva asientos en un avión T1 T2 Read X X:= X-N Write X Read Y Y:= Y + N Write Y Read X X:= X + M Write X
19. Planes y sus Grafos de Precedencia tiempo T1 T2 X PLAN B T1 T2 Read X X:= X + M Write X Read X X:= X-N Write X Read Y Y:= Y + N Write Y
20. Planes y sus Grafos de Precedencia tiempo T1 T2 X PLAN C X *** ACTUALIZACION PERDIDA : El valor de X es incorrecto, el numero de asientos es inconsitente T1 T2 Read X X:= X-N Read X X:= X + M Write X Read Y Write X *** Y:= Y + N Write Y
21. Planes y sus Grafos de Precedencia tiempo T1 T2 PLAN D X T1 T2 Read X X:= X-N Write X Read X X:= X + M Write X Read Y Y:= Y + N Write Y
22.
23. Control de Concurrencia: Bloqueo El bloqueo asegura que un objeto que va a ser utilizado por una transacción no cambie de manera impredecible, si esto puede afectar la confiabilidad del resultado. El efecto del bloqueo es no permitir que otras transacciones tengan acceso al objeto. Bloqueo Exclusivo : Si una Transacción A tiene un bloqueo X sobre el objeto R, cualquier otra Transacción B que solicite un bloqueo (de cualquier tipo) sobre R, entrará en un estado de espera, hasta que A libere el bloqueo sobre R. Bloqueo Compartido : Si una Transacción A tiene un bloqueo S sobre el objeto R: Si otra Transacción B solicita un bloqueo X sobre R, entrará en un estado de espera, hasta que A, libere a R. Si en cambio B, solicita un bloqueo S, su solicitud será concedida X: escritura, S:lectura
24. Control de Concurrencia Bloqueo y operaciones sobre Registros N: Hay conflicto, la transacción B entra en espera. S: Compatibilidad, se concede el bloqueo solicitado por B X S X N N S N S A B
25.
26.
27. Control de Concurrencia Bloqueo Mutuo, Punto Muerto o Interbloqueo : tiempo Transacción A Transacción B Solicita bloqueo X sobre R1 - concedido - Solicita bloqueo X sobre R2 - concedido - Solicita bloqueo X sobre R2 Esperar Solicita bloqueo X sobre R1 esperar esperar esperar esperar -------- --------
28. Control de Concurrencia El problema de la “lectura sucia”. tiempo Transacción A Transacción B Leer R ($250) Actualizar R= R-20 ($230) Leer R ($230) rollback Actualizar R=R-30 ($200) commit
29. Solución de bloqueo para la “lectura sucia” tiempo Transacción A Transacción B Obtener bloqueo S para R - concedido Leer R ($250) Obtener bloqueo X para R – concedido Actualizar R= R-20 ($230) Obtener bloqueo S para R – esperar rollback - esperar - Bloqueo concedido Leer R ($250) Obtener bloqueo X para R - concedido Actualizar R=R-30 ($220) commit
30. Control de Concurrencia El problema de la “lectura irrepetible” tiempo Transacción A Transacción B Leer R ($250) Leer R ($250) Actualizar R=R-30 ($220) commit Leer R ($220) ¡interferencia detectada!
31. Solución de bloqueo para la “lectura irrepetible” tiempo Transacción A Transacción B Obtener bloqueo S para R – concedido Leer R ($250) Obtener bloqueo S para R – concedido Leer R ($250) Obtener bloqueo X para R - esperar Leer R ($250) esperar (lectura repetible) esperar ............... ....................
32. Control de Concurrencia El problema de la aparición de “fantasmas”, resumen incompleto o análisis inconsistente tiempo Transacción 1 Transacción 2 Traer C 1 (40):Suma=40 Traer C 2 (50):Suma=90 Traer C 3 (30) Actualizar C 3 (20) Traer C 1 (40) Actualizar C 1 (50) COMMIT Traer C 3 (20):Suma=110
33. Solución de bloqueo para el problema de la aparición de “fantasmas” Transacción 1 Transacción 2 Obtener bloqueo S sobre C - concedido Traer C 1 (40):Suma=40 Traer C 2 (50):Suma=90 Obtener bloqueo X sobre C - esperar Traer C 3 (30):Suma=120 Esperar commit esperar Conceder bloqueo .............. ..............
34.
35. Nivel de Aislamiento / Interferencia Nivel de Aislamiento Situación de Interferencia Lectura sucia Lectura no repetible Fantasma Lectura no registrada Posible Posible Posible Lectura registrada No posible Posible Posible Lectura repetible No posible No posible Posible Seriable No posible No posible No posible
36.
37. Seriabilidad por marcas temporales Se asocia a cada tupla dos valores de marca temporal: t u es la marca temporal de la transacción más reciente que ha actualizado o creado la tupla t r es la marca temporal de la transacción más reciente que ha observado la tupla Obsérvese que siempre t u t r (una transacción siempre observa la tupla antes de actualizarla)
38. Seriabilidad por marcas temporales Si la transacción t solicita leer una tupla: Si t >= t u se ejecuta la operación leer y se actualiza t r por max ( t , t r ) Si t < t u una transacción más reciente (posterior en el tiempo) ya escribió el valor de la tupla, antes de que t tuviera oportunidad de leerla. T se retrocede y vuelve a iniciarse con una marca t’ más grande.
39. Seriabilidad por marcas temporales Si t solicita actualizar una tupla: Si t t r se ejecuta la actualización, dado que ninguna transacción más reciente que t ha leído siquiera la tupla Si t < t r ó t < t u se retrocede (rollback) la transacción t y se reinicia con una marca temporal mayor, porque alguna transacción posterior a t ya leyó o escribió la tupla antes de que t pueda hacerlo Si un rollback comprende la reinstalación de valores previos, el rollback debe tener una marca de hora nueva, que actualizará t u y t r de la tupla reinstalada
40.
41. Prevención de interbloqueos Esperar o Morir Si T i solicita un elemento que posee T j , T i puede esperar sólo si T i < T j (T i es más antigua que T j ) en otro caso T i se retrocede (muere) Herir o Esperar Si T i solicita un elemento que posee T j , T i espera sólo si T i > T j (T i es más reciente que T j ) ; en otro caso T j se retrocede (T i hiere a T j ). No-espera Si Ti no puede obtener un bloqueo se aborta de inmediato y se reinicia después de un cierto lapso sin comprobar si ocurriría o no un bloqueo mortal Espera Cautelosa Si Ti solicita un elemento que posee Tj, Ti espera sólo si Tj no está detenida (no está esperando que se libere ningún otro elemento bloqueado); en caso contrario Tj aborta.
42.
43. Transaction Log Programa de Aplicación DBMS Acceso Base de Datos Transaction Log (a) (b) Actualización de los datos (a) (b) Se modifican los datos (a) ante-imagen (b) post-imagen
44.
45.
46.
47.
48.
49.
50. Recuperación - Fallas del Sistema - Se pierde el contenido de la memoria principal y de las áreas de almacenamiento temporal. Por lo tanto, se perderá el estado preciso de la transacción que se está ejecutando y no podrá ser completada con éxito. Por este motivo será preciso anularla (retroceder) cuando se reinicie el sistema (aplicación de los registros ante-imagen desde el Log de transacciones). Para reducir este proceso, se introducen periódicamente Puntos de Revisión o Verificación .
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
Notas del editor
Resultado de la ejecución de un programa de usuario escrito en algún lenguaje de programación o de manipulación de datos de alto nivel (SQL, Cobol, Pascal, C, etc.)
Consistencia: La suma de A + B no debe ser alterada al ejecutar la transacción. Sin el requisito de consistencia ¡la transacción podría crear o destruir dinero! La responsabilidad de asegurar la consistencia de una transacción es del programador de la aplicación que la codifica. Atomicidad: Supongamos que antes de la transacción, los valores de las cuentas A y B son 20,000 y 40,000, respectivamente Durante la ejecución, hay momentos en que la BD se encuentra en un estado inconsistente . La atomicidad garantiza que esos estados inconsistentes no sean visibles sino al interior de la transacción. La BD conserva los valores antiguos (en disco), y si la transacción no se completa, recupera dichos valores. La responsabilidad de asegurar la atomicidad es del gestor de transacciones de la BD. Durabilidad: Cuando se ha completado con éxito la transacción, no debe suceder que una falla en el sistema produzca la pérdida de datos correspondientes a la transferencia. Las modificaciones realizadas en la transacción se guardan en disco antes que ésta finalice Esta información guardada es suficiente para reconstruirla en caso de fallo. La responsabilidad de asegurar la durabilidad es del gestor de recuperaciones de la BD, estrechamente ligado al gestor de transacciones. Aislamiento: Aunque haya otras transacciones accedan concurrentemente a A y B, sus operaciones no se entrelazarán de modo que ocasionen inconsistencias en la BD. Es decir, las transacciones se ejecutan “como si” su tratamiento fuera secuencial. La responsabilidad de asegurar la atomicidad es del componente de control de concurrencias de la BD.
Si el DBMS encuentra un begin transaction cuando hay otra transacción en proceso, bloquea la nueva hasta que la anterior termine. Este método elimina la interferencia, pero es pesimista al suponer que cualquier actividad concurrente representa una amenaza de interferencia.
Transacción A: transferir $20 de R a P Transacción B: transferir $30 de R a P Las acciones se están intercalando sin resultados indeseables
Activa , el estado inicial; permanece en ese estado durante su ejecución Parcialmente comprometida , después de ejecutarse su última instrucción Fallida , tras descubrir que no puede continuar su ejecución normal Abortada , después de haber retrocedido la transacción y restablecido la BD a su estado anterior al comienzo de la misma. Comprometida , tras completarse con éxito.
Con bloqueo estricto de dos fases
El bloqueo se aplica sobre criterios de búsqueda, no sobre tuplas individuales
Lectura registrada: solamente bloqueos X Lectura repetible: bloqueos X y S, sobre objetos individuales Seriable: bloqueos sobre criterios de búsqueda
En Esperar – Morir, una transacción más antigua debe esperar a que una más reciente libere sus elementos de datos. Así, cuanto más antigua se vuelve, más tiende a esperar. Por el contrario, en herir – esperar, una transacción más antigua nunca espera a una más reciente. En esperar – morir, si Ti muere y se retrocede a causa de haber solicitado un elemento de dato que posee Tj, entonces Ti puede volver a realizar la misma secuencia de peticiones cuando vuelva a comenzar. Si Tj posee todavía ese elemento de dato, Ti morirá de nuevo. Así, Ti puede morir varias veces hasta que adquiera el elemento que necesita. Por el contrario, en el esquema herir-esperar, si Ti está herida y retrocede porque Tj solicita un elemento de datos que posee; cuando vuelva a comenzar Ti y solicita el elemento de datos que ahora posee Tj, Ti espera. De este modo puede haber menos retrocesos en el esquema herir-esperar.
![Objetivos del Día de Hoy ,[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)