Explica el concepto de transacción, fallo y recuperación de fallos, proponiendo al

menos dos posibles transacciones en escenario de las entregas anteriores.

Una transacción es una colección de acciones que hacen transformaciones consistentes

de los estados de un sistema preservando la consistencia del sistema. Una base de datos
está en un estado consistente si obedece todas las restricciones de integridad definidas
sobre ella. Los cambios de estado ocurren debido a actualizaciones, inserciones, y
supresiones de información. Por supuesto, se quiere asegurar que la base de datos nunca
entra en un estado de inconsistencia. Sin embargo, durante la ejecución de una
transacción, la base de datos puede estar temporalmente en un estado inconsistente. El
punto importante aquí es asegurar que la base de datos regresa a un estado consistente
al fin de la ejecución de una transacción.

Lo que se persigue con el manejo de transacciones es por un lado tener una

transparencia adecuada de las acciones concurrentes a una base de datos y por otro lado
tener una transparencia adecuada en el manejo de las fallas que se pueden presentar en
una base de datos.

TIPOS DE FALLAS.

El sistema debe estar preparado para recuperarse no sólo de fallas puramente

locales, como la aparición de una condición de desborde dentro de una transacción,
sino también de fallas globales, como podría ser la interrupción del suministro
eléctrico al CPU.

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.
Estas fallas pueden ser:
1
  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 (cash) 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.

Además, puede ocurrir que sea necesario volver a ejecutar algunas transacciones
que sí se realizaron con éxito antes de la falla, pero cuyas modificaciones no
lograron efectuarse sobre la base de datos porque no lograron ser transferidas de
los buffers de la base de datos a la base de Datos física (en disco).

• 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 DB. La recuperación de una falla semejante implica
en esencia cargar de nuevo la DB 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 DB después

de una falla de los medios de almacenamiento a partir de una copia de respaldo

2
especificada.
Por ejemplo, una falla en el controlador de disco o un aterrizaje de cabeza en el disco,
estas fallas sí causan daños a la base de datos o a una porción de ella y afecta, al
menos, a las transacciones que están haciendo uso de esa porción.

Las fallas de los medios de almacenamiento se llaman caídas duras. La

Recuperación de una falla semejante implica, en esencia, cargar de nuevo la base
de datos a partir de una copia de respaldo (data base Backus) y después utilizar la
bitácora, o sistema log, para realizar de nuevo todas las transacciones terminadas
desde que se hizo esa copia para respaldo.

No hay necesidad de anular todas las transacciones inconclusas en el momento de

la falla, porque por definición esas transacciones ya se anularon (se destruyeron) de
todas maneras.

• FALLAS POR CATÁSTROFES:

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 de
la data base Backus.

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

• ERRORES DEL SISTEMA:

Como realizar operaciones que causen un ovarlo 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

3
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 in VAX/VMS o en
UNIX).

• APLICACIÓN DEL CONTROL DE CONCURRENCIA:

Que ocurre por ejemplo cuando una transacción viola las reglas de socialización o cae en
abrazo mortal o interbloqueo.

Los sistemas que tratan el problema de control de concurrencia permiten que sus
usuarios asuman que cada una de sus aplicaciones se ejecutan atómicamente, como si
no existieran otras aplicaciones ejecutándose concurrentemente.

Esta abstracción de una ejecución atómica y confiable de una aplicación se conoce como
una transacción.

Un algoritmo de control de concurrencia asegura que las transacciones se ejecuten

atómicamente controlando la intercalación de transacciones concurrentes, para dar la
ilusión de que las transacciones se ejecutan seriamente, una después de la otra, sin
ninguna intercalación. Las ejecuciones intercaladas cuyos efectos son los mismos que las
ejecuciones seriales son denominadas serializarles y son correctos ya que soportan la
ilusión de la atomicidad de las transacciones.

El concepto principal es el de transacción. Informalmente, una transacción es la ejecución

de ciertas instrucciones que accedan a una base de datos compartida. El objetivo del
control de concurrencia y recuperación es asegurar que dichas transacciones se ejecuten
atómicamente, es decir: Cada transacción accede a información compartida sin interferir
con otras transacciones, y si una transacción termina normalmente, todos sus efectos son
permanentes, en caso contrario no tiene afecto alguno.

