TRANSACCIONES

DISEÑO DE BASE DE DATOS

TRANSACCION

 Colección de operaciones que forman una

única unidad lógica de trabajo.
PROPIEDAD DE UNA TRANSACCION

 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 tx
 Escribir (x)
 Transfiere de memoria intermedia a la base de datos
EJEMPLO
 Sea Ti una transacción para transferir Q. 50 de la
cuenta A a 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
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 TRANSACCION

 Una 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

Commit
Consistente

parcialmente comprometida
comprometida
Fin

activa

Fa
Fallo Consistente
ll o

Rollback
fallida abortada

Puede estar inconsistente

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

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.
Almacenamiento
secundario

bitacora

Almacenamiento
primario
BITACORA (LOG)
Transaction T2
Cuenta A = 10,000 Transaction T1
•Begin transaction
Cuenta B = 5,000 •Begin transaction
• ReadDB(B)
Cuenta C = 1,000 • ReadDB(A)
• ReadDB(C)
Cuenta D = 10,000 • A = A + 5000
• B= B – 1000
Cuenta E = 10,000 • WriteDB(A)
• C = C + 1000
Cuenta F = 3,000 •Commit
• WriteDB(B)
Cuenta G = 8,000
• WriteDB(C)
•Commit
Transaction T3
•Begin transaction
• ReadDB(D) Transaction T4 Transaction T5
• ReadDB(G) •Begin transaction •Begin transaction
• D= D – 1000 • ReadDB(A) • ReadDB(B)
• G= G + 1000 • A= A – 10,000 • B= B + 10,000
• WriteDB(D) • WriteDB(A) • WriteDB(B)
• WriteDB(G) •Commit •Commit
•Commit
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
            rollback
end prueba;