Gestión de transacciones Dr. José Luis Zechinelli Martini zechinel@mail.udlap.mx IS 580 Equipo Tecnologías de Bases de Datos CENTIA - INIP

Introducción (1) Sistemas mono-usuario vs. multi-usuarios: sistemas de reservaciones, de bancos, de tarjetas de crédito, de supermercados. Concepto de transacción: Mecanismo para describir unidades lógicas de procesamiento. Representación lógica de un proceso que debe ser ejecutado por completo para asegurar la coherencia de la información. Sistemas de procesamiento de transacciones: sistemas con grandes bases de datos y cientos de usuarios concurrentes.

Introducción (2) Una transacción es una unidad lógica de procesamiento en la BD. Formada por una o varias operaciones (inserción, borrado, modificación, recuperación). Expresada usando un lenguaje de consultas de alto nivel (SQL). Especificada dentro de un programa de aplicación: Varias transacciones. begin transaction - end transaction. Realizada sin hacer modificaciones (read-only transaction).

Modelo simplificado (1) Una BD es una colección de datos nombrados: items. El tamaño de un item define su granularidad: atributo, registro, archivo, disco. Las operaciones que una transacción puede incluir son: read_item(X): leer un item. write_item(X): escribir un item.

Modelo simplificado (2) Pasos para ejecutar read_item(X): Encontrar la dirección del bloque en disco que contiene el item X. Copiar el bloque en un buffer en memoria (si no está). Copiar el item X del buffer a la variable del programa. Pasos para ejecutar write_item(X): Copiar el bloque en un buffer en memoria. Copiar el item X de la variable del programa al buffer. Almacenar el bloque actualizado en disco (inmediato o diferido). El almacenamiento en disco depende del administrador de recuperaciones y del sistema operativo.

Ejemplos de transacciones T1: transferencia read_item(X); X := X – N; write_item(X); read_item(Y); Y := Y + N; write_item(Y); T2: depósito read_item(X); X := X + M; write_item(X); Mecanismos de control de la concurrencia y recuperación concernidos

Control de la concurrencia Perdida de actualizaciones: acceso concurrente del mismo item provocando que su valor al final de la ejecución quede incoherente. Lectura sucia: actualización de un item por una transacción que falla leído por otra antes de restablecer su valor original. Resumen incoherente: acceso concurrente de un conjunto de items donde una transacción actualiza todos sus valores y la otra opera tomando la mitad actualizados y la otra mitad no.

Perdida de actualizaciones read_item(X); X := X – N; write_item(X); read_item(Y); Y := Y + N; write_item(Y); X := X + M; Item X tiene un valor incoherente porque la actualización de T1 se perdió

Lectura sucia T1 T2 T1 falla y debe restaurar el valor de X read_item(X); X := X – N; write_item(X); read_item(Y); X := X + M; T1 falla y debe restaurar el valor de X T2 leyó un valor incorrecto de X

Resumen incoherente T1 T3 read_item(X); X := X – N; write_item(X); read_item(Y); Y := Y + N; write_item(Y); sum := 0; read_item(A); sum := sum + A; . sum := sum + X; sum := sum + Y; T3 lee X después de ser actualizada y lee Y antes de ser actualizada

Recuperación Evitar de tener items en la base de datos afectados por transacciones que fallaron (incompletas). Tipos de fallas: Falla de hardware, de software o de red. Error sistema (integer overflow, division by 0 o lógicos). Errores locales o excepciones (data not found). Salida forzada por el controlador de la concurrencia (serializability, deadlock). Fallas de disco (descomposturas físicas de sectores o disco). Problemas físicos y catástrofes (power, fire, sabotaje, etc.)

Plan Introducción a la gestión de transacciones Conceptos de transacciones Propiedades de las transacciones Schedules y recoverability Serializabilidad Transacciones en SQL

Operaciones El sistema de tolerancia a fallas almacena las siguientes operaciones para poderse recuperar en caso de errores. BEGIN_TRANSACTION marca el inicio de la ejecución de la transacción. READ o WRITE especifican operaciones de lectura o escritura de items. END_TRANSACTION especifica que las operaciones de lectura y escritura de una transacción han terminado y marca el final de la ejecución de la transacción (commit o abort). COMMIT_TRANSACTION señala una ejecución exitosa y sus actualizaciones no serán deshechas. ROLLBACK (o ABORT) señala una ejecución sin éxito y deshace todo cambio o efecto realizado por la transacción.

