S.E.P.

S.N.E.S.T. D.G.E.S.T.

INSTITUTO TECNOLGICO
DEL ISTMO
MATERIA:
Base de Datos Distribuidas.
CATEDRATICO:

Gmez Valdivieso Mara Isabel.

ALUMNA:

Velazquez Castillo Leslie.

TEMA:

Unidad 4 Mapeo de Transacciones.

ESPECIALIDAD:

Ing. En sistemas Computacionales

GRUPO:

8O

HEROICA CIUDAD DE JUCHITAN DE ZARAGOZA, OAXACA.

I N D I C E.
Unidad 4 Mapeo de Transacciones.3
4.1 Transacciones....................................................................3
4.1.1 Estructura de Transacciones..................9
4.1.2 Ejecucin de Transacciones...........................................11
4.1.3 Estructura de Transacciones..........................................15

4.2 Control de Concurrencia.17

4.2.1 Serializacion de Transacciones.19
4.2.2 Algoritmos de control de Concurrencia.21
4.2.3 Disciplinas de interbloqueo.22

4.3 Confiabilidad..24
4.3.1 Conceptos bsicos de confiabilidad.25
4.3.2 Protocolos REDO/UNDO27
4.3.3 Checkpoints...30
4.3.4 Protocolos 2Pc de confiabilidad distribuida.32

UNIDAD 4 MANEJO DE TRANSACCIONES.

4.1 TRANSACCIONES.
Concepto: Es una unidad de ejecucin en un programa que accede y
posiblemente actualiza varios elementos de datos.
Una transaccin es una coleccin que hacen transformaciones consistentes de los
estados de un sistema preservando la consistencia del sistema. Se dice que una
base de datos esta 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 informacin.
Una

transaccin en

un Sistema de Gestin de

Bases

de Datos

( S G B D ) , e s u n conjunto de rdenes que se ejecutan formando una unidad de

trabajo, es decir, en forma indivisible o atmica.
Es un conjunto de acciones llevadas a cabo por un usuario o un
p r o g r a m a d e aplicacin, que acceden o cambian el contenido de la base de
datos.
Una transaccin consiste en una serie de operaciones. Realizado en una
base de datos. La cuestin importante en ir a la gestin de transacciones es que si
una base de datos estaba en un, estado coherente antes de la iniciacin de una
transaccin a continuacin, la base de datos debe volver a un estado
coherente. Despus de la t r a n s a c c i n s e h a c o m p l e t a d o .
Esto se debe hacer

independientemente del hecho de q u e

l a s t r a n s a c c i o n e s s e ejecutado con xito al mismo tiempo o hay fallos

durante la ejecucin. Por lo tanto, una transaccin es una unidad de la
coherencia y la fiabilidad.
3

Las transacciones fueron originalmente desarrolladas para ser utilizadas dentro de

los sistemas de base de datos, donde se usaba para ayudar en el mantenimiento
de los datos de las aplicaciones y que dependan de la
c o n s i s t e n c i a d e l a informacin almacenada.
Las

transacciones

construccin

de

son

mecanismos

sistemas

que

confiables

ayudan
mediante

simplificar
procesos

la
que

proporcionan soporte uniforme para invocar y sincronizar operaciones como:

Operaciones de comparacin de datos.

Aseguramiento de la seriabilidad de las transacciones con otras.
Atomicidad en su comportamiento.
Recuperacin de fallas.

La palabra transaccin describe una secuencia de operaciones con uno

o ms recursos que transforman su estado actual en un nuevo estado de
consistencia. Es un conjunto de operaciones sobre datos que son
tratadas como una unidad. Una transaccin puede terminar, haciendo
sus cambios persistentes, o abortar voluntaria o involuntariamente
Una

transaccin

es

una

coleccin

de

operaciones

que

hacen

transformacionesconsistentes de los estados de un sistema conservando la con

sistencia delsistema. Una base de datos est en estado consistente si cumple
todas las restricciones de integridad definidas sobre ella. Los cambios de
estado

se

dan

debido a actualizacin, insercin y eliminacin de la informacin. Se qui

ere a s e g u r a r q u e l a b a s e d e d a t o s n o e n t r e e n u n e s t a d o d e
inconsistencia,

pero

durante la ejecucin de una transaccin, la base de d

a t o s p u e d e e s t a r temporalmente

en

un

estado

inconsistente.

Lo

importante aqu es asegurar que la b a s e d e d a t o s v u e l v a a u n e s t a d o

c o n s i s t e n t e a l c o n c l u i r l a e j e c u c i n d e u n a transaccin (Figura A).

Figura A. Un modelo de transaccin.

Lo que se persigue con el uso de transacciones es por un lado
c o n t a r c o n u n a transparencia adecuada de las acciones concurrentes a
una base de datos y por el otro tener una transparencia adecuada en el manejo
de las fallas que se pueden presentar en una base de datos.

Instrucciones para el uso de transacciones.

La programacin con uso de transacciones requiere de instrucciones especiales,
las cuales deben ser proporcionadas por el sistema operativo, por el
compilador del lenguaje o por el manejador de la base de datos, algunos son:
BEGIN _TRANSACCIN: Los comandos siguientes forman una transaccin
END _ TRANSACCIN: Termina la transaccin y se intenta un compromiso
ABORT_ TRANSACCIN: Se elimina la transaccin, se recuperan los valores
anteriores
5

