1

GESTIN DE DATOS 2012

- Clase 7 -

Transacciones: Conceptos
2

Transaccin: Conjunto de operaciones que forman una nica unidad lgica de trabajo. Un ejemplo de transaccin es la transferencia de dinero de una cuenta a otra cuenta que consta de dos actualizaciones, una para cada cuenta. Una transaccin se inicia por la ejecucin de un programa de usuario escrito en un lenguaje de manipulacin de datos de alto nivel o en un lenguaje de programacin (SQL, Java) y est delimitado por instrucciones begin transaction y end transaction.

Transacciones: Propiedades
3

Para asegurar la integridad de los datos se necesita que el sistema de Base de Datos mantenga las cuatro propiedades bsicas denominadas Propiedades ACID:

Atomicity (Atomicidad): Garantiza que todas las instrucciones de una transaccin se ejecutan sobre la Base de Datos, o ninguna de ellas se lleva a cabo.

Transacciones: Propiedades
4

Consistency (Consistencia): La ejecucin completa de una transaccin lleva a la BD de un estado consistente a otro consistente. Para esto, la transaccin debe estar escrita correctamente.
Isolation (Aislamiento): Cada transaccin acta como si fuera nica en el sistema; ignorando al resto de las transacciones que se ejecutan concurrentemente. Durability (Durabilidad): Tras la finalizacin con xito de una transaccin, los cambios realizados en la BD permanecen, incluso si hay fallos en el sistema.

Transacciones: Propiedades
5

Para comprender mejor las propiedades ACID y la necesidad de dichas propiedades, consideremos un sistema bancario simplificado constituido por varias cuentas y un conjunto de transacciones que acceden y actualizan dichas cuentas. El acceso a la base de datos se lleva a cabo mediante las operaciones:

Leer (X): Transfiere el dato X de la base de datos a una memoria intermedia local perteneciente a la transaccin que ejecuta la operacin leer. Escribir (X): Transfiere el dato X desde la memoria intermedia local de la transaccin que ejecuta la operacin escribir a la base de datos.

Transacciones: Propiedades
6

Sea Ti una transaccin que sirve para generar el pago de un servicio:

Ti : Leer (cuentaCliente) cuentaCliente = cuentaCliente importeServicio Escribir (cuentaCliente) Leer (cuentaPrestatario) cuentaPrestatario = cuentaPrestatario + importeServicio Escribir (cuentaPrestatario)

Se cumplen las propiedades ACID?

Transacciones: Estados
7

Una transaccin debe estar en alguno de los siguientes cinco estados:

Activo: Estado desde que comienza la ejecucin de la transaccin hasta completar la ltima instruccin, o hasta que se produce un fallo. Parcialmente finalizado: Se alcanza en el momento posterior a que la transaccin ejecuta su ltima instruccin.

Transacciones: Estados
8

Finalizado: Se alcanza cuando la transaccin finaliz su ejecucin con xito, y sus acciones fueron almacenadas correctamente en almacenamiento secundario. Fallado: A este estado se arriba cuando la transaccin no puede continuar con su ejecucin normal.
Abortado: Este estado garantiza que una transaccin fallada no ha producido ningn cambio en la Base de Datos, manteniendo la integridad de la informacin all contenida.

Transacciones: Estados
9

Diagrama de estados correspondiente a una transaccin:

Activo

Parcialmente finalizado

Fallado

Finalizado

Abortado

Transacciones: Estados
10

Una transaccin llega al estado fallado despus de que se determina que dicha transaccin no puede continuar su ejecucin normal. Despus pasa al estado abortado. En este punto hay dos opciones:

Reiniciar la transaccin: Esta accin se puede llevar a cabo cuando el error se produjo por el entorno y no por la lgica interna de la transaccin. Una transaccin reiniciada se considera una nueva transaccin Cancelar definitivamente la transaccin: Esta accin se lleva a cabo cuando se detecta un error interno en la lgica de la transaccin. Este error slo puede ser salvado si la transaccin es redefinida.

Transacciones: Fallos
11

Las computadoras, al igual que cualquier otro dispositivo elctrico o mecnico, estn sujetos a fallos. Por esto, el sistema de Bases de Datos debe realizar con anticipacin acciones que garanticen que las propiedades de atomicidad y durabilidad de las transacciones se preservan a pesar de tales fallos.
Una parte integral de un sistema de Base de Datos es un esquema de recuperacin, el cual es responsable de la restauracin de la BD al estado consistente previo al fallo. Tal esquema debe proporcionar alta disponibilidad, o sea, debe minimizar el tiempo durante el que la BD no se puede usar despus de un fallo.

