Recuperaciòn de fallas
es aquel defecto o falta que presenta algo y que por tanto lo hará menos útil de lo que era o directamente no funcionará.
Fallas locales
Afectan solo a la transacción en donde ocurriò
Fallas globales
Afectan a varias y casi siempre a todas las transacciones que se estaban efectuando en el momento de la falla
Tiene implicaciones importantes en el sistema
Fallas del sistema
Afectan a todas las transacciones que se estaban ejecutando pero no afecta la base de datos
Fallas en los medios de almacenamiento
Es un percance en el cual se destruye físicamente alguna porción de la DB.
Su recuperación implica cargar de nuevo la DB a partir de una copia de respaldo (database backup)
La restauración de utilitaria sirve para recrear la DB despues de una falla
Fallas por catastrofe
Como su nombre lo indica sucede por una catástrofe y es similar al de fallas de los medios
Su recuperación se hace a partir del Database Backup.
Hace un respaldo periódico
Errores del sistema
Ralizar operaciones que causen un overflow
Modelo de transacciones
Propiedades
- Atomicidad - Consistencia - Aislamiento -Permanencia
Técnicas basadas en actualización inmediata
UNDO/REDO Recovery
PROCEDURE RIU_M usa dos listas de transacciones
Las transacciones que han llegado a su COMMIT desde el último checkpoint
Las transacciones activas
UNDO (WRITE_OP) deshacer una operación de escritura sobre un data ítem WRITE_OP consiste en examinar sus entradas al log
Recovery
Cada DBMS envuelto en una transacción multi-DB tendrá su propia técnica de recovery y su propio controlador de transacciones separado de los otros DBMS.
Procesamiento
Si sufre algún problema que le impida ejecutarse, la operación ROLLBACK señala el término no exitoso de la transacción, deben "retroceder" o anularse
Si una transacción no sufrió ningún problema y se pudo ejecutar completa, entonces el DBMS debe "comprometerse" a hacer permanentes los cambios que la transacción hizo sobre la base de datos ya que ésta debió quedar en un estado consistente.
La atomicidad controla la llegada con el COMMIT
actualización diferida
Es postergar o diferir cualquier actualización a la DB hasta que la transacción complete su ejecución exitosamente y llegue a su COMMIT.
Durante la ejecución de la transacción las actualizaciones son grabadas en el log y en el área de trabajo de la transacción. Cuando la transacción llega a su COMMIT, el log es forzado a escribirse en disco y luego las actualizaciones se reflejan en la DB. Si la transacción falla antes de llegar a su COMMIT no es necesario aplicar el UNDO
El protocolo de la actualización diferida se define así
Una transacción no puede hacer cambios a la base de datos hasta que llegue a su COMMIT
Una transacción no llega a su COMMIT hasta que todas las operaciones de actualización hayan sido registradas en el log y el log haya sido forzado a escribirse en disco