Los DBMSs soportan la concurrencia y la recuperación de fallos mediante transacciones ACID (atómicas, consistentes, aisladas y duraderas), registro de operaciones y la búsqueda de horarios equivalentes a la ejecución en serie. El protocolo de bloqueo de dos fases estricto (2PL) garantiza horarios serializables, mientras que el registro de escrituras anticipadas (WAL) permite deshacer operaciones abortadas y recuperar el sistema tras un fallo al estado consistente.

1. Control de concurrencia

2. Transacciones Ejecución simultánea de programas de usuario es esencial para el buen desempeño de DBMS. Debido a que los accesos a disco son frecuentes, y relativamente lentos, es importante mantener el CPU trabajando en varios programas de usuario al mismo tiempo. Un programa de usuario puede llevar a cabo varias operaciones en los datos recuperados de la base de datos, pero el DBMS sólo está preocupado por los datos que se leen / escriben desde / hacia la base de datos. Una transacción es una vista abstracta del DBMS de un programa de usuario: una secuencia de lecturas y escrituras.

3. Concurrencia en un DBMS Los usuarios envían las transacciones, y se puede pensar de cada transacción , que se ejecuta por sí mismo. Se logra concurrencia por el DBMS, que entrelaza las acciones (lee / escribe de objetos BD) de las diversas transacciones. Cada transacción debe dejar la base de datos en un estado consistente si la BD es consistente cuando comienza la transacción. El DBMS no entiende la semántica de los datos. (por ejemplo, no entiende cómo se calcula el interés en una cuenta bancaria).

4. Atomicidad de las transacciones Una transacción puede hacer commit después de completar todas sus acciones, o puede abortar (o ser abortado por el DBMS) después de ejecutar algunas acciones. Una propiedad muy importante garantizada por el DBMS para todas las transacciones es que son atómicas . DBMS registra en logs todas las acciones para que se pueda deshacer las acciones de las operaciones abortadas.

5. ACID Atómico Consistencia debe dejar la base de datos en un estado consistente Aislamiento ( Isolation) "Protegido" de los efectos de programar concurrentemente otras transacciones durabilidad Los efectos deben persistir incluso si el sistema falla antes de que todos los cambios se reflejen en disco.

6. Ejemplo Considere dos transacciones : T1: BEGIN A=A+100, B=B-100 END T2: BEGIN A=1.06*A, B=1.06*B END Intuitivamente, la primera transacción transfiere $100 de la cuenta B a la cuenta A. La segunda es la acreditación de las dos cuentas con un pago de interés del 6%. No hay garantía de que T1 se ejecutará antes de T2 o viceversa, si ambos se envían juntos. Sin embargo, el efecto neto debe ser equivalente a las dos transacciones ejecutándose en serie en algún orden.

7. Ejemplo(Cont.) Considere un posible entrelazado (horario): T1: A=A+100, B=B-100 T2: A=1.06*A, B=1.06*B Esto está bien. Pero qué ocurre si: T1: A=A+100, B=B-100 T2: A=1.06*A, B=1.06*B La vista del DBMS del segunda horario: T1: R(A), W(A), R(B), W(B) T2: R(A), W(A), R(B), W(B)

8. Programando Transacciones Horario serial: Programa no entralaza las acciones de las diferentes transacciones. Horario equivalentes: Para cualquier estado de base de datos, el efecto (en el conjunto de objetos en la base de datos) de la ejecución del primera horario es idéntica a los efectos de la ejecución del segundo horario. Horario Serializable : Un programa que es equivalente a alguna ejecución en serie de las transacciones. (Nota: Si cada transacción mantiene consistencia, todos los horarios serializables preservan la consistencia.)

9. Anomalías con ejecuciones entrelazadas Lectura de datos sin confirmar (conflictos WR, "lecturas sucias"): Lecturas Irrepetibles (conflictos RW): T1: R(A), W(A), R(B), W(B), Abort T2: R(A), W(A), C T1: R(A), R(A), W(A), C T2: R(A), W(A), C

10. Anomalía (Cont.) Sobrescribir datos no confirmados (conflictos WW): T1: W(A), W(B), C T2: W(A), W(B), C

11. Bloqueo basado en Control de concurrencia Protocolo Estricto bloqueo de dos fases (2PL estricto): Cada transacción debe obtener un bloqueo S (compartido) en el objeto antes de leer, y un bloqueo X (exclusivo) en el objeto antes de escribir. Todos los bloqueos efectuados por una transacción se liberan cuando se complete la transacción (No estricto) 2PL Variante: libera los bloqueos en cualquier momento, pero no pueden adquirir bloqueos después de la liberación de cualquier bloqueo. Si una transacción mantiene un bloqueo X en un objeto, ninguna otra transacción puede obtener un bloqueo (S o X) en ese objeto. 2PL estricto sólo permite horarios serializables. Además, simplifica la anulación de transacciones (No estricto) 2PL también permite sólo horarios serializables, pero implica procesos más complejos de abortar

12. Cancelación de una transacción Si una transacción Ti se aborta, todas sus acciones tienen que ser deshechas. No sólo eso, si Tj lee un objeto escrito últimamente por Ti, Tj debe ser abortado también! La mayoría de los sistemas evitan estos abortos en cascada liberando un bloqueo de una transacción sólo durante el commit. Si Ti escribe un objeto, Tj puede leer esto sólo después que Ti hace commit. Con el fin de deshacer las acciones de una transacción anulada, el DBMS mantiene un registro en el que se registra cada escritura. Este mecanismo se utiliza también para recuperarse de los fallos del sistema: todas las transacciones activas en el momento del accidente se anulan cuando el sistema vuelve a funcionar.

