Transacciones

Transacciones
Alumnos:
Jesús Hernández CI:18.020.681
José De Abreu CI: 18 855 500
Agenda
1 Concepto de Transacción
1.1 Consistencia y Aislamiento
1.2 Atomicidad y Durabilidad
2 Transacciones y Planificadores (Schedules)
3 Ejecución concurrente de transacciones
3.1 Motivos para la ejecución concurrente
3.2 Seriabilidad
3.3 Anomalías de ejecución
3.4 Planificación Invocando a transacciones Abortadas
4 Cerraduras (Locks)
4.1 2PL
4.2 Dead-Locks
4.3 Deteccion
4.4 Prevención
4.5 Gestor
4.6 Tablas
1
Transacciones
Concepto
Una transacción es una ejecución de un programa de
usuario, visto por el DBMS como una serie de operaciones
lecturas y escrituras, la cual accede a la base de datos que es
compartida por varios usuarios en forma simultánea. Es una
colección de acciones que hacen transformaciones de los
estados de un sistema preservando la consistencia del mismo.
Una base de datos está en un estado consistente si
obedece todas las restricciones de integridad definidas sobre
ella. Los cambios de estado ocurren debido a actualizaciones,
inserciones, y supresiones de información. Por supuesto, se
quiere asegurar que la base de datos nunca entra en un estado
de inconsistencia. Sin embargo, durante la ejecución de una
transacción, la base de datos puede estar temporalmente en un
estado inconsistente. El punto importante aquí es asegurar que
la base de datos regresa a un estado consistente al fin de la
ejecución de una transacción.
Transacciones
Concepto
Lo que se persigue con el uso de transacciones es por un lado
contar con una transparencia adecuada de las acciones concurrentes a
una base de datos y por el otro tener una transparencia adecuada en el
manejo de las fallas que se pueden presentar en una base de datos.
2
1.1 Consistencia y Aislamiento
Consistencia: Una transacción es un programa
correcto que lleva la base de datos de un estado consistente
a otro con la misma característica. Gracias a esto, las
transacciones no violan las reglas de integridad de una base
de datos.
Aislamiento: Una transacción en ejecución no puede
revelar sus resultados a otras transacciones concurrentes
antes de su commit. Más aún, si varias transacciones se
ejecutan concurrentemente, los resultados deben ser los
mismos que si ellas se hubieran ejecutado de manera
secuencial (seriabilidad). La seriabilidad consiste en
asegurarse que los cambios siguen un orden adecuado.
1.2 Atomicidad y Durabilidad
Atomicidad: Una transacción es tratada como una
unidad de operación. Por lo tanto todas las acciones de la
transacción se llevan a cabo o ninguna de ellas se realiza
.La atomicidad requiere que si una transacción se
interrumpe por una falla, sus resultados parciales deben ser
deshechos. Se efectúan todas las transacciones, pero en
caso de fallas no se realiza ninguna. Una transacción debe
concluir comprometida o abortada. En el caso del
compromiso se instalan todas las actualizaciones y en el
aborto se descartan todas las actualizaciones.
Durabilidad: Es la propiedad de las transacciones
que asegura que una vez que una transacción realiza su
commit, sus resultados son permanentes y no pueden ser
borrados de la base de datos, se asegura que los resultados
de una transacción sobrevivirán a fallas del sistema.
3
2 Transacciones y Planificadores
Hasta ahora conocemos que una transacción es vista
por el DBMS como una serie, o lista, de acciones las cuales
ejecutan operaciones de lectura y escritura en elementos de
la Base de Datos. También sabemos que una transacción
debe especificar su acción de finalización como commit
(Finalizó exitosamente) o abort (finalizó pero deshizo todas
las acciones llevadas a cabo).
Ahora, una planificación, es una lista de acciones
(lecturas, escrituras, abortos o commit) de un conjunto de
transacciones, y el orden que el cual dos acciones de una
transacción T aparecen en una Planificación debe ser el
mismo orden en el cual aparecen en T. En otras palabras
una Planificación representa una secuencia de ejecución
actual o potencial el cual describe las acciones de las
transacciones así como son vistas por el DBMS.
2 Transacciones y Planificadores
T1
T2
R(A)
W(A)
R(B)
W(B)
Commit
R(C)
W(C)
Una Planificación completa es aquella
que contiene todas las acciones de cada
transacción que aparecen en el.
Si las acciones de diferentes
transacciones no están entrelazadas (las acciones
son ejecutadas de inicio a fin, una por una) la
llamamos una Planificación Serial o Secuencial
Commit
4
3 Ejecución concurrente de
transacciones
Conociendo ahora el concepto de planificación
podemos describir las ejecuciones entrelazadas o
interleaved de transacciones.
El DBMS entrelaza las acciones de diferentes
transacciones para mejor el funcionamiento, en términos de
aumentar el promedio de transacciones completadas en un
tiempo determinado o mejorar los tiempos de respuestas de
las transacciones cortas.
3.1 Motivos para la ejecución
concurrente
Ejecución entrelazada de dos transacciones
T1
T2
R(A)
W(A)
R(B)
W(B)
R(C)
W(C)
Asegurar el aislamiento de las transacciones mientras se permite la ejecución
concurrente es difícil, pero es necesario, hay que mejorar el rendimiento.
5
3.2 Seriabilidad
Una planificación, después de su ejecución debe dejar
la base de datos en un estado consistente. La planificación
debe ser, de alguna forma, equivalente a una planificación
en serie. A esta característica se le denomina seriabilidad.
Dicho de otra forma, la seriabilidad de una planificación
garantiza que la ejecución de esa planificación asegura la
consistencia de la base de datos.
3.3 Anomalías de ejecución
Lectura “sucia”(Planificaciones
recuperables)
Ocurre cuando una transacción modifica una
fila y la segunda transacción lee esa fila antes
de que la primera transacción comprometa el
cambio (termine). Si la primera transacción
retrocede y deshace el cambio, la información
leída por la segunda transacción se vuelve
incorrecta.
6
3.3 Anomalías de ejecución
Lectura no repetible
Ocurren cuando una transacción lee una fila
y una segunda transacción modifica esa fila.
Si la segunda transacción comete ese
cambio, las siguientes lecturas de la primera
transacción producen resultados diferentes
al de la primera lectura.
3.3 Anomalías de ejecución
Problema de la modificación perdida
Surge cuando 2 transacciones o más
acceden a la misma fila y modifican su valor
basándose en el valor original de la misma.
Como cada transacción ignora el resto de las
transacciones, la última modificación
sobrescribe las modificaciones realizadas
por las otras transacciones..
7
3.3 Anomalías de ejecución
Lectura fantasma
Se produce cuando una transacción lee
un conjunto de filas que satisfacen una
condición de búsqueda y después, una
segunda modifica los datos (por medio de
una sentencia insert, update o delete). Si la
primera transacción repite la lectura con las
mismas condiciones de búsqueda, obtiene
un conjunto diferente de filas.
3.4 Planificación Invocando a
transacciones Abortadas
Una transacción siempre termina, aun en la presencia
de fallas. Si una transacción termina de manera exitosa
se dice que la transacción hace un compromiso. Si la
transacción se detiene sin terminar su tarea, se dice que
la transacción aborta.
Cuando la transacción es abortada, puede ser por
distintas razones relacionadas con la naturaleza de la
transacción misma, o por conflicto con otras
transacciones o por fallo de un proceso o computador,
entonces su ejecución es detenida y todas las acciones
ejecutadas hasta el momento son deshechas regresando
a la base de datos al estado antes de su ejecución. A
esta operación también se la conoce como rollback.
8
4. Protocolos basados en
candados
(LOCKS)‫‏‬
Un candado es un mecanismo de control de acceso
concurrente a un dato
Los datos pueden tener candados en dos modos:
• Modo exclusivo (X). El dato puede ser leído y escrito. Un
candado en este modo se solicita con la instrucción lock-X
• Modo compartido (S). El dato solo puede ser leído. Un
candado en este modo se solicita con la instrucción lock-S.
Las peticiones por candados se hacen al manager de
control de concurrencia. La transacción puede
proceder solo después de que una solicitud es
otorgada.
4. Protocolos basados en
candados
(LOCKS)‫‏‬
Un candado es un mecanismo de control de acceso
concurrente a un dato
Los datos pueden tener candados en dos modos:
• Modo exclusivo (X). El dato puede ser leído y escrito. Un
candado en este modo se solicita con la instrucción lock-X
• Modo compartido (S). El dato solo puede ser leído. Un
candado en este modo se solicita con la instrucción lock-S.
Las peticiones por candados se hacen al manager de
control de concurrencia. La transacción puede
proceder solo después de que una solicitud es
otorgada.
9
4. Protocolos basados en
candados
(LOCKS)‫‏‬
Un candado es un mecanismo de control de acceso
concurrente a un dato
Los datos pueden tener candados en dos modos:
• Modo exclusivo (X). El dato puede ser leído y escrito. Un
candado en este modo se solicita con la instrucción lock-X
• Modo compartido (S). El dato solo puede ser leído. Un
candado en este modo se solicita con la instrucción lock-S.
Las peticiones por candados se hacen al manager de
control de concurrencia. La transacción puede
proceder solo después de que una solicitud es
otorgada.
4. Protocolos basados en
candados
(LOCKS)‫‏‬
Un candado es otorgado si
el candado solicitado es
compatible con otros
candados previamente
otorgados
Se pueden tener varios
candados compartidos sobre
un dato, pero sólo un
candado exclusivo
Si un candado no puede ser
concedido, la transacción
que lo solicita debe esperar
a que todos los candados
incompatibles sean liberados
Compartid
o
Exclusivo
Compartid
o
Exclusivo
verdadero
falso
falso
falso
Matriz de compatibilidad de
candados
10
4. Protocolos basados en
candados
(LOCKS)‫‏‬
El poner candados no es
suficiente para garantizar
seriabilidad
Ejemplo: si A se actualiza
después de la lectura de B,
la suma será incorrecta
Un protocolo basado en
candados es un conjunto de
reglas seguidas por todas
las transacciones para
solicitar y liberar candados
T2
lock-S(A);
read (A);
unlock(A);
lock-S(B);
read (B);
unlock(B);
display(A+B)‫‏‬
4.1 Protocolos de candados en 2
fases
(2PL)‫‏‬
Asegura planes serializables
Fase 1: Crecimiento
• Una transacción puede
solicitar/obtener candados
• Una transacción no puede liberar
candados
Fase 2: Encogimiento
• Una transacción puede liberar
candados
• Una transacción no puede obtener
candados
11
4.1 Protocolos de candados en 2
fases
(2PL)‫‏‬
Protocolo de candado en dos fases (2PL):
La importancia de los candados de dos fases es que se ha demostrado de
manera teórica que todos los planificadores generados por algoritmos de
control de concurrencia que obedecen a los candados de dos fases son
serializables.
Abortos en Cascada: Puede suceder si una transacción aborta después de
liberar un candado, otras transacciones que hayan accedido el mismo
elemento de datos aborten también.
Para evitar lo anterior, los despachadores para candados de dos fases
implementan lo que se conoce como los candados estrictos de dos fases
en los cuales se liberan todos los candados cuando la transacción termina
4.2 Problemas de los protocolos
basados en candados: Bloqueo
mutuo (Dead-Lock)‫‏‬
Bloqueo mutuo: dos
transacciones esperan
mutuamente a que la otra
libere un candado
Prevención: una transacción
pone un candado a todos los
datos a los que se refiere
antes de comenzar su
ejecución
Evitar: si una transacción
intenta crear un ciclo,
entonces se echa para atrás
(roll back) esa transacción
T3
T4
lock-X (B)‫‏‬
read (B)‫‏‬
B := B – 50
write (B)
lock-S (A)‫‏‬
read (A)‫‏‬
lock-S (B)‫‏‬
lock-X (A)‫‏‬
12
4.3 Prevención de Bloqueos
Mutuos
Asignar priorodades basadas en marcas de tiempo/espera:
Asumimos que Ti quiere un candado que Tj mantiene cerrado.
Dos politicas son posibles:
esperar-morir: Si Ti tiene prioridad mas alta, Ti espera por Tj;
de otra manera Ti se cancela.
herir-esperar: si Ti tiene prioridad mas alta, Tj se cancela;
de otra manera Ti espera.
Si una transaccion se reinicia, asgurarse de que este posee
su marca de tiempo/espera original.
4.3 Prevención de Bloqueos
Mutuos
Asignar priorodades basadas en marcas de tiempo/espera:
Caracterizticas
-Asegura secuenciabilidad según conflictos
-Asegura que no hay bloqueos (interbloqueos) mortales –deadlocks–
-se puede dar reinicio cíclico (inanición)‫‏‬
-Genera retrocesos en cascada.
13
4.4 Detección de Bloqueos
Mutuos
Los Deadlocks pueden ser descritos como un grafo de espera, que
consiste en un par G = (V,E),
V son los vertices (todas las transacciones en el sistema)
E son los arcos; cada elemento es un par ordenado Ti →Tj.
Problemas de los protocolos
basados en candados: Bloqueo
mutuo (Dead-Lock)‫‏‬
El potencial para el dead-lock existe en la mayoría de los protocolos de fijación. Los
dead-lock son un mal necesario. La espera concurrente (inanición) es tambien
posible si se diseña mal las concurrencias.
Por ejemplo: Una transacción puede esperar un X-lock, mientras que una
secuencia de otras transacciones solicita y se concede una S-lock en el mismo
artículo. La misma transacción es en varias ocasiones rodada atrás (roll back)
debido a los dead-locks.
T1
lock-S(A)
T2
lock-X(A)
wait
T3
T4
T5
lock-S(A)
lock-S(A)
lock-S(A)
14
4.5 Gestor de Cerraduras
Un gestor de cerradura puede ser puesto en ejecución como
proceso separado a el cual las transacciones envíen la cerradura
y abran peticiones
El gestor responde a las solicitudes de bloqueo enviando
mensajes de permiso de bloqueo (o un mensaje pidiendo a la
transaccion que se devuelva en caso de bloqueo muerto)
La transacción espera hasta que se contesta su petición
El encargado de la cerradura mantiene una estructura de
datos llamada “ tabla de la cerradura” para registrar cerraduras
concedidas y peticiones
4.6 Tabla De Bloqueo
−
−
−
−
Los rectangulos negros indican
los bloqueos o cerraduras
concedidas
Los rectangulos blancos
representan peticiones en
espera
Las nuevas peticiones son
eviadas al final de la lista y son
concedidas solo si son
compatible con las anteriores.
Si la transaccion aborta todas la
demas peticiones son
automaticamente eliminadas
15
Tecnicas de cerraduras
Especializadas
Lecturas fantasma
Una transacción vuelve a ejecutar una consulta, devolviendo un
conjunto de filas que satisfacen una condición de búsqueda y
encuentra que otras filas que satisfacen la condición que han sido
insertadas por otra transacción cursada.
Control de Concurrencia sin
locking
Control de concurrencia optimista
Los algoritmos de control de concurrencia discutidos antes son por naturaleza
pesimistas. En otras palabras, ellos asumen que los conflictos entre
transacciones son muy frecuentes y no permiten el acceso a un dato si existe
una transacción conflictiva que acceda al mismo dato.
Así, la ejecución de cualquier operación de una transacción sigue la secuencia
de fases: validación (V), lectura (R), cómputo (C) y escritura (W).
Los algoritmos optimistas, por otra parte, retrasan la fase de validación justo
antes de la fase de escritura. De esta manera, una operación sometida a un
despachador optimista nunca es retrasada.
16
Gestion de transacciones en
SQL:2003
Las sentencias del estandar SQL:2003 que nos permiten trabajar con
transacciones son las siguientes:
START TRANSACTION: Marca el inicio de una transaccion. Permite
establecer el nivel aislamiento con
que se debe ejecutar la transaccion y su modo de acceso (solo
lectura o lectura/escritura).
COMMIT: Valida los cambios realizados (sobre la base de datos) por
la transaccion actual y finaliza la transaccion.
ROLLBACK: Deshace todos los cambios realizados por la
transaccion actual y finaliza la transaccion.
SAVEPOINT: Crea una marca dentro de la transaccion actual.
Gestion de transacciones en
SQL:2003
ROLLBACK TO SAVEPOINT: Deshace los cambios realizados a
partir de la marca, borrando las marcas que se hayan hecho por
detras de ella.
RELEASE SAVEPOINT: Elimina una marca creada previamente
dentro de la transaccion actual.
SET TRANSACTION: Permite establecer el nivel de aislamiento de
una transaccion y su modo de acceso.
17
Gestion de transacciones en
SQL:2003
A continuacion se muestra la sintaxis de las sentencias que permiten
establecer el nivel de aislamiento y el modo de acceso de la
transaccion:
START TRANSACTION [ ISOLATION LEVEL nivel ] [ READ ONLY |
READ WRITE ]
SET TRANSACTION [ ISOLATION LEVEL nivel ] [ READ ONLY |
READ WRITE ]
donde nivel puede ser SERIALIZABLE, REPETEABLE READ, READ
COMMITTED o READ UNCOMMITTED.
Gestion de transacciones en
PostgreSQL
La version 7de PostgreSQL proporciona las sentencias del estandar :
START TRANSACTION, SET TRANSACTION, COMMIT y
ROLLBACK.
La version 8 incorpora, ademas, la posibilidad de trabajar con marcas
mediante las sentencias:
SAVEPOINT, ROLLBACK TO SAVEPOINT y RELEASE
SAVEPOINT.
Si no se especifica el inicio de una transaccion, PostgreSQL trata
cada sentencia SQL como una transaccion.
18
Gestion de transacciones en
ORACLE
Oracle proporciona todas las sentencias del estandar para manejo de
transacciones excepto START TRANSACTION y RELEASE
SAVEPOINT.
Una vez finalizada una transaccion, la siguiente sentencia SQL
ejecutada inicia una nueva transaccion, que deber´a ser finalizada
de manera explıcita mediante COMMIT o ROLLBACK.
Gestion de transacciones en
Aislamiento
Nivel de aislamiento
SERIALIZABLE
REPETEABLE READ
READ COMMITTED
READ UNCOMMITTED
lectura sucia lectura irrepetible lectura fantasma
no
no
no
puede
no
no
puede
puede
no
puede
puede
puede
En el unico nivel en que no puede producirse ninguna de ellas es en
el SERIALIZABLE.
19
GRACIAS!!...
20