1. Una transacción es un programa que se ejecuta como una sola operación para conservar la integridad de la base de datos. 2. El manejo de transacciones controla múltiples transacciones ejecutando de forma paralela sobre una misma base de datos. 3. Las propiedades clave de las transacciones son atomicidad, consistencia, aislamiento y durabilidad.

1. Investigación
LAS TRANSACCIONES DE UNA B.D.
BASE DE DATOS
DR. CARLOS A. TORRES GASTELU
RINCÓN OCHOA LEYDI DIANA
JORGE MENGELLE CASTRO

2. TRANSACCIONES 10/10/2011
Manejo de transacciones. ........................................................................................................... 4
Gestor de transacciones .............................................................................................................. 4
Manejo de Transacciones............................................................................................................ 5
Estados de una transacción ............................................................................................................. 6
Implementación de la atomicidad y la durabilidad ......................................................................... 7
Ejecuciones concurrentes ............................................................................................................... 7
Planificaciones ................................................................................................................................. 8
Secuencialidad................................................................................................................................. 8
RECUPERABILIDAD .......................................................................................................................... 9
IMPLEMENTACION DE AISLAMIENTO ........................................................................................... 10
Procesamiento de Transacciones SGBD. ................................................................................... 10
Gestión de Concurrencia. .......................................................................................................... 10
Procedimientos de recuperación. ............................................................................................ 10
Inicio de transacciones .............................................................................................................. 11
Incorporación del manejador de transacciones a la arquitectura de un SMBD ....................... 19
2

3. TRANSACCIONES 10/10/2011
Introducción
Esta es una investigación sobre las transacciones que ocurren en una base de datos,
para su mejor funcionamiento en una base de datos. Una transacción es programa que
se ejecuta como una sola operación la cual se encarga de conservar la integridad de la
base de datos. El manejo de transacciones consiste en controlar múltiples
transacciones ejecutando el paralelo sobre una misma base de datos corriendo en un
sistema que puede fallar. Las transacciones son de gran utilidad en una base de datos
por lo que veremos más adelante y con más claridad el uso que se les da dentro de
una de las B.D.
3

4. TRANSACCIONES 10/10/2011
Manejo de transacciones.
1
Una transacción es un
programa que se ejecuta
como una sola operación.
Esto quiere decir que
luego de una ejecución en
la que se produce una falla
es el mismo que se
obtendría si el programa
no se hubiera ejecutado.
Los SGBD proveen
mecanismos para
programar las modificaciones de los datos de una forma mucho más simple que si
no se dispusiera de ellos.
Gestor de transacciones
Se encarga de conservar la integridad de la base de datos.
Una transacción es una colección de operaciones que realizan una única función
lógica sobre la base de datos.
*el gestor de transacciones asegura que la base de datos permanecerá en un
estado consistente (correcto) a pesar de fallos en el sistema o de fallos en las
transacciones.
*también controla la interacción entre transacciones concurrentes, para asegurar
la consistencia de la base de datos.
1
http://www.oocities.org/mx/analvaca/bdd/man_trans.htm
4

5. TRANSACCIONES 10/10/2011
Manejo de Transacciones
2
Una de las áreas principales de aplicación de los sgbd's es lo que se llama
procesamiento de transacciones. Una transacción es un programa de aplicación,
generalmente de duración breve, que accede y actualiza una parte también
generalmente pequeña de la base de datos. Típicos ejemplos son un depósito o
extracción de una cuenta bancaria, o una reservación en un vuelo, o una
verificación de una tarjeta de crédito.
El manejo de transacciones consiste en controlar múltiples transacciones
ejecutando el paralelo sobre una misma base de datos corriendo en un sistema
que puede fallar. Los objetivos del gestor de transacciones del sgbd son: evitar
que las transacciones interfieran unas con otras al ejecutar en paralelo, y
garantizar que la base de datos no sea dañada en forma irreparable por caídas, ya
sea del sistema en sí o de alguna de las transacciones. El primero de los objetivos
da lugar a lo que se llama control de paralelismo; el segundo, a técnicas de
recuperación.
Una transacción es una unidad de la ejecución de un programa que accede y
posiblemente actualiza varios elementos de datos y está delimitada por
instrucciones de la forma inicio Transacción y fin transacción.
La transacción consiste en todas las operaciones que se ejecutan entre inicio
transacción y el fin transacción.
2
Modelo de una transacción
5

