Manual del estudiante de Ingeniería en Sistemas de UTN/Bases de datos avanzadas/Backup y recuperación

De Wikilibros, la colección de libros de texto de contenido libre.
Ir a la navegación Ir a la búsqueda

Objetivos de la copia de seguridad y recuperación[editar]

  • Proteger la base de datos contra los numerosos tipos de fallos.
  • Aumentar el MTBF (tiempo medio entre fallos).
  • Disminuir el MTTR (tiempo medio de recuperación).
  • Minimizar la pérdida de datos.

Categorías de Fallos[editar]

  • Fallo de sentencia.
  • Fallo de proceso de usuario.
  • Error de usuario.
  • Fallo de red.
  • Fallo de instancia.
  • Fallo de medio físico.

Fallos de Sentencia[editar]

Causas
  • Error de lógica en una aplicación.
  • Intento de introducir datos no válidos en una tabla.
  • Intentar una operación con privilegios insuficientes.
  • Intentar crear una tabla que excede los límites de la cuota asignada.
  • Intentar una operación INSERT o UPDATE en una tabla, que ocasiona la asignación de una extensión con insuficiente espacio libre en el tablespace.


Resolución
  • Corregir el flujo lógico del programa.
  • Modificar y emitir de nuevo la sentencia SQL.
  • Proporcionar los privilegios de base de datos necesarios.
  • Cambiar el límite de la cuota del usuario con el comando ALTER USER.
  • Agregar espacio de archivo al tablespace.

Fallos de Proceso de Usuario[editar]

Causas
  • El usuario ha realizado una desconexión anormal en la sesión.
  • La sesión del usuario ha terminado de forma anormal.
  • El programa del usuario ha provocado una excepción de dirección que ha terminado la sesión.


Resolución
  • El proceso PMON detecta un proceso de usuario que ha terminado anormalmente.
  • PMON hace rollback de la transacción y libera los recursos y bloqueos que ésta retenía.

Errores de usuario[editar]

Resolución
  • Formar a los usuarios de la base de datos.
  • Utilizar una copia de seguridad válida para la recuperación.
  • Importar la tabla de un archivo de exportación.
  • Utilizar LogMiner para determinar la hora del error.
  • Realizar una recuperación hasta un punto en el tiempo.
  • Utilizar LogMiner para realizar una recuperación de nivel de objeto.
  • Utilizar FlashBack para visualizar y reparar los datos históricos.

Fallo de Instancia[editar]

Recuperación
  • No se necesita ninguna acción de recuperación especial del DBA.
  • Iniciar la instancia.
  • Espere la notificación “database opened”.
  • Compruebe el log de alertas para determinar la causa del fallo.

Fallos del Medio Físico[editar]

Causas
  • Fallo de cabeza en la unidad de disco.
  • Problema físico al leer o escribir en archivos de base de datos.
  • Se borró el archivo accidentalmente.


Resolución
  • La estrategia de recuperación depende del método de copia de seguridad seleccionado y de los archivos afectados.
  • Aplicar los archivos redo log archivados, si existen, para recuperar los datos validados desde la última copia de seguridad.

Definición de una Estrategia de Copia de Seguridad y Recuperación[editar]

  • Requisitos de negocio.
  • Requisitos de operación.
  • Consideraciones técnicas.
  • Consenso de gestión.

Requisitos de Negocio[editar]

  • Tiempo medio de recuperación.
  • Tiempo medio entre fallos.
  • Proceso evolutivo..

Requisitos de Operación[editar]

  • Operaciones durante las 24 horas.
  • Comprobación y validación de copias de seguridad.
  • Volatilidad de base de datos.

Consideraciones Técnicas[editar]

  • Recursos: hardware, software, mano de obra y tiempo.
  • Copias de imágenes físicas de los archivos del sistema operativo.
  • Copias lógicas de los objetos de la base de datos.
  • Configuración de bases de datos.
  • El volumen de transacciones afecta a la frecuencia deseada de las copias de seguridad.

Temas de Recuperación de Catástrofes[editar]

¿Cómo se verá afectado su negocio en caso de una catástrofe de grandes proporciones? Por ejemplo
  • Terremoto, inundación o incendio
  • Pérdida completa de la máquina
  • Funcionamiento incorrecto del hardware o del software de almacenamiento
  • Pérdida de personal clave, como el administrador de la base de datos
¿Dispone de un plan para comprobar la estrategia periódicamente?

Back-up y recuperación en ORACLE 10g[editar]

Definiciones[editar]

Backup
Copia de datos, fundamentalmente los archivos de control (control file) y los archivos de datos (datafiles).
Backup Físico
Para hacer copias de datos y recuperación (archivos de datos físicos).

