Bases de Datos Transacciones

Manejo de Transacciones
Jorge P erez Rojas Universidad de Talca, II Semestre 2006

Bases de Datos Transacciones

Transacciones
Hasta ahora el modelo de operaci on en la BD ha sido o de 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 operaci on. La vida real es much simo m as compleja...

Bases de Datos Transacciones

Transacciones (cont.)
No s olo el hardware o el software pueden fallar dejando a la BD en un estado inexplicable a partir de operaciones. El sistema de base de datos normalmente est a siendo accedido 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

Serializaci on
Supongamos que en una aplicaci on de reserva de pasajes para un vuelo existe un procedimiento que: busca un asiento libre lo marca como ocupado asigna el asiento al pasajero que ejecut o la llamada Es totalmente posible que al mismo tiempo dos pasajeros ejecuten el procedimiento simult aneamente y dejen la BD en un estado indeseable.

Bases de Datos Transacciones

Serializaci on (cont.)
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

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

Bases de Datos Transacciones

Atomicidad
Supongamos que tenemos una aplicaci on bancaria y un 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 a que las operaciones se ejecutaran todas o que ninguna de ellas se ejecutara. La ejecuci on de una operaci on es at omica si el estado de la BD luego de la operaci on es como si todos sus componentes se hubiesen ejecutado o como si ninguno de ellos lo hubiese hecho.

Bases de Datos Transacciones

Transacciones
Los problemas de serializaci on y atomicidad pueden ser resueltos usando transacciones. Una transacci on est a compuesta por un grupo de instrucciones de SQL que se ejecutan at omicamente (se ejecutan todas o ninguna). Por defecto adem as, una transacci on exige ejecuciones serializables. En SQL2 se puede especicar m as libertad en la ejecuci on que simplemente serializable, esto se hace modicando los niveles de aislamiento que veremos m as adelante.

Bases de Datos Transacciones

10

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

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 transacci on puede no llegar a su t ermino debido a muchas razones: situaci on excepcional detectada que hace que el programa no pueda continuar falla del programa falla del software de BD falla del Sistema Operativo falla del hardware falla de energ a el ectrica 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 ejecuci on de 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 relaci on con esquema 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 olo Cristal a $450 y Escudo a $400. Juan quiere preguntar por la cerveza m as cara y m as barata del bar de Pepe. Al mismo tiempo Pepe elimina a Cirstal y Escudo y comienza a vender s olo Kunstmann en $500.

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 u nico que podemos asegurar con certeza es que (max) se ejecuta antes de (min), y que (del) se ejecuta antes de (ins), pero nada m as. Una posible ejecuci on podr a ser la siguiente: Juan: Pepe: (max) (del) (ins) (min)

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

Bases de Datos Transacciones

17

Nivel Serializable
Si Juan ejecuta sus instrucciones en una transacci on con nivel de aislamiento serializable entonces ver a la base de datos antes o despu es de la ejecuci on de las instrucciones de Pepe pero nunca en el medio. Depende del DBMS c omo asegura esto, lo u nico que interesa es 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 on de nivel serializable afecta s olo a quien la elige... por ejemplo, si Pepe ejecuta con nivel serializable pero Juan no, Juan perfectamente podr a ver los datos como si ejecutara en la mitad de la transacci on de Pepe.

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 on despu es del (ins) pero antes del rollback se tiene Juan: Pepe: (del) (ins) (max) (min) rollback

Entonces Juan leer a el dato $500 como precio m aximo y m nimo, sin embargo $500 es un dato que nunca existir a realmente en la base de datos, a esto se le llama Lectura Sucia. Lectura Sucia: transacci on T1 actualiza datos que T2 lee, luego T1 se aborta T2 ha le do datos inexistentes.

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 on s olo podr a leer datos que han sido rearmados por el commit de otra transacci on. 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 as permisivo que el serializable de hecho en la ejecuci on Juan: Pepe: (max) (del) (ins) (min)

es totalmente factible en read commited siempre que Pepe haga commit, y Juan ver a que el m aximo es $450 y que el m 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: transacci on T1 lee los mismo datos dos veces, entre ambas lecturas una transacci on T2 elimina algunos 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 on de que en una transacci on, todo lo que se vio en una lectura inicial debe ser visto si se ejecuta la misma lectura posteriormente. La segunda y siguientes lecturas pueden tener m as datos que la 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 o los valores $400 y $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 an consistentes en la lectura para Juan (comparados con read commited) ya que ver a que el m aximo 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 m as permisivo que serializable. Supongamos que Juan intenta leer dos veces el precio m aximo de 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 tambi en en el segundo (max), sin embargo en un caso obtiene que el m aximo es $450 y luego $500, esto se conoce como valor fantasma. Fantasmas: T1 lee datos que cumplen cierta condici on, T2 inserta un dato que cumple la condici on, si T1 vuelve a leer encontrar a una nueva tupla fantasma.

Bases de Datos Transacciones

23

Nivel Read Uncommited

Es el nivel m as permisivo. Una transacci on que se ejecuta con nivel read uncommited puede ver valores que otra transacci on ha escrito, o dejar de ver valores que otra transacci on haya borrado, a pesar de que esta no haya hecho commit y posiblemente nunca lo haga. Por ejemplo Juan podr a perfectamente ver el valor $500 como precio m aximo o m nimo a pesar que Pepe posteriormente a la inserci on aborte los cambios (rollback). 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 problem aticas. Pesimista: asume que es muy probable que ocurran problemas act ua a la defensiva impidiendo la aparici on de conictos usando locks.

Bases de Datos Transacciones

26

M as sobre Locks
Un lock es una estructura que s olo puede ser adquirida por una hebra de ejecuci on (thread ) a la vez. Si dos ejecuciones tratan de obtener un lock para actualizar una tabla, la primera que trate de obtenerlo tendr a acceso exclusivo 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 as de los locks exclusivos existen locks de s olo lectura o locks compartidos que pueden estar simult aneamente siendo utilizados por distintas ejecuciones.

Bases de Datos Transacciones

27

Transacciones en SQLServer
En SQLServer se puede nombrar a una transacci on para luego persistirla, deshacerla completa, o deshacer parte de ella. Para permitir deshacer parte de una transacci on se usan save points. begin transaction <tran>: comienza la transacci on <tran>. save transaction <savp>: especica un save point de nombre <savp> interno a una transacci on. rollback transaction <tran>: deshace los cambios realizados desde un save point, o dentro de una transacci on, de nombre <tran>. commit transaction <tran>: persiste los cambios en la transacci on <tran> que no hayan sido deshechos por alg un 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 S olo el primer update se hace efectivo en la BD.

Bases de Datos Transacciones

29

Transacciones en SQLServer (cont.)

SQLServer soporta todos los niveles de aislamiento denidos para SQL2. Antes de comenzar una transacci on se debe usar: set transaction isolation level serializable set transaction isolation level repeatable read set transaction isolation level read commited set transaction isolation level read uncommited