TRANSACCIONES

Taller de Base de Datos

Ing. Ignacio Aguilar
Abril 2014

Transacciones
Conceptos Bsicos
Se llama transaccin a una coleccin de
operaciones que forman una nica unidad lgica de
trabajo.
Un sistema de base de datos debe asegurar que la
ejecucin de las transacciones se realice
adecuadamente a pesar de la existencia de fallos: o
se ejecuta la transaccin completa o no se ejecuta en
absoluto.

Adems debe gestionar la ejecucin concurrente de

las transacciones evitando introducir inconsistencias.2

Transacciones
Conceptos Bsicos
Una transaccin es una unidad de la ejecucin de
un programa que accede y posiblemente actualiza
varios elementos de datos.
Una transaccin se inicia por la ejecucin de un
programa de usuario escrito en un lenguaje de
manipulacin de datos de alto nivel y est delimitado
por instrucciones de la forma inicio transaccin y fin
transaccin.

La transaccin consiste en todas las operaciones que

se ejecutan entre inicio transaccin y el fin
3
transaccin.

Transacciones
Conceptos Bsicos
En cualquier momento una transaccin slo puede estar en
uno de los siguientes estados:

Transacciones
Conceptos Bsicos
Estados de una transaccin:

Activa (Active): el estado inicial; la transaccin

permanece en este estado durante su ejecucin.

Parcialmente comprometida (Uncommited): Despus
de ejecutarse la ltima operacin.
Fallida (Failed): tras descubrir que no se puede
continuar la ejecucin normal.
Abortada (Rolled Back): despus de haber retrocedido
la transaccin y restablecido la base de datos a su
estado anterior al comienzo de la transaccin.
Comprometida (Commited): tras completarse con xito.
5

Transacciones
Propiedades de las transacciones

Para asegurar la integridad de los datos se necesita

que el sistema de base de datos mantenga las
siguientes propiedades de las transacciones:
atomicidad, coherencia, aislamiento y durabilidad.
Estas propiedades a menudo reciben el nombre de
propiedades ACID; el acrnimo se obtiene de la
primera letra de cada una de las cuatro propiedades
en ingls (Atomicity, Consistency, Isolation y
Durability, respectivamente).
6

Transacciones
Propiedades de las transacciones

Atomicidad

Una transaccin debe ser una unidad atmica de

trabajo, tanto si se realizan todas sus
modificaciones en los datos, como si no se realiza
ninguna de ellas.
Para que una transaccin sea atmica, deben
ejecutarse todas sus modificaciones de datos o
ninguna de ellas.
7

Transacciones
Propiedades de las transacciones

Coherencia/Consistencia
Cuando finaliza, una transaccin debe dejar todos
los datos en un estado coherente.
La ejecucin aislada de la transaccin (es decir, sin
otra transaccin que se ejecute concurrentemente)
conserva la coherencia de la base de datos.
Para ser coherente, una transaccin completa debe
dejar todos los datos en un estado coherente,
8
lgicamente correcto.

Transacciones
Propiedades de las transacciones

Aislamiento
Las modificaciones realizadas por una transaccin
se deben aislar de las modificaciones llevadas a
cabo por otras transacciones simultneas.
Para cumplir la propiedad de aislamiento, una
transaccin lee los datos en el estado en que
estaban antes de que otra transaccin simultnea
los modificara (sin haber confirmado an la
transaccin). Las modificaciones simultneas en
curso no afectan a la transaccin.
9

Transacciones
Propiedades de las transacciones

Aislamiento
Aunque se ejecuten varias transacciones
concurrentemente, el sistema garantiza que para
cada par de transacciones Ti y Tj, se cumple que
para los efectos de Ti, o bien Tj ha terminado su
ejecucin antes de que comience Ti , o bien que Tj
ha comenzado su ejecucin despus de que Ti
termine.
De este modo, cada transaccin ignora al resto de
10
las
transacciones
que
se
ejecuten
concurrentemente en el sistema.

Transacciones
Propiedades de las transacciones