READ: Se leen datos de un archivo

WRITE: Se escriben datos en un archivo
Las operaciones entre BEGIN y END integran el cuerpo de la transaccin y deben
ejecutarse todas o ninguna de ellas. La cantidad exacta de instrucciones
disponibles para manejar transacciones depende del tipo de objetos y operaciones
que deban ser procesadas.
Ejemplo 1:
Considere la siguiente consulta en SQL para incrementar el 10% del
presupuesto del proyecto CAD/CAM de la base de datos de ejemplo.

UPDATE J
SET BUDGET = BUDGET*1.1
WHERE JNAME = "CAD/CAM"
Esta consulta puede ser especificada, usando la notacin de SQL, como una
transaccin otorgndole un nombre:
Begin_transaction ACTUALIZA_PRESUPUESTO
begin
UPDATE J
SET BUDGET = BUDGET*1.1
WHERE JNAME = "CAD/CAM"

end.
.
Ejemplo 2:
Considere una agencia de reservaciones para lneas areas con las
siguientes relaciones:
FLIGHT( FNO, DATE, SRC, DEST, STSOLD, CAP )
CUST( CNAME, ADDR, BAL )FC( FNO, DATE, CNAME, SPECIAL )
Una versin simplificada de una reservacin tpica puede ser imp
l e m e n t a d a mediante la siguiente transaccin:
Begin_transaction Reservacin
Begin
Input ( flight_no, date, customer_name );
EXEC SQL UPDATE FLIGHT
SET STSOLD = STSOLD + 1
WHERE FNO = flight_no
AND DATE = date
EXEC SQL INSERT
INTO FC( FNAME, DATE, CNAME,SPECIAL )

VALUES (flight_no, date, customer_name, null )

Output ("reservacin terminada");
end.
Las transacciones cuentan con las siguientes propiedades:

Atomicidad:

Una transaccin es tratada como una unidad de operacin. Por lo tanto

todas las acciones de la transaccin se llevan a cabo o ninguna de ellas se
realiza .La atomicidad requiere que si una transaccin se interrumpe por una falla,
sus resultados parciales deben ser deshechos. Se efectan todas las
transacciones,

pero

en caso

de

fallas

transaccin debe concluir c o m p r o m e t i d a

no
o

se realiza

abortada.

ninguna.
En

el

Una
caso

d e l c o m p r o m i s o s e i n s t a l a n t o d a s l a s actualizaciones y en el aborto
se descartan todas las actualizaciones.

Consistencia:

Una transaccin es un programa correcto que lleva la base de datos de un estado

consistente a otro con la misma caracterstica. Gracias a esto, las
transacciones no violan las reglas de integridad de una base de datos.

Aislamiento:

Durante la ejecucin de una transaccin, esta no debe revelar sus

resultados a otras transacciones concurrentes antes de su compromiso. Si
varias transacciones se ejecutan concurrentemente, los resultados deben ser los
mismos que si ellas se hubieran ejecutado en forma secuencial (Seriabilidad). La
seriabilidad consiste en asegurarse que los cambios siguen un orden adecuado.

Durabilidad:
8

Es la propiedad de las transacciones que asegura que

una vez que una

transaccin realiza su compromiso, sus resultados son permanentes y no pueden

ser borrados de la base de datos, se asegura que los resultados de una
transaccin sobrevivirn a fallas del sistema.
Las transacciones brindan una ejecucin atmica y confiable en
p r e s e n c i a d e fallas, una ejecucin correcta en presencia de accesos de
usuario mltiples y un manejo correcto de replicas (en el caso que se
soporten).
4 . 1 . 1 E S T R U C T U R A D E T R AN S AC C I O N E S .
La estructura de una transaccin usualmente viene dada segn el
modelo de la transaccin, estas pueden ser planas (simples) o anidadas.

Transacciones planas: Consisten de una secuencia de operaciones

primitivas encerradas entre las palabras clave begin y end.

Por ejemplo:
Begin_transaction Reservacin

End

Transacciones anidadas: Consiste en tener transacciones que

pueden ser de otras transacciones, estn incluidas dentro de otras de un
nivel superior que se les conoce como subtransacciones.

Por ejemplo:
Begin_transaction Reservacin
Begin_transaction Vuelo

End. (Vuelo)
9

Begin_transaction Hotel

End

End.
Una transaccin anidada da otra transaccin conserva las mismas
propiedades que la de sus padres, esto implica, que puede contener as
mismo transacciones dentro de ella.
Existen restricciones obvias

en una

transaccin

anidada:

debe

empezar despusq u e s u p a d r e y d e b e t e r m i n a r a n t e s q u e
l . M s a n , e l c o m m i t d e u n a subtransaccin

es

c o n d i c i o n a l a l c o m m i t d e s u p a d r e , e n o t r a s p a l a b r a s , s i e l padre
de una o varias transacciones aborta, las subtransacciones hijas
tambin sern abortadas.
Las

transacciones

anidadas

brindan

un

nivel

ms

alto

de

c o n c u r r e n c i a e n t r e transacciones. Ya que una transaccin consiste de varias

transacciones
t e n e r
n a

es

m a y o r

s o l a

recuperarse

posible

c o n c u r r e n c i a

t r a n s a c c i n .
de de