6. TRANSACCIONES 10/10/2011
Para asegurar la integridad de los datos se necesita que el sistema de la base de
datos mantenga las siguientes propiedades de las transacciones:
Atomicidad: O todas las operaciones de la transacción se realizan
adecuadamente en la base de datos o ninguna de ellas.
Consistencia: La ejecución aislada de la transacción (es decir, sin otra
transacción que se ejecute concurrentemente) conserva la consistencia de
la base de datos.
Aislamiento: Aunque se ejecuten varias transacciones concurrentemente,
el sistema garantiza que para cada par de transacciones Ti y Tj se cumple
que para los efectos de Ti, o bien Tj ha terminado su ejecución antes de
que comience Ti, o bien que Tj ha comenzado su ejecución después de
que Ti termine.
Durabilidad: Tras la finalización con éxito de una transacción, los cambios
realizados en la base de datos permanecen incluso si hay fallos en el
sistema.
Estados de una transacción
En ausencia de fallos todas las transacciones se completan con éxito. Sin
embargo una transacción puede que no siempre acabe su ejecución con éxito.
Una transacción de este tipo se denomina abortada. Una vez deshechos los
cambios efectuados por la transacción abortada, se dice que la transacción esta
retrocedida. Una transacción que termina con éxito se dice que está
comprometida.
Una transacción debe estar en uno de los siguientes estados:
Activa: Estado inicial, permanece en ese estado durante su ejecución.
Parcialmente comprometida: Después de ejecutarse la última
instrucción.
Fallida: Tras descubrir que no puede continuar la ejecución normal.
Abortada: Después del retroceso de la transacción y de haber
restablecido la Base de Datos a su estado anterior al comienzo de la
transacción.
Comprometida: Tras completarse con éxito.
Una transacción llega al estado fallida después de que el sistema determine que
dicha transacción no puede continuar su transacción normal.
En abortada el sistema debe decidir entre reiniciar la transacción o cancelarla.
6

7. TRANSACCIONES 10/10/2011
Implementación de la atomicidad y la durabilidad
El componente de gestión de recuperaciones de un sistema de base de datos
implementa el soporte para la atomicidad y la durabilidad.
Un primer esquema simple pero ineficiente es la copia en la sombra, en el cual
todos los cambios los realiza en una copia de la base de datos dejando la
original inalterada. La implementación depende de que escribir el puntero sea una
operación atómica. Es poco eficiente y exige mucha memoria ya que la ejecución
de una simple transacción requiere copiar la base de datos completa. No se
permiten con este sistema las transacciones concurrentes.
Ejecuciones concurrentes
Existen 2 razones para permitir la concurrencia:
Productividad y utilización de recursos mejorada: Se puede explotar el
paralelismo de la CPU y del sistema E/S para ejecutar varias transacciones en
paralelo. Esto incrementa la productividad y la utilización del procesador y del
disco aumenta también. Están menos tiempo sin hacer ningún trabajo útil.
Un tiempo de espera reducido: Si las transacciones operan en partes distintas
de la BD es mejor hacer que se ejecuten concurrentemente compartiendo los
ciclos de la CPU y los accesos a disco entre ambas. Además se reduce el tiempo
medio de respuesta que es el tiempo medio desde que empieza una transacción
hasta que se completa.
Cuando se ejecutan varias transacciones concurrentemente, la consistencia de la
base de datos se puede destruir a pesar de que cada transacción individual sea
correcta. El sistema de base de datos debe controlar la interacción entre las
transacciones concurrentes para evitar que se destruya la consistencia de la base
de datos. Esto se lleva a cabo a través de una serie de mecanismos denominados
esquemas de control de la concurrencia.
7

