TRANSACCIONES EN UNA B.D.

BASE DE DATOS

DR. CARLOS A. TORRES GASTELU

JORGE MENGELLE CASTRO
ZS09007631








TRANSACCIONES 19/10/2011



2







Manejo de transacciones. ........................................................................................................... 4
Gestor de transacciones .............................................................................................................. 4
Manejo de Transacciones ............................................................................................................ 5
Estados de una transaccin ............................................................................................................. 6
Implementacin de la atomicidad y la durabilidad ......................................................................... 6
Ejecuciones concurrentes ............................................................................................................... 7
Planificaciones ................................................................................................................................. 7
Secuencialidad ................................................................................................................................. 8
RECUPERABILIDAD .......................................................................................................................... 9
IMPLEMENTACION DE AISLAMIENTO ............................................................................................. 9
Procesamiento de Transacciones SGBD. ..................................................................................... 9
Gestin de Concurrencia. ............................................................................................................ 9
Procedimientos de recuperacin. ............................................................................................ 10
Inicio de transacciones .............................................................................................................. 11
Incorporacin del manejador de transacciones a la arquitectura de un SMBD ....................... 19






TRANSACCIONES 19/10/2011



3


Introduccin

A continuacin se mostrara el transcurso de las transacciones que se llevan a cabo en
una base de datos, que representan la ejecucin de operaciones es decir estas se
encargara de mantener la integridad de la base de datos y de esta forma mejorar su
desempeo.. El manejo de transacciones consiste en controlar mltiples transacciones
ejecutando el paralelo sobre una misma base de datos corriendo en un sistema que
puede fallar. Las transacciones son de gran utilidad para las bases de datos como lo
que veremos ms adelante y con ms detenimiento revisaremos el uso que se les da
dentro de una de las B.D.














TRANSACCIONES 19/10/2011



4



Manejo de
transacciones.


Una transaccin es
un programa que
se ejecuta como
una sola operacin.
Esto quiere decir que luego de una ejecucin en la que se produce una falla es el
mismo que se obtendra si el programa no se hubiera ejecutado. Los SGBD
proveen mecanismos para programar las modificaciones de los datos de una
forma mucho ms simple que si no se dispusiera de ellos.
Gestor de transacciones
Se encarga de conservar la integridad de la base de datos.
Una transaccin es una coleccin de operaciones que realizan una nica funcin
lgica 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.
*tambin controla la interaccin entre transacciones concurrentes, para asegurar
la consistencia de la base de datos.





TRANSACCIONES 19/10/2011



5


Manejo de Transacciones


Una de las reas
principales de
aplicacin de los sgbd's
es lo que se llama
procesamiento de
transacciones. Una
transaccin es un
programa de
aplicacin,
generalmente de
duracin breve, que
accede y actualiza una
parte tambin generalmente pequea de la base de datos. Tpicos ejemplos son
un depsito o extraccin de una cuenta bancaria, o una reservacin en un vuelo, o
una verificacin de una tarjeta de crdito.
El manejo de transacciones consiste en controlar mltiples 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 daada en forma irreparable por cadas, 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 tcnicas de
recuperacin.

Una transaccin es una unidad de la ejecucin de un programa que accede y
posiblemente actualiza varios elementos de datos y est delimitada por
instrucciones de la forma inicio Transaccin y fin transaccin.
La transaccin consiste en todas las operaciones que se ejecutan entre inicio
transaccin y el fin transaccin.
Para asegurar la integridad de los datos se necesita que el sistema de la base de
datos mantenga las siguientes propiedades de las transacciones:


TRANSACCIONES 19/10/2011



6

