Base de datos - Unidad 5 Flashcards
(8 cards)
Recovery definicion y tipos.
Se trata de la características que poseen los DBMS para recuperarse automáticamente ante fallos, previniendo inconsistencias de datos.
Tipos:
* Implícita (una única operación es una transacción)
* Explícita (muchas operaciones conforman una única transacción)
El concepto principal es el de Transacción, que representa una unidad de trabajo lógica que comprende una o varias operaciones de DB, que se ejecutan como un todo. De ésta manera, una transacción también representa una unidad de recuperación, ya que, si una parte de la misma no puede ejecutarse, los datos se deberán revertirse como estaban originalmente antes de iniciar la misma.
Recovery en operaciones
- La operación BEGIN TRANSACTION indica el comienzo de una transacción: hasta ese momento los datos se están en un estado consistente, y a partir de allí comenzarán las modificaciones realizadas por la transacción en particular.
- La operación COMMIT indica la finalización de una transacción satisfactoria: indica al administrador de transacciones que una unidad lógica ha concluido satisfactoriamente, que la DB está o debería estar nuevamente en un estado consistente y que todas las actualizaciones efectuadas por esa unidad de trabajo ahora que pueden ser “confirmadas” o definitivas.
- Por el contrario, la operación ROLLBACK indica la finalización de una transacción no satisfactoria: indica al administrador de transacciones que algo ha salido mal, que la DB puede estar en un estado inconsistente y que todas las actualizaciones realizadas hasta este momento por la unidad de trabajo lógica deben ser “revertidas” o desechadas.
Propiedades de las Transacciones.
- Atomicidad: se garantiza (desde un punto de vista lógico) que se ejecuten en su totalidad o que no se ejecuten en lo absoluto (sin puntos medios).
- Consistencia: una transacción transforma un estado consistente de la DB en otro igual, sin necesidad de conservar la consistencia en todos los puntos intermedios.
- Aislamiento: las modificaciones realizadas por una no podrán ser vistas por otra transacción hasta que los cambios hayan sido confirmados. Están aisladas entre sí.
- Durabilidad: una vez que una transacción es confirmada (commit), sus actualizaciones quedan persistentes definitivamente, y sobreviven en la DB aun cuando haya una caída posterior del sistema.
Transacciones – Partes de T-Log
- Activa => Transacción en ejecución.
- Pasiva => Transacciones que ya terminaron.
Log de Transacción, Transaction Log, o T-Log
Para implementar el funcionamiento transaccional de las sentencias SQL, el DBMS mantiene un LOG de transacciones en donde guarda los detalles de todas las actualizaciones que van ocurriendo sobre la BD, y el estado anterior y posterior de los datos actualizados. Esto se puede utilizar para restaurar el objeto actualizado a su valor anterior.
El Log reside siempre en memoria secundaria, y se rige por el Protocolo de Escritura Adelantada, que dice que antes de realizar un cambio en la BD, debe haber persistido con éxito el registro en el T-LOG en memoria secundaria. Por esto, la velocidad de los dispositivos de los almacenamientos secundarios es crucial.
El T-LOG consta de dos partes: una activa y otra pasiva. La parte activa se usa para grabar los detalles de las actualizaciones conforme son realizadas, y normalmente es guardada en dispositivos de almacenamientos de alta velocidad. Cuando se llena, es transferido a la pasiva, en almacenamientos de menor desempeño y coste. Se puede hacer automáticamente por el DBMS o manualmente por el DBA. Equilibrio entre el T-Log pasivo y activo, para que prevenir situaciones que se estén consumiendo demasiado espacio de alto desempeño (costoso) para almacenar transacciones que ya han dejado de estar vigentes.
En el T-log se generan dos marcas especiales en determinados momentos:
- Commit Point: corresponde al final satisfactorio de una transacción (COMMIT), por lo tanto, a un punto en el cual la DB está en un estado consistente. Por el contrario, cando una transacción termina en ROLLBACK, se regresa la DB al estado en que estaba antes de BEGIN TRANSACTION, lo que en efecto significa regresar al commit point anterior. Luego de un commit point todos los cambios se vuelven permanentes y se liberan todos los recursos y estructuras de datos que el DBMS utilizó durante el procesamiento de la misma.
- Check Point: marcas específicas que el DBMS realiza en el T-LOG a determinados intervalos regulares prescritos. Esos puntos de verificación indican que en ese momento el DBMS finalizó satisfactoriamente de escribir físicamente en memoria secundaria el contenido de los búferes de la DB que estaban en memoria principal pendiente de persistir en la BD física.
Fallos. Significado y nombrar los tipos que existen.
Un fallo es una situación anómala que se desencadena en un DBMS (excepción o error), que obliga a disparar el ROLLBACK de una o más transacciones.
- Locales => afectan a una única transacción.
- Globales => afectan a todas las transacciones.
- Soft Crash (Caídas suaves)
- Hard Crash (Caídas duras)
Nombrar el significado de cada tipo de fallo.
Los fallos pueden ser locales o globales:
- Locales: son las que afectan sólo a una transacción. El procedimiento de recuperación implica utilizar la información registrada en el T-LOG para la transacción involucrada, y revertir todos los cambios ocurridos hasta el comienzo de la misma.
- Globales: fallas que afectan a todas las transacciones que están en progreso en el momento de la misma. Según el impacto de dichas fallas se pueden subclasificar en:
- Soft Crash (Caídas suaves): afectan a todas las transacciones que están actualmente en progreso, pero que no dañan físicamente a la DB (ej. interrupción del suministro eléctrico, crash del Sistema Operativo, etc.).
Se pierde el contenido de la memoria principal. Ya no es posible el estado preciso de cualquier transacción que estaba en progreso en el momento de la falla y deberá ser deshecha al reiniciar el sistema. Además, a la hora del reinicio, puede que sea necesario volver a realizar determinadas transacciones que se realizaron satisfactoriamente pero que no pudieron lograr que sus actualizaciones fueran transferidas desde los búferes de la DB (memoria principal) hacia la DB física (memoria secundaria). - Hard Crash (Caidas duras): causan daño a la DB o a alguna parte de ella, y afectan a la consistencia de los datos de al menos las transacciones que están usando porción (ej. ruptura de disco físico, inconsistencia en sistema de archivos, etc). La recuperación de éste tipo de fallas implica una restauración de la base de datos a partir de una copia de seguridad realizada con anterioridad (backup).
- Soft Crash (Caídas suaves): afectan a todas las transacciones que están actualmente en progreso, pero que no dañan físicamente a la DB (ej. interrupción del suministro eléctrico, crash del Sistema Operativo, etc.).
Recuperacion (recovery)
Proceso de recovery que un DBMS realiza ante un Soft Crash para recuperar la consistencia de un BD;
1. Comienza con dos listas de transacciones, la lista DESHACER y la lista REHACER. Carga la lista DESHACER con la lista de todas las transacciones dadas en CheckPoint más reciente y deja vacía la lista REHACER.
- Busca hacia adelante en el T-LOG comenzando a partir de ese CheckPoint.
- Si encuentra una entrada BEGIN TRANSACTION en el LOG para una transacción nueva, la añade a la lista DESHACER.
- Si encuentra una entrada COMMIT en el LOG para una transacción que finalizó, la mueve de la lista DESHACER a la lista REHACER.
- Cuando llega al fin del T-LOG, elimina de la lista de DESHACER las transacciones que comenzaron luego del último CheckPoint, y nunca finalizaron.
- Utiliza las listas resultantes DESHACER y REHACER para identificar las transacciones que deben deshacerse (rollback) y rehacerse (rollback + re-ejecuión) respectivamente. Por último, basándose en la información cargada en el T-LOG de cada transacción, realiza dichos procesos de reversión y re-ejecuión individualmente, para dejar finalmente la BD operativa para asumir nuevamente carga de trabajo.