8. TRANSACCIONES 10/10/2011
Planificaciones
Representan el orden cronológico en el que se ejecutan las instrucciones en el
sistema
Planificación secuencial
Consiste en una secuencia de instrucciones de varias transacciones en la cual las
instruccionespertenecientes a una única transacción están juntas en dicha
planificación.
Es una tarea del sistema de Base de datos asegurar que cualquier planificación
que se ejecute lleve la Base de datos a un estado consistente.
El componente del sistema de base de datos que realiza esta tarea se denomina
componente de control de concurrencia. Se puede asegurar la consistencia de la
base de datos en una ejecución concurrente si se está seguro de que cualquier
planificación que se ejecute tiene el mismo efecto que otra que se hubiera
ejecutado sin concurrencia.
Secuencialidad
Secuencialidad en cuanto a conflictos
Dos instrucciones Ii e Ij pertenecen a transacciones Ti y Tj. Si las instrucciones se
refieren a elementos de datos distintos se pueden intercambiar sin ningún
problema, pero si se refieren al mismo elemento Q entonces el orden de los dos
pasos puede ser importante. Hay cuatro casos:
1. Ii = leer(Q) , Ij=leer(Q). El orden de Ii e Ij no importa. – No hay conflicto
2. Ii = leer(Q) , Ij=escribir(Q). El orden de Ii e Ijsi importa. – Hay conflicto
3. Ii = escribir(Q) , Ij=leer(Q). El orden de Ii e Ijsi importa. – Hay conflicto
4. Ii = escribir(Q) , Ij=Escribir(Q). El orden de Ii e Ijsi importa. – Hay conflicto
Si Ii e Ij no están en conflicto, se pueden cambiar el orden para obtener una nueva
planificación.
Si una planificación P se puede transformar en P’ por una serie de intercambios de
instrucciones no conflictivas, se dice que P y P’ son equivalentes en cuanto a
conflictos.
Una planificación es secuenciable en cuanto a conflictos si es equivalente en
cuanto a conflictos a una planificación secuencial. Se pueden encontrar dos
planificaciones que nos lleven al mismo resultado y en cambio no sean
equivalentes en cuanto a conflictos.
8

9. TRANSACCIONES 10/10/2011
Secuencialidad en cuanto a vistas
Es una forma de equivalencia menos rigurosa que la equivalencia en cuanto a
conflictos. Se basa únicamente en las operaciones leer y escribir de las
transacciones.
Dos planificaciones P y P’ son equivalentes en cuanto a vistas si cumplen:
1- Si Ti lee el valor inicial de Q en la planificación P, entonces Ti debe leer también
el valor inicial de Q en P’.
2- Si Ti ejecuta leer (Q) en P y el valor lo ha producido Tj, entonces en P’ la
transacción debe leer también el valor de Q que ha producido Tj.
3- Para todo elemento de datos Q, la transacción que realice la última operación
escribir (Q) en P, debe realizar la última operación escribir (Q) también en P’.
La planificación P es secuenciable en cuanto a vistas si es equivalente en cuanto
a vistas a una planificación secuencial. Toda planificación secuenciable en cuanto
a conflictos es
secuenciable en cuanto a vistas, pero existen algunas secuenciables en cuanto a
vistas que no lo son en cuanto a conflictos.
RECUPERABILIDAD
Si la transacción Ti falla, será necesario deshacer el efecto de dicha transacción
para asegurar la atomicidad de la misma. En un sistema que permita
concurrencias hay que asegurarse que también toda transacción Tj que dependa
de Ti se aborta también. Para ello es necesario imponer algunas restricciones a
las planificaciones.
Planificaciones recuperables
Una planificación recuperable es aquella en que para todo par de transacciones
Ti y Tj tales que Tj lee elementos que se han escrito previamente por Ti, la
operación comprometer de Ti debe aparecen antes que la de Tj .
Planificaciones sin cascada
Cuando una operación provoca una serie de retrocesos se conoce como
retroceso en cascada. Una planificación sin cascada es aquella que para todo par
de operaciones Ti y Tj tales que Tj lee un elemento de datos que ha escrito
previamente Ti, la operación comprometer de Ti aparece antes que la operación
de lectura Tj. Toda planificación sin cascada es también recuperable.
9