Atomicidad: O todas las operaciones de la transaccin se realizan
adecuadamente en la base de datos o ninguna de ellas.
Consistencia: La ejecucin aislada de la transaccin (es decir, sin otra
transaccin 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 ejecucin antes de
que comience Ti, o bien que Tj ha comenzado su ejecucin despus de
que Ti termine.
Durabilidad: Tras la finalizacin con xito de una transaccin, los cambios
realizados en la base de datos permanecen incluso si hay fallos en el
sistema.


Estados de una transaccin

En ausencia de fallos todas las transacciones se completan con xito. Sin
embargo una transaccin puede que no siempre acabe su ejecucin con xito.
Una transaccin de este tipo se denomina abortada. Una vez deshechos los
cambios efectuados por la transaccin abortada, se dice que la transaccin esta
retrocedida. Una transaccin que termina con xito se dice que est
comprometida.

Una transaccin debe estar en uno de los siguientes estados:
Activa: Estado inicial, permanece en ese estado durante su ejecucin.
Parcialmente comprometida: Despus de ejecutarse la ltima
instruccin.
Fallida: Tras descubrir que no puede continuar la ejecucin normal.
Abortada: Despus del retroceso de la transaccin y de haber
restablecido la Base de Datos a su estado anterior al comienzo de la
transaccin.
Comprometida: Tras completarse con xito.

Una transaccin llega al estado fallida despus de que el sistema determine que
dicha transaccin no puede continuar su transaccin normal.
En abortada el sistema debe decidir entre reiniciar la transaccin o cancelarla.


Implementacin de la atomicidad y la durabilidad

TRANSACCIONES 19/10/2011



7

El componente de gestin 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 implementacin depende de que escribir el puntero sea una
operacin atmica. Es poco eficiente y exige mucha memoria ya que la ejecucin
de una simple transaccin 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 utilizacin 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 utilizacin del procesador y del
disco aumenta tambin. Estn menos tiempo sin hacer ningn 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. Adems se reduce el tiempo
medio de respuesta que es el tiempo medio desde que empieza una transaccin
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 transaccin individual sea
correcta. El sistema de base de datos debe controlar la interaccin entre las
transacciones concurrentes para evitar que se destruya la consistencia de la base
de datos. Esto se lleva a cabo a travs de una serie de mecanismos denominados
esquemas de control de la concurrencia.


Planificaciones

Representan el orden cronolgico en el que se ejecutan las instrucciones en el
sistema

Planificacin secuencial

Consiste en una secuencia de instrucciones de varias transacciones en la cual las
instrucciones pertenecientes a una nica transaccin estn juntas en dicha
planificacin.
TRANSACCIONES 19/10/2011



8

Es una tarea del sistema de Base de datos asegurar que cualquier planificacin
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 ejecucin concurrente si se est seguro de que cualquier
planificacin 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 ningn
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 estn en conflicto, se pueden cambiar el orden para obtener una nueva
planificacin.

Si una planificacin 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 planificacin es secuenciable en cuanto a conflictos si es equivalente en
cuanto a conflictos a una planificacin secuencial. Se pueden encontrar dos
planificaciones que nos lleven al mismo resultado y en cambio no sean
equivalentes en cuanto a conflictos.

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 planificacin P, entonces Ti debe leer tambin
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
transaccin debe leer tambin el valor de Q que ha producido Tj.
TRANSACCIONES 19/10/2011



9

3- Para todo elemento de datos Q, la transaccin que realice la ltima operacin
escribir (Q) en P, debe realizar la ltima operacin escribir (Q) tambin en P.

La planificacin P es secuenciable en cuanto a vistas si es equivalente en cuanto
a vistas a una planificacin secuencial. Toda planificacin 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 transaccin Ti falla, ser necesario deshacer el efecto de dicha transaccin
para asegurar la atomicidad de la misma. En un sistema que permita
concurrencias hay que asegurarse que tambin toda transaccin Tj que dependa
de Ti se aborta tambin. Para ello es necesario imponer algunas restricciones a
las planificaciones.

Planificaciones recuperables
Una planificacin 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
operacin comprometer de Ti debe aparecen antes que la de Tj .

Planificaciones sin cascada
Cuando una operacin provoca una serie de retrocesos se conoce como
retroceso en cascada. Una planificacin 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 operacin comprometer de Ti aparece antes que la operacin
de lectura Tj. Toda planificacin sin cascada es tambin recuperable.

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.
Gestin de Concurrencia.
TRANSACCIONES 19/10/2011



10

Procedimientos de recuperacin.
Transaccin Una transaccin es una secuencia de operaciones llevadas a cabo
como una unidad lgica de trabajo simple. Debe cumplir cuatro propiedades:
Atomicidad: debe ser una unidad atmica de trabajo (o se llevan a cabo todas
sus operaciones o no se realiza ninguna).
Consistencia: al terminar, una transaccin debe deja a la BBDD en un estado
consistente. Verificar la consistencia es responsabilidad del control semntico.
Asignar la consistencia es responsabilidad de los mecanismos de control de
concurrencia.
Aislamiento: la modificaciones realizas por una transaccin debe aislarse de las
posibles modificaciones de otras transacciones concurrentes. La transaccin debe
ver los datos en un estado posterior a la modificacin de otra transaccin, pero en
estados intermedios.
Durabilidad: una vez una transaccin 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 lgica de los datos:
Activa: esta normal, cuando se ejecuta su primera instruccin.
Parcialmente cometido: tras ejecutar la ltima sentencia de la transaccin.
Fallado: no se puede proceder la ejecucin normal.
Abortado: la transaccin ha retrocedido y se restaurado la BBDD al estado en
que estaba antes de la transaccin.
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]: Seala el final con xito de una transaccin.
TRANSACCIONES 19/10/2011



