Instituto de Estudios Universitarios Online.

Maestría en
Ciencias de la Computación
y Telecomunicaciones

Materia:
Bases De Datos Distribuidas En Las Telecomunicaciones

Profesor(a):
Mtro. Juan Manuel Amezcua Ortega

Semana 4 Actividad 4:
Actividad de aprendizaje 4. Caso de Aplicación: Transacciones en las B.D.
Distribuidas
Alumno:
Faustino Benjamín Rivera López

Matricula:
76613

Grupo:
CC18

Oaxaca de Juárez, Oaxaca 01 de mayo del 2017

Índice
Introducción ............................................................................................................. 3

Transacción, fallo y recuperación................................................................................ 4

Consultas no-atómicas ....................................................Error! Bookmark not defined.

Análisis de fallo y recuperación .................................................................................. 7

Conclusión ................................................................................................................ 9

Bibliografía ............................................................................................................. 10
Introducción
Recuperarse al fallo de una transacción significa que la base de datos se restaura al estado
coherente más reciente, es decir, inmediatamente anterior al momento del fallo para esto
el sistema guarda la información sobre los cambios de las transacciones esta información
se guarda en el registro del sistema.

Para asegurar la consistencia en la base de datos y la atomicidad de las transacciones (a

pesar de los fallos), los algoritmos tienen dos partes: Acciones tomadas durante el
procesamiento normal de la transacción para asegurar que existe suficiente información
para permitir la recuperación de fallos (preventivas) y las acciones tomadas a continuación
de un fallo para asegurar la consistencia de la base de datos y la atomicidad de las
transacciones. En este trabajo analizaremos y ejemplificamos los conceptos mencionados.
Transacción, fallo y recuperación
Transacción.
Una transacción es una unidad de la ejecución de un programa. Puede consistir en
varias operaciones de acceso a la base de datos. Esta se inicia por la ejecución de un
programa de usuario escrito en un lenguaje de manipulación de datos de alto nivel y está
delimitada por constructoras como begin-transaction y end-transaction. Para asegurar la
integridad de los datos, se necesita que el sistema de base de datos mantenga las
siguientes propiedades de las transacciones:

 Atomicidad. Se ejecutan todas las sentencias o ninguna. O todas las operaciones

de la transacción se realizan adecuadamente en la base de datos o ninguna de ellas.

 Preservación de la 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. Ya que una transacción no muestra los cambios que produce hasta
que finaliza.

 Persistencia. Ya que una vez que finaliza la transacción con éxito, sus efectos
perduran en la BD.

 Seriabilidad. En el sentido de que el efecto de ejecutar transacciones

concurrentemente debe ser el mismo que se produciría al ejecutarlas por separado
en un orden secuencial según van entrando en el sistema.

Fallas.
Las fallas locales son las que afectan sólo a la transacción en donde ocurrió. Por
el contrario las fallas globales, afectan a varias -y casi siempre a todas- las
transacciones que se estaban efectuando en el momento de la falla, por lo cual tienen
implicaciones importantes en el sistema.
Tipos de fallas
  Falla del sistema. Por ejemplo interrupción del servicio eléctrico, estas afectan a
todas Las transacciones que se estaban ejecutando pero no afectan a la base de
datos. Las fallas de sistema se conocen también como caídas (crash) suaves. El
problema aquí es que se pierda el contenido de memoria principal, en particular, las
áreas de almacenamiento temporal o buffers. Si esto ocurre, no se conocerá el
estado preciso de la transacción que se estaba ejecutando en el momento de la
falla, esta transacción jamás se podrá completar con éxito por lo que será preciso
anularla cuando se reinicie el sistema.
 Fallas en los medios de almacenamiento. Una falla de los medios de