Transacciones: Fallos
12

En un sistema pueden producirse varios tipos de fallos. Consideraremos los siguientes tipos de fallos:
1.

Fallo en la transaccin: Hay dos tipos de errores que pueden hacer que una transaccin falle: Error lgico. La transaccin no puede continuar con su ejecucin normal a causa de alguna condicin interna, como una entrada incorrecta, desbordamiento, etc. Error del sistema: El sistema se encuentra en un estado no deseado como consecuencia del cual una transaccin no puede continuar con su ejecucin normal; sin embargo, se puede volver a ejecutar ms tarde.

Transacciones: Fallos
13

2.

Cada del sistema: Un mal funcionamiento del hardware o un error en el software de la base de datos o del sistema operativo causa la prdida del contenido de la memoria voltil y aborta el procesamiento de una transaccin.
Fallo del disco: Algunos bloques de disco pueden perder sus datos por un mal funcionamiento de lectura o escritura, o por un fallo de una cabeza de lectura/escritura.

3.

Transacciones: Fallos
14

Ante un fallo en una transaccin, cules son las acciones que se deberan llevar a cabo para asegurar la integridad de la Base de Datos?
Una alternativa es volver a ejecutar completamente la transaccin fallida. El problema surge cuando la nueva transaccin comienza desde un estado de inconsistencia. Por lo tanto, volver a ejecutar una transaccin que anteriormente fall no retrotrae la Base de Datos a un estado de consistencia. Otra alternativa es no hacer nada, pero la Base de Datos permanecer inconsistente.

Transacciones: Fallos
15

Para la transaccin Ti , supongamos que falla en (1):

Ti : Leer (cuentaCliente) cuentaCliente = cuentaCliente importeServicio Escribir (cuentaCliente) Leer (cuentaPrestatario) cuentaPrestatario = cuentaPrestatario + importeServicio Escribir (cuentaPrestatario) (1)

Qu ocurre si se ejecuta nuevamente la transaccin? INCONSISTENCIA Qu pasa si no hacemos nada? INCONSISTENCIA

Transacciones: Fallos
16

Conclusin: Reejecutar o no una transaccin fallida NO asegura la consistencia de la Base de Datos.

Es necesario realizar acciones que permitan retrotraer el estado de la Base de Datos al instante anterior al comienzo de ejecucin de la transaccin. Estas acciones tienen que ver con dejar constancia de las actividades llevadas a cabo por la transaccin, que permitirn deshacer los cambios producidos.

Recuperacin de los fallos

17

Para garantizar la consistencia de la base de datos y la atomicidad de las transacciones a pesar de los fallos, existen algoritmos de recuperacin que constan de dos partes:
1.

Acciones que se ejecutan durante el procesamiento normal de las transacciones, que realizan acciones que permiten recuperar el estado de consistencia de la Base de Datos ante un fallo.
Acciones que se activan luego de detectarse un error en el procesamiento de las transacciones, que permiten recuperar el estado de consistencia ante un fallo.

2.

Mtodo de bitcora
18

El mtodo de bitcora o registro histrico consiste en registrar, en un archivo auxiliar y externo a la Base de Datos, todos los movimientos producidos por las transacciones antes de producir los cambios sobre la Base de Datos misma.
En caso de producirse un error, se tiene constancia de todos los movimientos efectuados. La estructura del archivo es simple. Cada transaccin debe indicar su comienzo, su finalizacin y cada una de las acciones llevadas a cabo sobre la Base de Datos que modifiquen su contenido.

Mtodo de bitcora
19

El gestor del SGBD es el encargado de administrar el archivo de bitcora. Para esto identifica cada transaccin asignndole un nmero correlativo nico. El formato de una transaccin en bitcora es:
<Ti comienza> <Ti, dato1, valor viejo, valor nuevo> <Ti, dato2, valor viejo, valor nuevo> <Ti, datoN, valor viejo, valor nuevo> <Ti finaliza>

Mtodo de bitcora
20

En el caso que la transaccin fallara, se proceder a abortarla. Una vez abortada, debe agregarse:
<Ti aborta>