11

ROLLBACK[WORK]: Seala el final sin xito de una transaccin, informa al
usuario que no se puede completar la transaccin 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 transaccin que termina antes de completar todas sus
operaciones.
Inicio de transacciones
Tipos:
Transacciones explcitas: comienzan explcitamente con la sentencia BEGIN
TRANSACTION.
Auto confirmacin (AUTOCOMMIT): Cada sentencia SQL es cometida cuando
termina. No se muestran sentencias adicionales para el control de la transaccin.
Implcitas: la siguiente sentencia comienza automticamente una nueva
transaccin. Cuando una transaccin termina la siguiente sentencia SQL
comienza una transaccin. Finalizacin de las transacciones Mediante una
sentencia COMMIT o ROLLBACK.
Modelos de transaccin Modelo ANSI/ISO Especifica una lenguaje SQL
programado (embebido) para utilizarlo en programas de aplicacin. ste estndar
especifica que una transaccin SQL comienza automticamente con la primera
sentencia SQL (transacciones implcitas).
La transaccin contina con las sentencias SQL subsiguientes que se finaliza uno
de los siguientes modos posibles:
Sentencia COMMIT (tras ella comienza una nueva transaccin).
Sentencia ROLLBACK (tras ella comienza una nueva transaccin).
Finalizacin de un programa con xito (que equivale a ejecutar COMMIT)
Finalizacin anormal del programa (equivale a ROLLBACK).
Bajo este modelo el usuario o programa est siempre en una transaccin. Modelo
multiusuario Ante mltiples accesos concurrentes, el SGBD no slo tiene de
ocuparse de recuperarse rodenamente de los fallos del sistema, adems debe
asegurarse de que las operaciones los usuarios / programas no interfieran entre
TRANSACCIONES 19/10/2011



12

s. El modelo de transaccin 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 representacin de las secuencias de ejecucin de las
transacciones. Representan el orden cronolgico en que se ejecutan las
instrucciones en el sistema.
Cualquier planificacin vlida debe constar de todas las instrucciones de la
transaccin y en el mismo orden. Desde el punto de vista de una planificacin, las
nicas operaciones significativas de una transaccin son leer y escribir.
Problemas de la concurrencia Si no se dispone de un mecanismo que garantice el
aislamiento y mltiples 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 modificacin perdida: dos o ms transacciones modifican un
valor basndose en el valor original. El ltimo sobre-escribe las otras
modificaciones.
2. Dependencia no comprotedia o lectura sucia (Datos no confirmados): cuando
una transaccin modifica una tupla y otra transaccin la lee antes de que la
primera complete el cambio.
3. Lectura no repetible: si una transaccin lee una fila y otra la modifica. Si la
segunda transaccin comete el cambio, las siguientes lecturas de la primera
transaccin producen resultados diferentes al de la primera lectura.
4. Lectura fantasma: una transaccin lee un conjunto de filas que satisfagan una
condicin de bsqueda y otra, despus modifica los datos.
Si la primera transaccin repite la bsqueda obtendr un conjunto distinto.
Garanta de consistencia
RECUPERABILIDAD: Si una transaccin T falla, es necesario deshacer el efecto
de dicha transaccin para asegurar la propiedad de atomicidad de la misma. En un
sistema concurrente es necesario, adems, asegurar que cada transaccin T, que
dependa de T (que haya ledo datos modificados por T) se aborte tambin. Para
garantizar esto hay que poner restricciones al tipo de planificacin permitida en el
sistema.
TRANSACCIONES 19/10/2011



