Bases de Datos Transacciones

Manejo de Transacciones
Jorge Prez Rojas e Universidad de Talca, II Semestre 2006

Bases de Datos Transacciones

Transacciones
Hasta ahora el modelo de operacin en la BD ha sido o de o consultas, o de modicaciones 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 operacin. o La vida real es much simo ms compleja... a

Bases de Datos Transacciones

Transacciones (cont.)
No slo 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.

Bases de Datos Transacciones

Serializacin o
Supongamos que en una aplicacin 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 simultneamente y dejen la BD en un estado a indeseable.

Bases de Datos Transacciones

Serializacin (cont.) o
P1 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. P2

Bases de Datos Transacciones

Serializacin (cont.) o
Nos gustar que sea cual sea el orden de ejecucin, 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 ejecucin serializable. o Si cualquier ejecucin 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, slo necesitamos que el resultado sea o serializable.

Bases de Datos Transacciones

Atomicidad
Supongamos que tenemos una aplicacin bancaria y un o procedimiento para transferir fondos entre las cuentas A1 y A2 : 1. Se verica que A1 tenga suciente dinero. 2. Se aumenta el saldo de A2 en el monto especicado. 3. Se disminuye el saldo de A1 en el monto especicado. 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).

Bases de Datos Transacciones

Atomicidad (cont.)
En el ejemplo anterior nos gustar que las operaciones se a ejecutaran todas o que ninguna de ellas se ejecutara. La ejecucin de una operacin es atmica si el estado de la BD o o o luego de la operacin es como si todos sus componentes se o hubiesen ejecutado o como si ninguno de ellos lo hubiese hecho.

Bases de Datos Transacciones

Transacciones
Los problemas de serializacin y atomicidad pueden ser resueltos o usando transacciones. Una transaccin est compuesta por un grupo de instrucciones de o a SQL que se ejecutan atmicamente (se ejecutan todas o ninguna). o Por defecto adems, una transaccin exige ejecuciones a o serializables. En SQL2 se puede especicar ms libertad en la ejecucin que a o simplemente serializable, esto se hace modicando los niveles de aislamiento que veremos ms adelante. a

Bases de Datos Transacciones

10

Transacciones (cont.)
Una transaccin se comienza con una instruccin o o begin transaction (no es necesario en algunos DBMS). La instruccin commit termina la transaccin en forma exitosa y o o hace permanente cualquier cambio realizado a la BD durante la transaccin. o Los cambios se hacen permanentes slo despus de un commit. o e La instruccin rollback aborta la transaccin y la hace terminar o o en forma no exitosa, cualquier cambio que la transaccin pudo o hacer a la BD se deshace. En general se puede hacer rollback para cualquier conjunto de instrucciones no necesariamente dentro de una transaccin. o

Bases de Datos Transacciones

11

Transacciones Ejemplo
Para el ejemplo de transferencia de fondos: 1. begin transaction 2. Si A1 no tiene suciente dinero rollback. 3. Se aumenta el saldo de A2 en el monto especicado. 4. Se disminuye el saldo de A1 en el monto especicado. 5. commit.

Bases de Datos Transacciones

12

Transacciones Abortadas
Una transaccin puede no llegar a su trmino debido a muchas razones: o e situacin 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 elctrica a e control de concurrencia ha detectado un conicto control de concurrencia ha detectado un deadlock

Bases de Datos Transacciones

13

Transacciones (cont.)
SQL2 permite denir distintos tipos de transacciones. Cada uno de ellos dene las posibilidades de accesos y enmallado de instrucciones que se pueden dar durante la ejecucin 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.

Bases de Datos Transacciones

14

Niveles de Aislamiento Ejemplo

Supongamos una base de datos con una relacin 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 slo Cristal a $450 y o Escudo a $400. Juan quiere preguntar por la cerveza ms cara y ms barata del a a bar de Pepe. Al mismo tiempo Pepe elimina a Cirstal y Escudo y comienza a vender slo Kunstmann en $500. o

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.

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 ms. a Una posible ejecucin podr ser la siguiente: o a Juan: Pepe: (max) (del) (ins) (min)