fallas

As

d e n t r o
tambin,

es

de forma independiente

d e

posible
de cada

subtransaccion. Esto limita el dao a una parte ms pequea de la

transaccin,
h a c i e n d o
u p e r a c i n

q u e
s e a

e l
e l

c o s t o

d e

l a

r e c

m e n o r .

10

Tambin se deben considerar el orden de las lecturas y escrituras. Si las acciones

de lectura y escritura pueden ser mezcladas sin ninguna restriccin,
entonces, a este tipo de transacciones se les conoce como Generales
.Por el contrario, si se r e s t r i n g e o i m p o n e q u e u n d a t o d e b e s e r
ledo

antes

de

que

pueda

ser

escritoe n t o n c e s s e t e n d r n t r a n s a c c i o n e s R e s t r i n g i d a s . S i l
a s t r a n s a c c i o n e s s o n restringidas a que todas las acciones de lectura se
realicen antes de las acciones de escritura entonces se les conoce como de
Dos Pasos. Finalmente existe un modelo de accin para transacciones
restringidas en donde se aplica aun ms la restriccin de que cada par
<read, write> tiene que ser ejecutado de manera atmica.

4.1.2 EJECUCIN DE TRANSACCIONES CENTRALIZADA Y DISTRIBUIDA.

Los siguientes son los aspectos ms importantes
r e l a c i o n a d o s c o n e l procesamiento de transacciones.
Modelo de estructura de transacciones.
Es importante considerar si las transacciones son planas o anidadas.
Consistencia de la base de datos interna.
Los algoritmos de control de datos tienen que satisfacer las
restricciones de

integridad cuando una transaccin pretende hacer un

compromiso.
Protocolos de confiabilidad.
En

transacciones

distribuidas

es

necesario

introducir

medios

de

comunicacine n t r e l o s d i f e r e n t e s n o d o s d e u n a r e d p a r a g a r a
n t i z a r l a a t o m i c i d a d d e l a s transacciones.

11

Algoritmos de control de concurrencia.

Deben sincronizar la ejecucin de transacciones concurrentes bajo el
criterio

de

correctitud. La consistencia entre transacciones se garanti

z a m e d i a n t e e l aislamiento de las mismas.
Protocolos de control de replicas.
Se refiere a cmo garantizar la consistencia mutua de datos replicados.
El procesamiento de transacciones bsicamente
consiste en una serie de

modificaciones

(transacciones)

un

determinado recurso del sistema (por ejemplo u n a b a s e d e d a t o s ) y e n

donde

se

define

un

punto

de

inicio

un

punto

determinacin que define un bloque entre el conjunto de

o p e r a c i o n e s q u e s o n realizadas.
Dentro de este proceso en bloque los dems usuarios no pueden
modificar

nada

hasta que no se presente un estado estable de los da

tos, esto ocasiona

inconsistencia temporal y conflictos. Para

evitar lo anterior se implementan dos maneras diferentes:

1. Ejecutar transacciones serializadas:
E s

u n

s i s t e m a

q u e

p e r m i t e

e l

procesamiento

de transacciones en forma secuencial o serializado dndole una

secuencia a cada transaccin, este proceso reduce el rendimiento
del sistema, pero tiene como ventaja que el proceso de sincronizacin es
ms sencillo.

12

2.
Ejecutar
transacciones
calendarizadas: Permite el proceso de transacciones asignndoles
tiempos de procesamiento el cual permite incrementar el rendimiento del
sistema

ya

que

se ejecuta

un mximo

de procesos

en forma

concurrente y no a travs de una serie. La ventaja es que a un

mismo tiempo de reloj se pueden hacer dos operaciones, aunque el
proceso de sincronizacin es ms complicado.

Un

aspecto muy importante en el manejo de transacciones es el de

mantener ya plicar algoritmos de control sobre los datos o recursos; para ese
control tambin se utilizan protocolos que proporcionen confiabilidad como lo
siguientes:
Atomicidad
Protocolos de recuperacin total
Protocolos de compromiso global
Para llevar el control de concurrencia dentro de un proceso de
transacciones se manejan dos modos:

Ejecucin centralizada de transacciones

13

4.1.3
ESTRUCTURA
DE TRANSAC
CIONES.
Las
transacciones
planas
consisten de
una

secuencia

de

operaciones

primitivas encerradas entre las palabras

clave begin y end. Por ejemplo,
Begin_transaction Reservacin
...
end.
La estructura de una transaccin
usualmente

viene

dada

segn

el

modelo de la transaccin, estas pueden

ser planas (simples) o anidadas.
Transacciones Anidadas:

14

Consiste en tener transacciones que dependen

e o t r a s , e s t a s transacciones estn incluidas dentro de otras de un nivel
superior y se las conoce c o m o s u b t r a n s a c c i o n e s . L a t r a n s a c c i n d e
n i v e l s u p e r i o r p u e d e p r o d u c i r h i j o s (subtransacciones) que hagan ms
fcil la programacin del sistema y mejoras del desempeo.
En las transacciones anidadas las operaciones de una transaccin pueden ser as
mismo otras transacciones.
Por ejemplo:
BEGIN _TRANSACTION Reservacin
..........
BEGIN _TRANSACTION Vuelo
........
END.( Vuelo ) ......
BEGIN _TRANSACTION Hotel
........
END
......
END.
En las transacciones anidadas las operaciones de una transaccin pueden ser as
mismo transacciones. Por ejemplo:
Begin_transaction Reservacin
...
Begin_transaction Vuelo
...
end. {Vuelo}. . .
Begin_transaction Hotel
...
end.