Estados PARCIALMENTE ACTIVA COMMITTED FALLADA TERMINADA READ WRITE Inicio Transacción Fin Transacción COMMIT PARCIALMENTE COMMITTED ACTIVA ABORT ABORT FALLADA TERMINADA

El sistema Log (1) Tipos de entradas llamadas registros log. Sea T el identificador único de una transacción: [start_transaction, T] indica que T ha iniciado su ejecución. [write_item, T, X, old_value, new_value] indica que T ha cambiado X. [read_item, T, X] indica que T ha leído X. [commit, T] indica que T ha completado exitosamente (guarda efectos). [abort, T] indica que T ha sido abortada.

El sistema Log (2) No todos los protocolos de recuperación requieren que: Sean grabadas las operaciones READ  auditorias. Sean grabadas las operaciones WRITE con new_value. Recuperación de un estado coherente de la base de datos (operaciones WRITE): Para toda transacción validada: rehacer las operaciones asignando al item correspondiente el valor new_value. Para toda transacción no validada: restablecer todos lo items con su antiguo valor old_value.

Punto commit de una transacción Una transacción COMMITTED T implica que: Todas las operaciones de T fueron ejecutadas. Todos los efectos de T fueron registrados en el Log (incluyendo [ commit, T ]). Archivo Log: Comúnmente se tiene varios bloques en memoria hasta llenarlos y se escriben una sola vez. Sólo las entradas del Log salvadas en disco son consideradas en el proceso de recuperación. Proceso force-writing, escribir en disco los bloques Log relacionados antes de terminar una transacción.

Plan Introducción a la gestión de transacciones Conceptos de transacciones Propiedades de las transacciones Schedules y recoverability Serializabilidad Transacciones en SQL

Propiedades ACID (1) Atomicity: una transacción es atómica, ella es ejecutada por completo o no es ejecutada. Consistency preservation: toda transacción completa que lleva a la BD de un estado coherente a otro. Isolation: las transacciones no deben interferirse entre ellas, al ser ejecutadas concurrentemente. Durability o permanency: los cambios realizados por una transacción validada (COMMITTED) deben ser permanentes.

Propiedades ACID (2) La atomicidad es responsabilidad del sistema de recuperación (commit, abort). La coherencia es generalmente responsabilidad de los programadores (restricciones de integridad). El aislamiento es forzado por el sistema de control de la concurrencia (las actualizaciones no son visibles hasta terminar las transacciones). La durabilidad es responsabilidad del sistema de recuperación.

Niveles de aislamiento Nivel 0: transacciones que no rescriben las lecturas de otras transacciones (no provocan lecturas sucias). Nivel 1: transacciones que no pierden actualizaciones. Nivel 2: transacciones que no pierden actualizaciones y no tienen lecturas sucias. Nivel 3: también llamada aislamiento verdadero, transacciones nivel 2 con lecturas repetidas.

Plan Introducción a la gestión de transacciones Conceptos de transacciones Propiedades de las transacciones Schedules y recoverability Serializabilidad Transacciones en SQL

Schedules Un schedule S de n transacciones T1, T2, ..., Tn es un orden de sus operaciones, sujeto a la restricción de que las operaciones de cada Ti en S aparecen en el mismo orden con el que ocurren en Ti. Notación corta: r, w, c, a denotan las operaciones read_item, write_item, commit, abort respectivamente. Ejemplos de schedules: Sa: r1(X); r2(X); w1(X); r1(Y); w2(X); w1(Y); Sb: r1(X); w1(X); r2(X); w2(X); r1(Y); a1;

Schedule completo (1) Dos operaciones se dicen en conflicto si: Pertenecen a dos transacciones diferentes. Acceden al mismo item X. Al menos una de las dos operaciones es un write_item(X). Un schecule S se dice ser un schedule completo si: Las operaciones de S son exactamente las operaciones de T1, T2, ..., Tn incluyendo commit o abort. Dadas dos operaciones de Ti su orden de aparición en S es el mismo de Ti. Dadas dos operaciones en conflicto, una de ellas debe ocurrir antes de la otra.

Schedule completo (2) Orden parcial: si no se especifica ningún orden dadas dos operaciones no conflictivas. Orden total: propiedad imperativa para las operaciones de las condiciones 2 y 3. Puesto que toda transacción habrá COMMITTED o ABORTED un schedule completo no contiene transacciones activas. C(S) es la proyección COMMITTED de un schedule S, sólo incluye operaciones de transacciones COMMITTED   Ti, ci  S.