13. El Log Las siguientes acciones se registran en el log: Ti escribe un objeto : el valor antiguo y el nuevo valor. El log debe ir a la disco antes de la página que ha cambiado! Ti commits/aborta : un log que indique esta acción. Las entradas de registro se encadenan por id de transacción, así que es fácil deshacer una transacción específica. El log es a menudo duplicado y archivado en un almacenamiento estable. Todas las actividades relacionadas al log (y de hecho, todas las actividades relacionadas con el bloqueo / desbloqueo, tratar con bloqueos, etc) se manejan de forma transparente por el DBMS.

14. Recuperarse de un fallo Hay tres fases en el algoritmo de recuperación Aries: Análisis : Analizar el log hacia adelante(desde el punto de comprobación más reciente) para identificar todos las transacciones que estaban activas, y todas las páginas sucias en el grupo de búferes en el momento del accidente. Rehacer : Rehace todas las actualizaciones de las páginas sucias en el búfer pool, según sea necesario, para asegurar que todas las actualizaciones que se registran de hecho se lleven a cabo y sean escritas en el disco. Deshacer : Las escrituras de todas las transacciones que estaban activas en el fallo se deshacen (restaurando el valor antes de la actualización, que está en el expediente de registro para la actualización), yendo hacia atrás en el log. (Se debe tener cuidado al manejar el caso de un fallo que ocurra durante el proceso de recuperación!)

15. Resumen El control de concurrencia y la recuperación se encuentran entre las más importantes funciones proporcionadas por un DBMS. Los usuarios no necesitan preocuparse acerca de la concurrencia. El sistema inserta automáticamente peticiones de bloquear/desbloquear y programa acciones de diferentes transacciones, de tal forma que se garantice que la ejecución resultante es equivalente a ejecutarlas una después de la otra en algún orden. Registro de escritura anticipada (WAL) se utiliza para deshacer las acciones de las operaciones abortadas y para restaurar el sistema a un estado consistente después de un fallo. Estado consistente: sólo los efectos de transacciones con commit se pueden ver.

16. Revisión DBMSs soportan concurrencia, recuperación de fallos con: Las transacciones ACID (atómicas, Consistencia, Aislamiento, Durabilidad) Registro de las operaciones Una ejecución en serie de transacciones es seguro pero lenta Tratar de encontrar los horarios equivalentes a la ejecución en serie Una solución para el horario serializable es 2PL

17. Conflicto de Horarios serializables Dos horarios son equivalentes en conflicto si: Involucra a las mismas acciones de las mismas transacciones Cada par de acciones en conflicto se ordena de la misma manera Horario S es serializable en conflicto si S es equivalente a un conflicto de horario serial

18. Ejemplo Un horario que no tiene conflicto serializable: El ciclo en el gráfico revela el problema. La salida de T1 depende de T2 , y viceversa. T1: R(A), W(A), R(B), W(B) T2: R(A), W(A), R(B), W(B) T1 T2 A B Gráfico de dependencia

19. Gráfico de dependencia Gráfico de dependencia : un nodo por transacción; flecha de Ti a Tj si una operación de Ti tiene conflicto con una operación de Tj y Ti aparece en el calendario antes de la operación en conflicto de Tj. Teorema: El horario es conflicto serializable si y sólo si su grafo de dependencias es acíclico

20. Vista Serializable Horarios S1 y S2 son equivalentes en vista si: Si Ti lee el valor inicial de A en S1, entonces Ti también lee el valor inicial de A en S2 Si Ti lee el valor de A escrito por Tj en S1, entonces Ti también lee el valor de A escrito por Tj en S2 Si Ti escribe el valor final de A en S1, entonces Ti también escribe el valor final de A en S2 Serialización de vista es "más débil" que la serialización conflicto! Cada horario de conflicto serializable es vista serializable, pero no al revés! Es decir admite más horarios legales T1: R(A) W(A) T2: W(A) T3: W(A) T1: R(A),W(A) T2: W(A) T3: W(A)

21. Deadlocks Deadlock: Ciclo de transacciones esperando por bloqueos que se liberarán por cada uno. Dos formas de tratar con deadlocks : prevención de Deadlock detección de Deadlock

22. Prevención de Deadlock Asignar prioridades en base a timestamps . Supongamos que Ti quiere un lock que tiene Tj. Dos políticas son posibles: Wait-Die: Si Ti tiene mayor prioridad, Ti espera por Tj, de lo contrario se anula Ti Wound-wait: Si Ti tiene mayor prioridad, se aborta Tj, de lo contrario Ti espera

23. Detección de Deadlock Crear un gráfico de espera : Los nodos son las transacciones Hay una ventaja de Ti a Tj si Ti está esperando a Tj para liberar un bloqueo Revise periódicamente los ciclos en el gráfico de espera

24. Detección de Deadlock(Cont.) Ejemplo: T1: S(A), S(D), S(B) T2: X(B) X(C) T3: S(D), S(C), X(A) T4: X(B) T1 T2 T4 T3 T1 T2 T4 T3

25. Detección de Deadlock (cont.) En la práctica, la mayoría de los sistemas practican detección Los experimentos muestran que la mayoría de espera para los ciclos son de longitud 2 o 3 Por lo tanto, pocas transacciones deben anularse Las implementaciones pueden variar Puede construir el gráfico y periódicamente buscar ciclos Puede hacer un esquema "tiempo fuera" : si usted ha estado esperando un bloqueo desde hace mucho tiempo, se asume que es un deadlock y aborta