Identifícate o Regístrate

Autor: Roberto www.ForInfor.net
Curso: 4,79/5 (16 opiniones) |16142 alumnos|Fecha publicación: 01/02/2006

Gestión de copias de seguridad

Cuando se habla de copias de seguridad se está hablando de poder recuperar la base de datos ante posibles fallos físicos de alguno de sus ficheros de : datos, control, parámetros, o redo log.

Los fallos a nivel físico pueden ser de cualquier tipo, desde la rotura de un disco duro hasta el borrado accidental de uno o varios ficheros, de todos ellos se puede recuperar la información si se realiza una adecuada gestión de copias de seguridad.

También se pueden exportar datos de tablas a nivel lógico, pero no son suficientes para recuperar la base de datos, por lo que nos centraremos en el nivel físico.

Básicamente se han de realizar tres tareas:

Backup. Guardar una copia de los ficheros de la base de datos en un medio de almacenamiento secundario.

Restore. Si es necesario recuperar los ficheros del sistema de almacenamiento secundario y almacenarlos en el directorio donde la base de datos lo busca

Recovery. Se dice que una copia de seguridad es inconsistente cuando los ficheros no contienen todos los cambios realizados en la base de datos, y es necesario utilizar la información de los ficheros de redo log más recientes. Esta tarea se utiliza para sincronizar la información contenida en los ficheros recuperados con los cambios registrados en los ficheros de redo log. Para realizar copias consistentes de la base de datos es necesario cerrarla previamente, y por ello se denomina copia de seguridad fuera de línea (Backup offline).

Aunque el proceso de recuperación es más sencillo cuando la copia de seguridad es consistente tiene la desventaja de que hay que parar y cerrar la base de datos, por ello suele ser útil realizar copias de seguridad inconsistentes con la base de datos trabajando en modo archivado (ARCHIVELOG) que ofrecen total seguridad para la recuperación posterior de la base de datos.

Backup

En el paso 8 de la creación de la base de datos se puede configurar la gestión de copias de seguridad automáticas, aunque en cualquier momento se puede configurar mediante:

La utilización de un área de recuperación flash (Flash Recovery Area) que permite automatizar la gestión de copias de seguridad de la mayoría de los ficheros. En este área Oracle se encarga automáticamente de almacenar por ejemplo los ficheros de redo logs, y de borrarlos cuando ya no son necesarios.

Ejecutar la base de datos en el modo archivado (ARCHIVELOG) de manera que se puedan realizar las copias de seguridad en línea sin parar la base de datos.

Utilizar el área de recuperación flash para almacenar los ficheros de archivado.

Definir las políticas que se han de aplicar para gestionar el área de memoria flash. Entre ellas se pueden indicar cuándo hacer copias de seguridad de determinados ficheros, y cuánto tiempo se han de mantener los datos.

El Enterprise Manager sugiera una política de copias de seguridad básica pero robusta

que se completa en cuatro pasos

El destino es el disco y concretamente el área de memoria flash.

La configuración indica que:

Se realiza una copia de seguridad completa la primera vez que se ejecuta

Las veces posteriores se realizan copias de seguridad incrementales

Se guardan las copias de seguridad necesarias para permitir la recuperación completa de la base de datos, o hasta un momento en el tiempo anterior a la última copia incremental realizada.

Se planifica la hora del día en que se realiza la copia de seguridad.

En el último paso se muestra el comando que se ejecutara diariamente

Archivo de Comandos Diario: run { allocate channel oem_disk_backup device type disk; recover copy of database with tag 'ORA$OEM_LEVEL_0'; backup incremental level 1 cumulative copies=1 for recover of copy with tag 'ORA$OEM_LEVEL_0' database; }

Con esta política de copias de seguridad se pueden recuperar los datos en base a los siguientes casos:

Supongamos que al finalizar el primer día (24:00:00 horas) se realiza una copia completa de la base de datos con los datos actualizados hasta ese momento. La copia de la base de datos junto con el fichero de redo log del segundo día, permiten recuperar los datos hasta cualquier momento del segundo día.

Al finalizar el segundo día (24:00:00) se realiza una copia de seguridad incremental con los cambios que ha habido durante el segundo día en la base de datos. La copia completa realizada el primer día y actualizada con los cambios realizados el segundo día, permiten recuperar los datos hasta cualquier momento del tercer día utilizando el redo log del mismo.

En los días posteriores, las copias de seguridad incrementales contienen los cambios que se han realizado a la base de datos desde la última copia de seguridad completa, siguiéndose un procedimiento similar al del punto anterior.

Restauración y recuperación

La recuperación completa de la base de datos a partir de los ficheros contenidos en la copia de seguridad se realiza de forma automática por el Enterprise Manager.

Las opciones para recuperar la base de datos completa, permiten restaurar los ficheros o bien elementos lógicos como tablas o tablespaces.

Si realizamos la recuperación de la base de datos completa, el Enterprise Manager informa que la base de datos está "abierta", y para realizar la restauración ha de cerrarla y dejarla en estado "Montada", y pide confirmación.

Si se confirma la operación, la base de datos se cerrará y montará, accediendo posteriormente a una nueva página del asistente de recuperación.