Las herramientas de backup físico son:

  • Utilitarios del SO.
  • RMAN de Oracle.
Backup Lógico
Contienen datos lógicos(como las tablas y los procedimientos almacenados).

Las herramientas de backup lógico son:

  • Utilitarios de Oracle, se almacenan en archivos binarios.

Backup físico y lógico[editar]

Backup físico[editar]

RMAN
Utilitario de ORACLE para hacer copias y recuperar archivos de datos (datafiles).

Se pueden usar comandos del SO y SQL*Plus para recuperación.

Se recomienda usar RMAN por ser más robusto y porque simplifica el trabajo.

Backup lógico[editar]

  • Utilitario Export para escribir archivos binarios.
  • Utilitario Import para recuperar los datos en la BD.

Backup Consistente[editar]

Consistente: los archivos que se copian tienen todos los cambios con el mismo SCN (system change number), lo que significa que los archivos del backup tienen todos lo datos tomados en el mismo punto en el tiempo.

Un backup consistente no requiere recovery después que éste se recupera.

Shut down normal, inmediato o transaccional y hacer el backup cuando la BD está cerrada.

Se puede recuperar un backup consistente de 1 año atrás sin necesidad de hacer recove; si se quieren actualizar los datos, se debe hacer redo de las transacciones.

En modo NOARCHIVELOG el único backup posible es un backup consistente de toda la BD ya que no hay modo de recuperar la BD ante fallas.

En modo ARCHIVELOG con un backup consistente y completo de la BD se puede recuperar y actualizar la misma.

Backup Inconsistente[editar]

Inconsistente: los archivos copiados no tienen todos los datos en el mismo valor de SCN (algunos cambios se perdieron) lo que significa que los archivos de datos son modificados mientras se realizan los backups.

Se hacen consistentes aplicando los cambios grabados en los archivos de log (archivados y on-line) en los archivos de datos.

Para BD 24-7 este es el único backup posible; en este caso, backup online la BD debe estar en modo ARCHIVELOG.

Después de un backup online se debe asegurar que se cuenta con la información de recuperación de la BD archivando los redo logs no archivados ++ haciendo backup los redo logs archivados y los archivos de control.

Backups de la base de datos

  • ARCHIVELOG
    • Open
      • Inconsistent
    • Closed
      • Consistent
      • Inconsistent
  • NOARCHIVELOG
    • Open
      • Inconsistent (inválido)
    • Closed
      • Consistent
      • Inconsistent (no recomendado)

Backup de Tablespaces y Datafiles[editar]

Tablespaces
Se realiza un backup de los archivos de datos que tiene el tablespace. Sólo son válidos en modo ARCHIVELOG, ya que se requiere hacer redos para hacerlo consistente con los otros tablespaces de la BD.
Datafiles
Backup de un archivo de datos. Son válidos en:
  • ARCHIVELOG
  • NOARCHIVELOG, cuando:
    • Todos los archivos del tablespace son copiados. No se puede restaurar la BD si no se copian todos los archivos.
    • Los archivos son read only u offline-normal.

Backup de archivos de control[editar]

Sin el archivo de control no se puede levantar en modo mount, ni abrir la BD.

Se puede definir que RMAN realice el backup del archivo de control automáticamente (CONFIGURE CONTROL FILE AUTOBACKUP) después de un backup.

De manera manual:

  • Comando de RMAN BACKUP CURRENT CONTROLFILE.
  • Comando SQL ALTER DATABASE BACKUP CONTROLFILE (backup binario).
  • Comando SQL ALTER DATABASE BACKUP CONTROLFILE TO TRACE exporta el contenido del archivo de control a un script SQL.

Se recomiendan los backups binarios.

Backup de archivos de redo-log[editar]

Son esenciales para recuperar un bakcup inconsistente (el único modo de recuperar un backup inconsistente sin los archivos de log es usar backups incrementales utilizando RMAN).

Para recuperar un backup hasta el log mas reciente se debe disponer de los logs generados entre esos dos puntos.

Métodos:

  • Comando RMAN BACKUP ARCHIVELOG.
  • Comando RMAN BACKUP…PLUS ARCHIVELOG.
  • Un utilitario del SO.

RMAN vs. Backups del usuario[editar]

Existen dos tipos de backup: copias imágen y conjuntos backup.

Las copias imágen se pueden crear con RMAN o el SO y se pueden recuperar como están sin procesamiento adicional por medio de RMAN o el SO.

