UNIDAD III.

TRANSACCIONES
Universidad Tecnológica de Coahuila – ITIN
OBJETIVO

El alumno construirá transacciones,

copias de seguridad y reingeniería
en una base de datos para el
manejo de usuarios e instancias.
DOSIFICACIÓN

Horas Prácticas 15
Horas Teóricas 5
Horas Totales 20
TEMAS

Procesamiento de transacciones.

Reingeniería de Base de Datos.

TRANSACCIÓN

Conjunto de instrucciones DML que se ejecutan

consecutivamente

Se pueden anula o aceptar

Una instrucción no es realmente efectuada hasta que

se acepta (Commit)
¿CÓMO ES SU CICLO?

Comienza con la primera instrucción DML

Finaliza con alguna de las siguientes circunstancias:

• Una operación COMMIT o ROLLBACK
• Una instrucción DDL (como ALTER TABLE por ejemplo)
• Una instrucción DCL (como GRANT)
• El usuario abandona la sesión
• Caída del sistema
COMMIT

Hace que los cambios realizados por la transacción sean

definitivos
Solo utilizar cuando se está 100% seguro y de acuerdo con los
cambios

El cierre correcto de sesión da lugar a un COMMIT

Conviene ejecutarlo explícitamente

ROLLBACK

Regresa a la instrucción anterior

Generalmente al último COMMIT

Anula definitivamente los cambios

Hay que estar seguro antes de ejecutar esta instrucción

Un abandono de sesión incorrecto o un problema de
comunicación da lugar a un ROLLBACK implícito
SAVEPOINT

Permite establecer un punto de ruptura

ROLLBACK o COMMIT anula o acepta todo

Esta instrucción permite señalar un punto intermedio entre el inicio de la

transacción y la situación actual.

Una vez creado se utiliza ROLLBACK TO SAVEPOINT seguido del

nombre
SINTAXIS SAVEPOINT

...instrucciones DML...
SAVEPOINT nombre
....instrucciones DML...
ESTADO DE UNA TRANSACCIÓN

Si se inicia una transacción usando comandos DML hay que

tener en cuenta que:
• Se puede volver a la instrucción anterior a la transacción cuando se desee
• Las instrucciones de consulta SELECT realizadas por el usuario que inició la
transacción muestran los datos ya modificados por las instrucciones DML
• El resto de usuarios ven los datos tal cual estaban antes de la transacción,
de hecho los registros afectados por la transacción aparecen bloqueados
hasta que la transacción finalice.
• Esos usuarios no podrán modificar los valores de dichos registros.
IMPORTANTE

Tras la transacción todos los usuarios ven los

datos tal cual quedan tras el fin de transacción.

Los bloqueos son liberados y los puntos de

ruptura borrados.
MÉTODOS DE RECUPERACIÓN

La recuperación significa que la BD e debe restaurar

desde cualquier estado correcto del pasado

El sistema debe mantener la información de todo lo

que afecta la BD

A esto se le llama Bitácora o system log

TÉCNICAS DE RECOVERY

Deferred Update (actualización diferida)

• Conocida como NO UNDO/REDO
• Actualiza la base de datos sólo después de que la transacción
ha llegado a su COMMIT
• Antes del COMMIT todas las modificaciones son guardadas
en un área local
• Durante el COMMIT son guardadas en el system log
• Después se guardan en la BD
TÉCNICAS DE RECOVERY

Inmediate Update (actualización inmediata)

• Conocida como UNDO/REDO
• Propone que algunas operaciones actualicen la BD antes del COMMIT
• Esas actualizaciones son guardadas en el system log a nivel de disco
• Posteriormente se aplican a la BD
• SI una transacción falla antes del COMMIT se debe aplicar un UNDO
(Rollback)
• Una variación consiste en permitir que los cambios puede ser mediante
Savepoint para lo hacer un Rollback completo
CONTROL DE CONCURRENCIA

Asegura que la consistencia de la BD

se mantiene en un ambiente
distribuido multiusuario
Si las transacciones son consistentes, la manera
más simple de lograr lo es ejecutar cada
transacción sola, una después de otra.

Sin embargo, esto puede afectar el desempeño

de un BDD dado que el nivel de concurrencia se
reduce al mínimo
El nivel de concurrencia

El número de transacciones activas

Es el parámetro más importante en sistemas distribuidos

Por lo tanto, los mecanismos de control de
concurrencia buscan encontrar un balance
entre el mantenimiento de la consistencia
de la base de datos y el mantenimiento de
un alto nivel de concurrencia.
IMPORTANTE

Un adecuado control de concurrencia evita

que se presenten cierta anomalías como:
• Perder actualizaciones provocando que algunas
transacciones no se reflejen en la BD
• Presencia de recuperaciones de información
inconsistentes
CALENDARIZACIÓN (SCHEDULE)

Conjunto de transacciones
T= {T1, T2 , … , Tn}
y especifica un orden entrelazado
de la ejecución de las operaciones
de las transacciones
EJEMPLO

Considere las siguientes tres transacciones:

• T1: Read( x ) T2: Write( x ) T3: Read( x ) Write( x ) Write( y )

Read( y )Commit Read( z ) Read( z ) Commit Commit
Una calendarización de las acciones de las tres
transacciones anteriores puede ser:
• H1 = { W2(x), R1(x), R3(x), W1(x), C1, W2(y), R3(y), R2(z), C2,
R3(z), C3 }
SE DICE

Dos operaciones

Oij(x) y Okl(x) (i y k no necesariamente distintos)

Que accedan el mismo dato de la base de datos x se dice que están en

conflicto si al menos una de ellas es una escritura.

De esta manera, las operaciones de lectura no tienen conflictos consigo

mismas.
POR TANTO

Existen dos tipos de conflictos read-write (o

write-read) y writewrite.

Las dos operaciones en conflicto pueden

pertenecer a la misma transacción o a
transacciones diferentes.
SERIABILIDAD

En bases de datos distribuidas es

necesario considerar dos tipos de historia
para poder generar calendarizaciones
serializables:
• Calendarización local
• Calendarización global
Para que las transacciones globales sean
serializables se deben satisfacer las
siguientes condiciones:
• cada historia local debe ser serializable
• dos operaciones en conflicto deben estar en el mismo
orden relativo en todas las historias locales donde las
operaciones aparecen juntas.
Se debe asegurar que el orden de
serialización sea el mismo en todos los
nodos en donde las transacciones en
conflicto se ejecutan juntas.
EJEMPLO

Considere las siguientes transacciones:

• T1: Read( x ) T2: Read( x ) x ← x + 5 x ← x * 5 Write( x ) Write( x )

Commit Commit

Las siguientes historias locales son individualmente

serializables (de hecho son seriales),
• LH1 = { R1(x), W1(x), C1, R2(x), W2(x), C2 }
• LH2 = { R2(x), W2(x), C2, R1(x), W1(x), C1 }