Actividad #15 y #16 Unidad 3

Bitácora de SGBD

Las bitácoras son fundamentales en lo que es la administración de bases de datos, pues con estas se puede tener un registro físicamente de todos los usuarios u objetos que se encuentren en determinada base de datos, esto nos sería muy útil en caso de pérdida de usuarios u objetos y sus dueños así como los roles que desempeñan dentro del gestor. Asimismo si ocurriera algún imprevisto en la base de datos o que A no llegara a estar disponible, una que se puede y checar diseño a datos el de u registro que se lleva con la bitácora. Continuación los mostraremos privilegios proposición en formato de una bitácora que nos permitirá registrar a los usuarios, tiene cuantos objetos de la base de datos, así como a la BD a la que pertenece y el rol que juega dentro de la misma. Es una bitácora sencilla pero muy útil pues contiene lo fundamental para hacer un registro muy completo y sin complejidades.

El sistema se mantiene al tanto de lo que hacen las transacciones mediante un fichero especial ll

amado bitácora del sistema de BD, también conocido como fichero log, diario registro histórico. La

bitácora es un fichero en el que se almacena detalles sobre las operaciones –efectuadas como

parte de las transacciones–que afectan a los valores de los elementos de información de la BD. Por ejemplo, para las actualizaciones se puede guardar el valor que tenían los datos afectados antes de la modificación y el que contienen después. La bitácora se mantiene en disco, fuera del área de la BD donde se almacenan los datos. Por tanto, no le afecta ningún tipo de fallo, salvo

(¡claro está!) los de tipo 5 y 6. Precisamente para protegerlo contra posibles fallos de estos tipos se suele realizar periódicamente una copia de seguridad (encinta, por ejemplo) del fichero bitácora.

Cada registro almacenado en la bitácora se llama entrada, y será de uno de los siguientes tipos:

< INICIAR, T >

Indica que la transacción

T ha comenzado

2

.

•

< ESCRIBIR, T, X, valor_anterior, valor_nuevo >

Indica que la transacción T ha cambiado el valor del elemento X de la BD 3. X contenía el

valor_anterior antes de la escritura y contendrá el valor_nuevo después de la escritura.

•< LEER, T, X >Indica que T leyó el valor del elemento  X de la base de datos

•< COMMIT, T >Indica que T finalizó con éxito y su efecto puede ser confirmado en la base de datos en disco; es decir, todos los cambios que ha realizado pueden ser consolidados o asenta

dos (quedar permanentes) en la BD.

•< ROLLBACK, T >Indica que la transacción T ha sido anulada (abortada, cancelada), de forma que ninguna de sus operaciones tendrá efecto sobre la base de datos en disco, como si T

Nunca se hubiera ejecutado: la transacción será revertida, todas sus operaciones serán deshechas.

Escritura anticipada en el fichero de bitácora. Hemos de tener en cuenta que la bitácora es un fichero en disco. Así que, como ya sabemos, actualizar la bitácora en disco implica:

1. copiar el bloque adecuado de la bitácora en disco en la memoria principal,

2. actualizar el bloque en memoria (insertar una nueva entrada) y

3. copiar el bloque desde la memoria al fichero de bitácora en disco. Esto supondría una escritura en disco cada vez que se inserta una nueva entrada en la bitácora (es

Decir, ¡cada vez que se anota la ejecución de una operación de transacción!).Para conseguir una

Única escritura por bloque, en la práctica...-

se mantiene un bloque completo de bitácora en memoria: un búfer de bitácora

9, y -cuando se llena de entradas, el bloque completo se escribe en disco (en el fichero de bitácora) Con esto se evita escribir varias veces en disco un mismo bloque de la bitácora, pero provoca otros  problemas, que ilustramos a continuación mediante un ejemplo. Supongamos una transacción  T en ejecución y que en el fichero de bitácora en disco ya está alma-cenada la correspondiente entrada

<INICIAR, T>.

Tras modificar los elementos X e  Y de la BD, se anotan las siguientes entradas sólo en el

búfer de bitácora en memoria: <ESCRIBIR, T, X, 7,15><ESCRIBIR, T, Y, 2,5>

Supongamos también que algunos de estos cambios se consolidan en la BD en disco10

, por ejemplo estos dos anteriores: en la base de datos se tiene por tanto X=15e Y=5. Realiza dos modificaciones más sobre los elementos Si V, y después finaliza con éxito, así que se anota,

todavía sólo en el búfer de bitácora, las entradas:<ESCRIBIR,T,Z,6,3><ESCRIBIR,T,V,8,1>y <COMMIT,T>El Comide Indica al sistema que puede confirmar en disco los cambios (hechos por T)aún no llevados a la BD, es decir los que modifican los valores Z de 6a 3 y Vde 8a 1