Segn la naturaleza del fallo, puede ocurrir que en la bitcora se registren un comienza, algunos cambios en la Base de Datos, y luego no se registre finaliza u aborta. Para esta situacin, la transaccin debe abortarse.

Mtodo de bitcora
21

Solo se registran en bitcora las instrucciones que modifican el contenido de la Base de Datos (las operaciones de escritura). Por ejemplo, la transaccin que efecta el pago de un servicio se registrar as:
<Ti, comienza> <Ti, cuentaCliente, 4500, 4350> <Ti, cuentaPrestatario, 1234500, 1234650> <Ti finaliza>

Mtodo de bitcora
22

Se debe garantizar que primero se graben los buffers correspondientes al archivo de bitcora en memoria secundaria, antes de grabar en disco los buffers de la Base de Datos.
El manejo de buffers de archivo es responsabilidad del sistema operativo. Si ste tuviera la necesidad de escribir en disco el buffer de la BD, el gestor de BD deber operar contra el SO, indicando que primero debe escribir el buffer correspondiente a la bitcora, an si esto no fuese necesario en ese momento.

Mtodo de bitcora
23

Durante el procesamiento normal de las transacciones, se genera el registro en bitcora y luego se actualiza la Base de Datos. Para todas las transacciones que alcanzan el estado de finalizada, el trabajo registrado en bitcora es innecesario. Slo cuando se produce un error, se deben activar las acciones que subsanan dicho error, utilizando para ello el registro en bitcora.

Mtodo de bitcora
24

Presenta dos alternativas para implementar el mtodo de recuperacin:

Modificacin diferida de la Base de Datos: Todas las escrituras en disco de las actualizaciones de la Base de Datos se demoran hasta que la transaccin alcance el estado de finalizada en bitcora. Modificacin inmediata de la Base de Datos: Ante un cambio, se guarda en la Bitcora y luego inmediatamente se lleva a la Base de Datos.

Mtodo de bitcora (Modificacin diferida de la

Base de Datos)
25

Ventaja: Si una transaccin activa falla, se puede asegurar que los cambios producidos por la transaccin no tuvieron impacto sobre la Base de Datos. El fallo es ignorado y la BD permanece ntegra.
La transaccin slo debe registrar:
<Ti, datoN, valor nuevo>

Ya que no es posible modificar la Base de Datos hasta que la transaccin alcanza el estado de finalizada.

Mtodo de bitcora (Modificacin diferida de la

Base de Datos)
26

Existe una condicin bajo la cual la Base de Datos puede perder la integridad. Esto ocurre cuando en bitcora la transaccin alcanza el estado de finalizada, entonces se empieza la actualizacin de la BD y en ese momento se produce un fallo.
Cuando el sistema se recupera del fallo, se ejecutan las acciones que permiten recuperar la integridad de la Base de Datos. Este mtodo utiliza un procedimiento recuperacin, denominado REHACER. de

Mtodo de bitcora (Modificacin diferida de la

Base de Datos)
27

Despus de ocurrir un fallo, el subsistema de recuperacin consulta la bitcora para determinar las transacciones que deben rehacerse. Una transaccin T debe rehacerse si y slo si en bitcora contiene los registros <T comienza> y <T finaliza>, y por consiguiente ejecuta el algoritmo REHACER.

Mtodo de bitcora (Modificacin diferida de la

Base de Datos)
28

Cuando la falla ocurre justo despus de haber escrito en almacenamiento estable, la ejecucin resulta innecesaria porque la Base de Datos estaba bien. Sin embargo, el algoritmo de recuperacin no tiene forma de detectar esta situacin; la transaccin se reejecuta, dejando la Base de Datos nuevamente en estado de consistencia. Las transacciones tienen una condicin de idempotencia. Esta condicin asegura que aunque se reejecute n veces una transaccin, se genera siempre el mismo resultado sobre la Base de Datos.

Mtodo de bitcora (Modificacin inmediata de la

Base de Datos)
29

Los cambios en la Base de Datos se realizan a medida que se producen en la transaccin que se est ejecutando, siempre bajo la consigna que indica que un cambio se registra primero en bitcora para luego grabarse en la Base de Datos.
Cuando el fallo se produce luego de haberse registrado en bitcora un <T finaliza>, tambin se utilizar el procedimiento REHACER.

Mtodo de bitcora (Modificacin inmediata de la

Base de Datos)
30

