TRANSACCIONES

DISEÑO DE BASE DE DATOS

TRANSACCION

Colección de operaciones que forman una única unidad lógica de trabajo.

Propiedad de una transacción

Atomicidad Consistencias Aislamiento -- Concurrencia Durabilidad

ATOMICIDAD Todas las operaciones de la transacción se realizan adecuadamente en la base de datos o ninguna de ellas

consistencia La ejecución aislada de la transacción (sin otra que se ejecute concurrentemente) conserva la consistencia de la base de datos)

aislamiento Aunque se ejecuten varias transacciones concurrentemente, el sistema garantiza que para cada par de transacciones, no se entrelazaran en su ejecución, sino que se realizaran de forma independiente.

DURABILIDAD Tras la finalización con éxito de una transacción, los cambios realizados en la base de datos permanecen, incluso si hay fallos en el sistema.

Propiedades ACID

Atomicity, Consistency, Isolation Durability

ACCESO A LA BASE DE DATOS Mediante 2 operaciones

Leer (x) Transfiere de BD a memoria intermedia de la T(x)

Escribir (x) Transfiere de memoria intermedia a la base de datos

EJEMPLO Sea Ti una transacción para transferir Q. 50.00 de la cuenta A hacia la cuenta B. Se puede definir dicha transacción como

Ti: leer(A);A := A – 50;escribir(A);leer(B);B := B + 50;escribir(B).

analizando Consistencia

Que no sea alterado el balance de las cuentas A y B al efectuar el traslado de fondos (transacción)

Responsabilidad: Programador

analizando Atomicidad

Suponiendo que la cuenta A tiene Q.1,000 y la B tiene Q.2,000 antes de efectuar el traslado

Que pasaría si durante el proceso de ejecutar la transacción ocurriera un fallo en el sistema? Alimentación Hardware Software Otro

analizando Durabilidad

Una vez se completa con éxito una T(x) aunque ocurriera un fallo en el sistema no se puede corromper dicha T(x)

Que pasaría si durante el proceso de ejecutar la transacción ocurriera un fallo en el sistema?

analizando Aislamiento

Que pasaría si todas las 3 propiedades se cumplieran sin problema sin embargo 2 cuenta habientes hacen un retiro al mismo tiempo?

La solución es ejecutarlas secuencialmente las transacciones

Modelos de almacenamiento Volátil

Falta de energía eléctrica se pierde la información

No Volátil Falta de energía NO se pierde la información Discos duros, CDs, etc.

Permanente No importa lo que pase siempre se dispondrá de la información

Múltiples copias

Modelos de almacenamiento Almacenamiento Secundario

No volátil Almacenamiento Primario

Es volátil RAM

procesamiento Procesamiento Concurrente

Es aquel que se da cuando varios procesos corren al mismo tiempo

Procesamiento Paralelo Sistema operativo maneja recursos de un sistema y guarda la información en bloques (sectores)

Bloque y buffer Bloque

Es la unidad de almacenamiento secundario

Buffer Es la unidad de transferencia de información entre el almacenamiento primario y secundario

Es la unidad de almacenamiento primario

Bloque y buffer Por lo regular si el DBMS pide un registro trae todo el bloque

El cual puede contener varios registros.

MODELO DE TRANSACCION Una transacción que termina su ejecución con éxito se dice que está comprometida

Una transacción comprometida que haya hecho modificaciones transforma la base de datos llevándola a un nueva estado consistente, que permanece incluso si hay fallo en el sistema

En ausencia de fallos, todas las transacciones se completan con éxito

MODELO DE TRANSACCIONUna transacción que no termina su ejecución con éxito se dice que está abortada

Para asegurar la atomicidad, las transacciones abortadas no deben tener efecto sobre el estado de la base de datos, cualquier cambio que haya hecho la transacción abortada debe deshacerse

Una vez deshechos los cambios de una transacción abortada se dice que la transacción se ha retrocedido

MODELO DE TRANSACCION Una transacción debe estar en uno de los siguientes estados:

Activa (estado inicial): la transacción permanece en este estado durante su ejecución

Parcialmente Comprometida: la transacción pasa a este estado cuando acaba de realizar la última instrucción

Fallida: la transacción pasa a este estado tras descubrir que no puede continuar la ejecución normal

Abortada: la transacción pasa a este estado después de haber restablecido la base de datos a su estado anterior

Comprometida: la transacción pasa a este estado tras completarse con éxito

MODELO DE TRANSACCION

parcialmente comprometida

fallida

comprometida

abortada

activa Consistente

Puede estar inconsistente

Consiste

nte

Fallo

Fin

Commit

Rollback

Fallo

Implementación de transacciones sql En la norma SQL el comienzo de una transacción se especifica explícitamente (usualmente begin/start transaction)

Las transacciones terminan con una de las siguientes instrucciones:

commit work (compromete la transacción actual) rollback work (provoca que la transacción aborte)

Si el programa termina sin ninguna de estas órdenes, los cambios se comprometen o abortan según indique cada sistema

Implementación de transacciones sql Programa pagar_cheque

Write (‘ingrese cuenta’) Read (cta) Write (‘valor’) Read (valor) Begin transaction

ReadDB (cta, saldo) Saldo = saldo – valor WriteDB (cta, saldo) Write DB (cheque, ‘P’)

Commit Write (‘Pague’)