almacenamiento es un percance en el cual se destruye físicamente alguna porción
de la base de datos. La recuperación de una falla semejante implica en esencia
cargar de nuevo la base de datos a partir de una copia de respaldo y utilizar después
la bitácora para realizar de nuevo todas las transacciones terminadas desde que se
hizo esa copia de respaldo. No hay necesidad de anular las transacciones
inconclusas en el momento de la falla, porque por definición todas las
modificaciones de esas transacciones ya se anularon de todas maneras.La parte de
restauración de la utilería servirá entonces para recrear la base de datos después
de una falla de los medios de almacenamiento a partir de una copia de respaldo
especificada.
 Fallas por catastrofes. Por ejemplo terremotos, incendios, inundaciones, etc. Su
tratamiento es similar al de fallas de los medios. La principal técnica para manejar
este tipo de fallas es la del database backup . Como se mencionó anteriormente,
este es un respaldo periódico que se hace de la base de datos. Después de una
caída de esta índole el sistema se restaura recargando la base de datos con la copia
del último respaldo y recreando la base de datos mediante la bitácora o system log.
 Errores del sistema. Como realizar operaciones que causen un overflow de un
entero o la división por cero, así mismo puede ocurrir que se pasen valores erróneos
a algún parámetro o que se detecte un error en la lógica de un programa, o que
sencillamente no se encuentren los datos del programa. Además, en algunos
ambientes de desarrollo el usuario puede explícitamente interrumpir una
transacción durante su ejecución (por ejemplo: usando el control_C in VAX/VMS
o en UNIX)

Recuperación de fallas.
La recuperación en un SBD (Sistema de Base de Datos) consiste en (volver a) dejar
la información almacenada en la base de datos en un estado consistente (correcto),
después de un fallo (o caída) del sistema que ha llevado la BD a un estado inconsistente,
o por lo menos “sospechoso” de serlo. Los SBD pequeños no suelen proporcionar
soporte para la recuperación. Sí lo hacen los grandes sistemas de base de datos
multiusuario.
El módulo componente del SGBD encargado de que el SBD sea seguro frente a
posibles fallos, es el Subsistema Gestor de Recuperación, cuya función es, entre otras
cosas, velar por que:
 Las transacciones no se pierdan (es decir, que se ejecuten)
 Las transacciones no se realicen parcialmente (deben ejecutarse en su totalidad)
 No se ejecute una operación más de una vez o, si se hace, que el resultado sea
equivalente al obtenido si se hubiera realizado una única vez.
Análisis de fallo y recuperación
Existen diversas causas por las que el sistema de bases de datos puede fallar.
Algunos tipos de fallos son los siguientes:
1. Errores locales previstos por la aplicación (rollback explícito o programado)
Durante la ejecución de una transacción pueden presentarse condiciones que
requieran la cancelación de la misma (por ejemplo, un saldo insuficiente en una
cuenta bancaria implica la cancelación de una transacción de reintegro sobre dicha
cuenta).
2. Errores locales no previstos (overflow, división por cero...)Errores lógicos de
programación (bugs), o interrupciones provocadas (ctrl-Cen entornos Unix...).Un
fallo local sólo afecta a la transacción que se está ejecutando donde ha
ocurrido el fallo. Normalmente supone la pérdida de los datos en memoria principal
y en los búferes de entrada/salida.
3. Fallos por imposición del control de concurrencia El Subsistema de Control
de Concurrencia puede decidir abortar una transacción T (para reiniciarla
posteriormente) bien porque viola la seriabilidad o porque varias transacciones
están en un estado de bloqueo mortal y se ha seleccionado T como víctima.
4. Fallos del sistema (caídas suaves) Consisten en un mal funcionamiento del
hardware, errores software (del SGBD o del SO) o de red, que afectan a todas
las transacciones en progreso de ejecución en el sistema de BD. No dañan
físicamente el disco (el contenido de la BD permanece intacto y no se
corrompe), pero se pierden los datos en la memoria principal y en los búferes de
entrada/salida.
5. Fallos de disco (caídas duras) Son fallos en los dispositivos de almacenamiento
(por ejemplo, si ocurre una rotura o un aterrizaje de alguna cabeza lectora-
escritora en el disco, si funciona mal la lectura o la escritura, o si ocurre un fallo
durante una transferencia de datos). Afectan a todas las transacciones en
curso y suponen la pérdida de información en disco (es decir, algunos bloques
del disco pueden per-der sus datos).
6. Fallos catastróficos o físicos Algunos ejemplos son el corte del suministro
eléctrico, robo del disco, incendio, sabotaje, sobre escritura en discos o cintas
por error, etc.
Un primer criterio es asegurar que «una vez que una transacción T se ha confirmado,
nunca será necesario deshacerla» (anularla, cancelarla, revertirla, abortarla). Un plan
que cumple este criterio es un plan recuperable. Un plan P es recuperable si ninguna
transacción T de P se confirma antes de haberse confirmado toda transacción T’ que haya
escrito un dato que T lee.