Juan lee como mximo el precio de Cristal que es $450 y a nalmente lee como precio m nimo el precio de Kunstmann que es $500... el mximo es menor que el m a nimo!!!!

Bases de Datos Transacciones

17

Nivel Serializable
Si Juan ejecuta sus instrucciones en una transaccin con nivel de o aislamiento serializable entonces ver la base de datos antes o a despus de la ejecucin de las instrucciones de Pepe pero nunca e o en el medio. Depende del DBMS cmo 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 eleccin de nivel serializable afecta slo 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 transaccin de Pepe. o

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 transaccin despus del (ins) pero antes del o e rollback se tiene Juan: Pepe: (del) (ins) (max) (min) rollback

Entonces Juan leer el dato $500 como precio mximo 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: transaccin T1 actualiza datos que T2 lee, luego o T1 se aborta T2 ha le datos inexistentes. do

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 transaccin slo podr leer datos que han sido o o a rearmados por el commit de otra transaccin. 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 ms permisivo que el serializable a de hecho en la ejecucin o Juan: Pepe: (max) (del) (ins) (min)

es totalmente factible en read commited siempre que Pepe haga commit, y Juan ver que el mximo es $450 y que el m a a nimo es $500.

Bases de Datos Transacciones

20

Nivel Repeatable Read

Este nivel evita lo que se conoce como lectura no repetible. Lectura No Repetible: transaccin T1 lee los mismo datos dos o veces, entre ambas lecturas una transaccin 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 restriccin de que en una transaccin, 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 ms datos que la a primera pero nunca se pueden perder datos.

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: Pepe: (max) (del) (ins) (min)

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 sern consistentes en la lectura para Juan a (comparados con read commited) ya que ver que el mximo a a precio es $450 y el m nimo es $400, a pesar de que esto no reeje el estado real de la base de datos luego de las transacciones.

Bases de Datos Transacciones

22

Nivel Repeatable Read (cont.)

Este nivel sigue siendo ms permisivo que serializable. a Supongamos que Juan intenta leer dos veces el precio mximo de a las cervezas y en el intertanto Pepe actualiza los precios Juan: Pepe: (max) (del) (ins) (max)

Si ejecuta en repeatable read se asegur que todo lo que lee en el primer (max) lo lee tambin en el segundo (max), sin embargo e en un caso obtiene que el mximo es $450 y luego $500, esto se a conoce como valor fantasma. Fantasmas: T1 lee datos que cumplen cierta condicin, T2 inserta o un dato que cumple la condicin, si T1 vuelve a leer o encontrar una nueva tupla fantasma. a

Bases de Datos Transacciones

23

Nivel Read Uncommited

Es el nivel ms permisivo. a Una transaccin que se ejecuta con nivel read uncommited o puede ver valores que otra transaccin ha escrito, o dejar de ver o valores que otra transaccin 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 mximo o m a nimo a pesar que Pepe posteriormente a la insercin aborte los cambios (rollback). o read uncommited permite entonces lecturas sucias, lecturas no repetibles y lecturas fantasmas.

Bases de Datos Transacciones

24

Niveles de Aislamiento
Podemos nalmente denir 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 serializable repeatable read read commited read uncommited Sucia NO NO NO SI No Repetible NO NO SI SI Fantasma NO SI SI SI

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 conictos son escasos permitir acceso concurrente y deshacer las acciones problemticas. a Pesimista: asume que es muy probable que ocurran problemas acta a la defensiva impidiendo la aparicin de conictos u o usando locks.

Bases de Datos Transacciones

26

Ms sobre Locks a
Un lock es una estructura que slo puede ser adquirida por una o hebra de ejecucin (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. Adems de los locks exclusivos existen locks de slo lectura o a o locks compartidos que pueden estar simultneamente siendo a utilizados por distintas ejecuciones.

Bases de Datos Transacciones

27

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

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 Slo el primer update se hace efectivo en la BD. o

Bases de Datos Transacciones

29

Transacciones en SQLServer (cont.)

SQLServer soporta todos los niveles de aislamiento denidos para SQL2. Antes de comenzar una transaccin 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