El documento describe los conceptos de transacciones y niveles de aislamiento en bases de datos. Explica que una transacción es un grupo de instrucciones SQL que se ejecutan de forma atómica y por defecto de forma serializable. También describe los cuatro niveles de aislamiento (serializable, repeatable read, read committed y read uncommitted) y cómo cada uno resuelve problemas como lecturas sucias y fantasmas.

1. Bases de Datos – Transacciones 1
Manejo de Transacciones
Jorge P´rez Rojas
e
Universidad de Talca, II Semestre 2006

2. Bases de Datos – Transacciones 2
Transacciones
Hasta ahora el modelo de operaci´n en la BD ha sido o de
o
consultas, o de modificaciones a la BD.
Hemos siempre supuesto que las acciones se ejecutan una a la vez
y que cada una se lleva a cabo completamente
Hemos supuesto que ni el software ni el hardware pueden fallar en
el intertanto de una operaci´n.
o
La vida real es much´
ısimo m´s compleja...
a

3. Bases de Datos – Transacciones 3
Transacciones (cont.)
No s´lo el hardware o el software pueden fallar dejando a la BD
o
en un estado inexplicable a partir de operaciones.
El sistema de base de datos normalmente est´ siendo accedido
a
simultaneamente por muchos usuarios tanto para hacer consultas
como actualizaciones.
Algunas ejecuciones paralelas pueden intercalarse de manera tal de
dejar a la BD en un estado inconsistente.

4. Bases de Datos – Transacciones 4
Serializaci´n
o
Supongamos que en una aplicaci´n de reserva de pasajes para un
o
vuelo existe un procedimiento que:
• busca un asiento libre
• lo marca como ocupado
• asigna el asiento al pasajero que ejecut´ la llamada
o
Es totalmente posible que al mismo tiempo dos pasajeros ejecuten
el procedimiento simult´neamente y dejen la BD en un estado
a
“indeseable”.

5. Bases de Datos – Transacciones 5
Serializaci´n (cont.)
o
P1 P2
P1 llama al procedimiento
P2 llama al procedimiento
Se encuentra asiento 10 libre
Se encuentra asiento 10 libre
Se marca 10 ocupado
Se marca 10 ocupado
Se asigna 10 a P1
Se asigna 10 a P2
Ambos pasajeros quedan con el mismo asiento asignado, la BD queda
en un estado indeseable.

6. Bases de Datos – Transacciones 6
Serializaci´n (cont.)
o
Nos gustar´ que sea cual sea el orden de ejecuci´n, el estado de la
ıa o
BD quedara “como si se hubiese” ejecutado un procedimiento
primero y luego el otro.
A esto se le llama una ejecuci´n serializable.
o
Si cualquier ejecuci´n de los procedimientos anteriores fuese
o
serializable entonces nunca se le asignar´ a dos pasajeros el
ıa
mismo asiento.
IMPORTANTE: NO queremos que los procedimientos siempre se
ejecuten uno tras otro, s´lo necesitamos que el resultado sea
o
“serializable”.

7. Bases de Datos – Transacciones 7
Atomicidad
Supongamos que tenemos una aplicaci´n bancaria y un
o
procedimiento para transferir fondos entre las cuentas A1 y A2 :
1. Se verifica que A1 tenga suficiente dinero.
2. Se aumenta el saldo de A2 en el monto especificado.
3. Se disminuye el saldo de A1 en el monto especificado.
Supongamos que el sistema falla justo antes de comenzar a
ejecutar la linea 3.
La BD queda en un estado indeseable (al menos para el banco).

8. Bases de Datos – Transacciones 8
Atomicidad (cont.)
En el ejemplo anterior nos gustar´ que las operaciones se
ıa
ejecutaran todas o que ninguna de ellas se ejecutara.
La ejecuci´n de una operaci´n es at´mica si el estado de la BD
o o o
luego de la operaci´n es como si todos sus componentes se
o
hubiesen ejecutado o como si ninguno de ellos lo hubiese hecho.

