Recuperación y concurrencia en base de datos.

En esta oportunidad quiero hablar un poco sobre como un motor de base de datos ataca los problemas de concurrencia o fallas durante el procesamiento de datos. Tambien se mencionará el concepto de transacción.

Los problemas de recuperación y concurrencia en un sistema de BD están muy vinculados a la noción de procesamiento de transacciones.

RECUPERACION DE TRANSACCIONES

Una transacción es una unidad lógica de trabajo. Supongamos, que la tabla P, la de partes, contiene un campo adicional CANTTOTAL que representa la cantidad total enviada de la parte en cuestión; el valor de CANTTOTAL para una parte dada es igual a la suma de todos los valores SP.CANT de todos los registros SP correspondientes a esa parte. Consideremos ahora la siguiente secuencia de operaciones, cuya intención es añadir un nuevo envío (S5, P1,  1000) a la BD:

EXEC SQL WHENEVER SQLERROR GO TO ANUAR;

EXEC SQL INSERT

                     INTO SP (S#, P#, CANT)

                     VALUES (‘S5’, ‘P1’, 1000);

EXEC SQL UPDATE P

                     SET CANTTOTAL = CANTTOTAL + 100

                     WHERE P# = P1;

EXEC SQL COMMIT;

                     GO TO TERMINAR;

ANULAR:

            EXEC SQL ROLLBACK;

TERMINAR: RETURN;

La proposición INSERT (insertar)  agrega el nuevo envío a la tabla SP, la proposición UPDATE (actualizar) pone al día en forma apropiada el campo CANTOTAL de la parte P1.

Esta operación implica en realidad 2 modificaciones de la BD. La BD ni siquiera es consistente entre esas 2 modificaciones; viola en forma temporal  el requerimiento según el cual el valor  de CANTTOTAL para la parte P1 debe ser igual a la suma de todos los valores SP.CANT correspondientes a esa parte.

En una situación ideal, nos gustaría tener una garantía absoluta de que se realizarán las 2 modificaciones. Por desgracia, es imposible ofrecer tal garantía; siempre existe la posibilidad de una falla y, además, de una falla en el peor momento posible.

 Pero si el sistema maneja el procesamiento de transacciones, podrá ofrecer lo más cercano a esa garantía. Garantizará que si la transacción  ejecuta algunas modificaciones y después presenta una falla antes de que llegue el término normal de la transacción, se anularán esas modificaciones. Así, o bien la transacción se lleve a cabo en su totalidad, o se cancela en su totalidad. De esta manera puede lograrse que una secuencia de operaciones, la cual en esencia no es atómica, aparente serlo desde un punto de vista externo.

El componente del sistema encargado de lograr la atomicidad se conoce como manejador de transacciones, y las operaciones COMMIT (comprometer) y ROLLBACK (retroceder) son la clave de su funcionamiento:

  • La operación COMMIT señala el término exitoso en la transacción: le dice al manejador de transacciones que se ha finalizado l con éxito una unidad lógica de trabajo, que la BD está de nuevo en un estado consistente, y que pueden «comprometer», todas las modificaciones efectuadas por esa unidad de trabajo.
  • La operación ROLLBACK, en cambio, señala el término no exitoso de la transacción: dice al manejador de transacciones que algo salió mal, que la BD podría estar en un estado inconsistente, y que todas las modificaciones efectuadas hasta el momento por la unidad lógica del trabajo deben «retroceder» o anularse.

 PUNTOS DE SINCRONIZACION

La ejecución de una operación COMMIT o ROLLBACK establece lo que se conoce como un punto de sincronización. Un punto de sincronización representa el límite entre 2 transacciones consecutivas, de modo que corresponde al final de una unidad lógica de trabajo, y por tanto al punto ene l cuál la BD está en un estado de consistencia. Las únicas operaciones que  establecen un punto de sincronización son COMMIT, ROLLBACK  y el inicio de un programa.

Cuando se establece un punto de sincronización: 

  •  Se comprometen (COMMIT) o se anulan (ROLLBACK) todas las modificaciones realizadas por el programa desde el punto de sincronización anterior;
  • Se cierran todos los cursores abiertos y se pierde todo lo posicionamiento en la BD;
  • Se liberan todos los registros bloqueados.

Es importante advertir que COMMIT y ROLLBACK terminan la transacción, no el programa. En general, una sola ejecución del programa incluirá una secuencia varias transacciones, efectuadas una tras otra. Cada operación COMMIT o ROLLBACK termina una transacción e inicia la siguiente. Sin embargo, muy a menudo una ejecución de un programa corresponderá a una sola transacción; y en esos casos, muchas veces será posible codificar ese programa sin proposiciones COMMIT y ROLLBACK explícitas.

RECUPERACION DEL SISTEMA Y DE LOS MEDIOS DE ALMACENAMIENTO

Examinaremos brevemente que se necesita para recuperarse de una falla global. Tales fallas se dividen en 2 categorías amplias:

  • Fallas del Sistema, las cuales afectan a todas las transacciones que se están realizando pero no dañan físicamente a la BD. Las fallas del sistema se conocen también como caídas suaves.
  • Fallas de los Medios de Almacenamiento, las cuales si causan daños a la BD, o a una porción de ella, y afectan al menos a las transacciones que están utilizando esa porción. Las fallas de los medios de almacenamiento se denominan a veces caídas duras.

FALLA DEL SISTEMA

El punto crítico de una falla del sistema es que se pierde el contenido de la memoria principal. Por tanto, ya no se conocerá el estado preciso  de la transacción que se estuviera realizando en el momento de la falla; esa transacción jamás se podrá completar con éxito, por lo cuál será preciso anularla cuando se reinicie el sistema.

Cada cierto intervalo previamente establecido el sistema establece un «punto de revisión»  de manera automática. El establecimiento de un punto de revisión implica:

•a)   Grabar físicamente el contenido de los buffers en la BD física;