En un plan recuperable nunca tiene que deshacerse una transacción confirmada.

Sin embargo puede ocurrir el fenómeno de la reversión en cascada, en el cual
una transacción no confirmada ha de deshacerse por haber leído un elemento de una
transacción que ha fallado. La cancelación en cascada puede consumir mucho tiempo,
si hubiera que deshacer una gran cantidad de transacciones, así que es interesante
caracterizar los planes en los que se garantiza que nunca ocurrirá este fenómeno.

Un plan sin cascada es aquel en el que toda transacción sólo lee datos escritos
por transacciones confirmadas. Así, nunca ocurrirá que T aborte después de haber escrito
un dato que luego haya leído T’, pues T’ no leerá un elemento a menos que se haya
confirmado toda transacción que lo haya escrito (en particular T).

Por último definimos un plan estricto, en el que las transacciones no pueden leer
ni escribir un elemento hasta que se haya confirmado (o abortado) toda transacción
que lo haya escrito. Los planes estrictos evitan un problema que puede surgir a la
hora de recuperar el fallo de una transacción, tal y como explicamos seguidamente
mediante un ejemplo. Si una transacción falla y por tanto ha de revertirse, hay que deshacer
sus operaciones de escritura. Deshacer una operación de escritura, por ejemplo e(X,5),
consiste en restaurar X a su valor anterior (el que tenía justo antes de realizar dicha
escritura).
Conclusión

Normalmente, la tarea de recuperar información implica especificar un conjunto de

palabras clave que describan los contenidos de los documentos a recuperar. Después de
un primer intento y de observar los documentos recuperados, si la respuesta del sistema
no se considera los suficientemente buena, el usuario suele entonces escoger otro conjunto
de palabras clave para describir de nuevo la consulta anterior y tratar de obtener una
respuesta que cubra mejor sus necesidades.

En otras ocasiones, al recibir la respuesta a una consulta, al usuario le puede surgir una
nueva necesidad de información que cambia su objetivo inicial y que se expresa con una
nueva consulta más o menos relacionada con la anterior. Este trabajo nos permitió analizar
los conceptos de transacción y recuperación ante fallos y explicar cómo están relacionados
estos dos términos a si cómo su operación en conjunto.
Bibliografía

Jiménez, C. M. Y. (2014). Bases de datos relacionales y modelado de datos (UF1471).

Madrid, ESPAÑA: IC Editorial.

Silberschatz, A.; Korth, H. F.; Sudarshan, S. (2011)

A. Silberschatzet al., Fundamentos de Bases de Datos (5ª edición). Ed. McGraw-Hill, 2006.

Rendón, A. (2014). Administración de bases de datos. Mexico: IU3.

Elmasri, R.; Navathe, S.B. Fundamentos de Sistemas de Bases de Datos. 3ª Edición.

Madrid [etc.]: Addi-son-Wesley, Pearson Educación, 2002.