Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Técnicas de Recuperación de Base de Datos

No description
by

Daihana Rivero

on 10 July 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Técnicas de Recuperación de Base de Datos

INTRODUCCIÓN
Con frecuencias las técnicas de recuperación están “ligadas” con los mecanismos de control de la concurrencia. Es decir, algunas técnicas funcionan mejor con unos métodos de control de concurrencia que con otros.

Dos técnicas fundamentales de recuperación de fallos no catastróficos son las técnicas basadas en
actualizaciones diferida
y en la
actualización inmediata

Técnicas de recuperación de fallos del sistema
Si el sistema sigue esta técnica, una vez reiniciando el mismo, el Gestor de Recuperación ejecutara el algoritmo de recuperación NO-DESHACER/ REHACER:

1. Crear dos listas de transacciones, llamadas ACTIVAS y CONFIRMADAS, ambas vacías.

2. Inicializar ACTIVAS a la lista de transacciones activas que aparecen en el registro de validación (correspondiente al último punto de revisión) escrito en la bitácora.

3. Examinar la bitácora a partir del último punto de revisión hacia adelante.

4. Si se encuentra una entrada, se añade T a la lista Activas.

5. Si se encuentra una entrada, mover T de la lista ACTIVAS a la lista CONFIRMADAS.

6. Al terminar de examinar la bitácora, REHACER las operaciones ESCRIBIR de las transacciones de la lista CONFIRMADAS, en el mismo orden en que se escribieron en la bitácora.

REINICIAR las transacciones de las lista ACTIVAS.


Técnica de actualización diferida
Técnicas de Recuperación de Base de Datos



Universidad de Oriente
Núcleo Monagas
Escuela de Ingeniería y Ciencias Aplicadas
Departamento de Ingeniería de Sistemas




TÉCNICAS DE RECUPERACIÓN DE BASE DATOS




Docente: Bachilleres:
Nesly Vivenes Rivero Daihana C.I.: 23534588
Salazar Vicmelis C.I.: 22966678
Suniaga Miguel C.I.: 22974477
Palenzuela Luis C.I.: 25272390
Reyes Roxana C.I.: 25452867
Chopite Ricardo C.I.: 23531132







CONCEPTO GENERAL DE RECUPERACIÓN:


La recuperación de una BD es el restablecimiento de un estado correcto de la BD (consistente) después que un fallo del sistema haya ocasionado que el estado actual sea inconsistente.



¿QUIÉN SE ENCARGA DE LA RECUPERACIÓN?

La recuperación la gestiona el módulo gestor de recuperación del SGBD




Daihana Rivero
Daihana Rivero
• TRANSACCIONES

- El sistema se mantiene al tanto de lo que hacen las transacciones mediante un fichero especial llamado bitácora del sistema de BD, también conocido como fichero log, diario o registro histórico.

- 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 ha comenzado.


< ESCRIBIR, T, X, valor_anterior, valor_nuevo >
Indica que la transacción ha cambiado el valor del elemento X de la BD. 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 la transacción leyó el valor del elemento X de la base de datos

< COMMIT, T >
Indica el término exitoso de una transacción

< ROLLBACK, T >
Indica que la transacción ha sido anulada (abortada, cancelada).



• CLASIFICACION DE LOS FALLOS DE UN SISTEMA DE BASE DE DATOS

1. Errores locales previstos por la aplicación (ROLLBACK)

2. Errores locales no previstos

3. Fallos por imposición del control de concurrencia

4. Fallos del sistema (caídas suaves)

5. Fallos de disco (caídas duras)

6. Fallos catastróficos o físicos: Algunos ejemplos son el corte del suministro eléctrico, robo del disco, incendio, etc.


Los fallos 5 y 6 suceden con menos frencuencia que el resto y su recuperación es más complicada.

Roxana Reyes
Vicmelis Salazar
Vicmelis Salazar
Si el sistema sigue esta técnica, una vez reiniciado el mismo, el Gestor de Recuperación ejecutará el algoritmo de recuperación DESHACER/ / REHACER:

1. Crear dos listas de transacciones, llamadas ACTIVAS y CONFIRMADAS, ambas vacías.

2. Inicializar ACTIVAS a la lista de transacciones activas que aparecen en el registro de validación (correspondiente al último punto de revisión) escrito en la bitácora.

