trabajo 5

Investigación

LAS TRANSACCIONES DE UNA B.D.

BASE DE DATOS

DR. CARLOS A. TORRES GASTELU

RINCÓN OCHOA LEYDI DIANA

JORGE MENGELLE CASTRO

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................................................................................................................................7

Secuencialidad................................................................................................................................8

RECUPERABILIDAD.........................................................................................................................9

IMPLEMENTACION DE AISLAMIENTO.............................................................................................9

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........................18

2


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


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.

1http://www.oocities.org/mx/analvaca/bdd/man_trans.htm

4

http://es.wikipedia.org/wiki/Transacci%C3%B3n_(inform%C3%A1tica)

http://www.oocities.org/mx/analvaca/bdd/man_trans.htm


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.

2Modelo de una transacción

5


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


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


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 conflicto2. Ii = leer(Q) , Ij=escribir(Q). El orden de Ii e Ijsi importa. – Hay conflicto3. Ii = escribir(Q) , Ij=leer(Q). El orden de Ii e Ijsi importa. – Hay conflicto4. Ii = escribir(Q) , Ij=Escribir(Q). El orden de Ii e Ijsi importa. – Hay conflictoSi 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


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 essecuenciable 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


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


• 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


• 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


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


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


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


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


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


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


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. 4. Commit.

3 Figura 5.2. un modelo del administrador de transacciones

19


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

4Figura 5

20


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


Linkografia


http://boards4.melodysoft.com/2005AAA0203/transacciones-87.html


22


http://boards4.melodysoft.com/2005AAA0203/transacciones-87.html


Documents

trabajo 5