13

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 Planificaciones Serializadles
Supongamos dos sentencias consecutivas de una planificacin, cada una de una
transaccin.
Si las instrucciones se refieren a distintos datos se puede intercambiar su orden de
ejecucin. 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 estn en
conflicto si son de transacciones diferentes y al menos una de ellas es una
instruccin escribir.
Dos planificaciones sern equivalentes en cuanto a conflictos si se puede llegar a
obtener una a partir de la otra realizando intercambios de instruccin que no estn
en conflicto. Asimismo, una planificacin es serializable si es equivalente en
cuanto a conflictos a una planificacin en serie.
Seriabilidad en vistas Dos planificaciones son equivalentes en cuanto a vistas si se
cumple que:
1. Para cada dato X si una transaccin lee su valor inicial, la otra tambin.
2. Si en una transaccin para un dato x se hace una lectura del valor producido
por otra transaccin debe ocurrir lo mismo en la otra planificacin.
3. Para cada dato X la transaccin que escribe su valor en una planificacin debe
hacerlo tambin en la otra.
Una planificacin es serializable en vistas si es queivalente en cuanto a vistas a
una planficacin en serie.
Pruebas de seriabilidad Son mtodos para determinar si una planificacin es
serializable:
Pruebas e Serializabilidad en conflictos: consiste en construir un grafo dirigido
llamado Grafo de Precedencia.
TRANSACCIONES 19/10/2011



14

Las transacciones son los vrtices 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
planificacin no es serializable. Si no hay ciclos entonces la planificacin es
serializable en conflictos.
Control de concurrencia Aunque hay muchos esquemas para garantizar la
serializabilidad de las transacciones concurrentes un SGBD, la inmensa mayora
usan tcnicas basadas en bloqueos.
Un bloque consisten garantizar que el acceso a los datos se realice de forma
mutuamente excluyente: mientras una transaccin 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 mltiples usuarios son
improbables y se permite a las transacciones ejecutarse sin necesidad de
bloquear recursos. Solo cuando la transaccin termina y va a cometerse se
comprueban los recursos utilizados para determinar si ha habido algn conflicto. Si
ha ocurrido, la transaccin empieza de nuevo y vuelve a intentarlo.
Descimienta: se bloquean los recursos cuando se desea acceder a ellos durante
todo el tiempo que dure la transaccin. A menos que ocurra un interbloqueo, esta
tcnica garantiza la finalizacin con xito de la transaccin. Cuando una
transaccin intenta acceder a un recurso bloqueado se queda a la espera de que
se libere. Recuperacin Parte integral del SGBD, esquema de recuperacin
responsable de la eliminacin de fallos y de la restauracin de la BBDD a un
estado consistente anterior al fallo.
PREVENCION: acciones tomadas durante el procesamiento normal de la
transaccin que aseguran que existe suficiente informacin apra permitir la
recuperacin de fallos.
RECUPERACIN: acciones tomadas a continuacin 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.
TRANSACCIONES 19/10/2011



15