Qu se hace si ocurre un fallo durante una transaccin y la Base de Datos est parcialmente modificada?
La Base de Datos qued en estado de inconsistencia, y la transaccin no puede reejecutarse (REHACER) porque no alcanz el estado de finalizada. Para estas situaciones, existe otro procedimiento, llamado DESHACER, cuyo efecto es retrotraer la Base de Datos al estado que tena antes de comenzar la transaccin. DESHACER vuelve a la Base de Datos los valores viejos de cada dato modificado por Ti registrados en bitcora.

Mtodo de bitcora (Modificacin inmediata de la

Base de Datos)
31

En resumen, si se produce un error, se debe REHACER toda transaccin de la bitcora que haya finalizado, y se debe DESHACER toda transaccin iniciada que no haya finalizado.

Mtodo de bitcora
32

Supongamos que durante un determinado tiempo no se han producido incidentes en la operacin con la Base de Datos. Las transacciones ejecutadas quedaron registradas en bitcora.
Cuando se produce un fallo, sin importar el mtodo de recuperacin utilizado, debern rehacerse todas las transacciones que tengan registrados <T comienza> y <T finaliza>. Es altamente probable que un gran porcentaje de las transacciones hayan finalizado bien, dejando la Base de Datos consistente.

Mtodo de bitcora
33

Rehacer todo ese trabajo es muy lento e innecesario.

Con el fin de evitar la revisin de toda la bitcora ante un fallo, el gestor de Base de Datos realiza peridicamente puntos de verificacin, para lo cual se ejecutan las siguientes acciones:
1.

2.

3.

Escritura en almacenamiento estable de todos los registros de la bitcora que residan en ese momento en memoria principal. Escritura en disco de todos los bloques de memoria intermedia que se hayan modificado. Escritura en almacenamiento estable de un registro de la bitcora <punto de verificacin>.

Mtodo de bitcora
34

Mientras se lleva a cabo un punto de verificacin no se permite que ninguna transaccin realice acciones de actualizacin. La finalidad es indicar que, ante un fallo, slo debe revisarse la bitcora desde el punto de verificacin en adelante.

Doble paginacin
35

Este mtodo, tambin llamado paginacin en la sombra, considera que la Base de Datos est compuesta por varias pginas de disco (o bloques de disco) de tamao fijo (por ejemplo n).
Se construye un directorio (tabla) con n entradas, donde la i-sima entrada de la tabla apunta a la isima pgina de la Base de datos. El directorio se mantiene en memoria principal si no es demasiado grande, y todas las lecturas y escrituras de la BD en el disco pasan a travs de l.

Doble paginacin
36

Cuando una transaccin comienza a ejecutarse, el directorio actual se copia en un directorio sombra. ste se guarda en disco mientras la transaccin usa el directorio actual. Durante la ejecucin de transacciones, el directorio sombra nunca se modifica. Cuando se efecta un write, se crea una nueva copia de la pgina de la BD modificada, pero no se sobreescribe la copia antigua de esa pgina. La nueva pgina se escribe en algn otro sitio (por ejemplo, en un bloque de disco desocupado). La entrada del directorio actual se modifica de modo que apunte al nuevo bloque de disco, mientras que el directorio sombra no.

Doble paginacin
37
1 2 3 4 5 6 ... 1 2 3 4 5 6 ...

Tabla de Directorio pginas Actual sombra Pginas en Disco

Tabla Directorio Actual de Sombra Pginas

Doble paginacin
38

Para recuperarse de un fallo mientras se ejecuta una transaccin basta con liberar las pginas modificadas de la Base de datos y desechar el directorio actual. El estado de la BD antes de ejecutarse la transaccin est disponible a travs del directorio sombra, y se recupera haciendo que el directorio sombra sea otra vez el directorio actual. As, la BD vuelve al estado previo a la transaccin que se estaba ejecutando cuando ocurri el fallo.
Confirmar una transaccin supone desechar el directorio sombra previo.

Doble paginacin
39

Desventajas:

La tarea de dividir la Base de Datos en pginas puede resultar compleja. Las pginas actualizadas de la BD cambian de lugar en el disco. El costo de escribir directorios sombra en disco cada vez que se confirman las transacciones es significativo. Es necesario definir algoritmos denominados recolectores de basura que detecten nodos no referenciados y liberen el espacio ocupado no utilizado. La operacin de migracin entre los directorios actual y sombra debe ser implementada como una operacin atmica.