Tipos de Fallos Acciones de recuperación Recuperación mediante

Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación
Elementos de Bases de Datos – 2do. Cuatrimestre de 2004
Tipos de Fallos
Elementos de
Bases de Datos
Fallos en la Transacción
„
Dpto.Ciencias e Ingeniería de la Computación
Universidad Nacional del Sur
Caida del sistema: por ejemplo errores del
hardware o software de base de datos o
software del sistema operativo.
Lic. María Mercedes Vitturini
[mvitturi@cs.uns.edu.ar]
Clase 19
Error lógico: la transacción no puede continuar su
ejecución a causa de alguna condición interna.
Error del sistema: el sistema alcanza un estado no
correcto. La transacción puede volver a ejecutarse
más tarde.
„
Fallo de disco: daño físico en el medio de
almacenamiento masivo.
1er. Cuatrimestre de 2004
Otras
transacciones
continuan
con su
ejecución
Todas las
transaccio
nes deben
ser
recuperadas
Elementos de Bases de Datos
Clase 19
Recuperación mediante
Bitácora
Acciones de recuperación
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).
Nombre del Dato: el nombre único del dato escrito.
Valor Nuevo: el valor que tendrá el dato después de la
escritura.
Elementos de Bases de Datos
Clase 19
3
4
Modificación diferida: pasos a
seguir
Modificación diferida
Garantiza la atomicidad de la transacción grabando
todas las modificaciones en la bitácora pero
aplazando todas las operaciones Write hasta que la
transacción se comete parcialmente.
La información en la bitácora asociada a la
transacción parcialmente cometida se usa en la
ejecución de las escrituras diferidas.
Información de la bitácora
„
Antes de que comience una transacción T, se escribe
el registro de bitácora <T,start>.
„
Si T realiza una operación Write(X,v), se escribe el
registro de bitácora <T,X,v>.
„
Cuando T está parcialmente cometida, se escribe el
registro de bitácora <T,commit>.
El esquema de recuperación usa la operación REDO
(Rehacer) usando información de la bitácora.
„ REDO (T) cuando en la bitácora existen los registros
Si el sistema se cae antes de que termine de
ejecutarse una transacción, o si la transacción
aborta, se ignora la información de la bitácora.
Elementos de Bases de Datos
Clase 19
La bitácora es una estructura usada para guardar
información sobre las modificaciones que se realizaron a
los datos.
Existen varias implementaciones. Veremos una
implementación que contiene registros con los campos:
Nombre de la Transacción: el nombre de la transacción
que ejecutó el Write.
Valor Antiguo: el valor del dato anterior a la escritura.
Acciones tomadas a continuación de un fallo para
asegurar la consistencia de la base de datos y la
atomicidad de las transacciones (paleativas).
Elementos de Bases de Datos
Clase 19
2
<T,start> y <T,commit>.
5
Elementos de Bases de Datos
Clase 19
6
1
Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación
Elementos de Bases de Datos – 2do. Cuatrimestre de 2004
Modificación inmediata: pasos a
seguir
Modificación inmediata
Las modificaciones en la base de datos se realizan
mientras la transacción está activa, antes de
alcanzar el estado de cometida.
Este tipo de modificaciones se denominan
modificaciones no cometidas.
La operación Undo extrae la información de la bitácora para determinar que datos deben restaurarse.
Elementos de Bases de Datos
Clase 19
„
Antes de que comience una transacción T, se escribe
el registro de bitácora <T,start>.
Si T realiza una operación Write(X,v), se escribe el
registro de bitácora <T,X,v1,v2>.
Cuando T está parcialmente cometida, se escribe el
registro de bitácora <T,commit>.
No puede permitirse la actualización efectiva de la
base de datos (Output (RegDatos)) antes de que se
escriba el registro de bitácora en memoria estable
(Output(RegBitácora)).
Elementos de Bases de Datos
Clase 19
7
8
Puntos de Verificación
(Checkpoints)
Recuperación de fallos
El esquema de recuperación usa las operaciones
y Undo (Deshacer) y Redo (Rehacer) usando
información de la bitácora.
Cuando se produce un fallo, el esquema de
recuperación consulta a la bitácora para
determinar que transacciones deben deshacerse
o rehacerse.
„
„
„
En caso de que ocurra una caída o fallo de una
transacción se debe recurrir a una operación Undo
que “deshace” los cambios hechos.
„
Información de la bitácora
UNDO (T): cuando la bitácora contiene el registro
<T,start> pero no contiene el registro <T,commit>.
REDO (T): cuando la bitácora contiene tanto el registro
<T,start> como el registro <T,commit>
Elementos de Bases de Datos
Clase 19
Cuando ocurre un fallo del sistema es necesario
consultar la bitácora para ver cuáles
transacciones deben rehacerse y cuáles
deshacerse.
Esto implica revisar TODA la bitácora.
„
„
„
El proceso de búsqueda consume tiempo.
La mayor parte de las transacciones que, según el
algoritmo, deben volver a hacerse, ya escribieron sus
actualizaciones en la base de datos en memoria
estable.
Volver a hacerlas no causa daño (redo es
idempotente) pero consume tiempo.
Elementos de Bases de Datos
Clase 19
9
10
Checkpoints: pasos a seguir
Checkpoints: pasos a seguir
Los checkpoints buscan reducir los tiempos extra en
los procesos de búsqueda en la bitácora.
Al disparar un checkpoint el sistema realiza la
siguiente secuencia de acciones:
„
„
„
Bitácora
M. Principal
Registros
sobre datos
A1…An
(*) Inicio de
checkpoint
Grabar en memoria estable todos los registros de
bitácora que están en memoria principal.
Grabar en disco los bloques modificados de los registros
intermedios (buffer).
Grabar un registro de bitácora <checkpoint> en
memoria estable.
El checkpoint es una actividad del sistema de base
de datos periódica y programada.
Elementos de Bases de Datos
Clase 19
11
Base de Datos
M. Estable
M. Principal
Escrituras
sobre datos
A1…An
Registros
sobre datos
A1…An
<Checkpoint>
Tiempo
M. Estable
Elementos de Bases de Datos
Clase 19
Escrituras
sobre datos
A1…An
12
2
Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación
Elementos de Bases de Datos – 2do. Cuatrimestre de 2004
Checkpoints: pasos a seguir ante fallos
Para cada transacción Ti tal que aparece en la
bitácora el registro <Ti,commit> antes del registro
<checkpoint>, no es necesario ejecutar un REDO.
Después de un fallo, se examina la bitácora para
determinar cuál fue la última transacción Ti que
comenzó a ejecutarse antes del último checkpoint.
„
„
Esto se hace examinando la bitácora hacia atrás
buscando el primer registro <checkpoint> y cual es el
registro <Ti,start> más cercano.
Luego, se aplica Redo o Undo sobre Ti y todas las
transacciones Tk que le suceden.
Elementos de Bases de Datos
Clase 19
En el esquema de recuperación sólo
deben reconsiderarse T67, T68,..., T100.
„
Ejecutar Redo(Tk) para todas las transacciones
cuyo registro <Tk,commit> aparece en la bitácora.
Ejecutar Undo(Tk) de la transacción cuyo registro
<Tk,commit> no aparece en la bitácora (sólo si se
usa modificación inmediata).
Hasta ahora el algoritmo de recuperación sólo considera un
ambiente de trabajo centralizado y no concurrente. Al
momento de un fallo de sistema, a lo sumo existe una única
transacción activa
Elementos de Bases de Datos
Clase 19
„
<Checkpoint>
...
T100
15
Elementos de Bases de Datos
Clase 19
16
Recuperación y
Concurrencia
Checkpoints con transacciones
concurrentes
En lugar de agregar un registro <checkpoint>
solamente, se agrega un registro de la forma:
<checkpoint L>
donde L denota a la lista de transacciones activas
al momento del checkpoint.
La lista L limita la búsqueda hacia atrás del
checkpoint en la bitácora.
Como en el caso anterior, no existen
actualizaciones a los bloques de buffer ni a la
bitácora durante el proceso de checkpointing.
Elementos de Bases de Datos
Clase 19
Aquellas transacciones que comenzaron después del
checkpoint más reciente.
La única transacción (si existía) que estaba activa al
momento del más reciente checkpoint.
En un esquema concurrente puede haber más de
una transacción activa al momento del checkpoint.
Por lo tanto, el esquema de checkpoints debe ser
levemente modificado cuando se utilizan
transacciones concurrentes.
T68
Elementos de Bases de Datos
Clase 19
14
En un esquema sin concurrencia, en el proceso de
recuperación solamente se consideraban:
„
T66
T67
„
Checkpoints con transacciones
concurrentes
T0
...
Pasos a seguir con el resto de las transacciones:
13
Checkpoints: un ejemplo
T1
Checkpoints: pasos a seguir
ante fallos
Hasta ahora, consideramos recuperaciones en
entornos donde solamente se ejecuta una
transacción por vez.
Un sistema centralizado, aún cuando incorpora
facilidades de concurrencia, cuenta con un
único buffer de disco y un único registro de
bitácora.
Los bloques de buffering son compartidos por
todas las transacciones.
17
Elementos de Bases de Datos
Clase 19
18
3
Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación
Elementos de Bases de Datos – 2do. Cuatrimestre de 2004
Tipos de Fallos y Concurrencia
Fallo de una transacción
„
„
Cualquiera sea el motivo por el que falle una
transacción T (lógico o del sistema) el rollback
puede involucrar a otras transacciones además de la
transacción T abortada (retrocesos en cascada).
Las transacciones no involucradas continuan su
ejecución.
Caida del Sistema
„
La recuperación involucra a todas las transacciones
ejecutadas o en ejecución a partir del último punto
de verificación.
Retroceso de Transacciones
Una transacción puede ser retrocedida (rolled
back) no solamente cuando se produce una falla
en el sistema sino cuando es abortada.
Una transacción puede ser abortada por
diferentes razones:
„
„
„
En ambos casos se usa la información de
bitácora para proceder a la recuperación.
Elementos de Bases de Datos
Clase 19
El esquema de recuperación depende fuertemente del
esquema de control de concurrencia utilizado.
El retroceso de una transacción fallada, debe deshacer
los cambios hechos por la misma.
„
„
Ejemplo: Si una transacción T0 modificó el dato Q y tiene que
ser retrocedida, entonces debe restaurarse el valor anterior
de Q.
Pero si una transacción T1 realizó otro cambio sobre Q
después del cambio de T0 pero antes de que T0 sea
retrocedida, el cambio realizado por T1 se perderá.
undo-list
redo-list,
Estas listas contienen a las transacciones que
deben deshacerse y rehacerse respectivamente.
„
Inicialmente estas listas están vacías.
Elementos de Bases de Datos
Clase 19
El retroceso de una transacción T fallada implica
recorrer la bitácora hacia atrás, ya que una
transacción puede realizar más de un cambio sobre
el mismo dato.
…,<T,A,10,20>, …,<T,A,20,30>, …
El orden en que se recorre la bitácora es importante
ya que si no la recorremos hacia atrás, se
restauraría el valor 20 a A (cuando debe ser 10).
Elementos de Bases de Datos
Clase 19
22
Undo-List y Redo-List
La recuperación involucra a todas las
transacciones ejecutadas o en ejecución
(posiblemente más de una) a partir del último
punto de verificación.
El sistema de recuperación recorre la bitácora
para construir dos listas:
„
Retroceso de Transacciones
21
Crash o Caidas de Sistemas
„
20
Esto es, T primero modifica A de 10 a 20 y luego de
20 a 30.
Por lo tanto, si una transacción T actualiza un item Q,
es deseable que cualquier otra transacción que desee
modificar Q espere que T esté cometida.
Elementos de Bases de Datos
Clase 19
Elementos de Bases de Datos
Clase 19
19
Recuperación y Concurrencia
Por un usuario, por ejemplo, cuando decide abortar.
Por si misma, por ejemplo, por algún error inesperado.
Por el sistema, por ejemplo, cuando una transacción
está en deadlock con otras transacciones.
23
Se realiza un recorrido hacia atrás de los
registros almacenados en la bitácora hasta el
primer <checkpoint, L>:
„
„
Por cada item <Ti,commit>, se agrega Ti a redo-list.
Por cada item <Ti,start>, si Ti no está en redo-list
entonces se agrega a la lista undo-list
Luego se examina la lista L de transacciones
activas la momento del <checkpoint, L>
„
Por cada transacción Ti de L si Ti no esta incluída en
redo-list se agrega a undo-list.
Elementos de Bases de Datos
Clase 19
24
4
Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación
Elementos de Bases de Datos – 2do. Cuatrimestre de 2004
Recuperación ante Fallos
Recuperación ante Fallos
1 Se vuelve a recorrer la bitácora hacia atrás, realizando
un undo por cada transacción en la lista undo-list. El
proceso se detiene cuando se encuentra en la bitácora
el item <Ti,start> de cada transacción Ti en la lista
undo-list.
2 Se ubica el más reciente <checkpoint> en la bitácora.
Este paso puede involucrar un recorrido hacia adelante
si el checkpoint fue pasado en el paso 1.
3 Se recorre hacia adelante desde el más reciente
<checkpoint> y se realiza un redo de cada transacción
Ti en la lista redo-list.
Elementos de Bases de Datos
Clase 19
Es importante respetar el orden de ejecución de las
operaciones para la recuperación.
Las operaciones undo deben realizarse antes que las
operaciones redo.
Las operaciones de undo se realizan recorriendo la
bitácora desde abajo hacia arriba, esto es, en orden
inverso al que se ejecutaron.
Las operaciones de redo se realizan recorriendo la
bitácora desde arriba hacia abajo, esto es, en el
mismo orden en que se actualizó.
Elementos de Bases de Datos
Clase 19
25
Ejemplo – Fallo de sistema de
una transaccion
Recuperación ante fallos
Estampillas
Ejemplo:
T1
read (A)
<Tj,A,20,30>
write (A)
Ti aborta pero Tj comete
El valor final de A debería ser 30, y eso es
posible de alcanzar si se realiza primero el undo
y luego el redo.
Elementos de Bases de Datos
Clase 19
R-ts(A)=ts(T2)
read (B)
R-ts(B)=ts(T2)
write (B)
W-ts(B)=ts(T2)
read (B)
Bitacora
<T1 start>
<T1, A, 100, 200>
<T2 start>
<T2, B, 400, 200>
•Protocolo: Estampilla de tiempo con ts(T1) < ts(T2)
•T1 debe retroceder por no cumplir las condiciones del protocolo
•T2 debe retroceder en cascada.
Elementos de Bases de Datos
Clase 19
28
Crash de Sistema
Acciones llevadas a cabo durante la
recuperación :
<T1,start>
Undo (T2)
Undo (T1)
Cuando una transacción retrocede deben
deshacerse TODAS sus modificaciones, en el
ejemplo que se esta siguiendo, esto incluye
deshacer las modificaciones de estampillas de
tiempo realizadas por T1 y T2
R-ts(A) = W-ts(A) = R-ts(B)= W-ts(B)= 0
Elementos de Bases de Datos
Clase 19
W-ts(A)=ts(T1)
27
Ejemplo – Fallo de sistema de
una transacción
„
R-ts(A)= ts(T1)
read (A)
Si se realiza un redo primero, A quedará en 30 y
el posterior undo dejará a A con 10.
„
T2
<Ti,A,10,20>
<Tj,commit>
„
26
Dada la siguiente foto de la bitácora
de un crash de sistema.
<T1,B,50,20>
antes
<T2,start>
<T2,A,20,30>
<checkpoint, <T1, T2>>
<T1,commit>
<T3,start>
<T3,B,20,40>
<T4,start>
<T4,B,40,80>
<T4,C,100,50>
<T4,commit>
Undo-List: T3, T2
Redo-List: T1, T4
B: 20,
20, 80
A: 20,
C: 50,
... Crash ...
29
Elementos de Bases de Datos
Clase 19
30
5
Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación
Elementos de Bases de Datos – 2do. Cuatrimestre de 2004
Garantizar la atomicidad
Organización de la Memoria
La transacción T entra en el estado cometido después
de haberse grabado en memoria estable el registro
de bitácora <T,commit>.
Antes de que el registro de bitácora <T,commit>
pueda grabarse en memoria estable, deben haberse
grabado en memoria estable todos los registros de
bitácora que pertenecen a T.
Antes de grabar en la base de datos un bloque que
está en memoria principal (volátil) deben haberse
grabado en memoria estable todos los registros de
bitácora que pertenecen a los datos de ese bloque.
Elementos de Bases de Datos
Clase 19
M. Volátil
Volátil
31
Base de Datos
M. No Volátil
Registros
sobre datos
A1…An
M. Volátil
Registros
sobre datos
A1…An
<Checkpoint>
Tiempo
M. No Volátil
Escrituras
sobre datos
A1…An
(*) Inicio de
checkpoint
Elementos de Bases de Datos
Clase 19
No Volátil
Base de Datos
Memoria
Checkpoints: pasos a seguir
Bitácora
Memoria
Escrituras
sobre datos
A1…An
33
Buffering de la base de
datos
Buffer de
la Base
de Datos
Bitácora
Buffer de
Bitácora
Elementos de Bases de Datos
Clase 19
Buffering de registros de
bitácora
Anteriormente supusimos que cada registro de bitácora
se graba en memoria estable en el momento en que se
crea.
Esto genera un gasto extra (overhead) pues la
información normalmente se graba en bloques.
Como cada registro de bitácora es mucho más pequeño
que un bloque, la grabación de cada registro de
bitácora se traduce en una grabación mucho mayor en
el nivel físico.
Grabar un bloque en memoria estable puede requerir
varias operaciones de grabación en el nivel físico.
Elementos de Bases de Datos
Clase 19
34
Buffering de la base de
datos
La base de datos se almacena en memoria no volátil
(disco) y se van trayendo a memoria principal según se
requiera. Esto se hace mediante un esquema de
bloques.
Si un bloque B1 en memoria principal fue modificado
pero debe ser reemplazado por otro bloque B2,
entonces debe hacerse lo siguiente:
Supongamos que la entrada del bloque B2
hace que el bloque B1 deba salir de memoria
principal:
Deben grabarse en memoria estable todos los
registros de bitácora pertenecientes al bloque
B1.
„
Grabar B1 (Output(B1)).
Debe grabarse el bloque B1 en el disco.
„
Luego cargar B2 (Input(B2)).
Recién después puede cargarse el bloque B2
desde el disco a memoria principal.
Este es el concepto estándar de memoria virtual de los
sistemas operativos.
Elementos de Bases de Datos
Clase 19
32
35
Elementos de Bases de Datos
Clase 19
36
6
Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación
Elementos de Bases de Datos – 2do. Cuatrimestre de 2004
Buffering de la base de datos
Transacción T
Bitácora
<T,start>
<T,A,1000,950>
...
Read(B,b1)
...
Bloque donde reside
B fuera de MP
Se graba en
memoria estable:
1) <T,A,1000,950>
2) Bloque donde
reside el dato A.
Rol del SO en el manejo del
buffer
El buffer puede manejarse de dos maneras:
El SMBD reserva parte de memoria principal para
usarla como buffer.
„
„
El SMBD implementa el buffer en un espacio de
memoria virtual provisto por el sistema operativo.
Se elige sacar bloque
donde reside A
„
„
Elementos de Bases de Datos
Clase 19
Si falla el almacenamiento no volátil, se
restaura el contenido de la última copia.
Esto restaura la base de datos al estado en
que se encontraba cuando se realizó la copia
de la bases de datos completa a memoria
estable.
Luego, el sistema usa la bitácora para llevar
la base de datos al estado consistente más
reciente posible.
Elementos de Bases de Datos
Clase 19
39
40
Implementación de Memoria
Estable
Copias de Seguridad
La información que reside en memoria estable nunca se
pierde.
Para alcanzar ello, debe repetirse la información (de
manera controlada) en varios medios de almacenamiento.
La transferencia de bloques entre la memoria y el disco
puede resultar en:
Ninguna transacción debe estar activa durante
el proceso de dump y se ejecuta un proceso
similar al checkpointing:
Se vuelcan los registros de bitácora residiendo
actualmente en memoria principal al almacenamiento
estable.
Se vuelcan todos los bloques de buffer al disco.
Se copian los contenidos de la base de datos al
almacenamiento estable.
Se vuelca un registro de bitácora <dump> al
almacenamiento estable.
Elementos de Bases de Datos
Clase 19
38
Falla con pérdida de información
no volátil
Hasta ahora abordamos fallas que resultan en
pérdida de información que reside en memoria
volátil.
Aunque rara vez se producen fallos en la
memoria no volátil, debemos estar preparados
para este tipo de fallos.
La técnica es copiar periódicamente el
contenido entero (dump) de la base de datos
a un almacenamiento estable (por ejemplo,
cintas magnéticas).
Elementos de Bases de Datos
Clase 19
El SO decide sacar los bloques de memoria, de modo tal
que el SMBD nunca tiene control de las salidas de bloques
de buffer.
Esto genera accesos extras al disco.
Elementos de Bases de Datos
Clase 19
37
Falla con pérdida de información
no volátil
El tamaño del buffer está acotado por los requerimientos
de memoria por parte de otras aplicaciones.
Aunque no se use el espacio del buffer, no puede usarse
para otro fines.
–
–
–
41
Terminación con Éxito: la información transferida llegó íntegra a su
destino.
Fallo Parcial: ocurrió un fallo durante la transferencia y el bloque
destino tiene información incorrecta.
Fallo Total: ocurrió un fallo al inicio de la transferencia y el bloque
destino queda intacto.
Elementos de Bases de Datos
Clase 19
42
7
Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación
Elementos de Bases de Datos – 2do. Cuatrimestre de 2004
Implementación de Memoria
Estable
La Operación Output(B)
Si ocurre un fallo en la transferencia de datos,
el sistema debe detectarlo e invocar un sistema
de recuperación que restaure el bloque a un
estado consistente.
Para hacerlo, el sistema debe mantener dos
bloques físicos por cada bloque lógico de la
base de datos.
En el caso de discos espejados, ambos bloques están
fisicamente en la misma locación.
„ En el caso de copias remotas, uno de los bloques es
local y el otro está en un sitio remoto.
Una operación de salida se ejecuta
como sigue:
„
„
„
Elementos de Bases de Datos
Clase 19
44
Puntos de Verificación Difusos
Durante la recuperación, se examina cada par de
bloques físicos.
Si los dos son iguales y no existen errores detectables,
no es necesario tomar más acciones.
Si un bloque contiene un error detectable (checksum),
se sustituye su contenido por el valor del segundo
bloque.
Si ambos bloques no contienen errores detectables,
pero el contenido es diferente, entonces se sustituye el
contenido del primer bloque por el valor del segundo.
Este procedimiento garantiza que una escritura en
almacenamiento estable termine con éxito o no
produzca cambio alguno.
Elementos de Bases de Datos
Los puntos de verificación (checkpoints) requieren que
todas las actualizaciones a las base de datos se
suspendan temporariamente.
La técnica de puntos de verificación difusos (fuzzy
checkpointing) permite que se reinicien las
actualizaciones después de grabar el registro de
checkpoint en bitácora en memoria estable pero antes
de que los bloques modificados se escriban en disco.
En lugar de recorrer hacia atrás la bitácora hasta
encontrar un registro de checkpoint (donde se hizo la
última escritura segura), se almacena en una posición
fija del disco la ubicación del último checkpoint (lastcheckpoint).
Elementos de Bases de Datos
Clase 19
45
46
Temas de la clase de hoy
Puntos de Verificación Difusos
Antes de escribir el registro de checkpoint, se crea una
lista de todos los buffers modificados.
La información de last-checkpoint se actualiza después de
que todos los bloques de buffer en la lista de modificados
han sido grabados (output) en disco.
Los bloques de buffer no deben modificarse mientras
están siendo grabados en disco.
Se debe contar con un protocolo de escritura por
adelantado (write-ahead) para que se graben antes los
registros de bitácora pertenecientes a los bloques que
están siendo grabados en memoria estable.
La bitácora sólo se utiliza para los efectos de deshacer.
Los puntos de verificación
difusos tienen problemas.
Elementos de Bases de Datos
Clase 19
Elementos de Bases de Datos
Clase 19
43
Implementación de Memoria
Estable
Clase 19
„
Escribir la información en el primer
bloque físico.
Una vez que se completa con éxito la
primera escritura, escribir la misma
información en el segundo bloque físico.
La salida está completa sólo después de
terminar con éxito la segunda escritura.
47
Recuperación de Fallos
„
„
Puntos de Verificación. Modificación para
ambientes concurrentes.
Puntos de Verificación Difusos.
Implementación de Memoria Estable
Bibliografía
„
“Fundamentos de Bases de Datos” – A.
Silberschatz. Capítulo 15.
Elementos de Bases de Datos
Clase 19
48
8