9. Bases de Datos – Transacciones 9
Transacciones
Los problemas de serializaci´n y atomicidad pueden ser resueltos
o
usando transacciones.
Una transacci´n est´ compuesta por un grupo de instrucciones de
o a
SQL que se ejecutan at´micamente (se ejecutan todas o ninguna).
o
Por defecto adem´s, una transacci´n exige ejecuciones
a o
serializables.
En SQL2 se puede especificar m´s libertad en la ejecuci´n que
a o
simplemente serializable, esto se hace modificando los niveles de
aislamiento que veremos m´s adelante.
a

10. Bases de Datos – Transacciones 10
Transacciones (cont.)
Una transacci´n se comienza con una instrucci´n
o o
begin transaction (no es necesario en algunos DBMS).
La instrucci´n commit termina la transacci´n en forma exitosa y
o o
hace permanente cualquier cambio realizado a la BD durante la
transacci´n.
o
Los cambios se hacen permanentes s´lo despu´s de un commit.
o e
La instrucci´n rollback aborta la transacci´n y la hace terminar
o o
en forma no exitosa, cualquier cambio que la transacci´n pudo
o
hacer a la BD se deshace.
En general se puede hacer rollback para cualquier conjunto de
instrucciones no necesariamente dentro de una transacci´n.
o

11. Bases de Datos – Transacciones 11
Transacciones – Ejemplo
Para el ejemplo de transferencia de fondos:
1. begin transaction
2. Si A1 no tiene suficiente dinero ⇒ rollback.
3. Se aumenta el saldo de A2 en el monto especificado.
4. Se disminuye el saldo de A1 en el monto especificado.
5. commit.

12. Bases de Datos – Transacciones 12
Transacciones Abortadas
Una transacci´n puede no llegar a su t´rmino debido a muchas razones:
o e
situaci´n excepcional detectada que hace que el programa no
o
pueda continuar
falla del programa
falla del software de BD
falla del Sistema Operativo
falla del hardware
falla de energ´ el´ctrica
ıa e
control de concurrencia ha detectado un conflicto
control de concurrencia ha detectado un deadlock

13. Bases de Datos – Transacciones 13
Transacciones (cont.)
SQL2 permite definir distintos tipos de transacciones.
Cada uno de ellos define las posibilidades de accesos y enmallado
de instrucciones que se pueden dar durante la ejecuci´n de
o
transacciones en paralelo.
Se permiten los siguiente niveles de aislamiento
• serializable (por defecto)
• repeatable read
• read commited
• read uncommited
Para setearlos se usa set transaction, por ejemplo
set transaction repeatable read.
Veremos un ejemplo para dejar claro cada uno de los niveles.

14. Bases de Datos – Transacciones 14
Niveles de Aislamiento – Ejemplo
Supongamos una base de datos con una relaci´n con esquema
o
vende(bar,cerveza,precio) que indica que cierta cerveza se
vende a cierto precio en cierto bar.
Supongamos que el bar de Pepe vende s´lo Cristal a $450 y
o
Escudo a $400.
Juan quiere preguntar por la cerveza m´s cara y m´s barata del
a a
bar de Pepe.
Al mismo tiempo Pepe elimina a Cirstal y Escudo y comienza a
vender s´lo Kunstmann en $500.
o

15. Bases de Datos – Transacciones 15
Niveles de Aislamiento – Ejemplo (cont.)
En SQL, Juan ejecuta las instrucciones
select max(precio) from vende where bar = ’Pepe’
select min(precio) from vende where bar = ’Pepe’
que llamaremos (max) y (min) respectivamente.
Por su parte Pepe ejecuta
delete from vende where bar = ’Pepe’
insert into vende values(’Pepe’,’Kunstmann’,500)
que llamaremos (del), e (ins) respectivamente.

16. Bases de Datos – Transacciones 16
Niveles de Aislamiento – Ejemplo (cont.)
Supongamos que se ejecutan simultaneamente en la base de datos
los dos grupos de instrucciones.
Lo unico que podemos asegurar con certeza es que (max) se
´
ejecuta antes de (min), y que (del) se ejecuta antes de (ins),
pero nada m´s.
a
Una posible ejecuci´n podr´ ser la siguiente:
o ıa
Juan: (max) (min)
Pepe: (del) (ins)
Juan lee como m´ximo el precio de Cristal que es $450 y
a
finalmente lee como precio m´ınimo el precio de Kunstmann que es
$500... el m´ximo es menor que el m´
a ınimo!!!!