10. TRANSACCIONES 10/10/2011
IMPLEMENTACION DE AISLAMIENTO
El objetivo de los esquemas de control de concurrencia es proporcionar un
elevado grado de concurrencia, al mismo tiempo que aseguran que todas las
planificaciones que se generan son secuenciales en cuanto a conflictos o en
cuanto a vistas y son sin cascada.
Procesamiento de Transacciones SGBD.
Gestión de Concurrencia.
Procedimientos de recuperación.
Transacción Una transacción es una secuencia de operaciones llevadas a cabo
como una unidad lógica de trabajo simple. Debe cumplir cuatro propiedades:
• Atomicidad: debe ser una unidad atómica de trabajo (o se llevan a cabo todas
sus operaciones o no se realiza ninguna).
• Consistencia: al terminar, una transacción debe deja a la BBDD en un estado
consistente. Verificar la consistencia es responsabilidad del control semántico.
Asignar la consistencia es responsabilidad de los mecanismos de control de
concurrencia.
• Aislamiento: la modificaciones realizas por una transacción debe aislarse de las
posibles modificaciones de otras transacciones concurrentes. La transacción debe
ver los datos en un estado posterior a la modificación de otra transacción, pero en
estados intermedios.
• Durabilidad: una vez una transacción finaliza con éxito, sus efectos deben
hacerse permanentes en la BBDD, incluso en el caso de fallo del sistema. El
SGBD debe proporcionar los mecanismos que garanticen la integridad de las
transacciones.
Los programadores son responsables de establecer puntos que hagan cumplir la
consistencia lógica de los datos:
• Activa: esta normal, cuando se ejecuta su primera instrucción.
• Parcialmente cometido: tras ejecutar la última sentencia de la transacción.
• Fallado: no se puede proceder la ejecución normal.
10

11. TRANSACCIONES 10/10/2011
• Abortado: la transacción ha retrocedido y se restaurado la BBDD al estado en
que estaba antes de la transacción.
• Cometido: se ha cometido parcialmente y se garantiza que nunca se abortará.
Control de transacciones SQL soporta las transacciones de BBDD mediante dos
sentencias de procesamiento de transacciones SQL:
• COMMIT [WORK]: Señala el final con éxito de una transacción.
• ROLLBACK[WORK]: Señala el final sin éxito de una transacción, informa al
usuario que no se puede completar la transacción y que el SGBD debe retroceder
y deshacer los cambios.
Las aplicaciones controlan las transacciones cuando comienzan y cuando
terminan. El sistema de ver ser capaz de manejar correctamente los errores
producidos por una transacción que termina antes de completar todas sus
operaciones.
Inicio de transacciones
Tipos:
• Transacciones explícitas: comienzan explícitamente con la sentencia BEGIN
TRANSACTION.
• Autoconfirmación (AUTOCOMMIT): Cada sentencia SQL es “cometida” cuando
termina. No se muestran sentencias adicionales para el control de la transacción.
• Implícitas: la siguiente sentencia comienzaautomáticamente una nueva
transacción. Cuando una transacción termina la siguiente sentencia SQL
comienza una transacción. Finalización de las transacciones Mediante una
sentencia COMMIT o ROLLBACK.
Modelos de transacción Modelo ANSI/ISO Especifica una lenguaje SQL
programado (embebido) para utilizarlo en programas de aplicación. Éste estándar
especifica que una transacción SQL comienza automáticamente con la primera
sentencia SQL (transacciones implícitas).
Latransacción continúa con las sentencias SQL subsiguientes que se finaliza uno
de los siguientes modos posibles:
• Sentencia COMMIT (tras ella comienza una nueva transacción).
11