4
Los cambios de estado ocurren debido a actualizaciones, inserciones y supresiones de
información. Por supuesto, se quiere asegurar que la base de datos nunca entre en un
estado de inconsistencia.

Sin embargo, durante la ejecución de una transacción, la base de datos puede estar
temporalmente en un estado inconsistente.

El punto importante aquí es asegurar que la base de datos regresa a un estado

consistente al fin de la ejecución de una transacción.

PROPIEDADES FUNDAMENTALES DE UNA TRANSACCIÓN:

Atomicidad Se refiere al hecho de que una transacción se trata como una unidad de
operación.

Por lo tanto, o todas las acciones de la transacción se realizan o ninguna de ellas se lleva
a cabo. La atomicidad requiere que, si una transacción se interrumpe por una falla, sus
resultados parciales sean anulados.

Consistencia La consistencia de una transacción es simplemente su correctito. En otras

palabras, una transacción es un programa correcto que lleva a la base de datos de un

5
estado consistente a otro con la misma característica. Debido a esto, las transacciones no
violan las restricciones de integridad de una base de datos.

Aislamiento Una transacción en ejecución no puede revelar sus resultados a otras

transacciones concurrentes antes de finalizar.

Más aún, si varias transacciones se ejecutan concurrentemente, los resultados deben ser
los mismos que si ellas se hubieran ejecutado de manera secuencial.

Permanencia Es la propiedad de las transacciones que asegura que una vez que una
transacción finaliza exitosamente, sus resultados son permanentes y no pueden ser
borrados de la base de datos por alguna falla posterior.

Por lo tanto, los sistemas manejadores de base de datos aseguran que los resultados de
una transacción sobrevivirán a fallas del sistema. Esta propiedad motiva el aspecto de
recuperación de base de datos, el cual trata sobre cómo recuperar la base de datos a un
estado consistente donde todas las acciones que han finalizado con éxito queden
reflejadas en la base.

En esencia, lo que se persigue con el procesamiento de transacciones es, por una parte,
obtener una transparencia adecuada de las acciones concurrentes a una base de datos y
por otra, manejar adecuadamente las fallas que se puedan presentar en una base de
datos.

La mayoría de medianas y grandes compañías modernas utilizan el procesamiento de

transacciones para sus sistemas de producción, y es tan imprescindible que las
organizaciones no pueden funcionar en ausencia de él.

El procesamiento de transacciones representa una enorme y significativa porción del

mercado de los sistemas informáticos (más de cincuenta billones de dólares al año) y es,
probablemente, la aplicación simple más amplia de las computadoras.

En esta ocasión, la asignación es proponer dos consultas a la

información que sean no-atómicas, es decir, proponer consultas que
representen una transacción.
6
Atomicidad: establece que las modificaciones de la base de datos deben seguir una
regla de "todo o nada ". Se dice que cada transacción es "atómica". Si una parte de la
transacción falla, la transacción completa falla. Es fundamental que el sistema de
administración de la base de datos mantenga la naturaleza atómica de las transacciones
a pesar de cualquier sistema de gestión de bases de datos relacionales, sistema operativo
o fallo de hardware.

La consistencia indica que solo se escribirán datos válidos en la base de datos. Si por
alguna razón, se ejecuta una transacción que viola las reglas de consistencia de la base
de datos, la transacción completa se revertirá y la base de datos se restaurará a un
estado consistente con esas reglas. Por otro lado, si una transacción se ejecuta con éxito,
llevará la base de datos al nuevo estado consistente con las reglas.

El aislamiento requiere que las transacciones múltiples que ocurren al mismo tiempo no

afecten la ejecución del otro. Por ejemplo, si Joel emite una transacción contra una base

de datos al mismo tiempo que Charles emite una transacción diferente, ambas

transacciones deberían operar en la base de datos de manera aislada. La base de datos

debe realizar la transacción completa de Joel antes de ejecutar la de Charles o viceversa.

Esto evita que la transacción de Joel lea datos intermedios producidos como un efecto

secundario de parte de la transacción de Charles que eventualmente no se comprometerá