15

Las transacciones anidadas proporcionan un nivel ms alto de concurrencia entre

transacciones. Ya que una transaccin consiste de varias transacciones, es
posible tener ms concurrencia dentro de una sola transaccin. As
tambin, es posible recuperarse de fallas de manera independiente de
cada subtransaccin. Esto limita el dao a un parte ms pequea de la
transaccin, haciendo que costo de la recuperacin sea menor.
Una transaccin anidada dentro de otra transaccin conserva las mismas
propiedades que la de sus padres, esto implica, que puede contener as
mismo tran saccio nes dentro de ella . Exi sten restriccion es ob via s en
una tra nsa ccin anidada: debe empezar despus que su padre y debe
terminar antes que l. Ms an, el commit de una subtransaccin es
condicional

al

commit

de

su

padre,

en

otras palabras, si el padre de una o varias

transacciones aborta, las

subtransacciones hijas tambin sern

abortadas
4.2 CONTROL DE CONCURRENCIA.
El control de concurrencia trata con los problemas de aislamiento y
consistencia del procesamiento de transacciones. El control de concurrencia
distribuido de una D D B M S a s e g u r a q u e l a c o n s i s t e n c i a d e l a b a s e d e
datos

se

mantiene

en

una m b i e n t e d i s t r i b u i d o m u l t i u s u a r i o . S i l a s t r a n s a c c i o n e s s
o n i n t e r n a m e n t e consistentes, la manera ms simple de lograr
e s t e o b j e t i v o e s e j e c u t a r c a d a transaccin sola, una despus de otra.
Un mtodo de control de concurrencia es correcto si es serializable, es decir existe
una secuencia equivalente en que las operaciones de cada transaccin
aparecen antes o despus de otra transaccin pero no entremezcladas. Una
ejecucin serial de transacciones es siempre correcta.
16

Si no se hace un adecuado control de concurrencia, se pueden

presentar dos anomalas.
E n p r i m e r l u g a r, s e p u e d e n p e r d e r a c t u a l i z a c i o n e s p r o v o c a n d o
q u e l o s efectos de algunas transacciones no se reflejen en la base de datos.

En segundo trmino, pueden presentarse recuperaciones de

informacin inconsistentes.

El control de concurrencia es una actividad de coordinar accesos concurrentes a la

base de datos. El control de concurrencia permite a los usuarios accesar a la base
de datos. El control de concurrencia permite a los usuarios accesar a la
base de datos en una forma multi programada mientras se preserva la ilusin de
que cada usuario este utilizando solo en un sistema dedicado. El control
de

concurrencia

asegura

que

las

transacciones

mltiples

s o m e t i d o s p o r u s u a r i o s d i f e r e n t e s n o interfieren unos con otros de forma

que se produzca resultados incorrectos.
La finalidad del control de concurrencia es asegurar la consistencia de los datos al
ejecutar transacciones, y que cada accin atmica sea completada en
un tiempo finito. Uno de los problemas de concurrencia especficos de
las bases de datos distribuidas es la consistencia de copia mltiple, se
produce

cuando

un

mismod a t o e s t a e n v a r i a s l o c a l i z a c i o n e s . A d e m s s e s i
g u e n d a n d o l o s m i s m o s problemas para bases de datos c
entralizadas prdida de actualizaciones,

dependencia

neutral

uncommitted dependency y anlisis inconsistentes

17

4.2.1SERIALIZACIN DE TRANSACCIONES.
Seriabilidad.
La seriabilidad consiste en asegurarse que los cambi
o s s i g u e n u n o r d e n adecuado.
Teora de la serializad Una canderilizacion ischedulel tambin llamado una historia
se define un conjunto de transacciones I= {T1,T2, TN} y especifican orden
entrelazada de la ejecucin de las operaciones de las transacciones. La
canderilizacion puede ser especificada como una orden parcial sobre T.
T1=read (x) T2=write(x) T3=read (x)
Write (x) write (y) read (y)
Commit read (z) read (z)
Comimit commit
Una candelizacion de las acciones de las tres transacciones de las tres
transacciones anteriores puede ser:
H1 = {W2 (x), R1(x), R3(x), W1(x), C1, W2 (y), R3(y), R2(z), C2, R3(z), C3 }
En bases de datos distribuidos es necesario considerar dos tipos
de historia para poder generar calendarizaciones serializables: la canderizacion
de

la

ejecucin

det r a n s a c c i o n e s g l o b a l e s s e r n s e r i a l i z a b l e s s e d e b e n s a t i s f a c e r
l a s s i g u i e n t e s condiciones:
Cada historia local debe ser serializable.
D o s o p e r a c i o n e s e n c o n f l i c t o d e b e n e s t a r e n e l m i s m o o r d e n
r e l a t i v o e n todas las historias locales donde las operaciones aparecen juntas.
Dos operaciones Oij ( x ) y Okl ( x ) (i yk no necesariamente distintos) que
accesan el mismo dato de la base de datos x se dice que estn en
conflictos si al menos una de ellas es una escritura. De esta manera, las
18