12. TRANSACCIONES 10/10/2011
• Sentenica ROLLBACK (tras ella comienza una nueva transacción).
• Finalización de un programa con éxito (que equivale a ejecutar COMMIT)
• Finalización anormal del programa (equivale a ROLLBACK).
Bajo este modelo el usuario o programa está siempre en una transacción. Modelo
multiusuario Ante múltiples accesos concurrentes, el SGBD no sólo tiene de
ocuparse de recuperarse rodenamente de los fallos del sistema, además debe
asegurarse de que las operaciones los usuarios / programas no interfieran entre
sí. El modelo de transacción debe aislar a los usuarios unos de otros. Esto se
logra mediante diferentes mecanismos conocidos como esquemas de control de
concurrencia. Planificaciones (concurrencia) Al ejecutar varias transacciones de
manera concurrente la consistencia de la BBDD puede destruirse aun cuando
cada una de las transacciones individuales sea correcta.
Las planificaciones son la representación de las secuencias de ejecución de las
transacciones. Representan el orden cronológico en que se ejecutan las
instrucciones en el sistema.
Cualquier planificación válida debe constar de todas las instrucciones de la
transacción y en el mismo orden. Desde el punto de vista de una planificación, las
únicas operaciones significativas de una transacción son leer y escribir.
Problemas de la concurrencia Si no se dispone de un mecanismo que garantice el
aislamiento y múltiples usuarios acceden concurrentemente a la BBDD, pueden
darse cuatro tipos de problemas si sus transacciones usan los mismos datos al
mismo tiempo:
1. Problema de la modificación perdida: dos o más transacciones modifican un
valor basándose en el valor original. El último sobre-escribe las otras
modificaciones.
2. Dependencia no comprotedia o “lectura sucia” (Datos no confirmados): cuando
una transacción modifica una tupla y otra transacción la lee antes de que la
primera complete el cambio.
3. Lectura no repetible: si una transacción lee una fila y otra la modifica. Si la
segunda transacción comete el cambio, las siguientes lecturas de la primera
transacción producen resultados diferentes al de la primera lectura.
4. Lectura fantasma: una transacción lee un conjunto de filas que satisfagan una
condición de búsqueda y otra, después modifica los datos.
12

13. TRANSACCIONES 10/10/2011
Si la primera transacción repite la búsqueda obtendrá un conjunto distinto.
Garantía de consistencia
• RECUPERABILIDAD: Si una transacción T falla, es necesario deshacer el efecto
de dicha transacción para asegurar la propiedad de atomicidad de la misma. En un
sistema concurrente es necesario, además, asegurar que cada transacción T, que
dependa de T (que haya leído datos modificados por T) se aborte también. Para
garantizar esto hay que poner restricciones al tipo de planificación permitida en el
sistema.
• PLANIFICACION RECUPERABLE: Es aquella en la que para todo par de
transacciones Ti y Tj, en el que Tj lee documentos modificados por Tj, COMMIT de
Ti aparece antes que el COMMIT de Tj. Conflicto en PlanificacionesSerializadles
Supongamos dos sentencias consecutivas de una planificación, cada una de una
transacción.
Si las instrucciones se refieren a distintos datos se puede intercambiar su orden de
ejecución. Si se refieren al mismo dato, consideremos cuatro casos:
• Leer i (x), Leer j(x): no importa el orden.
• Leer i (x) Escribir j (x): si importa el orden.
• Escribir i (x) Leer j(x): si importa el orden
• Escribir i (x) Escribir j (x): si importa el orden. Luego dos instrucciones están en
conflicto si son de transacciones diferentes y al menos una de ellas es una
instrucción escribir.
Dos planificaciones serán equivalentes en cuanto a conflictos si se puede llegar a
obtener una a partir de la otra realizando intercambios de instrucción que no estén
en conflicto. Asimismo, una planificación es serializable si es equivalente en
cuanto a conflictos a una planificación en serie.
Seriabilidad en vistas Dos planificaciones son equivalentes en cuanto a vistas si se
cumple que:
1. Para cada dato X si una transacción lee su valor inicial, la otra también.
2. Si en una trnsacción para un dato x se hace una lectura del valor producido por
otra transacción debe ocurrir lo mismo en la otra planificación.
3. Para cada dato X la transacción que escribe su valor en una planificación debe
hacerlo también en la otra.
13