Durabilidad
Para cumplir la propiedad de durabilidad, las
modificaciones de una transaccin deben
conservarse, es decir, deben quedar en la base de
datos aunque se produzca un error del sistema.
Una vez reconocida una confirmacin, el sistema
debe garantizar que la transaccin se conserva.

11

Transacciones
Propiedades de las transacciones
Para fines ilustrativos supngase que el acceso a la
base de datos se lleva a cabo mediante las dos
operaciones siguientes:

leer (X), que transfiere el dato X de la base de datos

a una memoria intermedia local perteneciente a la
transaccin que ejecuta la operacin leer.
escribir (X), que transfiere el dato X desde la
memoria intermedia local de la transaccin que
ejecuta la operacin escribir a la base de datos.
12

Transacciones
Propiedades de las transacciones
Sea Ti una transaccin para transferir 50 pesos de la
cuenta A a la cuenta B. Se puede definir dicha
transaccin como:

Ti:

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

Transacciones
Propiedades de las transacciones
Consistencia:
En este caso el requisito de consistencia es que la
suma de A y B no sea alterada al ejecutar la
transaccin. Sin el requisito de consistencia, la
transaccin podra crear o destruir dinero!.
La responsabilidad de asegurar la consistencia de
una transaccin es del programador de la aplicacin
que codifica dicha transaccin.
14

Transacciones
Propiedades de las transacciones
Atomicidad:
Supngase que justo antes de ejecutar la transaccin Ti los
valores de las cuentas A y B son de $1,000 y de $2,000.
Supngase ahora que durante la ejecucin de la transaccin Ti
se produce un fallo que impide que dicha transaccin finalice
con xito su ejecucin. Adems, supngase que el fallo tiene
lugar despus de ejecutarse la operacin escribir(A), pero
antes de ejecutarse la operacin escribir(B).
Es ese caso, los valores de las cuentas A y B que se ven
reflejados en la base de datos son $950 y $2,000. Se han
perdido $50 de la cuenta A como resultado de este fallo. En
15
particular se puede ver que ya no se conserva la suma A + B.

Transacciones
Propiedades de las transacciones

Ti:

leer(A);
A := A 50;
escribir(A);
Estado inconsistente temporal

leer(B);
B := B + 50;
escribir(B).

16

Transacciones
Propiedades de las transacciones
Atomicidad
La idea bsica que hay detrs de asegurar la
atomicidad es la siguiente. El sistema de base de
datos mantiene los valores antiguos (en disco) de
aquellos datos sobre los que una transaccin realiza
una escritura y, si la transaccin no completa su
ejecucin, los valores antiguos se recuperan para
que parezca que la transaccin no se ha ejecutado.

La responsabilidad de asegurar la atomicidad es del

DBMS; en concreto, lo maneja un componente
17
llamado gestor de transacciones.

Transacciones
Propiedades de las transacciones
Durabilidad.
La propiedad de durabilidad asegura que, una vez
que se completa con xito una transaccin, persisten
todas las modificaciones realizadas en la base de
datos, incluso si hay un fallo en el sistema despus
de completarse la ejecucin de dicha transaccin.
Se puede garantizar la durabilidad si se asegura que:

1. Las modificaciones realizadas por la transaccin

se guardan en disco antes de que finalice 18la
transaccin.

Transacciones
Propiedades de las transacciones
Durabilidad
2. La informacin guardada de las modificaciones
realizadas por la transaccin es suficiente para
permitir al DBMS reconstruir dichas modificaciones
cuando el sistema se reinicie despus del fallo.
La responsabilidad de asegurar la durabilidad es del
componente del sistema de base de datos llamado
gestor de recuperaciones.
El gestor de transacciones y el gestor de
19
recuperaciones estn estrechamente relacionados.

Transacciones
Propiedades de las transacciones
Aislamiento.
Incluso si se aseguran las propiedades de
consistencia y de atomicidad para cada transaccin,
si
varias
transacciones
se
ejecutan
concurrentemente, se pueden entrelazar sus
operaciones de un modo no deseado, produciendo
un estado inconsistente.
Observe que en el ejemplo referido, la base de datos
es inconsistente temporalmente durante la ejecucin
de la transaccin, con el total deducido escrito ya en
20
A y el total incrementado todava sin escribir en B.