operaciones

de

lectura

no

tienenc o n f l i c t o s c o n s i g o m i s m a s . P o r t a n t o , e x i s t e n d o s t i p o
s de conflicto

read-write(o

write-read) y

write-write

Las dos operaciones en conflicto pueden

pertenecer a

la misma transaccin o a transacciones diferentes. En el ltimo caso, se dice que

las transacciones tienen conflicto. De manera intuitiva, la existencia de un conflicto
entre dos operaciones indica que su orden de ejecucin es importante. El orden de
dos operaciones de lectura es insignificante.
Una

calendarizacin completa

define

el

orden

r a c i o n e s
u n a

e n

de

s u

ejecucin

d o m i n i o .

c a l e n d a r i z a c i n

de

todas

laso p e

F o r m a l m e n t e ,

completa

S T c definido

sobre

un

conjunto de transacciones T = {T 1,T 2, ...,T n} es un orden parcial S T c = { ST , <

T } en donde
1. ST= UiSi , para todos los i = 1, 2, ...,n
2. <T i <i , para todos los i = 1, 2, ...,n
3. Para cualesquiera dos operaciones en conflicto Oij y Okl ST ,
Oij <T Okl Okl <T Oij
La

primera

condicin

establece

simplemente

que

el

dominio

de

la

calendarizacine s l a u n i n d e l o s d o m i n i o s d e l a s t r a n s a c c i o n e
s i n d i v i d u a l e s . L a s e g u n d a condicin define la relacin de ordenamiento
como un sper conjunto de la relacin de ordenamiento de transacciones
individuales. Esto mantiene el ordenamiento de las operaciones dentro
de cada transaccin. La condicin final define el orden de ejecucin entre
dos operaciones en conflicto.

19

4 . 2 . 2 AL G O R I T M O S D E C O N T R O L D E C O N C U R R E N C I A.
Aquellos algoritmos que estn basados en acceso mutuamente exclusivo a datos
compartidos (candados o bloqueos) y aquellos que intentar ordenar la
ejecucind e l a s t r a n s a c c i o n e s d e a c u e r d o a u n c o n j u n t o d e r
eglas (protocolos).
S i n embargo, estas primitivas se pueden usar en algoritmos con dos
puntos de vista diferentes:
El

punto

de

vista

pesimista

que

considera

que

muchas

t r a n s a c c i o n e s t i e n e n conflictos con otras, o el punto de vista optimista que

supone que no se presentan muchos conflictos entre transacciones.
Los algoritmos pesimistas sincronizan la ejecucin co
ncurrente de last r a n s a c c i o n e s
n i c i a l

d e

s u

c i c l o

d e

e n

s u

e j e c u c i n .

e t a p a

L o s algori

tmos optimistas retrasan la sincronizacin de las transacciones h

a s t a s u terminacin. El grupo de algoritmos pesimistas consiste de algoritmos
basados
enc a n d a d o s , a l g o r i t m o s b a s a d o s e n o r d e n a m i e n t o p o r e s t a
m p a s d e t i e m p o y algoritmos hbridos.
Los algoritmos para el control de concurrencia son tiles cuando
s e e j e c u t a n varias transacciones al mismo tiempo

20

4.2.3 DISCIPLINAS DEL INTERBLOQUEO: PREVENCIN, DETECCIN,

ELIMINACIN Y RECUPERACIN.
El interbloqueo: Un esquema para resolver el interbloque en su detencin, es un
bloqueo permanente de un conjunto de procesos que compiten por los
recursos del sistema o bien se comunican unos con otros. A diferencia
de otros problemas

de la gestin concurrente de procesos, no existe

una solucin eficiente para el caso general.

Formas de presentar el interbloqueo
Grafo de esperas.
Grafo de reservas.
Grafo de esperas: Es un grafo en el cual los nodos son las
transacciones y la relacin de espera entrenada se define como sigue: Una
transaccin y relacin de espera a otra transaccin T9 si te ha solicitado el
bloqueo de un granulo y esta peticin no puede ser aceptada porque T9 lo
tiene bloqueado.
21

Grafo de reservas: Grafo con dos tipos de nodos, los de las transacciones y los
Correspondientes a grnulos.
Un nodo une un granulo G1 a una transaccin T10 si T9
t i e n e b l o q u e a d o e l granulo G1. Un arco une una transaccin T9 con un
granulo G1 si T9 ha solicitad o un bloqueo del granulo pero no le ha conseguido.
Una condicin necesaria para que haya un interbloqueo es que Q1 exista con ciclo
en el grafo de reservas.
Detencin: Existen diversos algoritmos para ello en la detencin de
ciclos en el grafo de esperas, entre ellos:
Algoritmo 1: Comprueba la existencia de ciclos mediante la eliminacin de nodos
terminales.
Algoritmo 2: Comprueba posibles ciclos desde la ltima transaccin bloqueada y
marcando los nodos por lo que pasa. Si pasa dos veces por el
m i s m o n o d o a detectado un ciclo.
Prevencin: L a s t c n i c a s d e i n t e r b l o q u e o u t i l i z a n e l c o n c e p t o
d e m a r c a d e tiempo de transaccin existen dos esquemas que evitan el
interbloqueo.
Recuperacin: El objetivo de esta parte de la asignacin es conocer y
entender las distintas fallas que pueden ocurrir en un BMS y cmo es
posible restaurar el sistema despus de dichas fallas este tema se llama
recuperacin de fallas.
La recuperacin de fallas esta internamente ligado Al procesami
ento de lastransacciones tiene la cualidad de ser anotmica a
pesar de que puede estar compuesto de varias operaciones de
atomicidad