Un conjunto backup se crea por medio de RMAN y tiene un formato propietario que consiste de uno o más archivos físicos llamados "piezas backup". Difieren de la copia imágen porque contienen más de un archivo de datos y se pueden hacer copias usando procesamiento especial tales como compresión o backup incremental.

Para backup online es más seguro emplear RMAN que una facilidad del SO porque asegura la consistencia de los bloques que se graban.

Recuperación[editar]

Restaurar (restore) un archivo de datos y un archivo de control es reconstruirlo y dejarlo disponible para el servidor.

Recuperar (recovery) un archivo restaurado es actualizarlo aplicando los redo-logs archivados y en línea, lo cual significa aplicar los cambios hechos a la BD después que se hizo el backup.

Con RMAN se pueden recuperar los archivos de datos con backup incrementales que son los que registran sólo los cambios hechos a un backup incremental previo.

Después de la restauración de los archivos, la recuperación la debe realizar el usuario utilizando operaciones como restore, roll-forward o roll-back del backup de archivos de datos.

Errores de lógica o del usuario[editar]

Para la corrección de errores de lógica o del usuario que causan corrupción de datos se emplea ORACLE Flashback. Oracle Flashback DATABASE y ORACLE Flashback Table permiten recuperar la BD rápidamente a un tiempo anterior.

Tipos de recuperación[editar]

Recuperación de dispositivos (media recovery): backup y redo de transacciones. Se recupera a un momento anterior ó al actual. Implica la recuperación de los archivos de datos. Puede ser:

  • Completo.
  • Incompleto.
  • Datafile media recovery.
  • Block media recovery.

Block media recovery es una operación más especializada que se emplea para recuperar unos pocos bloques corruptos de los archivos de datos.

Crash recovery e instance recovery se hacen automáticamente después de una falla de la instancia.

Recuperación de dispositivo completa[editar]

Involucra rehacer las transacciones o emplear backup incremental + el backup de la BD, tablespace o archivos de datos para actualizar al punto más reciente en tiempo.

Es completo, porque aplica todo los cambios de los redo-logs archivados y en línea.

Recuperación completa de la BD
  • Levantar la BD en modo mount.
  • Asegurar que todos los archivos de datos a recuperar están en línea.
  • Emplear el backup para restaurar la BD ó los archivos que quiera recuperar.
  • Aplicar los redo-logs archivados ó en línea ó una combinación de ambos.
Recuperación completa de un tablespace o datafile
  • Sacar de línea (off-line) el tablespace ó datafile a recuperar.
  • Emplear el backup para restaurar los datafiles a recuperar.
  • Aplicar los redo-logs archivados o en línea o una combinación de ambos.

Recuperación Incompleta[editar]

Recupera la BD a un punto en el tiempo que no es el actual, por lo tanto no se emplean todos los registros de redo-log generados después del backup más reciente.

Se utiliza:

  • Cuando se destruyen parte/todo los redo-logs en línea.
  • Un usuario causa la pérdida de datos (DROP TABLE).
  • Se pierde un redo-log archivado.
  • Se pierde el archivo de control actual y se debe usar uno anterior.

Para completarlo se deben restaurar todos los archivos de datos previos al momento en el cual se quiere recuperar y abrir la BD con la opción RESETLOGS cuando la recuperación se completa. Antes de aplicar esta opción se debe asegurar que los datos se están recuperados al momento correcto.

Recuperación de Archivos de datos[editar]

Se emplea por daño ó pérdida de un archivo de datos o el archivo de control, o cuando un tablespace salió de línea sin la opción OFFLINE NORMAL.

Características
  • Aplicar los cambios (redo) a los backups restaurados de los archivos de datos dañados.
  • Se puede usar logs archivados o en línea.
  • Requiere una invocación explícita por parte del usuario.
  • No detecta la falla del dispositivo automáticamente (la necesidad de utilizar un backup).
  • El usuario debe determinar el tiempo de recuperación.

Recuperación de Archivos de datos[editar]

La BD no se puede abrir si uno de los archivos de datos necesita recuperación. TAMPOCO se puede poner en línea el archivo hasta que se hace la recuperación.

En los siguiente casos también es necesaria una recuperación del dispositivo:

  • Si se restaura un archivo de datos desde el backup.
  • Si se restaura el archivo de control desde el backup.
  • Un archivo de datos se saca de línea sin la opción OFFLINE NORMAL.

La recuperación de archivo de datos sólo funciona con los archivos de datos fuera de línea.

Recuperación de bloques de datos[editar]

Se emplea para restaurar y recuperar bloques individuales de datos mientras la BD permanece en línea y disponible. Si sólo unos pocos bloques están corruptos esta recuperación es preferible a la de los archivos de datos.

La interfase la provee RMAN.