Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Transacciones 2
Transacciones 2
Manejo de Transacciones
Jorge Prez Rojas e Universidad de Talca, II Semestre 2006
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
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.
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.
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
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.
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).
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.
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
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
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.
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
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.
14
15
16
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!!!!
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
18
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
19
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.
20
21
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.
22
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
23
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
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.
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.
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.
28
29