Las transacciones meten informacin el disco en memoria principal y vuelven a
guardarlo en disco (las transferencias se realizan en bloques).
Bloques de disco:
Bloques fsicos 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 despus de escribir ya que X est en un
bloque contiene ms datos que se pueden estar utilizando.
Si el sistema se cae entre escribir y output el nuevo valor de X se pierde.
Tras abortar una transaccin hay dos opciones: volver a ejecutar T o no. Ninguna
de las dos opciones garantizar dejar la BBDD en un estado consistente.
Esquemas de recuperacin A) Recuperacin basada en bitcora. Si una
transaccin requiere de mltiples operaciones de salida y falla entre medias, la
BBDD queda inconsistente. Para lograr la atomicidad primero hay que obtener
informacin describiendo las modificaciones del almacenamiento estable sin
modificar la BBDD. Esto nos permitir sacar todas las modificaciones que hizo la
transaccin a pesar de los fallos.
La bitcora es la estructura que guarda las modificaciones a la base de datos.
Cada registro describe una nica escritura. Contiene los datos: nombre de la
transaccin, nombre del dato, valor antiguo y el valor nuevo.
Registros especiales.
Ti starts -> Transaccin activa. Ti commits -> transaccin parcialmente cometida
(terminada). El registro de bitcora debe crearse antes de modificar la BBDD.
Los registros de bitcora deben residir en memoria estable.
Existen dos tcnicas para garantizar la atomicidad usando bitcora:
Modificacin diferida de la base de datos
TRANSACCIONES 19/10/2011



16

Modificacin inmediata de la base de datos. Modificacin diferida Graba las
modificaciones a la BBDD en la bitcora pero aplaza las escrituras de una
transaccin hasta que sta est parcialmente cometida. La informacin de la
bitcora se usa para hacer las escrituras.
Si el sistema se cae o la transaccin se aborta se ignora el contenido de la
bitcora.
Ejecucin de una transaccin:
1. Antes de empezar <Ti starts>
2. Al terminar <Ti commits>
3. Escritura de la bitcora en memoria estable
4. Escritura diferida de las mdoficaciones en la BBDD
5. Estado cometido Esquema de recuperacin:
redo(Ti): asigna los nuevos valores a todos los datos que actualiza la transaccin
Ti. Los datos modificados y sus valores se encuentran en la bitcora. Tras un fallo
el sistema de recuperacin consulta la bitcora para determinar qu transacciones
deben volverse a ejecutar. La transaccin ti debe volverse a ejecutar si la bitcora
contiene tanto el registro <Ti starts> como el registro <Ticommits>. Modificacin
inmediata Permite que las modificaciones a la BBDD se escriban mientras la
transaccin 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 ejecutcin cualquier escritura va precedida del registro en bitcora.
3. Cuando est parcialmente cometida se escribe <Ticommits>
Esquema de recuperacin:
Undo(Ti): restaura a los valores originales.
Redo(Ti): asigna los nuevos valores.
TRANSACCIONES 19/10/2011



17

Despus de un fallo del sistema de recuperacin consulta la bitcora para
determinar qu transacciones necesitan deshacerse y cules volverse a hacer:
Deshacer: si existe Ti starts pero no Ti commits
Rehacer: si existen tanto Ti starts como Ti commits. Gestin de registros
intermedios Implementacin de un sistema de recuperacin que garantice la
consistencia de los datos y que requiera un tiempo extra mnimo: Buffering de
registros de Bitcora. La grabacin en memoria estable se hace por bloques.
Sin embargo, un registro de bitcora ocupa menos que un bloque (escritura
mayor de lo necesario). Conviene grabar varios registros de bitcora de una sola
vez, luego se puede mantener el registro de bitcora en memoria voltil. Sin
embargo, dado que el contenido de sta memoria se pierde si el sistema se cae,
hay que aadir nuevos requisitos para garantizar la atomicidad de la transaccin:
Ti entra en sus estado cometido despus de guardarse en memoria estable:
<Ticommits> Antes de que se pueda grabar <Ticommits> deben haberse grabado
todos los registros de bitcora pertenecientes a Ti. Antes de grabar a al BBDD un
bloque de memoria principal deben haberse grabado en memoria estable todos los
registros de bitcora que pertenecen a los datos de ese bloque. Buffering de la
Base de datos Si es necesario sobrescribir en memoria principal un bloque B1
para tener un bloque B2 y B1 se haba modificado deben grabarse primero B1
antes de la entrada de B2, luego todos los registros de bitcora que pertenecen a
datos que estn en B1 deben grabarse.
Secuencia de acciones. Grabar los registros de bitcora pertenecientes a datos
de B1 Grabar B1 en disco. Traer B2 a la memoria principal, Puntos de verificacin
Cuando ocurre un fallo se consulta, la bitcora para determinar que transacciones
necesitan volver a hacerse y cuales necesitan deshacerse.
Inconvenientes:
Consumo de tiempo: si la mayora de las transacciones ya se han escrito volver
a ejecutarlas no es daino pero si costoso. Los puntos de verificacin pretenden
ahorra tiempo. Durante la ejecucin el sistema mantiene la bitcora con una de las
tcnicas anteriores y adems, realiza peridicamente puntos de verificacin que
consisten en la siguiente secuencia de acciones:
1. - Grabar todos los registros de la bitcora.
2. - cometer todas las transacciones parcialmente cometidas en el momento del
punto de verificacin.
3. Escribir en la bitcora un registro <checkpoint> en memoria estable.
TRANSACCIONES 19/10/2011