Supongamos ahora que el sistema comienza a escribir en la BD en disco los elementos Si V

modificados por, pero, recordemos, la realización de estos cambios todavía no se ha anotado ella bitácora en disco (sino que las entradas correspondientes siguen en el búfer de bitácora, que

no está lleno aún).Si el fallo ocurre justo durante la consolidación de los cambios de la BD en disco (transferencia), entonces es posible que algunos cambios de T sí se graben en disco (en BD queda

Z=3), pero otros no (en BD sigue V=8).Lo más normal es que el fallo haya provocado la pérdida del contenido de la memoria principal (es decir, el área local a T, el búfer de bitácora y el búfer de BD). El proceso de recuperación accede al fichero de bitácora en disco donde hallará la entrada <INICIAR, T>, pero no encontrará ninguna de las entradas del búfer de bitácora que todavía no se habían volcado en disco cuando ocurrió el fa-

yo. En particular no encontrará la entrada <COMMIT, T>, así que intentará anular.

Sin embargo  T no debe ser anulada, pues se realizó totalmente y con éxito. Lo único que ocurre

es que no se completó la confirmación en disco de sus cambios. Tan sólo se debería rehacer

cada una de sus operaciones.

Este error se hubiera evitado si, antes de comenzar la consolidación de cambios de BD en disco, se hubiera grabado en disco (y con éxito) la porción de bitácora que sólo estaba en el búfer de

bitácora: el sistema hubiera detectado la confirmación de T (pues en la bitácora en disco estaría la entrada <COMMIT, T>), y además sí sería posible rehacerlas modificaciones de T, porque estarían en bitácora (en disco) todas las entradas <ESCRIBIR, T,...>11.

Pero aún existe un problema adicional. Decíamos que el sistema intentará anular.

Dos de las en-tiradas perdidas a causa del fallo son:<ESCRIBIR, T, X, 7,15>y <ESCRIBIR, T, Y, 2,5>

así que no se tiene anotado en bitácora en disco ni el valor_anteriorni el valor_nuevopara Xni para Y.Pero ambos cambios fueron llevados a la BD en disco, de forma que X e Yya contienen sus nuevos valores 15y 5. No es posible deshacer estas operaciones de forma correcta. Otra entrada perdida es <ESCRIBIR, T, Z, 6,3>, que corresponde a otro cambio de Toque sí ha dado tiempo a consolidar en disco antes del fallo. Tampoco en este caso se puede deshacer

esta operación, por la misma razón que antes.

Vemos que es imposible recuperar la base de datos a un estado de consistencia anterior

.Todo esto también se hubiera evitado si, antes de comenzar la grabación de cambios de BD en

disco, se hubiera grabado en disco la porción de bitácora que sólo estaba en el búfer de bitácora:

sí sería posible deshacer las modificaciones de T (si ello fuera necesario, claro), porque estarían en

bitácora (en disco) todas las entradas <ESCRIBIR, T,...>12necesarias.

En realidad, lo que hemos hecho es razonar que, para evitar estos problemas, es necesario seguir

un protocolo de bitácora adelantada, puesto que asegurará que la base de datos podrá ser rechupe-rada de forma correcta. E l protocolo de bitácora adelantada indica que...1.

No se puede grabar en disco los cambios realizados por una transacción13T, hasta que se haya

forzado la escritura en disco de toda entrada de bitácora para T, hasta el momento actual14.

2. La operación confirmar de una transacción no se puede completar15hasta que se haya forzado la escritura en disco de cualquier entrada de bitácora para esa transacción 16

.Es decir, fuerza la escritura de la bitácora en disco antes de consolidar cualquier cambio realizado

por T. Ya sea para consolidar cambios en disco antes de que Alcance su punto de confirmación, o para consolidarlos después de que Tol haya alcanzado17.

Así que nunca va a ocurrir que 1º) se lleven a disco los cambios de elementos de BD realizados por

T y 2º) el sistema falle al ir a grabar en disco la parte de bitácora. Pero sí puede ocurrir que 1º) se grabe físicamente la parte de la bitácora de una modificación y 2º) el sistema falle cuando va a aplicar el cambio a la BD en disco. En este último caso, al recuperar T, el Gestor de Recuperación “verá” si cada modificación pudo hacerse o no físicamente, pues está registrada en bitácora. Podrá deshacerla o rehacerla usando la entrada correspondiente en bitácora.

Con el uso del protocolo de bitácora adelantada, siempre estamos seguros de que podemos llevar

la base de datos a un estado consistente, aunque ocurra un fallo mientras se graban en disco los

cambios de elementos de BD, pues será posible rehacer y/o deshacer los cambios.