Implementación de transacciones sql Begin transaction

ReadDB (cta, saldo) If saldo >= valor then

Begin Saldo = saldo – valor WriteDB (cta, saldo) Commit Write (‘Pague’)

End Begin

WriteDB (histo, x) Commit

End

Modelo de fallo

A

B

C

D

E

Tiempo de verificación Tiempo de fallo

RECUPERACION DEL SISTEMA Para que el sistema se pueda recuperar ante fallos se necesita grabar cada operación con la BD en un fichero LOG (bitácora). Checkpoints. Se escribe en el fichero LOG antes que en la BD El fichero LOG debe estar en memoria estable

Por cada operación se escribe un reg. en LOG <comienza-transacción, numt> <escritura, numt, id_dato, val_viejo, val_nuevo> <lectura, numt, id_dato, valor> <termina_transacción_con_éxito, numt> <punto_comprobación, numt, numc>

Bitacora (log) Archivo especial que no conviene tenerlo en el mismo disco o directorio donde esta la base de datos.

bitacora

Almacenamiento primario

Almacenamiento secundario

Bitacora (log)Transaction T1•Begin transaction• ReadDB(A)• A = A + 5000• WriteDB(A)

•Commit

Transaction T2•Begin transaction• ReadDB(B)• ReadDB(C)• B= B – 1000• C = C + 1000• WriteDB(B)• WriteDB(C)

•CommitTransaction T3•Begin transaction• ReadDB(D)• ReadDB(G)• D= D – 1000• G= G + 1000• WriteDB(D)• WriteDB(G)

•Commit

Transaction T4•Begin transaction• ReadDB(A)• A= A – 10,000• WriteDB(A)

•Commit

Transaction T5•Begin transaction• ReadDB(B)• B= B + 10,000• WriteDB(B)

•Commit

Cuenta A = 10,000Cuenta B = 5,000Cuenta C = 1,000Cuenta D = 10,000Cuenta E = 10,000Cuenta F = 3,000Cuenta G = 8,000

Problemas de concurrencia La ejecución concurrente de transacciones puede dar lugar a problemas: Problema de la actualización perdida

Problema de leer una actualización temporal (lectura sucia)

Problema del resumen incorrecto Problema de la lectura no repetible

Técnicas de bloqueo (lock) A cada elemento de datos o gránulo X de la BD se

le asocia una variable operación lock_exclusivo(X): deja bloqueado al que

lo pide si otro ya tiene cualquier lock sobre X operación lock_compartido(X): deja bloqueado al

que lo pide si otro ya tiene un lock exclusivo sobre X

operación unlock(X): libera su lock sobre X Antes de leer X lock_compartido(X) Antes de escribir (leer) X lock_exclusivo(X) Si no se va a leer o escribir más unlock(X)

Deadlocks Deadlock (o abrazo mortal o interbloqueo): Cuando una transacción T1 está bloqueada esperando a que otra T2 libere un lock, la cual también está bloqueada esperando a que T1 libere uno de sus lock. Se puede generalizar para N transacciones.

Prevención de deadlocks Cada transacción obtiene todos los locks al principio y si no puede entonces no obtiene ninguno. Problema de livelock (inanición de algunas transacciones que pueden no obtener todos los que necesiten)

Los elementos de la BD están ordenados de alguna manera y los lock hay que obtenerlos en dicho orden. Los programadores deben controlarlo !!

Detección y recuperación de deadlocks. A medida que se piden y conceden los lock se construye un grafo de las transacciones que están esperando a otras. Si existe un ciclo en dicho grafo: deadlock. Hay que proceder a abortar a alguna de las transacciones. Problema de livelock si se aborta siempre a la misma!

En la practica (Oracle pl/sql)

DECLARE   importe NUMBER;   ctaOrigen VARCHAR2(23);   ctaDestino VARCHAR2(23);BEGIN     importe := 100;     ctaOrigen  := '2530 10 2000 1234567890';     ctaDestino := '2532 10 2010 0987654321';     UPDATE CUENTAS SET SALDO = SALDO - importe     WHERE CUENTA = ctaOrigen;     UPDATE CUENTAS SET SALDO = SALDO + importe     WHERE CUENTA = ctaDestino;     INSERT INTO MOVIMIENTOS     (CUENTA_ORIGEN, CUENTA_DESTINO,IMPORTE, FECHA_MOVIMIENTO)     VALUES     (ctaOrigen, ctaDestino, importe*(-1), SYSDATE);     INSERT INTO MOVIMIENTOS     (CUENTA_ORIGEN, CUENTA_DESTINO,IMPORTE, FECHA_MOVIMIENTO)     VALUES     (ctaDestino,ctaOrigen, importe, SYSDATE);     COMMIT;EXCEPTION WHEN OTHERS THEN     dbms_output.put_line('Error en la transaccion:'||SQLERRM);     dbms_output.put_line('Se deshacen las modificaciones);     ROLLBACK;END;

EN LA PRACTICA (ORACLE PL/SQL) create or replace procedure prueba (nfilas number)as   begin      savepoint ninguna;      insert into tmp values ('primera fila');      savepoint una;      insert into tmp values ('segunda fila');      savepoint dos;      if nfilas=1 then         rollback to una;      else if nfilas=2 then         rollback to dos;      else         rollback to ninguna;      end if;      commit;      exception         when other then            rollbackend prueba;