Alumna: Laura Valentina Rodriguez Diaz Universidad San José Semestre: Sexto Ing. Sistemas Asignatura: Diseño y gestión de bases de datos
Se ejecutan automáticamente controlando la intercalación de transacciones concurrentes
Es la ejecución de instrucciones que accesan a una DB compartida
Cambios de estado debido a actualizaciones, inserciones y supresiones
Una base de datos está en un estado consistente si obedece todas las restricciones de integridad definidas sobre ella
El usuario interrumpe el proceso
Se puede perder el contenido de almacenamiento temporal o buffers
Se conoce como caídas suaves (crash)
es aquel defecto o falta que presenta algo y que por tanto lo hará menos útil de lo que era o directamente no funcionará.
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 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
Una transacción no puede hacer cambios a la base de datos hasta que llegue a su COMMIT
Técnicas basadas en actualización inmediata
Procesamiento
La atomicidad controla la llegada con el COMMIT
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.
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
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.
UNDO/REDO Recovery
UNDO (WRITE_OP) deshacer una operación de escritura sobre un data ítem WRITE_OP consiste en examinar sus entradas al log
PROCEDURE RIU_M usa dos listas de transacciones
Las transacciones activas
Las transacciones que han llegado a su COMMIT desde el último checkpoint
Modelo de transacciones
Propiedades
- Atomicidad - Consistencia - Aislamiento -Permanencia
Errores del sistema
Ralizar operaciones que causen un overflow
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 por catastrofe
Como su nombre lo indica sucede por una catástrofe y es similar al de fallas de los medios
Hace un respaldo periódico
Su recuperación se hace a partir del Database Backup.
Fallas en los medios de almacenamiento
Es un percance en el cual se destruye físicamente alguna porción de la DB.
La restauración de utilitaria sirve para recrear la DB despues de una falla
Su recuperación implica cargar de nuevo la DB a partir de una copia de respaldo (database backup)
Fallas del sistema
Afectan a todas las transacciones que se estaban ejecutando pero no afecta la base de datos
Fallas locales
Afectan solo a la transacción en donde ocurriò
Recuperaciòn de fallas