14. TRANSACCIONES 10/10/2011
Una planificación es serializable en vistas si es queivalente en cuanto a vistas a
una planficación en serie.
Pruebas de seriabilidad Son métodos para determinar si una planificación es
serializable:
Pruebas e Serializabilidad en conflictos: conssite en construir un grafo dirigiado
llamado Grafo de Precedencia.
Las transacciones son los vértices las aristas existen cuando se cumpla una de las
siguientes condiciones: •
Ti ejecuta escribir(x) atesqueTj ejecute leer(x): Ti ->Tj
• Ti lee(x) antes de que Tj escriba(x)
• Ti escribe(x) antes de que Tj escriba(x) Si en el grafo aparecen ciclos, la
planificación no es serializable. Si no hay ciclos entonces la planificación es
serializable en conflictos.
Control de concurrencia Aunque hay muchos esquemas para garantizar la
serializabilidad de las transacciones concurrentes un SGBD, la inmensa mayoría
usan téncias basadas en bloqueos.
Un bloquoconsisteen garantizar que el aceso a los datos se realice de forma
mútuamente excluyente: mientras una transacción accede a un dato ninguna otra
puede modificarlo, es transporte al usuario.
Hay dos enfoques de control de concurrencia:
• Optimista: se presume que los conflictos entre múltiples usuarios son
improbables y se permite a las transacciones ejecutarse sin necesidad de
bloquear recursos. Solo cuando la transacción termina y va a cometerse se
comprueban los recursos utilizados para determinar si ha habido algún conflicto.Si
ha ocurrido, la transacción empieza de nuevo y vuelve a intentarlo.
• Pesimienta: se bloquean los recursos cuando se desea acceder a ellos durante
todo el tiempo que dure la transacción. A menos que ocurra un interbloqueo, esta
técnica garantiza la finalización con éxito de la transacción. Cuando una
transacción intenta acceder a un recurso bloqueado se queda a la espera de que
se libere. Recuperación Parte integral del SGBD, esquema de recuperación
responsable de la eliminación de fallos y de la restauración de la BBDD a un
estado consistente anterior al fallo.
14

15. TRANSACCIONES 10/10/2011
PREVENCION: acciones tomadas durante el procesamiento normal de la
transacción que aseguran que existe suficiente información apra permitir la
recuperación de fallos.
RECUPERACIÓN: acciones tomadas a continuación de un fallo para asegurar la
consistencia de la base de datos y la atomicidad de las transacciones.
JERARQUIA DE ALAMACENAMIENTO: La BBDD reside en disco dividida en
bloques.
Las transacciones meten información el disco en memoria principal y vuelven a
guardarlo en disco (las transferencias se realizan en bloques).
Bloques de disco:
Bloques físicos Bloques en memoria:
Buffers Operaciones:input(x): traer a la memoria el bloque que contiene el dato X
Output(x): escribir en el disco el bloque que contiene el dato X.
Leer (x, xi): si es necesario se ejecuta input(x)
Escribir(x,xi): si es necesario ejecuta input(x) El bloque se graba en el disco ya
sea porque el gestor necesite espacio o porque desea reflejar el cambio hecho a
X. Output(x) no necesita ejecutarse después de escribir ya que X está en un
bloque contiene más datos que se pueden estar utilizando.
Si el sistema se cae entre escribir y output el nuevo valorde X se pierde.
Tras abortar una transacción hay dos opciones: volver a ejecutar T o no. Ninguna
de las dos opciones garantizar dejar la BBDD en un estado consistente.
Esquemas de recuperación A) Recuperación basada en bitácora. Si una
transacción requiere de múltiples operaciones de salida y falla entre medias, la
BBDD queda inconsistente. Para lograr la atomicidad primero hay que obtener
información describiendo las modificaciones del almacenamiento estable sin
modificar la BBDD. Esto nos permitirá sacar todas las modificaciones que hizo la
transacción a pesar de los fallos.
La bitácora es la estructura que guarda las modificaciones a la base de datos.
Cada registro describe una única escritura. Contiene los datos: nombre de la
transacción, nombre del dato, valor antiguo y el valor nuevo.
Registros especiales.
15