17. Bases de Datos – Transacciones 17
Nivel Serializable
Si Juan ejecuta sus instrucciones en una transacci´n con nivel de
o
aislamiento serializable entonces ver´ la base de datos antes o
a
despu´s de la ejecuci´n de las instrucciones de Pepe pero nunca
e o
en el medio.
Depende del DBMS c´mo asegura esto, lo unico que interesa es
o ´
que la vista de los datos por parte de Juan es como si uno de los
grupos de instrucciones (de Juan o de Pepe) se ejecute antes que
el otro.
La elecci´n de nivel serializable afecta s´lo a quien la elige...
o o
por ejemplo, si Pepe ejecuta con nivel serializable pero Juan
no, Juan perfectamente podr´ ver los datos como si ejecutara en
ıa
la mitad de la transacci´n de Pepe.
o

18. Bases de Datos – Transacciones 18
Nivel Read Commited
Supongamos que Pepe ejecuta (del) e (ins) pero luego lo piensa
mejor, se arrepiente y hace rollback para deshacer los cambios.
Si Juan ejecuta su transacci´n despu´s del (ins) pero antes del
o e
rollback se tiene
Juan: (max) (min)
Pepe: (del) (ins) rollback
Entonces Juan leer´ el dato $500 como precio m´ximo y m´
a a ınimo,
sin embargo $500 es un dato que nunca existir´ realmente en la
a
base de datos, a esto se le llama Lectura Sucia.
Lectura Sucia: transacci´n T1 actualiza datos que T2 lee, luego
o
T1 se aborta ⇒ T2 ha le´ datos inexistentes.
ıdo

19. Bases de Datos – Transacciones 19
Nivel Read Commited (cont.)
El nivel read commited evita la lectura sucia ya que como su
nombre lo dice la transacci´n s´lo podr´ leer datos que han sido
o o a
reafirmados por el commit de otra transacci´n.
o
De alguna forma el DBMS se las debe arreglar para que Juan no
pueda leer el valor $500 si es que Pepe hace rollback.
El nivel read commited es m´s permisivo que el serializable
a
de hecho en la ejecuci´n
o
Juan: (max) (min)
Pepe: (del) (ins)
es totalmente factible en read commited siempre que Pepe haga
commit, y Juan ver´ que el m´ximo es $450 y que el m´
a a ınimo es
$500.

20. Bases de Datos – Transacciones 20
Nivel Repeatable Read
Este nivel evita lo que se conoce como lectura no repetible.
Lectura No Repetible: transacci´n T1 lee los mismo datos dos
o
veces, entre ambas lecturas una transacci´n T2 elimina algunos
o
datos ⇒ en la segunda lectura de T1 se pierden datos con
respecto a la primera.
El nivel repateable read es similar a read commited
adicionando la restricci´n de que en una transacci´n, todo lo que
o o
se vio en una lectura inicial debe ser visto si se ejecuta la misma
lectura posteriormente.
La segunda y siguientes lecturas pueden tener m´s datos que la
a
primera pero nunca se pueden perder datos.

21. Bases de Datos – Transacciones 21
Nivel Repeatable Read – Ejemplo
Suponga que Juan ejecuta con nivel repeatable read y el orden
de las instrucciones es
Juan: (max) (min)
Pepe: (del) (ins)
Dado que durante la lectura (max) Juan ley´ los valores $400 y
o
$450, el sistema debe asegurar que durante (min) se vean
adicionalmente a $500, los valores $400 y $450 ya que estos
fueron vistos en la lectura anterior en (max).
En este caso los datos ser´n consistentes en la lectura para Juan
a
(comparados con read commited) ya que ver´ que el m´ximo
a a
precio es $450 y el m´ınimo es $400, a pesar de que esto no refleje
el estado real de la base de datos luego de las transacciones.