Transacciones
Propiedades de las transacciones
Aislamiento
Si una segunda transaccin que se ejecuta
concurrentemente lee A y B en este punto intermedio
y calcula A + B, observar un valor inconsistente.

Adems, si esta segunda transaccin realiza despus

modificaciones en A y B basndose en los valores
ledos, la base de datos puede permanecer en un
estado inconsistente aunque ambas transacciones
terminen.
21

Transacciones
Propiedades de las transacciones
Aislamiento(Ejemplo de una ejecucin incorrecta)
Ti:
----------------------------leer(A);
A := A 50;
escribir(A);
leer(B);

Ti:
-----------------------------

leer(A);
A := A 100;
escribir(A);
leer(B);
B := B + 100;
escribir(B)
B := B + 50;
escribir(B)

22

Transacciones
Grados de consistencia
El concepto subyacente para mantener la consistencia en el
proceso concurrente es el de secuencialidad.

Si todas las transacciones tienen la propiedad de mantener la

consistencia de la Base de Datos si se ejecutan por separado,
la secuencialidad asegura que las ejecuciones concurrentes
mantienen la consistencia.
Sin embargo, puede que los protocolos necesarios para
asegurar la secuencialidad permitan muy poca concurrencia
en algunas aplicaciones.

En estos casos se utilizan los niveles mas dbiles de

consistencia.
23

Transacciones
Grados de consistencia
Ejecuciones concurrentes.
Los sistemas de procesamiento de transacciones permiten
normalmente la ejecucin de varias transacciones
concurrentes.
Asegurar la consistencia a pesar de la ejecucin concurrente
de las transacciones requiere un trabajo extra; es mucho mas
sencillo exigir que las transacciones se ejecuten
secuencialmente.
Sin embargo, existen buenas razones para permitir la
24
concurrencia:

Transacciones
Grados de consistencia
Consistencia es un trmino ms amplio que el de integridad.
Podra definirse como la coherencia entre todos los datos de la
base de datos. Cuando se pierde la integridad tambin se
pierde la consistencia. Pero la consistencia tambin puede
perderse por razones de funcionamiento.
La ejecucin de una transaccin debe conducir a un estado de
la base de datos consistente (que cumple todas las
restricciones de integridad definidas).
Si se confirma definitivamente el sistema asegura la
persistencia de los cambios que ha efectuado en la base de
datos.
Si se anula los cambios que ha efectuado son deshechos.25

Transacciones
Grados de consistencia
Una transaccin mantendr la consistencia de la
base de datos.
Esto es, si la base de datos se encuentra en un
estado consistente antes de ejecutar la transaccin,
una vez que sta termine la consistencia de la base
de datos deber conservarse.
Por consistente se debe entender, internamente
consistente.
26

Transacciones
Grados de consistencia

Ti:

leer(A);
A := A 50;
escribir(A);
Estado inconsistente temporal

leer(B);
B := B + 50;
escribir(B).

27

Transacciones
Grados de consistencia
Consistencia de datos.
Eliminando o controlando las redundancias de datos se
reduce en gran medida el riesgo de que haya
inconsistencias.
Si un dato est almacenado una sola vez, cualquier
actualizacin se debe realizar slo una vez, y est
disponible para todos los usuarios inmediatamente.
Si un dato est duplicado y el sistema conoce esta
redundancia, el propio sistema puede encargarse de
garantizar que todas las copias se mantienen
consistentes.
28

Transacciones
Grados de consistencia
En trminos de base de datos, esto significa que se
satisfacen todas las restricciones en cuanto a su
integridad que incluyen:
Todos los valores de la llave primaria son nicos.
La base de datos mantiene integridad referencial lo
que significa que los registros solo referencian
informacin que existe.
Ciertos predicados se mantienen. Por ejemplo, la
suma de los gastos es menor o igual al presupuesto.
29