Como se ve la instancia está "montada" y se ofrece la posibilidad de iniciarla o realizar la recuperación, debiendo de seleccionar la segunda opción. De nuevo es necesario conectarse con un usuario con privilegios de administración en el sistema operativo y en el SGBDR.

Los cinco pasos que se siguen para la restauración completa son:

Point-in-time. Indicar si se desea recuperar la base de datos hasta el momento actual o hasta un punto anterior en el tiempo.

Flashback. En la recuperación completa no aplica.

Cambiar nombre. Permite indicar una nueva ubicación para los archivos restaurados.

Planificar. No aplica

Revisar. Permite verificar los comandos que se van a ejecutar.

run { restore database until time "to_date('2005-11-20 17:19:23', 'YYYY-MM-DD HH24:MI:SS')"; recover database until time "to_date('2005-11-20 17:19:23', 'YYYY-MM-DD HH24:MI:SS')"; }

Al finalizar la operación se muestra el resultado de la misma y los comandos ejecutados.

SQL*Plus: Release 10.2.0.1.0 - Production on Lun Nov 21 17:25:48 2005 Copyright (c) 1982, 2005, Oracle. All rights reserved. SQL> SQL> Conectado. SQL> SQL> SQL> ORA-01109: base de datos sin abrir Base de datos desmontada. Instancia Oracle cerrada. SQL> SQL> Desconectado de Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production With the Partitioning, OLAP and Data Mining options SQL*Plus: Release 10.2.0.1.0 - Production on Lun Nov 21 17:25:55 2005 Copyright (c) 1982, 2005, Oracle. All rights reserved. SQL> SQL> Conectado a una instancia inactiva. SQL> SQL> Instancia Oracle iniciada. Total SYSTEM Global Area 167772160 bytes Fixed Size 1247876 bytes Variable Size 88081788 bytes Database Buffers 71303168 bytes Redo Buffers 7139328 bytes Base de datos montada. SQL> Desconectado de Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production With the Partitioning, OLAP and Data Mining options Recovery Manager : Release 10.2.0.1.0 - Production on Lun Nov 21 17:26:01 2005 Copyright (c) 1982, 2005, Oracle. All rights reserved. RMAN> conectado a la base de datos destino: ORCLE10 (DBID=3008764522, no abierto) se utiliza el archivo de control de la base de datos destino en lugar del catálogo de recuperación RMAN> echo activado RMAN> run { 2> restore database until time "to_date('2005-11-20 17:19:00', 'YYYY-MM-DD HH24:MI:SS')"; 3> recover database until time "to_date('2005-11-20 17:19:00', 'YYYY-MM-DD HH24:MI:SS')"; 4> } Iniciando restore en 21/11/05 canal asignado: ORA_DISK_1 canal ORA_DISK_1: sid=156 devtype=DISK

Finalizada la recuperación se ha de arrancar la instancia de la base de datos para que vuelva a estar disponible a todos los usuarios.

Se ha visto que la recuperación de la base de datos se puede realizar hasta un punto de restauración denominado "SCN", el Enterprise Manager permite que el administrador cree un SCN cuando considere que la información almacenada en la base de datos hasta ese momento es consistente e importante para realizar una recuperación hasta ese punto si fuera necesario.

Cuando se realiza la recuperación lógica el número de pásos varía entre tres y siete en función del tipo de objeto que se desee recuperar.

Al seleccionar el tipo de objeto "tabla" se puede realizar una recuperación denominada Flasback que muestra los datos que tenía la tabla en el momento indicado. Esta recuperación se puede realizar tanto en tablas existentes como ya borradas. Este tipo de recuperación permite recuperar exclusivamente un elemento lógico en el cual se pueden haber insertado, actualizado o borrado datos de manera errónea.

Desde el Enterprise Manager se pueden "Gestionar las copias de seguridad actuales". La gestión de las copias de seguridad incluye por una parte un aspecto físico relacionado con el dispositivo donde ha sido almacenada y otra lógica relativa al registro que se mantiene en el repositorio de la base de datos. El registro asociado a una copia de seguridad puede estar en tres estados:

Disponible, que indica que la copia está en el disco o cinta de almacenamiento y los registros en el repositorio.

Caducado, que indica que la copia de seguridad ha sido borrada del disco, pero el registro todavía está en el repositorio. Si la copia ha sido borrada definitivamente del disco, debe de eliminarse el registro del repositorio.

No disponible, indicando que la copia de seguridad no puede ser utilizada para la recuperación de la base de datos. La razón puede ser sencillamente que está almacenada en una cinta que no está accesible en ese momento.

Una copia de seguridad también puede quedar obsoleta porque se cambie la política de gestión de copias de seguridad y la información contenida en ella no sea necesaria para la recuperación de la base de datos.

Desde el Enterprise Manager se puede además:

Listar las copias de seguridad que se han realizado

Realizar chequeos cruzados que entre otras tareas permiten identificar copias que están caducadas por no estar disponibles los ficheros.

Borrar los registros asociados a copias caducadas u obsoletas.

Recibe nuestras novedades

Recibir

Al presionar "Recibir" estás dándote de alta y aceptas las condiciones legales de mailxmail