Recoverability (1) Un schedule S se dice recuperable si ninguna transacción T en S valida (COMMIT) hasta que validen (COMMIT) todas las transacciones T’ que escribieron un item leído por T. Se dice que T lee de T’ si algún item X es primero escrito por T’ y más tarde leído por T. T’ no debe haber abortado antes de que T lea y ninguna otra transacción debe haber escrito el item X después de que T’ lo escribió y antes de que T lo lea.

Recoverability (2) Sa y Sb son ambas recuperables, puesto que cumplen con la definición anterior. Sa’: r1(X); r2(X); w1(X); r1(Y); w2(X); c2; w1(Y); c1; Sb’: r1(X); w1(X); r2(X); w2(X); r1(Y); a1; a2; Consideremos Sc, Sd y Se: Sc: r1(X); w1(X); r2(X); r1(Y); w2(X); c2; a1; // no recuperable Sd: r1(X); w1(X); r2(X); r1(Y); w2(X); w1(X); c1; c2; Se: r1(X); w1(X); r2(X); r1(Y); w2(X); w1(X); a1; a2; Un schedule recuperable no tiene transacciones validadas que deban ser abortadas (rolled back).

Recoverability (3) Evitar el fenómeno de cascading rollback: consumidor de tiempo. Tipos de schedules recuperables: Recoverability. Prohibir cascading rollback, toda transacción en S sólo lee items escritos por transacciones validadas  Sf: w1(X,5); w2(X,8); a1; Schedule estricto, toda transacción en S no puede leer ni escribir un item X hasta que la última transacción que escribió X valide o aborte.

Plan Introducción a la gestión de transacciones Conceptos de transacciones Propiedades de las transacciones Schedules y recoverability Serializabilidad Transacciones en SQL

Serializabilidad (1) Serializabilidad de schedules: identificar todos los schedules correctos. Dadas dos transacciones T1 y T2: Ejecutar todas las operaciones de T1 (en secuencia) seguidas por todas las operaciones de T2. Ejecutar todas las operaciones de T2 (en secuencia) seguidas por todas las operaciones de T1. Si se permite la ejecución entre mezclada de las operaciones, existen muchos ordenes posibles.

Serializabilidad (2) Schedule A T1 T2 Schedule B T1 T2 read_item(X); X := X – N; write_item(X); read_item(Y); Y := Y + N; write_item(Y); X := X + M; Schedule B T1 T2 read_item(X); X := X – N; write_item(X); read_item(Y); Y := Y + N; write_item(Y); X := X + M;

Schedule serial Un schedule S es serial: Si para cada transacción T en S, todas las operaciones de T son ejecutadas consecutivamente en S. Si sólo una transacción está activa a un tiempo. Su terminación (commit o abort) inicia la ejecución de la siguiente. Si las transacciones son independientes, entonces cualquier schedule serial es correcto.

Schedules no seriales Schedule C T1 T2 Schedule D T1 T2 read_item(X); X := X – N; write_item(X); read_item(Y); Y := Y + N; write_item(Y); X := X + M; Schedule D T1 T2 read_item(X); X := X – N; write_item(X); read_item(Y); Y := Y + N; write_item(Y); X := X + M;

Schedules seriales y no seriales (1) Schedule serial limita la concurrencia: Si T espera una operación I/O no se puede pasar la ejecución a otra transacción. Si T es muy larga, el resto de las transacciones deben esperar a que T termine. En general, los schedules seriales son considerados inaceptables en la práctica. Algunos schedules no seriales dan un resultado correcto: determinar cuales dan siempre un resultado correcto. Un schedule S de n transacciones es serializable si es equivalente a algún schedule serial de las mismas n transacciones (dos grupos disjuntos). Hay n! posibles schedules seriales. Muchos más schedules no seriales.

Schedules seriales y no seriales (2) Accidentalmente dos schedules diferentes podrían producir el mismo estado final. Sea X = 100, S1 y S2 producen el mismo resultado. Sin embargo, no son equivalentes con X diferente de 100. No hacer ninguna asunción. S1 S2 read_item(X); X := X + 10; write_item(X); X := X * 1.1;

Equivalencia en conflictos Dos schedules S1, S2 se dicen ser equivalentes en conflictos (conflict equivalent) si el orden de cualesquiera dos operaciones en conflicto es el mismo en S1 y en S2. Si las operaciones pueden dar un efecto diferente al ser aplicadas en diferente orden  Schedules no equivalentes. S1: r1(X); w2(X); es diferente a S2: w2(X); r1(X); S1: w1(X); w2(X); es diferente a S2: w2(X); w1(X); Un schedule S es serializable en conflictos si S es equivalente (en conflictos) a algún schedule serial S’. D es serializable en conflictos puesto que D es equivalente a A. C no es serializable puesto que no es equivalente ni A ni a B.