Transacciones
Grados de consistencia
A diferencia de la atomicidad, el aislamiento y la
durabilidad, la consistencia es una prctica de
programacin.
La atomicidad, el aislamiento y la durabilidad estn
aseguradas estn o no programadas para preservar
la consistencia.
Es responsabilidad del desarrollador de la aplicacin
asegurar que su programa preserva la consistencia.
30

Transacciones
Niveles de aislamiento
De las cuatro propiedades ACID de un Sistema de
gestin de bases de datos relacionales (SGBDR), la de
aislamiento es la que ms frecuentemente se relaja.
El nivel de aislamiento especifica el grado en el que una
transaccin se separa de las acciones de otras
transacciones.
Los niveles de aislamiento se describen en cuanto a los
efectos secundarios de la simultaneidad que se permiten,
como las lecturas desfasadas o ficticias.
31

Transacciones
Niveles de aislamiento
Para obtener el mayor nivel de aislamiento, un SGBDR
generalmente hace un bloqueo de los datos o
implementa un control de concurrencia mediante
versiones mltiples (MVCC*), lo que puede resultar en
una prdida de concurrencia.

A mayor grado de aislamiento, mayor precisin, pero

a costa de menor concurrencia.
La mayora de los SGBDR ofrecen ciertos niveles de
aislamiento que controlan el grado de bloqueo
durante el acceso a los datos.
32

Transacciones
Niveles de aislamiento
Para la mayor parte de aplicaciones, el acceso a los
datos se puede realizar de modo que se eviten altos
niveles de aislamiento, reduciendo as la sobrecarga
debida a la necesidad de bloqueos por el sistema.
El programador debe analizar detenidamente el cdigo
que accede a la base de datos para asegurarse de que el
descenso del nivel de aislamiento que ofrece el SGBD no
produce errores en el programa.
Recprocamente, si se usan altos niveles de aislamiento
la posibilidad de bloqueo aumenta, lo que tambin
33
requiere anlisis cuidadoso del cdigo.

Transacciones
Niveles de aislamiento
Los niveles de aislamiento estn definidos por
ANSI/ISO SQL, y se listan a continuacin:

el

(1) Secuenciable / Serializable.

Este es el nivel de aislamiento ms alto. Especifica
que todas las transacciones ocurran de modo
aislado, (como si se ejecutaran de modo serie, es
decir, una tras otra). La sensacin de ejecucin
simultnea de dos o ms transacciones que perciben
los usuarios sera una ilusin producida por el SGBD.
34

Transacciones
Niveles de aislamiento
Secuenciables/Serializable
Si el SGBDR hace una implementacin basada en
bloqueos, la serializacin requiere que los bloqueos de
lectura y escritura se liberen al final de la transaccin.
Del mismo modo deben realizarse bloqueos de rango sobre los datos seleccionados con SELECT usando
WHERE- para evitar el efecto de las lecturas
fantasma*.
Cuando se hace una implementacin no basada en
bloqueos, si el SGBDR detecta una colisin de escritura
entre transacciones slo a una de ellas se le autoriza
35
cometer.

Transacciones
Niveles de aislamiento
(2) Lecturas repetibles (Repeatable reads)
En este nivel de aislamiento, un SGBDR que
implemente el control de concurrencia basado en
bloqueos mantiene los bloqueos de lectura y
escritura -de los datos seleccionados- hasta el final
de la transaccin. Sin embargo, no se gestionan
los bloqueos de rango, por lo que las lecturas
fantasma* pueden ocurrir.
36

Transacciones
Niveles de aislamiento
(3) Lecturas comprometidas (Read committed)
En este nivel de aislamiento, un SGBDR que
implemente el control de concurrencia basado en
bloqueos mantiene los bloqueos de escritura -de los
datos seleccionados- hasta el final de la transaccin,
mientras que los bloqueos de lectura se cancelan
tan
pronto
como
acaba
la
operacin
de SELECT (por lo que el efecto de las lecturas no
repetibles* puede ocurrir). Al igual ocurra en el
nivel anterior, no se gestionan los bloqueos de
37
rango.