se

controla

como

llegada

alc o m m i t . S i u n a t r a n s a c c i n n o s u f r i n i n g n p r o b l e m a y s
22

e p u d o e j e c u t a r completa,

entonces

el

DBMS

debe

de

comprometerse hacer permanentes los c a m b i o s q u e l a t r a n s a c c i n

h i z o s o b r e l a b a s e d e d a t o s y a q u e e s t a d e b i d o quedar en un estado
de conciencia.

4.3 CONFIABILIDAD.
Un sistema de manejo de bases de datos confiable es aquel que puede
continuar procesando las solicitudes de usuario an cuando el sistema
sobre el que opera no es confiable. En otras palabras, aun cuando los
componentes de un sistema distribuido fallen, un DBMS confiable debe
seguir ejecutando las solicitudes de usuario sin violar la consistencia de la
base de datos.
La confiabilidad de un DBMS se refiere a la atomicidad y
d u r a b i l i d a d d e l a s transacciones. El sistema sobre el cual se ejecutan los
mecanismos de control de concurrencia debe de ser confiable.
PROPIEDADES:
ATOMICIDAD: Se refiere cuando las operaciones de una transaccin se ejecutan
todas o ninguno.
DURABILIDAD: Despus de que una transaccin se ejecut
c o n x i t o , l o s cambios en la BD persisten, ms all de las fallas del sistema.
La confiabilidad se refiere a la consistencia de los resultados.
La confiabilidad se busca que los resultados de un cuestionario
concuerden con los resultados del mismo cuestionario en otra ocasin.
Si esto ocurre se puede decir que hay un alto grado de confiabilidad.
23

Un sistema de manejo de base de datos confiables aquel que

p u e d e c o n t i n u a r procesando las solicitudes de usuario aun cuando el
sistema sobre el que opera no es confiable en otras palabras, aun
cuando los componentes de un sistema distribuido fallen un DDMBS
confiable debe seguir ejecutndose las solicitudes de usuario sin violar la
consistencia de la base de datos

4 . 3 . 1 C O N C E P T O S B S I C O S D E C O N F I AB I L I D AD .
SISTEMA, ESTADO Y FALLA:
Un

sistema

se refiere a un mecanismo que consiste de una colec

c i n d e componentes y sus interacciones con el medio amb
i e n t e q u e r e s p o n d e n a estmulos que provienen del mismo con un patrn
de comportamiento reconocible.
Un estado externo d e

un

sistema

se

puede

definir

como

la

r e s p u e s t a q u e u n sistema proporciona a un estmulo externo. Por lo

tanto, es posible hablar de un s i s t e m a q u e s e m u e v e d e n t r o d e
e s t a d o s e x t e r n o s d e a c u e r d o a u n e s t m u l o proveniente del medio
ambiente. Un estado interno es, por lo tanto, la respuesta del sistema a un
estmulo interno.
Cualquier desviacin de un sistema del comportamien
t o d e s c r i t o e n s u especificacin se considera como una falla
.C u a l q u i e r e r r o r e n l o s e s t a d o s i n t e r n o s d e l o s c o m p o n e n t e s d e l
s i s t e m a s e l e conoce como una falta en el sistema. As, una falta causa
un error lo que puede inducir una falla del sistema.

24

La confiabilidad de un sistema, R(t), se define como la siguiente probabilidad

condicional:
R(t) = Pr{ 0 fallas en el tiempo [0,t] | no hubo fallas en t = 0 }
Si la ocurrencia de fallas sigue una distribucin de Poisson, entonces,
R(t) = Pr{ 0 fallas en el tiempo [0,t] }.
El clculo de la confiabilidad y disponibilidad puede ser tedioso. Por lo
tanto,
esa c o s t u m b r a d o u s a r d o s m t r i c a s d e u n s l o p a r m e t
r o p a r a m o d e l a r e l comportamiento del sistema.
Las dos mtricas son el tiempo medio entre fallas (MTBF por sus siglas en
ingls) y el tiempo medio para reparaciones (MTTR). El M T B F p u e d e s e r
calculado a partir de datos empricos de la funcin de
confiabilidad.
La confiabilidad es una condicin necesaria, pero no suficiente para la validez. Las
evidencias de validez siempre han de ir de la mano con
l a s e v i d e n c i a s d e Confiabilidad.
La confiabilidad indica el grado de consistencia, pero no dice si las inferencias
queS e h a c e n y l a s d e c i s i o n e s q u e s e t o m a n p a r t i e n d o
d e l c u e s t i o n a r i o s o n defendibles.
La confiabilidad tambin se refiere a la medida en la cual un
i n s t r u m e n t o d e recopilacin de datos producir los mismos resultados cada
vez que se administra. En la investigacin cualitativa, la confiabilidad significa
hasta

qu

punto

diferentesi n v e s t i g a d o r e s , a l e x p o n e r s e a l a m i s m a s i t u a c i n , l
l e g a r a n a l a s m i s m a s conclusiones.

25

