Universidad Nacional del Sur Departamento de Ciencias e Ingeniería de la Computación Elementos de Bases de Datos 2do. Cuatrimestre de 2004

Transcripción

1 2do. Cuatrimestre de 2004 Elementos de Bases de Datos Dpto.Ciencias e Ingeniería de la Computación Universidad Nacional del Sur Lic. María Mercedes Vitturini [mvitturi@cs.uns.edu.ar] Clase 19 1er. Cuatrimestre de 2004 Tipos de Fallos Fallos en la Transacción 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. Caida del sistema: por ejemplo errores del hardware o software de base de datos o software del sistema operativo. Fallo de disco: daño físico en el medio de almacenamiento masivo. Otras transacciones continuan con su ejecución Todas las transaccio nes deben ser recuperadas Clase 19 2 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). Acciones tomadas a continuación de un fallo para asegurar la consistencia de la base de datos y la atomicidad de las transacciones (paleativas). Clase 19 3 Recuperación mediante 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. Nombre del Dato: el nombre único del dato escrito. Valor Antiguo: el valor del dato anterior a la escritura. Valor Nuevo: el valor que tendrá el dato después de la escritura. Clase 19 4 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. 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. Clase 19 5 Modificación diferida: pasos a seguir 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 <T,start> y <T,commit>. Clase

2 2do. Cuatrimestre de 2004 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. 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. La operación Undo extrae la información de la bitácora para determinar que datos deben restaurarse. Clase 19 7 Modificación inmediata: pasos a seguir 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 1,v 2 >. 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(Reg)). Clase 19 8 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. 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> Clase 19 9 Puntos de Verificación (Checkpoints) 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. Clase 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: 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. Clase Checkpoints: pasos a seguir Base de Datos M. Principal Registros Tiempo M. Estable (*) Inicio de checkpoint Registros <Checkpoint> M. Principal Escrituras M. Estable Escrituras Clase

3 2do. Cuatrimestre de 2004 Checkpoints: pasos a seguir ante fallos Para cada transacción T i tal que aparece en la bitácora el registro <T i,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 T i 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 <T i,start> más cercano. Luego, se aplica Redo o Undo sobre T i y todas las transacciones T k que le suceden. Clase Checkpoints: pasos a seguir ante fallos Pasos a seguir con el resto de las transacciones: Ejecutar Redo(T k ) para todas las transacciones cuyo registro <T k,commit> aparece en la bitácora. Ejecutar Undo(T k ) de la transacción cuyo registro <T k,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 Clase Checkpoints: un ejemplo T 0 T 1... T 66 T 67 T T 100 En el esquema de recuperación sólo deben reconsiderarse T 67, T 68,..., T 100. <Checkpoint> Clase Checkpoints con transacciones concurrentes En un esquema sin concurrencia, en el proceso de recuperación solamente se consideraban: 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. Clase 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. Clase Recuperación y Concurrencia 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. Clase

4 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. En ambos casos se usa la información de bitácora para proceder a la recuperación. Clase 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: 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. Clase Recuperación y Concurrencia 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 T 0 modificó el dato Q y tiene que ser retrocedida, entonces debe restaurarse el valor anterior de Q. Pero si una transacción T 1 realizóotrocambiosobreq después del cambio de T 0 pero antes de que T 0 sea retrocedida, el cambio realizado por T 1 se perderá. 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. Clase Retroceso de Transacciones 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>, Esto es, T primero modifica A de 10 a 20 y luego de 20 a 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). Clase Crash o Caidas de Sistemas 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: undo-list redo-list, Estas listas contienen a las transacciones que deben deshacerse y rehacerse respectivamente. Inicialmente estas listas están vacías. Clase Undo-List y Redo-List Se realiza un recorrido hacia atrás de los registros almacenados en la bitácora hasta el primer <checkpoint, L>: Por cada item <T i,commit>, se agrega T i a redo-list. Por cada item <T i,start>, si T i 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 T i de L si T i no esta incluída en redo-list se agrega a undo-list. Clase

5 2do. Cuatrimestre de 2004 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 <T i,start> de cada transacción T i 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 T i en la lista redo-list. Clase Recuperación ante Fallos 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ó. Clase Recuperación ante fallos Ejemplo: <T i,a,10,20> <T j,a,20,30> <T j,commit> T i aborta pero T j comete Si se realiza un redo primero, A quedará en 30 y el posterior undo dejará a A con 10. 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. Clase Ejemplo Fallo de sistema de una transaccion T1 read (A) write (A) read (B) T2 read (A) read (B) write (B) Estampillas R-ts(A)= ts(t 1 ) W-ts(A)=ts(T 1 ) R-ts(A)=ts(T 2 ) R-ts(B)=ts(T 2 ) W-ts(B)=ts(T 2 ) Bitacora <T 1 start> <T 1, A, 100, 200> <T 2 start> <T 2, B, 400, 200> Protocolo: Estampilla de tiempo con ts(t 1 ) < ts(t 2 ) T 1 debe retroceder por no cumplir las condiciones del protocolo T 2 debe retroceder en cascada. Clase Ejemplo Fallo de sistema de una transacción Acciones llevadas a cabo durante la recuperación : Undo (T 2 ) Undo (T 1 ) 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 T 1 y T 2 R-ts(A) = W-ts(A) = R-ts(B)= W-ts(B)= 0 Clase Crash de Sistema <T 1,start> <T 1,B,50,20> <T 2,start> <T 2,A,20,30> <checkpoint, <T 1, T 2 >> <T 1,commit> <T 3,start> <T 3,B,20,40> <T 4,start> <T 4,B,40,80> <T 4,C,100,50> Dada la siguiente foto de la bitácora antes de un crash de sistema. Undo-List: T 3, T 2 Redo-List: T 1, T 4 B: 20, 80 A: 20, C: 50, <T 4,commit>... Crash... Clase

6 2do. Cuatrimestre de 2004 Garantizar la atomicidad 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. Clase Organización de la Memoria Memoria No Volátil Memoria Volátil Base de Datos Buffer de la Base de Datos Buffer de Clase Checkpoints: pasos a seguir Base de Datos M. Volátil Registros Tiempo M. No Volátil (*) Inicio de checkpoint Registros <Checkpoint> M. Volátil Escrituras M. No Volátil Escrituras Clase 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. Clase 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: Grabar B1 (Output(B1)). Luego cargar B2 (Input(B2)). Este es el concepto estándar de memoria virtual de los sistemas operativos. Clase Buffering de la base de datos 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. Debe grabarse el bloque B1 en el disco. Recién después puede cargarse el bloque B2 desde el disco a memoria principal. Clase

7 2do. Cuatrimestre de 2004 Buffering de la base de datos Transacción T... Read(B,b 1 )... Bloque donde reside B fuera de MP <T,start> <T,A,1000,950> Se graba en memoria estable: 1) <T,A,1000,950> 2) Bloque donde reside el dato A. Se elige sacar bloque donde reside A Clase 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 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. El SMBD implementa el buffer en un espacio de memoria virtual provisto por el sistema operativo. 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. Clase 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). Clase Falla con pérdida de información no volátil 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. Clase Copias de Seguridad 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. Clase Implementación de Memoria Estable 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: 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. Clase

8 2do. Cuatrimestre de 2004 Implementación de Memoria Estable 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. Clase La Operación Output(B) Una operación de salida se ejecuta como sigue: 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. Clase Implementación de Memoria Estable 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. Clase Puntos de Verificación Difusos 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). Clase 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. Clase Temas de la clase de hoy 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. Clase