con la base de datos. Ten en cuenta que la propiedad de aislamiento no garantiza qué

transacción se ejecutará primero, simplemente que las transacciones no interferirán entre

sí.

La durabilidad asegura que cualquier transacción comprometida con la base de datos no

se perderá. La durabilidad se garantiza mediante el uso de copias de seguridad de la

base de datos y registros de transacciones que facilitan la restauración de transacciones

comprometidas a pesar de cualquier fallo de software o hardware.

7
Existen tres modelos para atender peticiones en un sistema de transacciones con
replicación:

Asíncrono: Son modelos donde las peticiones son procesadas por servidores de réplicas
locales.

Síncrono: En este modelo las peticiones de modificación son procesadas en el mismo

orden en todas las réplicas (orden total).

Mixto: En este modelo ciertas réplicas pueden ser contactadas y procesadas por el mismo
orden.

El modelo seleccionado depende de la razón entre el número promedio de lecturas y

escrituras. El orden en que pueden ser procesadas dos peticiones r1 y r2 en los
servidores de réplicas son:

Total: Si r1 es procesada antes que r2 en todos los servidores de réplicas

o viceversa.

Casual: Si r1  r2, lo que implica que r1 sea procesado antes que r2 en todos los
servidores de réplicas.

Conclusiones

El guardado y recuperación de la información, en el cual los objetos generados mediante

la programación son guardados como objetos en la base de datos, permitiendo así, tener
una idea clara de que es lo que está sucediendo con la información y como se encuentra
clasificada en la base de datos. Por consiguiente, el guardar la información de esta
forma, nos permite tener una recuperación eficiente y rápida, sin reestructurar
información en el proceso. Este se cumplió gracias a que la base de datos en que se
desarrolló el almacenamiento permitió la generación de tipos de datos necesarios para
nuestro modelo. Reduciendo así las restricciones de tipos de datos como los que son
8
manejados en una base de datos relacional.

Se ha hecho especial hincapié en transacciones, fallos y recuperación de fallos a través

de métodos y algoritmos muy frecuentes.

También debería tenerse presente la existencia de enfoques de fragmentación distintos y,

posiblemente, más complejos, pero se debe pensar que más eficientes. Si bien, estos
métodos son enfoques formales más que prácticos, desarrollados por insignes
investigadores en universidades.

Pese a la aparición de los métodos de bases de datos distribuidas hace ya años, parece
que el salto de lo centralizado a lo distribuido a escala comercial está por venir. Todavía
no se ha extendido suficientemente el esquema distribuido, pero se espera que
próximamente se produzca el avance definitivo. Considere los dos componentes básicos
de los sistemas de bases de datos distribuidos (la propia base de datos y la red de
ordenadores) y piense en la situación actual de la informática. Si las bases de datos es
una de las ramas más antiguas e importantes de la informática.

Se debe de apostar más fuerte por este enfoque a través de sus famosos sistemas
gestores de bases de datos y que se produzca la consolidación de la resolución de los
problemas que el enfoque distribuido acarrea.

El impacto que presenta se debe a la estructura de la información. Permite una

transparencia amplia, y una reducción de tablas y tuplas en su base de datos. Entre ellas
encontramos el modelo orientado a objeto, el cual nos permite guardar la información de
un objeto creado en la base de datos, y no generar más tablas y tuplas de las necesarias,
como es el caso del modelo relacional. Ese último la información se encuentra distribuida
tanto en varias tablas como tuplas este formada. Con el modelo orientado a objeto nos
olvidamos de tener que reestructurar nuestra información tomando de diferentes tablas la
información.

9
Bibliografía

Capítulo 2: Arquitectura de Base de datos distinuida. (s.f.). En A. Bolivia, Diseño

de Base de Datos Distribuida. Cochabamba – Bolivia: IC Editorial.

PARTE 7 ARQUITECTURA DE SISTEMAS- Cap 20 Arquitecturas de los sistemas

de bases de datos. (2006). En A. S.-H. KORTH-SUDARSHAN, Fundamentos de
Bases de Datos Quinta Edicion (págs. 663-666). Madrid: McGRAW-
HILL/INTERAMERICANA DE ESPAÑA, S.A.U.

10