En trminos de confiabilidad lo que preocupa es la consistencia de los resultados.

Se necesita la confiabilidad para poder hablar de resultados vlidos,
puesto que no es posible evaluar algo que cambia continuamente.
4.3.2PROTOCOLOS REDO/UNDO.
En un protocolo con escritura previa en bitcora, las entradas en la
bitcora se dividen en dos tipos: las necesarias para operaciones REDO
(entradas
write_temc o n t e n i e n d o s l o n u e v o s v a l o r e s ) y l a s n e c e s a r i a s p a r a
o p e r a c i o n e s U N D O (entradas write_tem conteniendo los valores viejo y
nuevo, y entradas read_tem).
Cuando se produce un fallo, el esquema de recuperacin consulta a la
bitcora para determinar que transacciones deben deshacerse o rehacerse.
UNDO (T): cuando la bitcora contiene el registro <T,start> pero no
contiene el registro <T,commit>.
REDO (T): cuando la bitcora contiene tanto el registro <T,start> como el
registro<T,commit>.
El esquema de recuperacin usa la operacin REDO
r e h a c e r u s a n d o informacin de la bitcora. En caso de
que

ocurra

una

cada

fallo

de

una

transaccin se debe

recurrir a una operacin UNDO que deshace los cambios hechos.

Undo (T): restaura todos los datos que T actualiza a los
v a l o r e s q u e t e n a anteriormente. Redo (T): asigna los nuevos valores
a todos los datos que actualiza la transaccin.
Es importante respetar el orden de ejecucin de las o
p e r a c i o n e s p a r a l a recuperacin.

Las

operaciones

UNDO

deben
26

realizarse antes que las operaciones REDO. Las operaciones de UNDO se

realizan recorriendo la bitcora desde abajo hacia arriba, esto es, en orden
inverso al que se ejecutaron. Las operaciones de REDO se realizan
recorriendo la bitcora desde arriba hacia abajo, esto es, en el mismo
orden en que se actualiz.
Ejemplo:
<Ti,A,10,20>
<Tj,A,20,30>
<Tj,commit> Ti aborta pero Tj comete
Si se realiza un REDO primero, A quedar en 30 y el posterior UNDO
dejar a Acon 10. El valor final de A debera ser 30, y eso es posible de alcanzar
si se realiza primero el UNDO y luego el REDO.
La operacin redo utiliza la informacin del registro de la base de datos y realiza
de nuevo las acciones que pueden haber sido realizadas antes de la falla, la
operacin redo genera nueva imagen.

27

Es posible que el administrador del buffer haya realizado la escritura en la base

ded a t o s
la

estable

base

de

de

datos

algunas

de

las

pginas

de

v o l t i l correspondientes a la transaccin

T 2. As, la informacin de recuperacin debe incluir datos suficientes para

permitir deshacer ciertas actualizaciones en el nuevo estado de la base de datos y
regresarla al estado anterior.
La operacin UNDO restablece un dato a su imagen anterior utilizando la
informacin del registro de bases de datos

Independientemente
o asncrona,

se

de que

debe

la escritura

observar

un

del registro

protocolo

sea sncrona

importante

para

el

mantenimiento del registro de la base de datos. Considere el caso donde

las actualizaciones a la base de datos son escritas en el almacenamiento
estable antes de que el registro sea modificado en el registro estable para reflejar
la actualizacin. Si una falla ocurre antes de que el registro sea escrito, la base de
datos permanecer en forma actualizada, pero el registro no indicar la
actualizacin lo que har imposible recuperar la base de datos a un estado
consistente antes de la actualizacin.

28

4 . 3 . 3 P U N T O S D E V E R I F I C AC I N ( C H E C K P O I N T S ) .
Los checkpoints buscan reducir los tiempos extra en los procesos de bsqueda en
la bitcora. Al disparar un checkpoint el sistema realiza la siguiente
secuencia de acciones:
Grabar

en

memoria

estable

todos

los

registros

de

b i t c o r a q u e e s t n e n memoria principal.
Grabar en disco los bloques modificados de los regis
t r o s i n t e r m e d i o s (buffer).
Grabar

un

registro

de

bitcora

<checkpoint>

en

memoria

estable.
Cuando ocurre un fallo del sistema es necesario consultar la
bitcora

para

v e r cules

transacciones

deben

rehacerse

cules

deshacerse.
PASOS A SEGUIR ANTE FALLOS:
1.- Para cada transaccin Ti tal que aparece en la bitcora el registro
<Ti,commit>antes del registro <checkpoint>, no es necesario ejecutar un REDO.
2.- Despus de un fallo, se examina la bitcora para determinar cul fue la ltima
transaccin Ti que comenz a ejecutarse antes del ltimo checkpoint.
*Esto se hace examinando la bitcora hacia atrs buscando el primer registro
<checkpoint> y c u l e s e l r e g i s t r o < Ti , s t a r t > m s c e r c a n o . * L u e g o ,
s e a p l i c a R E D O o U N D O sobre Ti y todas las transacciones que le suceden.
Un

punto

de

control

(checkpoints).

Es

registrado

en

la

bitcora

peridicamente e n e l m o m e n t o e n q u e e l s i s t e m a h a g r a b a d o e n l a
B D e n d i s c o l o s e f e c t o s d e todas las operaciones de escritura de las
transacciones confirmadas.