16. TRANSACCIONES 10/10/2011
Ti starts -> Transacción activa. Ti commits -> transacción parcialmente cometida
(terminada). El registro de bitácora debe crearse antes de modificar la BBDD.
Los registros de bitácora deben residir en memoria estable.
Existen dos técnicas para garantizar la atomicidad usando bitácora:
• Modificación diferida de la base de datos
• Modificación inmediata de la base de datos. Modificación diferida Graba las
modificaciones a la BBDD en la bitácora pero aplaza las escrituras de una
transacción hasta que ésta está parcialmente cometida. La información de la
bitácora se usa para hacer las escrituras.
Si el sistema se cae o la transacción se aborta se ignora el contenido de la
bitácora.
Ejecución de una transacción:
1. Antes de empezar <Ti starts>
2. Al terminar <Ti commits>
3. Escritura de la bitácora en memoria estable
4. Escritura diferida de las mdoficaciones en la BBDD
5. Estado cometido Esquema de recuperacion:
redo(Ti): asigna los nuevos valores a todos los datos que actualzia la transacción
Ti. Los datos modificados y sus valores se encuentran en la bitácora. Tras un fallo
el sistema de recuperación consulta la bitácora para determianr qué transacciones
deben volverse a ejecutar. La transacción ti debe volverse a ejecutar si la bitácora
contiene tanto el registro <Ti starts> como el registro <Ticommits>. Modificación
inmediata Permite que las modificaciones a la BBDD se escriban mientras la
transacción está en estado activo (son modificaciones no cometidas). En caso de
fallo se utiliza el campo de valor antiguo para restaurar la base de datos a un
estado consistente previo.
Proceso:
1. Antes de que Ti comience se escribe <Tistarts>
2. Durante la ejecutción cualquier escritura va precedida del registro en bitácora.
16

17. TRANSACCIONES 10/10/2011
3. Cuando esté parcialmente cometida se escribe <Ticommits>
Esquema de recuperación:
Undo(Ti): restaura a los valores originales.
Redo(Ti): asigna los nuevos valores.
Después de un fallo del sistema de recuperación consulta la bitácora para
determinar qué transacciones necesitan deshacerse y cuáles volverse a hacer:
• Deshacer: si existe Ti starts pero no Ti commits
• Rehacer: si existen tanto Ti starts como Ti commits. Gestion de registros
intermedios Implementación de un sistema de recuperación que garantice la
consistencia de los datos y que requiera un tiempo extra mínimo: Buffering de
registros de Bitácora. La grabación en memoria estable se hace por bloques.
Sin embargo, un registro de bitácora ocupa menos que un bloque (escritura
mayor de lo necesario). Conviene grabar varios registros de bitácora de una sola
vez, luego se puede mantener el registro de bitácora en memoria volátil. Sin
embargo, dado que el contenido de ésta memoria se pierde si el sistema se cae,
hay que añadir nuevos requisitos para garantizar la atomicidad de la transacción:
Ti entra en sus estado cometido después de guardarse en memoria estable:
<Ticommits> Antes de que se pueda grabar <Ticommits> deben haberse grabado
todos los registros de bitácora pertenecientes a Ti. Antes de grabar a al BBDD un
bloque de memoria principal deben haberse grabado en memoria estable todos los
registros de bitácora que pertenecen a los datos de ese bloque. Buffering de la
Base de datos Si es necesario sobreescribir en memoria principal un bloque B1
para tener un bloque B2 y B1 se había modificado deben grabarse primero B1
antes de la entrada de B2, luego todos los registros de bitácora que pertenecen a
datos que están en B1 deben grabarse.
Secuencia de acciones. Grabar los registros de bitácora pertenecientes a datos
de B1 Grabar B1 en disco. Traer B2 a la memoria principal, Puntos de verificación
Cuando ocurre un fallo se consulta, la bitácora para determinar que transacciones
necesitan volver a hacerse y cuales necesitan deshacerse.
Inconvenientes:
• Consumo de tiempo: si la mayoría de las transacciones ya se han escrito volver
a ejecutarlas no es dañino pero si costoso. Los puntos de verificación pretenden
ahorra tiempo. Durante la ejecución el sistema mantiene la bitácora con una de las
técnicas anteriores y además, realiza periódicamente puntos de verificación que
consisten en la siguiente secuencia de acciones:
17