3. Examinar la bitácora a partir del último punto de revisión hacia adelante.

4. Si se encuentra una entrada <INICIAR,T> , se añade T a la lista ACTIVAS.

5. Si se encuentra una entrada<COMMIT,T> , mover T de la lista ACTIVAS a CONFIRMADAS.

6. Al terminar de examinar la bitácora,

• DESHACER, con base en la bitácora, las operaciones ESCRIBIR de las transacciones en ACTIVAS. Deben deshacerse en orden inverso a aquel en que se anotaron en bitácora,
• REHACER, con base en la bitácora, las operaciones ESCRIBIR de las transacciones en CONFIRMADAS, en el mismo orden en que se escribieron en bitácora.

El sistema está ahora preparado para aceptar nuevos trabajos (la BD está consistente).



Técnica de actualización inmediata
Ejemplo
Miguel Suniaga
Copias de seguridad
Luis Palenzuela

Con este método se consigue la restauración mediante la copia de respaldo de la base para recuperar la porcion principal de los datos.

Consta de dos partes:

1. Después de un fallo que produce un daño en la base de datos, se utiliza la última copia de seguridad para restaurarla.

2. Se procesa el diario, a partir del punto en que se efectuó la última copia de seguridad. Para cada transacción completada anotada en el diario, se sustituye la versión actual del registro de la base de datos por la imagen final correspondiente.


Recuperación por adelanto
Roxana Reyes
Este es un proceso muy útil en situaciones en las que los procedimientos de la base de datos se ven interrumpidos y a pesar de esto la base de datos no recibe daños.

Para que se pueda aplicar esta técnica de recuperación, se necesita que el diario de transacciones contenga imágenes iniciales de la última modificación de la base de datos. Una imagen inicial es una copia de un registro justa antes de ser modificado.

Una vez la base de datos se encuentra en su estado normal y se aplica dicha técnica este lo que hace es reemplazar transacciones incompletas por el estado original de las mismas transacciones gracias a la imagen inicial.

El objetivo de este proceso es eliminar todas las transacciones incompletas. Para que este proceso funcione el diario de transacciones debe tener un "comienzo de transacción” y un "final de transacción” todas aquellas transacciones que tengan un comienzo pero no un fin se consideraran como transacciones incompletas, estas serán eliminadas y sobrescritas por la imagen inicial correspondiente.




Recuperación por retroceso
Ricardo Chopite
Miguel Suniaga

Para poder efectuar cualquier tipo de restricción de una base de datos, es necesario la realización de copias de seguridad (backups) de la base de datos de forma periódica.

-Cuando se trata de base de datos criticas, como las que guardan información bancaria, suele guardarse al menos una copia en un lugar alejado bastantes kilómetros de la instalación del ordenador.

Diarios de transacción y restauración/reejecucion

Una extensión de las técnicas anteriores consiste en el mantenimiento automático de un fichero de ordenador, que contenga una lista de los cambios hechos en la base de datos entre dos copias de seguridad consecutivas. esta lista se conoce como diario de transacciones.
Referencias biblográficas
. Ramez A. Elmarsi, Shamkant B. Navathe, "Fundamentos de Sistemas de Base de Datos" Addison Wesley (tercera edición, capítulo 21)

. Archivo en PDF:
http://ldc.usb.ve/~yudith/docencia/UCV/SistemasDistribuidos/MecanismosRecuperaci%C3%B3nSMBDSahyra.pdf


En conclusión...

Una computadora, al igual que cualquier otro dispositivo eléctrico o mecánico, está sujeta a fallos. Éstos se producen por los diferentes motivos ya antes mencionados. En cada uno de estos casos puede perderse información.
Una parte integral de un sistema de bases de datos es el módulo gestor de recuperación del SGBD, el cual es responsable de que el SBD sea seguro frente a posibles fallos.




Si la bitácora, en tres instantes de tiempo al fallar es:

















La recuperación en cada caso es como sigue

Caso (a): se deshace T0, restaurando A=1000 y B=2000

Caso (b): se deshace T1 y se rehace T0, restaurando C=700 y
estableciendo A=950 y B=2050

Caso (c): se rehace T0 y T1, poniendo A=950, B=2050, C=600

Full transcript