29

En un esquema sin concurrencia, en el proceso de recuperacin

s o l a m e n t e s e consideraban: *Aquellas transacciones que comenzaron
despus del checkpoint ms reciente. *La nica transaccin (si exista)
que estaba activa al momento del ms reciente checkpoint. En un
esquema concurrente puede haber ms de una transaccin activa al
momento del checkpoint.

Las operaciones de recuperacin requieren recorrer todo el registro de la base de

datos. As, el buscar todas las transacciones a las cuales es necesario
aplicarles u n U N D O o R E D O p u e d e t o m a r u n a c a n t i d a d d e
t r a b a j o c o n s i d e r a b l e . P a r a reducir este trabajo se pueden poner
puntos de verificacin (checkpoints) en el registro de la base de datos para
indicar que en esos puntos la base de datos est actualizada y consistente. En
este

caso,

un

REDO

tiene

que

iniciar

desde

un

puntod e v e r i f i c a c i n y u n U N D O t i e n e q u e r e g r e s a r a l p u n t o
d e v e r i f i c a c i n m s i n m e d i a t o a n t e r i o r. L a c o l o c a c i n d e p u n t o s
d e v e r i f i c a c i n s e r e a l i z a c o n l a s siguientes acciones: Se escribe un
begin_checkpoint

en

el

registro

de

la

base

de

datos.

Se

recolectant o d o s l o s d a t o s v e r i f i c a d o s e n l a b a s e d e d
30

a t o s e s t a b l e . S e e s c r i b e u n fin_de_checkpoint en el registro de
la base de datos.
Estos puntos de verificacin nos ayudan para reducir
e l g a s t o d e t i e m p o consultando la bitcora. El punto de verificacin en un
registro que se genera en la b i t c o r a p a r a c o n c l u i r e n t o d o l o q u e
s e e n c u e n t r a a n t e s d e e s e p u n t o e s t a correcto y verificado.
Si el sistema se llega a caer se realiza la bitcora buscando del final al
inicio

el

primer registro check point ya encontrado se procesan lo

r e g i s t r o s q u e s e encuentran despus del check point.

4.3.4PROTOCOLOS 2PC DE CONFIABILIDAD DISTRIBUIDA.

Es un protocolo que consume un gran volumen de tiempo en la ejecucin de una
Transferencia durante el procesamiento normal se puede eliminar accesos a disco
o el nmero de mensajes en el proceso de la transaccin la
p e r t e n e n c i a 2 p c podra ser mejorado.
El 2pc es conocido tambin como el protocolo que no resume
nada para que t r a t a t o d a s l a s t r a n s a c c i o n e s d e l a m i s m a
f o r m a s i n i m p o r t a r s i l a s m i s m a s cometen o abortan.
En

el

protocolo

de

bloqueo

de

dos

fases

estricto

cada

s u b t r a n s a c c i n d e b e informar a las otras subtransacciones de que

ha

requerido

bloqueos.U n a
n

sitio

todos

transaccin
y

dividida

en

que

fue

los
iniciada

en

v a r i a s subtransacciones

ejecutndose en diferentes sitios.

Las subtransaccin se ordenan en un coordinador y las otras participantes.
31

 C a d a s u b t r a n s a c c i n Ti d e c i d e s i c o m e t e r o a b o r t a r, y e n v a a l
coordinador u n m e n s a j e . E l c o o r d i n a d o r t o m a l a d e c i s i n
f i n a l e n f u n c i n d e l a s votaciones de todos los participantes.
Cuando se presentan fallas en la red, este protocolo puede
l l e v a r a e s t a d o s de bloqueo, esto es, una subtransaccin en un sitio
que no fall no puede cometer ni abortar hasta que se repare la falla en el sitio
de origen.
PROTOCOLO DE COMPROMISO DE 2 FASES

Mejora: Cada subtransaccin mide el tiempo mximo

d e e s p e r a p o r u n a respuesta.
Un participante que alcanza el tiempo mximo pasa

a l e s t a d o d e i n t e n t a r recuperarse.
Para ello enva un mensaje de ayuda help me a los
o t r o s p a r t i c i p a n t e s . Ante el pedido de ayuda, otros participantes

segn su estado contestan:

Si est en estado cometida, le enva un mensaje commit.
Si est en estado abortado, le enva un mensaje abort.
Si est en estado decidiendo (no vot an) decide abortar y

e n v a a b o r t T al coordinador.
S i e s t e n e s t a d o d i s p u e s t a a c o m e n t a r, n o p u e d e a y u d a r.

En la siguiente figura se presentan las dos fases de comunicacin para realizar un

commit en sistemas distribuidos. El esquema presentado en la figura se
conoce c o m o c e n t r a l i z a d o y a q u e l a c o m u n i c a c i n e s s o l o e n t r e
e l c o o r d i n a d o r y l o s participantes; los participantes no se comunican entre
ellos.

32

Replicacin nerge.
Esta permite la replicacin de tablas y procedimientos alm
a c e n a d o s . L a s modificaciones pueden hacerse en el Publisher o bien
en las copias mantenidas por los suscriptores. Para mantener la integridad
de los datos replicados el proceso de sincronizacin s e e n c a r g a d e
actualizar las modificaciones realizadas en las copias de
l o s suscriptores y viceversa

33