22. Bases de Datos – Transacciones 22
Nivel Repeatable Read (cont.)
Este nivel sigue siendo m´s permisivo que serializable.
a
Supongamos que Juan intenta leer dos veces el precio m´ximo de
a
las cervezas y en el intertanto Pepe actualiza los precios
Juan: (max) (max)
Pepe: (del) (ins)
Si ejecuta en repeatable read se asegur que todo lo que lee en
el primer (max) lo lee tambi´n en el segundo (max), sin embargo
e
en un caso obtiene que el m´ximo es $450 y luego $500, esto se
a
conoce como valor fantasma.
Fantasmas: T1 lee datos que cumplen cierta condici´n, T2 inserta
o
un dato que cumple la condici´n, ⇒ si T1 vuelve a leer
o
encontrar´ una nueva tupla fantasma.
a

23. Bases de Datos – Transacciones 23
Nivel Read Uncommited
Es el nivel m´s permisivo.
a
Una transacci´n que se ejecuta con nivel read uncommited
o
puede ver valores que otra transacci´n ha escrito, o dejar de ver
o
valores que otra transacci´n haya borrado, a pesar de que esta no
o
haya hecho commit y posiblemente nunca lo haga.
Por ejemplo Juan podr´ perfectamente ver el valor $500 como
ıa
precio m´ximo o m´
a ınimo a pesar que Pepe posteriormente a la
inserci´n aborte los cambios (rollback).
o
read uncommited permite entonces lecturas sucias, lecturas no
repetibles y lecturas fantasmas.

24. Bases de Datos – Transacciones 24
Niveles de Aislamiento
Podemos finalmente definir los distintos niveles de aislamiento a
partir de si cada uno de ellos permite o no lecturas sucias, lecturas
no repetibles, y/o lecturas fantasmas.
Nivel Sucia No Repetible Fantasma
serializable NO NO NO
repeatable read NO NO SI
read commited NO SI SI
read uncommited SI SI SI

25. Bases de Datos – Transacciones 25
Control de Concurrencia
Forma en que el DBMS maneja las ejecuciones paralelas en la BD.
Principalmente dos enfoques:
• Optimista: supone que los conflictos son escasos ⇒ permitir
acceso concurrente y deshacer las acciones problem´ticas.
a
• Pesimista: asume que es muy probable que ocurran problemas
⇒ act´a a la defensiva impidiendo la aparici´n de conflictos
u o
usando locks.

26. Bases de Datos – Transacciones 26
M´s sobre Locks
a
Un lock es una estructura que s´lo puede ser adquirida por una
o
hebra de ejecuci´n (thread) a la vez.
o
Si dos ejecuciones tratan de obtener un lock para actualizar una
tabla, la primera que trate de obtenerlo tendr´ acceso exclusivo a
a
la tabla, la segunda debe esperar a que la primera lo suelte para
obtener el acceso.
Los locks pueden tener distintas granularidades: Base de Datos,
Tabla, Tupla, Atributo.
Adem´s de los locks exclusivos existen locks de s´lo lectura o
a o
locks compartidos que pueden estar simult´neamente siendo
a
utilizados por distintas ejecuciones.

27. Bases de Datos – Transacciones 27
Transacciones en SQLServer
En SQLServer se puede nombrar a una transacci´n para luego
o
persistirla, deshacerla completa, o deshacer parte de ella. Para
permitir deshacer parte de una transacci´n se usan save points.
o
begin transaction <tran>: comienza la transacci´n <tran>.
o
save transaction <savp>: especifica un save point de nombre
<savp> interno a una transacci´n.
o
rollback transaction <tran>: deshace los cambios realizados
desde un save point, o dentro de una transacci´n, de nombre
o
<tran>.
commit transaction <tran>: persiste los cambios en la
transacci´n <tran> que no hayan sido deshechos por alg´n
o u
rollback intermedio.

28. Bases de Datos – Transacciones 28
Transacciones en SQLServer – Ejemplo
begin transaction t
update empleado ...
save transaction s
update departamento ...
select ... from empleado ...
rollback transaction s
commit transaction t
S´lo el primer update se hace efectivo en la BD.
o

29. Bases de Datos – Transacciones 29
Transacciones en SQLServer (cont.)
SQLServer soporta todos los niveles de aislamiento definidos para
SQL2.
Antes de comenzar una transacci´n se debe usar:
o
• set transaction isolation level serializable
• set transaction isolation level repeatable read
• set transaction isolation level read commited
• set transaction isolation level read uncommited