Detección de la serializabilidad (1) Algoritmo simple para determinar la serializabilidad en conflictos de un schedule S: Sólo analiza las operaciones read_item y write_item. Construye un grafo dirigido G = (N, E) donde N = {T1, T2, ..., Tn} y E = {e1, e2, ..., em}. Para cada transacción Ti en S, hay un nodo en el grafo. Cada arco ei en el grafo es de la forma Tj  Tk y es creado si una de las operaciones en Tj aparece antes de alguna operación en conflicto en Tk.

Detección de la serializabilidad (2) Algoritmo: detección de la serializabilidad en conflictos. Para cada transacción Ti en S, crear un nodo etiquetado Ti en el grafo de precedencias. Para cada caso en S donde Tj ejecute un read_item(X) después de que Ti ejecuta un write_item(X), crear un arco Ti  Tj en el grafo. Para cada caso en S donde Tj ejecute un write_item(X) después de que Ti ejecuta un read_item(X), crear un arco Ti  Tj en el grafo. Para cada caso en S donde Tj ejecute un write_item(X) después de que Ti ejecuta un write_item(X), crear un arco Ti  Tj en el grafo. El schedule S es serializable si y sólo si el grafo resultante no tiene ciclos.

Detección de la serializabilidad (3) Grafos de precedencias para los schedules seriales A y B así como para los no seriales C y D. X T1 T2 T1 T2 X X T1 T2 T1 T2 X X

Ejemplo T1 T2 T3 read_item(X); write_item(X); read_item(Y); write_item(Y); read_item(Z); write_item(Z);

Ejemplo: schedule E T1 T2 T3 read_item(Z); read_item(X); write_item(X); read_item(Y); write_item(Y); read_item(Z); write_item(Z);

Ejemplo: schedule F T1 T2 T3 read_item(X); write_item(X); read_item(Y); write_item(Y); read_item(Z); write_item(Z);

Usos de la serializabilidad Un schedule serializable tiene la ventaja de proveer una ejecución concurrente. Factores tales como la carga de sistema, el tiempo de preparación de una transacción y las propiedades de los procesos contribuyen al ordenamiento de las operaciones en un schedule. Solución práctica: determinar métodos que aseguren la serializabilidad sin tener que probar los schedules (protocolos). Sin embargo puesto que las transacciones son sometidas continuamente, es difícil determinar cuando un schedule inicia y termina  considerar sólo la proyección COMMITTED C(S) que sea equivalente a un schedule serial.

Plan Introducción a la gestión de transacciones Conceptos de transacciones Propiedades de las transacciones Schedules y recoverability Serializabilidad Transacciones en SQL

Transacciones en SQL (1) Unidad lógica de trabajo: un instrucción SQL es siempre atómica. El inicio de una transacción se hace de manera implícita y su final se puede expresar de manera explicita (commit o rollback). Características de las transacciones, SET TRANSACTION. Access Mode: READ ONLY o READ WRITE. Por defecto, READ WRITE. Diagnostic Area Size: DIAGNOSTICS SIZE N especifica el número de condiciones tomas en cuenta simultáneamente (feedback information). Isolation Level: ISOLATION LEVEL <isolation> donde <isolation> puede ser READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ o SERIALIZABLE. Por defecto, SERIALIZABLE.

Transacciones en SQL (2) Posibles violaciones basadas en los niveles de aislamiento: Nivel de aislamiento Tipos de violaciones Lectura sucia Lectura no repetible Fantasmas READ UNCOMMITTED READ COMMITTED REPEATABLE READ SERIALIZABLE Sí No

Transacciones en SQL (3) WHENEVER SQLERROR GOTO UNDO; SET TRANSACTION READ WRITE DIAGNOSTICS SIZE 5 ISOLATION LEVEL SERIALIZABLE; INSERT INTO EMPLOYEE(FNAME, LNAME, SSN, DNO, SALARY) VALUES(‘Robert’, ‘Smith’, ‘991’, 2, 350); UPDATE EMPLOYEE SET SALARY = SALARY * 1.1 WHERE DNO = 2; COMMIT; GOTO THE_END; UNDO: ROLLBACK; THE_END: ...