18

La bitcora Cuando se realiza un punto de verificacin se realizan los tres pasos
descritos para una sola transaccin, pero en el registro <checkpoint> se aade la
lista de transacciones activas en el momento del punto de verificacin, esto es:
<checkpoint L>
Cuando el sistema se recupera de una cada construye dos listas: lista de
deshacer y lista de rehacer.
Procedimiento de recuperacin:
Se examina la bitcora hacia atrs hasta el primer punto de verificacin.
Por cada <Ticommits> se aade Ti a la lsita Rehacer.
Por cada <Tjstarts> si Tj no est en la anterior vista, se aade a la lista
Deshacer.
Se comprueba finalmente la lista L y a cada transaccin de L que no est en
Rehacer se aade a Deshacer.
Una vez construidas las listas:
1) Se vuelve a examinar la bitcora hacia atrs y se hace undo(ti) para cada
transaccin en la lista deshacer.
2) Se contina hacia atrs hasta localizar <Tistarts> para todas las transacciones
de la lista deshacer.
3)Se examina la bitcora hacia delante y se ejecuta redo(tj) para todas las
transacciones de la lista Rehacer.










TRANSACCIONES 19/10/2011



19

Incorporacin del manejador de transacciones a la arquitectura de un
SMBD
Con la introduccin del concepto de transaccin, se requiere revisar el modelo
arquitectural presentado en el captulo 2. En esta seccin, se expande el papel del
monitor de ejecucin distribuida.
El monitor de ejecucin distribuida consiste de dos mdulos: 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 ejecucin en
la base de datos de las operaciones que realiza una aplicacin. El despachador,
por otra parte, es responsable de implementar un algoritmo especfico 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 recuperacin local cuya funcin es implementar
procedimientos locales que le permitan a una base de datos local recuperarse a
un estado consistente despus de una falla.
1

Los administradores de transacciones implementan una interfaz para los
programas de aplicacin que consiste de los comandos:

1
Figura 5.2. un modelo del administrador de transacciones
TRANSACCIONES 19/10/2011



20

1. Begin_transaction.
2. Read.
3. Write.
4. Commit.
5. Abort.
En la Figura 5.3 se presenta la arquitectura requerida para la ejecucin
centralizada de transacciones. Las modificaciones requeridas en la arquitectura
para una ejecucin distribuida se pueden apreciar en las Figura 5.4. En esta ltima
figura se presentan tambin los protocolos de comunicacin necesarios para el
manejo de transacciones distribuidas.

2
















2
Figura 5
TRANSACCIONES 19/10/2011



21






Ahora sabemos que una transaccin es un programa de aplicacin, generalmente
de duracin breve, que accede y actualiza una parte considerada generalmente
pequea en la base de datos, su labor principal es conservar la integridad en una
base de datos. A su vez un gestor de transacciones asegura que la base de datos
permanecer en un estado consistente a pesar de fallos en el sistema o de fallos
en las transacciones.
































TRANSACCIONES 19/10/2011



22

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)