•b)   Y grabar físicamente un registro de punto de revisión especial en la bitácora física.

El registro de punto de revisión incluye una lista de todas las transacciones que se estaban realizando en el momento de establecerse el punto de revisión. Para comprender la forma como se utiliza esta información deberá leerse de la siguiente manera:

 tiempo-transacciones

  • Se presentó una falla en el sistema en el momento tf.
  • El punto de verificación más reciente antes de tf se tomó en el momento tv.
  • Las transacciones de tipo T1 se completaron antes del tiempo tv.
  • Las transacciones de tipo T2 se iniciaron antes del tiempo tv y se completaron después del tiempo tv y antes del tiempo tf.
  • Las transacciones de tipo T3 también se iniciaron antes del tiempo tv pero no se completaron antes del tiempo tf.
  • Las transacciones de tipo T4 se iniciaron después del tiempo tv y se completaron antes del tiempo tv.
  • Por último, las transacciones de tipo T5 también se iniciaron después del tiempo tv pero no se completaron antes del tiempo tf.

Por tanto, ene l momento del reinicio el sistema efectúa el siguiente procedimiento a fin de identificar las transacciones de los tipos T2-T5:

•1.   Comenzar con 2 listas de transacciones, la lista ANULAR y la lista REPETIR. Igualar la lista ANULAR a la lista de todas las transacciones incluidas en el registro de punto de revisión. Dejar vacía la lista REPETIR.

•2.   Examinar la bitácora hacia delante a partir del registro de punto de revisión.

•3.   Si se encuentra una entrada de bitácora de «iniciar transacción» para la transacción T, añadir T a la lista ANULAR.

•4.    Si se encuentra una entrada de bitácora de «comprender» para la transacción T, pasar esa transacción de la lista ANULAR a la lista REPETIR.

•5.   Cuando se llegue al final de la bitácora, las listas ANULAR y REPETIR identificarán, respectivamente, las transacciones de los tipos T3 y T5 y la de los tipos T2 y T4.

Enseguida el sistema revisará la bitácora hacia atrás, anulando todas las transacciones de la lista ANULAR. A continuación la revisará otra vez hacia delante, realizando de nuevo todas las transacciones de la lista REPETIR. Por último, una vez terminada toda esa actividad de recuperación, el sistema estará listo para aceptar trabajos nuevos.

 FALLA DE LOS MEDIOS DE ALMACENAMIENTO

Una falla de los medios de almacenamiento es un percance ene l cual se destruye físicamente alguna porción de la BD. La recuperación de una falla semejante implica en esencia cargar de nuevo la BD a partir de una copia de respaldo y utilizar después la bitácora para realizar de nuevo todas las transacciones terminadas desde que se hizo esa copia de respaldo. No hay necesidad de anular las transacciones inconclusas en el momento de la falla, porque por definición todas las modificaciones de esas transacciones ya se anularon de todas maneras.

La parte de restauración de la utilería servirá entonces para recrear la BD después de una falla de los medios de almacenamiento a partir de una copia de respaldo especificada.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.