18. TRANSACCIONES 10/10/2011
1. - Grabar todos los registros de la bitácora.
2. - cometer todas las transacciones parcialmente cometidas en el momento del
punto de verificación.
3. Escribir en la bitácora un registro <checkpoint> en memoria estable.
La bitácora Cuando se realiza un punto de verificación se realizan los tres pasos
descritos para una sola transacción, pero en el registro <checkpoint> se añade la
lista de transacciones activas en el momento del punto de verificación, esto es:
<checkpoint L>
Cuando el sistema se recupera de una caída construye dos listas: lista de
deshacer y lista de rehacer.
Procedimiento de recuperación:
• Se examina la bitácora hacia atrás hasta el primer punto de verificación.
• Por cada <Ticommits> se añade Ti a la lsita Rehacer.
• Por cada <Tjstarts> si Tj no está en la anterior vista, se añade a la lista
Deshacer.
•Se comprueba finalmente la lista L y a cada transacción de L que no está en
Rehacer se añade a Deshacer.
• Una vez construidas las listas:
1) Se vuelve a examinar la bitácora hacia atrás y se hace undo(ti) para cada
transacción en la lista deshacer.
2) Se continúa hacia atrás hasta localizar <Tistarts> para todas las transacciones
de la lista deshacer.
3)Se examina la bitácora hacia delante y se ejecuta redo(tj) para todas las
transacciones de la lista Rehacer.
18

19. TRANSACCIONES 10/10/2011
Incorporación del manejador de transacciones a la arquitectura de un
SMBD
Con la introducción del concepto de transacción, se requiere revisar el modelo
arquitectural presentado en el capítulo 2. En esta sección, se expande el papel del
monitor de ejecución distribuida.
El monitor de ejecución distribuida consiste de dos módulos: El administrador de
transacciones (TM) y el despachador (SC). Como se puede apreciar en la Figura
5.2, el administrador de transacciones es responsable de coordinar la ejecución en
la base de datos de las operaciones que realiza una aplicación. El despachador,
por otra parte, es responsable de implementar un algoritmo específico de control
de concurrencia para sincronizar los accesos a la base de datos.
Un tercer componente que participa en el manejo de transacciones distribuidas es
el administrador de recuperación localcuya función es implementar procedimientos
locales que le permitan a una base de datos local recuperarse a un estado
consistente después de una falla.
3
Los administradores de transacciones implementan una interfaz para los
programas de aplicación que consiste de los comandos:
1. Begin_transaction.
2. Read.
3. Write.
3
Figura 5.2. un modelo del administrador de transacciones
19

20. TRANSACCIONES 10/10/2011
4. Commit.
5. Abort.
En la Figura 5.3 se presenta la arquitectura requerida para la ejecución
centralizada de transacciones. Las modificaciones requeridas en la arquitectura
para una ejecución distribuida se pueden apreciar en las Figura 5.4. En esta última
figura se presentan también los protocolos de comunicación necesarios para el
manejo de transacciones distribuidas.
4
4
Figura 5
20

21. TRANSACCIONES 10/10/2011
En conclusión:
Una transacción es un programa de aplicación, generalmente de duración breve,
que accede y actualiza una parte también generalmente pequeña de la base de
datos, su principal labor es conservar la integridad en una base de datos,un
gestor de transacciones asegura que la base de datos permanecerá en un estado
consistente (correcto) a pesar de fallos en el sistema o de fallos en las
transacciones, también controla la interacción entre transacciones concurrentes,
para asegurar la consistencia de la base de datos.
21

22. TRANSACCIONES 10/10/2011
Linkografia
http://www.oocities.org/mx/analvaca/bdd/man_trans.htm
http://boards4.melodysoft.com/2005AAA0203/transacciones-87.html
http://es.wikipedia.org/wiki/Transacci%C3%B3n_(inform%C3%A1tica)
22