Transacciones
Niveles de aislamiento
(4)
Lecturas
uncommitted)

no

comprometidas

(Read

Este es el menor nivel de aislamiento. En l se

permiten las lecturas sucias*, por lo que una
transaccin pude ver cambios no cometidos an por
otra transaccin.

38

Transacciones
Niveles de aislamiento
Efectos que definen los cuatro niveles de aislamiento
transaccional del estndar ANSI/ISO SQL.

39

Transacciones
Niveles de aislamiento
Lectura sucia. Las sentencias SELECT son ejecutadas sin
realizar bloqueos; esto implica que podra usarse una versin
anterior de un registro. Por lo tanto, las lecturas no son
consistentes al usar este nivel de aislamiento.
Lectura no repetible. Una transaccin vuelve a leer datos que
previamente haba ledo y encuentra que han sido modificados
o eliminados por una transaccin cursada.
Lectura fantasma. Una transaccin vuelve a ejecutar una
consulta, devolviendo un conjunto de registros que satisfacen
una condicin de bsqueda y encuentra que otros registros
que satisfacen la condicin han sido insertadas por otra
40
transaccin.

Transacciones
Niveles de aislamiento en MySQL
MySQL ofrece los cuatro niveles de aislamiento para los
motores de almacenamiento InnoDB y BDB. El nivel de
aislamiento para las transacciones puede fijarse cambiarse
con el siguiente comando:

SET [GLOBAL | SESSION] TRANSACTION ISOLATION

LEVEL { READ UNCOMMITTED | READ COMMITTED |
REPEATABLE READ | SERIALIZABLE }
*El nivel de aislamiento predeterminado es REPEATABLE READ

Este comando prepara el nivel de aislamiento de transaccin

para la siguiente transaccin, globalmente, o para la sesin
actual.
41

Transacciones
Niveles de aislamiento en MySQL
El
comportamiento
por
defecto
de
SET
TRANSACTION es poner el nivel de aislamiento para la
siguiente transaccin (que no ha empezado todava).
Si usa la palabra clave GLOBAL el comando pone el
nivel de aislamiento de transaccin por defecto
globalmente para todas las transacciones creadas desde
ese momento. Las conexiones existentes no se ven
afectadas. Necesita el permiso SUPER para hacerlo.
Usar la palabra clave SESSION determina el nivel de
transaccin para todas las transacciones futuras
realizadas en la conexin actual.
42

Transacciones
Niveles de aislamiento en MySQL
Bloqueos en MySQL:
Las partes de las sentencias de SQL involucradas con el
bloqueo son las siguientes:
SELECT [FOR UPDATE | LOCK IN SHARE MODE]
Si usa FOR UPDATE en un motor de almacenamiento
que usa bloqueo de pginas o registros, los registros
examinados por la consulta se bloquean para escritura
hasta el final de la transaccin actual.
Usar LOCK IN SHARE MODE crea un bloqueo
compartido que evita a otras transacciones actualizar o
43
borrar los registros examinados.

Transacciones
Operaciones COMMIT y ROLLBACK

El componente del sistema encargado de lograr la

atomicidad se conoce como gestor de transacciones y
las
operaciones
COMMIT
(comprometer)
y
ROLLBACK (retroceder) son la clave de su
funcionamiento.
El estndar SQL establece que toda transaccin debe
ser iniciada con la sentencia BEGIN TRAN y
terminada con cualquiera de las siguientes: COMMIT
TRAN ROLLBACK TRAN
44

Transacciones
Operaciones COMMIT y ROLLBACK

La operacin COMMIT seala el trmino exitoso de la

transaccin: le dice al gestor de transacciones que se
ha finalizado con xito una unidad lgica de trabajo,
que la base de datos est o debera estar de nuevo
en un estado consistente y que se pueden
comprometer, o hacer permanentes todas las
modificaciones efectuadas por esa unidad de trabajo.
Pasa una transaccin de estado parcialmente
comprometido al estado comprometido.
45

Transacciones
Operaciones COMMIT y ROLLBACK

La operacin ROLLBACK, en cambio, seala el

trmino no exitoso de la transaccin: le dice al
administrador de transacciones que algo sali mal,
que la base de datos podra estar en un estado
inconsistente y que todas las modificaciones
efectuadas hasta el momento por la unidad lgica de
trabajo deben retroceder o anularse.
Pasa una transaccin de un estado fallido a un estado
abortada.
46

Transacciones
Operaciones COMMIT y ROLLBACK
Los pasos para usar transacciones en son:

Iniciar una transaccin con el uso de la sentencia BEGIN.

Modificar, insertar o eliminar registros en la base de datos.

Si se quieren hacer permanentes los cambios a la base de

datos, completar la transaccin con el uso de la sentencia
COMMIT.

Si sucede algn problema, se puede hacer uso de la

sentencia ROLLBACK para cancelar los cambios que han
sido realizados por las comandos que han sido ejecutados
hasta el momento.
47

Transacciones
COMMIT y ROLLBACK en MySQL
Por defecto, MySQL se ejecuta con el modo autocommit*
activado. Esto significa que en cuanto se ejecute un comando
que actualice una tabla, MySQL almacena la actualizacin en
disco.

Si se usan tablas transaccionales (como InnoDB o BDB), se

puede desactivar el modo autocommit con el siguiente
comando:
SET AUTOCOMMIT=0;
Quiere decir que es responsabilidad del usuario indicar al
MySQL el modo de comportamiento y por tanto una vez
concluida la transaccin el usuario deber restablecer el modo
autocommit.
48

Transacciones
COMMIT y ROLLBACK en MySQL
Si se quiere deshabilitar el modo autocommit para una
serie nica de comandos, se puede usar el
comando START TRANSACTION:
START TRANSACTION;
SELECT FROM WHERE ;
UPDATE SET WHERE ;
COMMIT;

Con START TRANSACTION, autocommit permanece

deshabilitado hasta el final de la transaccin, y
con COMMIT o ROLLBACK el modo autocommit vuelve a
su estado previo.
49

Transacciones
Practica#1
Objetivo:
Revisar de la documentacin de MySQL los
diferentes motores de almacenamiento para tablas.

MySAM
InnoDB
Etc.
Obtener conclusiones.
50

Transacciones
Practica#2
Objetivo:
Disear una transaccin para la base de datos en
uso y probarla con motores MyISAM y InnoDB para
ver los efectos.
Desarrollo:

Incluir los campos correspondientes en las tablas:

pedido.total,
cliente.saldo,
vendedor.ventas,
articulo.ventas y sucursal.ventas

La transaccin debe afectar las 5 tablas al insertar

en concepto
51

Probar el commit y el rollbak

Transacciones
Practica#3
Objetivo:
Disear una transaccin para la base de datos en
uso y probarla en modo concurrente.
Desarrollo:

Primero probarla de manera aislada

Despus probarla de manera concurrente. Para

esto permitir el acceso a la base de datos desde
otro equipo y usuario.
52

Transacciones
Practica#4
Objetivo:
Disear una transaccin para la base de datos en
uso y probarla con diferentes niveles de
aislamiento.
Desarrollo:

Primero probarla de manera aislada

Despus probarla de manera concurrente. Para

esto permitir el acceso a la base de datos desde
otro equipo y usuario.
53

Transacciones
Control de concurrencia mediante versiones mltiples
(MVCC)
El procedimiento consiste en implementar las
actualizaciones de datos no borrando los datos antiguos y
sobre escribindolos con los nuevos, sino marcando los
antiguos como obsoletos y aadiendo los nuevos.
De ese modo habr en algn momento ms de una
versin de los mismos datos almacenada, teniendo
validez slo la versin ms reciente.
Se evita as al SGBD dedicar tiempo a rellenar huecos en
memoria o disco, al precio de tener que recorrer
peridicamente la memoria o el disco para eliminar dichos
54
objetos obsoletos.