ORACLE: Backup and Recovery


Para conseguir un funcionamiento seguro de la BD y una pronta recuperación ante Fallas se necesita planear una estrategia de copias de seguridad, backup, y de recuperación, recovery, ya que de nada sirve pensar que estamos a salvo de tales circunstancias, y que eso no nos puede pasar a nosotros. Y el primer paso a dar es definir las características fundamentales de la implantación, porque mal vamos a conseguir unos objetivos si se desconocen o están indefinidos. El segundo paso es establecer unos planes de copias de seguridad y recuperación que nos permitan asegurar los objetivos.

Junio de 2007.

Felipe Manriquez
Administración de Bases de Datos Oracle
Carrera Ingenieria  Ejecución Informática
DUOC
fmanriquez@gmail.com
 

 


Índice


1 Introducción al Backup and Recovery

1.1 Presentación del Backup
1.2 Presentación de la Recuperación

2 Principios de Backup

2.1 Diseño de la BD y Reglas Básicas de Backup
2.2 Backups Físicos  Administrados por Usuario DBA

2.2 Backups Físicos  Administrados por Usuario DBA

2.3 Backups físicos Administrados con RMAN (Recovery Manager)
2.4  Backups Lógicos

3 Principios de la Recuperación

3.1 Definiciones y Conceptos
3.2 Métodos de Recuperación
3.3 Recuperación Física
3.4 Recuperación Lógica

3.5 Recuperación Física usando RMAN

 


1 Introducción al Backup and Recovery


Planificar y comprobar los procedimientos de backup del sistema es la única garantía que existe contra fallas del sistema, del SO, del software o cualquier otro tipo de circunstancias.

Las causas de error en un sistema de BD pueden agruparse en las siguientes categorías:

  • Físicas

son causadas por Fallas del hardware, como por ejemplo del disco o de la CPU.

  • de Diseño

son agujeros en el software, ya sea en el SO o en el SGBD.

  • de Funcionamiento

son causadas por la intervención humana, debidos a Fallas del DBA, configuraciones inapropiadas o mal planteamiento de los procedimientos de backup.

  • del entorno

como por ejemplo desastres naturales, Fallas de corriente, temperatura excesiva.

De entre todas estas posibilidades, el DBA sólo puede influir y prever los errores de funcionamiento, ya que el resto habitualmente no está dentro de sus responsabilidades y capacidades.

Dada la complejidad de los sistemas actuales y las necesidades cada vez más críticas en la disponibilidad de los sistemas, donde una BD caida puede causar pérdidas millonarias, puede ser interesante considerar los mecanismos de protección hardware y de redundancia que la tecnología nos proporciona:

  • UPS o fuentes de corriente ininterrumpida,
  • espejado de disco, o tecnología RAID,
  • Componentes duplicados,
  • Sistemas redundantes.

Una de las más importantes decisiones que un DBA debe tomar es decidir si arrancar la BD en modo ARCHIVELOG o no. Esta decisión tiene sus ventajas e inconvenientes:

  • Ventajas:
    • Aunque se pierdan los archivos de datos, siempre se puede recuperar la BD con una copia antigua de los archivos de datos y los archivos de redo log archivados.
    • Es posible realizar backups en caliente.
  • Inconvenientes:
    • Se necesitará más espacio en disco, normalmente un disco especial de destino de archiving, incluso en modalidad duplex .
    • El trabajo del DBA se incrementa al tener que determinar el destino del archivado de los redo log.


1.1 Presentación del Backup

Los backups se pueden clasificar en físicos y lógicos. Los físicos se realizan cuando se copian los archivos que soportan la BD. Entre estos se encuentran los backups del SO, los backups en frío y los backups en caliente.

Los backups lógicos sólo extraen los datos de las tablas utilizando comandos SQL y se realizan con la utilidad export/import.

Backups del SO

Este tipo de backup es el más sencillo de ejecutar, aunque consume mucho tiempo y hace inaccesible al sistema mientras se lleva a cabo. Aprovecha el backup del SO para almacenar también todos los archivos de la BD. Los pasos de este tipo de backup son los siguientes:

    1. Parar la BD y el SO
    2. Arrancar en modo superusuario.
    3. Realizar copia de todos los archivos del sistema de archivos
    4. Arrancar el sistema en modo normal y luego la BD.

Backups de la BD en Frio

Los backups en frio implican parar la BD en modo normal y copiar todos los archivos sobre los que se asienta. Antes de parar la BD hay que parar también todos las aplicaciones que estén trabajando con la BD. Una vez realizada la copia de los archivos, la BD se puede volver a arrancar.

Backups de la BD en Caliente

El backup en caliente se realiza mientras la BD está abierta y funcionando en modo ARCHIVELOG. Habrá que tener cuidado de realizarlo cuando la carga de la BD sea pequeña. Este tipo de backup consiste en copiar todos los archivos correspondientes a un tablespace determinado, los archivos redo log archivados y los archivos de control. Esto para cada tablespace de la BD.

Backups Lógicos con Export/Import

Estas utilidades permiten al DBA hacer copias de determinados objetos de la BD, así como restaurarlos o moverlos de una BD a otra. Estas herramientas utilizan comandos del SQL para obtener el contenido de los objetos y escribirlos en/leerlos de archivos

Una vez que se ha planeado una estrategia de backup y se ha probado, conviene automatizarla para facilitar así su cumplimiento.


1.2 Presentación de la Recuperación

Oracle proporciona diferentes modos de recuperar un fallo en la BD, y es importante que el DBA conozca como funciona cada uno de ellos para determinar cuándo ha de ser utilizado.

Una de las mayores responsabilidades del DBA consiste en tener la BD a punto, y prepararla ante la posibilidad de que se produzca un fallo. Así, ante un fallo el DBA podrá recuperar la BD en el menor tiempo posible. Los procesos de recuperación dependen del tipo de error y de las estructuras afectadas.

Así, los tipos de error que se pueden producir son:

Errores de Usuario

Como por ejemplo un usuario borrando una fila o eliminando una tabla. Estos errores se solucionan importando una tabla de una copia lógica anterior. Si no se dispone de la copia lógica, se puede recuperar la BD en una instancia auxiliar, exportar la tabla en cuestión de la instancia auxiliar e importarla en la instancia operativa.

Fallas de Sentencias

Se definen como la imposibilidad del SGBD Oracle de ejecutar alguna sentencia SQL. Un ejemplo de esto se produce cuando se intenta una selección de una tabla que no existe. Estos Fallas se recuperan automáticamente mediante un rollback de la transacción que contenía la sentencia fallida. El usuario necesitará volver a ejecutar otra vez la transacción cuando se haya solucionado la causa del problema.

Fallas de Procesos

Es una terminación anormal de un proceso. Si el proceso era un proceso de usuario, del servidor o de una aplicación el PMON efectuará la recuperación del proceso. Si el proceso era alguno de los de background, la instancia debe de ser parada y arrancada de nuevo, proceso durante el cual se recupera la caida efectuando un roll forward y un rollback de las transacciones no confirmadas.

Fallas de la Red

Algunas veces los Fallas en la red producen Fallas de proceso, que son tratados por el PMON. Si en el error de red se ve envuelta una transacción distribuida, una vez que se reestablece la conexión, el proceso RECO resuelve los conflictos automáticamente.

Fallas de Instancia

Pueden deberse a Fallas físicos o de diseño del software que hacen que algún proceso background caiga y la instancia con él. La recuperación es automática cuando se levanta la BD, tomandose más o menos tiempo en la recuperación.

Fallas del Sistema

Son los Fallas más peligrosos, no sólo porque se pueden perder datos, sino porque se tarda más tiempo en recuperar que los otros Fallas. Además se depende mucho de la experiencia del DBA para levantar la BD rápidamente y sin pédida (o casi) de datos.

Existen tres tipos de recuperación en Oracle: a nivel de bloque, de thread y física.

Recuperación de bloques

Es el mecanismo de recuperación más simple, y se realiza automáticamente. Se produce cuando un proceso muere justo cuando está cambiando un bloque, y se utilizan los registros redo log en línea para reconstruir el bloque y escribirlo en disco.

Recuperación de threads

Se realiza automáticamente cuando Oracle descubre que una instancia muere dejando abierto un thread, entonces se restauran los bloques de datos modificados que estaban en el cache de la instancia muerta, y cerrando el thread que estaba abierto. La recuperación se efectua automáticamento cuando la BD se levanta.

Recuperación física

Se realiza como respuesta a un comando RECOVER. Se utiliza para convertir los archivos de backup en actuales, o para restaurar los cambios que fueron perdidos cuando un archivo de datos fue puesto offline sin un checkpoint, aplicando los archivo redo log archivados y en línea.


2 Principios de Backup


Un backup válido es una copia de la información sobre la BD necesaria para reconstruir la BD a partir de un estado no utilizable de la misma. Normalmente, si la estrategia de backup se basa en la copia de los archivos de datos y en el archivado de los archivos redo log, se han de tener copias de los archivos de datos, de los archivos de control, de los archivos redo log activos y también de los archivados. Si se pierde uno de los archivos redo log archivados se dice que se tiene un agujero en la secuencia de archivos. Esto invalida el backup, pero permite a la BD ser llevada hasta el principio del agujero realizando una recuperación incompleta.


2.1 Diseño de la BD y Reglas Básicas de Backup

Antes de nada, es muy importante entender ciertas reglas que determinan la situación de los archivos y otras consideraciones que afectarán al esquema de backup:

  • Es recomendable archivar los archivos redo log en disco, y luego copiarlos a cinta, pero siempre en un disco diferente del que soporta los archivos de datos y de redo log activos.
  • Los archivos copias no deben estar en el mismo dispositivo que los originales. No siempre hay que pasar las copias a cinta, ya que si se dejan en disco se acelera la recuperación. Además, si se copian las copias a cinta y se mantienen en el disco, se puede sobrevivir a diversos Fallas de dispositivo.
  • Se deberían mantener diferentes copias de los archivos de control, colocadas en diferentes discos con diferentes controladores.
  • Los archivos redo log en línea deben estar multiplexados, con un mínimo de 2 miembros por grupo, residiendo cada miembro en un disco distinto.
  • Siempre que la estructura de la BD cambie debido a la inclusión, borrado o renombrado de un archivo de datos o de redo log, se debe copiar el archivo de control, ya que almacenan la estructura de la BD. Además, cada archivo añadido también debe ser copiado. El archivo de control puede ser copiado mientras la BD está abierta con el siguiente comando:
·                 
·                SQL> alter database backup controlfile to 'destino'; 

Teniendo en cuenta las reglas anteriores, los siguientes puntos pueden considerarse un ejemplo de estrategia de backup:

  1. Activar el modo ARCHIVELOG.
  2. Realizar un backup al menos una vez a la semana si la BD se puede parar. En otro caso, realizar backups en caliente cada día.
  3. Copiar todos los archivos redo log archivados cada cuatro horas. El tamaño y el número de ellos dependerá de la tasa de transacciones.
  4. Efectuar un export de la BD semanalmente en modo RESTRICT.


2.2 Backups Físicos  Administrados por Usuario DBA

Los backups físicos son aquellos que copian físicamente los archivos de la BD. Existen dos opciones: en frío y en caliente. Se dice que el backup es en frio cuando los archivos se copian con la BD está detenida si servicios. En caliente es cuando se copian los archivos con la BD abierta y funcionando.

Backup en Frío

El primer paso es parar la BD con el comando shutdown normal. Si la BD se tiene que parar con inmediate o abort debe rearrancarse con el modo RESTRICT y vuelta a parar en modo normal. Después se copian los archivos de datos, los de redo log y los de control, además de los redo log archivados y aún no copiados.

Una buena idea es automatizar todo este proceso con los scripts correspondientes, de modo que no nos olvidemos de copiar ningún archivo.

Por ejemplo, el siguiente script para Oracle 8i

#!/bin/sh
################################################
# Backup en frio para Base de Datos Oracle 8i. #
# 2000-02-29 JLM                               #
################################################

export BD
BACKUP=/tmp
export BACKUP
BD=$1;
LANG=es_ES@euro
export LANG
echo "***************************************************************"
echo "Respaldo $1 iniciado el `date +%c` ..."
echo "****************************************************************"
echo " "
echo "Iniciando Respaldo en Frio de Archivos de Base de Datos $1"
echo " "
if [ -z "${BD}" ]
then
   echo "Usar : ksh backup_frio <ORACLE_SID>"
   exit 1
fi

######################################
# Seteo de las variables de ambiente #
######################################

export ORACLE_HOME=/u01/app/oracle/product/8.1.7
export NLS_LANG=spanish_spain.we8dec
export LD_LIBRARY_PATH=$ORACLE_HOME/lib
export ORACLE_SID=$BD
PATH=$ORACLE_HOME/bin:/usr/bin:/usr/sbin:/bin:/sbin:/usr/local/bin:/usr/local/jre:$PATH
export PATH
BLOCKSIZE=4096

###################
# Tensar la cinta #
###################

mt -f /dev/nst0 load
mt -f /dev/nst0 rewind
mt -f /dev/nst0 retension

###################################################
# Comprobamos que la base de datos este levantada #
###################################################

echo " "
echo "**************************************************"
echo "Verificando Status de Base de Datos $ORACLE_SID..."
echo "**************************************************"
echo " "
if [`ps -ef|grep -v grep|grep smon_$ORACLE_SID|wc -l` != 1 ]; then
    echo "ERROR: Base de datos $ORACLE_SID no esta arrancada"
    echo "       Backup Abortado"
    echo "-------------- FIN --------------------------"
    exit 3
fi
echo "Base de Datos $ORACLE_SID esta online"
echo

#######################################
# Generamos fichero con los datafiles #
#######################################

echo " "
echo "**************************************************"
echo "Generando lista de Datafiles, Controlfiles y Redos..."
echo "**************************************************"
echo " "
sqlplus -s internal/ << FIN
set pagesize 0
set feedback off
set serveroutput off
spool $BACKUP/dbfiles.lst
select name from v\$controlfile
union
select name from v\$datafile
union
select member from v\$logfile;
spool off
exit
FIN

############################
# Bajamos la Base de Datos #
############################

echo " "
echo "**************************************************"
echo "Bajando Base de Datos $ORACLE_SID..."
echo "**************************************************"
echo " "
svrmgrl << FIN
connect internal;
shutdown immediate;
FIN

####################################
# Copia comprimida de los archivos #
####################################
archivos=" "
FICHEROS=`cat $BACKUP/dbfiles.lst`
for v_fichero in $FICHEROS
do
  echo $v_fichero
done
for v_fichero in $FICHEROS
do
  archivos=$archivos" "$v_fichero
done

echo " "
echo "**************************************************"
echo "Iniciando copia de los archivos a cinta..."
echo "**************************************************"
echo " "
tar cvf /dev/nst0 $archivos
tar cvf /dev/nst0 $BACKUP/dbfiles.lst
tar cvf /dev/nst0 /u01/app/oracle/admin/pfile/mpw/initmpw.ora
echo " "
echo "Copia de archivos a cinta finalizada"
echo " "

#############################
# Levantar la Base de Datos #
#############################

echo " "
echo "**************************************************"
echo "Levantando Base de Datos $ORACLE_SID..."
echo "**************************************************"
echo " "
svrmgrl << FIN
connect internal
startup
exit
FIN
echo " "
echo "Base de Datos $ORACLE_SID levantada"
echo " "
echo -n "Borrando lista de archivos..."
rm -f $BACKUP/dbfiles.lst
echo " OK"
echo " "
#echo -n "Expulsando cinta..."
#mt -f /dev/nst0 rewoffl
#echo " OK"
echo " "
echo "Respaldo en Frío finalizado"
echo " "
echo "****************************************************************************"
echo "Respaldo Base De Datos $1 finalizado el `date +%c`"
echo "****************************************************************************"
exit 0

Como este tipo de backup es una copia de los archivos de la BD, si estos contienen algún tipo de corrupción, la traspasaremos a la copia de seguridad sin detectarla. Por esto es importante comprobar las copias de seguridad.

Procedimiento Respaldo Offline o frio

1.- Bajar la base de datos (SHUTDOWN [NORMAL,| IMMEDIATE | TRANSACTIONAL])

2.- Anote el layout físico de filesystems, podria ser necesario en caso de falla de disco

3.- Hacer copias de todos los datafiles de tablespaces con comandos del sistema operativo

4.- Hacer copias de todos los archivos de online redologs con comandos del sistema operativo

5.- Hacer copias de todos los archivos de control con comandos del sistema operativo

6.- Hacer copia del archivo de parámetros spfile o init%SID%.ora

 

Backup en Caliente

Si la implantación de BD requiere disponibilidad de la misma 24h. al día, 7 dias a la semana no se pueden realizar backups en frío. Para efectuar un backup en caliente debemos trabajar con la BD en modo ARCHIVELOG. El procedimiento de backup en caliente es bastante parecido al frío. Existen dos comandos adicionales: begin backup antes de comenzar y end backup al finalizar el backup. Por ejemplo, antes y después de efectuar un backup del tablespace users se deberían ejecutar las sentencias:

 
·                SQL> alter tablespace users begin backup;
 
      Aqui se utilizan commandos de S.O para copiar los datafiles a la zona de respaldo
 
·                SQL> alter tablespace users end backup;

 

Así como el backup en frio permitía realizar una copia de toda la BD al tiempo, en los backups en caliente la unidad de tratamiento es el tablespace. El backup en caliente consiste en la copia de los archivos de datos (por tablespaces), el actual archivo de control y todos los archivos redo log archivados creados durante el periodo de backup. También se necesitarán todos los archivos redo log archivados después del backup en caliente para conseguir una recuperación total.

Procedimiento Respaldo Caliente

 

1.- Ejecute comando archive log list. Note que el valor para  Oldest online log sequence es el redolog más antiguo requerido para usar en el online backup

 

·                SQL> archive log list;
·                Database log mode              Archive Mode
·                Automatic archival             Enabled
·                Archive destination            /u02/oradata/orion/archive
·                Oldest online log sequence     672
·                Next log sequence to archive   674
·                Current log sequence           674
·                SQL>

 

2.- Ejecute ALTER TABLESPACE nombre_tablespace BEGIN BACKUP desde sqlplus. Esto prepara el respaldo online de los datafiles del tablespace.

 

·                SQL> alter tablespace users begin backup;

 

3.- Copie los datafiles por cada tablespace usando comandos de sistema operativos o productos de terceros. Asegúrese que las copias residan en un  disco diferente al que se encuentran los datafiles de producción.

 

4.- Ejecute ALTER TABLESPACE nombre_tablespace END BACKUP desde sqlplus. Este paso completa el respaldo online del tablespace.

 

·                SQL> alter tablespace users end backup;

 

5.- Repita pasos 2 al 4 hasta que todos los tablespaces se encuentren respaldados. (Se exceptúan los tablespaces TEMPORALES)

 

6.- Ejecute comando archive log list nuevamente. Esta vez, note que el valor para  Current log sequence. Este es el último redolog que forma parte esencial del online backup

 

·                SQL> archive log list;
·                Database log mode              Archive Mode
·                Automatic archival             Enabled
·                Archive destination            /u02/oradata/orion/archive
·                Oldest online log sequence     672
·                Next log sequence to archive   681
·                Current log sequence           681
·                SQL>

 

7.- Ejecute ALTER SYSTEM SWITCH LOGFILE para obligar a Oracle a archivar el Current redolog file. Este archivo debe ser almacenado en el area de destino de los archive log, en el caso del ejemplo  /u02/oradata/orion/archive. Si desea, copie los archive log que se generaron durante el proceso de respaldo (en el ejemplo secuencias 672 a 681)  a la cinta junto con el resto del respaldo.

 

·                SQL> ALTER SYSTEM SWITCH LOGFILE;

 

8.- Crear una copia del archivo de control.

 

·                SQL> ALTER DATABASE BACKUP CONTROLFILE TO '/backupDir/control.bck';

 

 

2.3 Backups físicos Administrados con RMAN (Recovery Manager)

 

RMAN es la herramienta recomendada para realizar los respaldos y recuperaciones  de bases de datos Oracle.

 

Características de Recovery Manager

 

Recovery Manager (RMAN) es una utilidad de Oracle que se usa para manejar respaldos, restauraciones, y  operaciones de recuperación de las bases de datos Oracle. RMAN tiene un poderoso lenguaje de comandos que es independiente del sistema operativo.  Recovery Manager tiene una interfaz de comandos. Oracle Enterprise Manager también proporciona un interfaz gráfica para el Recovery Manager. Recovery Manager puede ser utilizado en bases de datos de Oracle 8 y posteriores. RMAN proporciona varias características no disponibles cuando se hacen respaldos administrados por  usuario utilizando comandos del sistema operativo. Por ejemplo:

 

         Se puede almacenar operaciones de uso frecuentes como scripts en la base de datos (cuando se utiliza CATALOGO)

         Usando la característica de backup incremental  a nivel de  bloque, se puede limitar el backup solamente a esos bloques que han cambiado desde el backup anterior. Esto puede también reducir el tiempo que toma para realizar operaciones de la recuperación en modo ARCHIVELOG.

         Se puede utilizar RMAN para manejar el tamaño de piezas de backup y para ahorrar tiempo parelelizando la operación de backup.

         Las operaciones de RMAN se pueden integrar con la  programación de tareas del sistema operativo para automatizar operaciones de backup.

 

         Se puede detectar la corrupción de bloque. La información referente a la corrupción de bloque que se detecta durante el respaldo puede ser obtenida usando las vistas dinámicas V$BACKUP_CORRUPTION y V$COPY_CORRUPTION.

         RMAN proporciona mejoras de desempeño tales como :

 

         Paralelismo  automático de backup, restore, y operaciones de la recuperación

         No existe generación extra de información de redo entries durante el respaldo

         Respaldos que se restringen para limitar lecturas por archivo, por segundo para evitar interferir con las operaciones de OLTP.

         Evita saturación de lectura/escritura de cualquier archivo mientras todavía mantiene un flujo activo hacia la cinta de respaldo, usando multiplexación.

          

         Bajo el método de respaldo manejado por usuario se necesita mantener control de todos los archivos y respaldos de base de datos. En situaciones de recuperación se debe ubicar los respaldos para cada datafile, copiarlo al lugar correcto usando comandos del sistema operativo, y elegir qué archivos de archivelog deben aplicarse. RMAN maneja estas tareas automáticamente. Esta ventaja de usar RMAN es especialmente verdadera si se utilizan archivos manejados por Oracle (OMF).

 

La mayor ventaja de RMAN es que solo respaldará el espacio usado en base de datos. RMAN  no pone los  tablespaces en modo de backup, ahorrando en sobrecarga de generación de entradas de redolog

 

El ambiente RMAN consiste de utilidades y base de datos que juegan un rol en el respaldo de los datos.   El ambiente RMAN debe incluir como mínimo lo siguiente: :

  • La base de datos que  va a ser respaldada (base de datos target)
  • El cliente RMAN, que interpreta los comandos de respaldo y recuperación, dirige las sesiones de servidor para ejecutar esos comandos, y registra la actividad de los respaldos y recuperación en el archivo de control de la base de datos target.

Algunos ambientes también usarán las siguientes componentes opcionales:

  • Un área llamada flash recovery area, que es un área de disco en la cual la base de datos puede almacenar y manejar archivos relacionados con respaldos y recuperaciones;
  • Media management software, que son librerías que deben proveer los proveedores de unidades de respaldos que es requerido por RMAN como interfaz para controlar las cintas de los dispositivos de respaldos. 
  • Una base de datos de   catalogo de recuperación, que es un esquema de base de datos separado usado para registrar la actividad de  RMAN en relación a una o más bases de datos target.

 

Como ingresar y salir de RMAN

El cliente RMAN se inicia ejecutando el comando rman en el  prompt del sistema operativo (usuario oracle)

Para ejecutar tareas de respaldo y recuperación RMAN debe conectarse a una base de datos target (con privilegios SYSDBA). RMAN tambien se puede conectar a una base de datos de CATALOGO DE RECUPERACION si se desea utilizar uno. Se especifica las base de datos target y de catalogo de recuperación usando las opciones de linea de comando o  usando el comando CONNECT dentro de RMAN.

Este comando conecta a  RMAN a una base de datos target database y un catalogo de  recuperación:

% rman TARGET / CATALOG usuario_catalog/pwd@cat_tns_alias 
 

Este comando conecta a  RMAN a una base de datos target sin usar  un catalogo de  recuperación:

% rman TARGET SYS/pwd@target_str 
 

Este comando inicia  RMAN sin conectarse a una base de datos:

% rman
 

Configuración de Seteos Persistentes para el ambiente RMAN

Se pueden Configurar las definiciones persistentes de parámetros que afectan el ambiente RMAN, los cuales se aplican a todas las operaciones subsecuentes, incluso si sale y vuelve a entrar a RMAN.  Estas configuraciones forman una metadata que se guarda en el archivo de control.

Configuración de Dispositivos de Discos ( Disk Devices)  y Canales(Channels)

Los canales RMAN son conexiones a  sesiones de servidor sobre la base de datos target, que se utilizan para realizar todas las operaciones de respaldos, restauración y de recuperación. Por defecto, RMAN asigna un canal de disco para todas las operaciones. Se pueden configurar canales adicionales para el uso con discos y con otros medios.

Por defecto, RMAN envía todos los respaldos a disco. Si se configura una flash recovery area, esta es  el destino por  defecto; si no el directorio por  defecto es dependiente de la plataforma. Si, según lo recomendado, se utiliza una flash recovery area como destino para todos los respaldos a disco, se define  una flash recovery area utilizando el siguiente comando CONFIGURE:

RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT CLEAR;
 

El siguiente comando configura RMAN para escribir respaldos a discos en el directorio /tmp :

RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/tmp/%U';
 

El formato %U is reemplazado con nombres de archivos únicos cuando se toman respaldos, de esta forma los respaldos RMAN nunca se pisan.

Configuración de Dispositivos de Cintas ( Tape Devices)  y Canales(Channels)

Después de haber instalado y configurado el software de administración de cintas, se puede configurar RMAN para que el dispositivo de cinta sea el destino por defecto de los respaldos RMAN:

RMAN> CONFIGURE DEFAULT DEVICE TYPE TO sbt; 
 

Algunos administradores de cintas (por ejemplo Data Protector de HP, Brighstore de CA, Legato de EMC, Veritas de Symantec, Tivoli de IBM,  Netbackup, entre otros.) requieren un string PARMS para  configurar los parámetros del dispositivo:

RMAN> CONFIGURE CHANNEL DEVICE TYPE sbt PARMS='ENV=mml_env_settings';
 

Se pueden configurar múltiple canales para ejecutar respaldos en paralelo. El siguiente comando configura dos canales sbt para usar jobs RMAN.

RMAN> CONFIGURE DEVICE TYPE sbt PARALLELISM 2;

 

 

Ejemplo de asignación de canales paralelos a cinta (sbt)

         RMAN> run {
       2>    allocate channel c1 type sbt;
       3>    allocate channel c2 type sbt;
       4>    allocate channel c3 type sbt;
       5>    backup
       6>      incremental level = 0
       7>      format '/disk1/backup/df_%d_%s_%p.bak‘
       8>      (datafile 1,4,5 channel c1 tag=DF1)
       9>      (datafile 2,3,9 channel c2 tag=DF2)
      10>      (datafile 6,7,8 channel c3 tag=DF3);
      11>    alter system archive log current;
      12> }

 

Configuración de Política de Retención

Retention policy governs how long backup files are retained. Retention policy can be set in terms of a recovery window (how far into the past you need to be able to recover your database), or a redundancy value (how many backups of each file must be retained).

La política de retención gobierna cuánto tiempo se conservan los archivos de respaldos. La política de retención se puede fijar en términos de una ventana de recuperación (hasta punto en el pasado se necesita poder recuperar la base de datos), o un valor de redundancia (cuántas respaldos de cada archivo se deben retener)

El siguiente comando asegura que  RMAN retenga todos los respaldos que se necesitan para recuperar la base de datos hasta cualquier punto en el tiempo en los últimos 7 dias :

 RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;

El siguiente comando asegura que  RMAN retenga tres respaldos de cada archivo de datos :

RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 3;

Utilice el comando DELETE OBSOLETE para borrar en el acto respaldos que ya no se requieran de acuerdo a  la política la retención. (Para los respaldos almacenados en un área flash recovery, no se necesita realizar este paso. La base de datos elimina automáticamente archivos obsoletos y archivos que ya han sido respaldados a cinta cuando se necesita el espacio).  Se  puede utilizar la opción KEEP de los comandos  BACKUP y CHANGE para no tomar en cuenta la política de retención para respaldos individuales. -- por ejemplo, forzar la retención de un respaldo específico.

 

Configuración de  Control File Autobackups

El siguiente comando configura  RMAN para respaldar el archivo de control después de ejecutar los comandos backup o copy :

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;

Por defecto, RMAN nombra automáticamente los autobackups del archivo de control y los almacena en el area de flash recovery. El comando siguiente configura RMAN para generar autobackups del archivo de control al directorio /mybackupdir:

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT 
           FOR DEVICE TYPE DISK TO '/mybackupdir/cf%F';
 

El elemento %F del string de formato combina el DBID (Identificador de la Base de Datos, aparece en la vista v$database) , el día, el mes, el año, y el número de secuencia  para generar un nombre de archivo único. Se requiere %F para los autobackups del archivo de control.

Restauración de Valores de Configuración por Defecto

Resetee cualquier definición que se haya hecho con el comando  CONFIGURE a su valor por defecto ejecutando el comando con la opción CLEAR, como se muestra aquí:

RMAN> CONFIGURE CHANNEL DEVICE TYPE sbt CLEAR;
RMAN> CONFIGURE RETENTION POLICY CLEAR;
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK 
CLEAR;
Consultar la Configuración Vigente

Este comando muestra todas de definiciones de configuración de RMAN :

RMAN> SHOW ALL;

La salida lista los comandos CONFIGURE para  recrear esta configuración.

 

 

RMAN re-leerá un bloque de la BD hasta que esta lectura sea una imagen consistente del bloque. Veamos el siguiente ejemplo de backup RMAN:

 
         $ rman target sys/*** nocatalog 
         RMAN> run { 
               allocate channel t1 type disk;
                backup 
                format '/app/oracle/db_backup/%d_t%t_s%s_p%p'
                ( database ); 
               release channel t1; 
                  }

Ejemplo de restauración de  RMAN:

 

         $ rman target sys/*** nocatalog 
         RMAN>run {
                allocate channel t1 type disk;
                # set until time 'Aug 07 2000 :51';
                restore tablespace users; 
                recover tablespace users; 
                release channel t1; 
                }

 

Los ejemplos anteriores son extremadamente simplistas y solamente útiles para ilustrar conceptos básicos. Por defecto Oracle utiliza los controlfiles de la base de datos para almacenar la información sobre backups. Normalmente se configurará una base de datos de catalogo de RMAN para almacenar la meta data de RMAN. Lea la guía Oracle Backup and Recovery antes de poner backups de RMAN en ejecución.

 

 

Recovery Manager puede realizar los siguientes tipos de respaldos:

         Copias Imagen son copias de un  datafile, control file, o archivos de archived redo log. Una  copia puede hacerse con RMAN o usando comandos de sistemas operativos. La copia de un datafile consiste en todos los bloques del datafile, incluyendo los bloques no usados. La copia imagen puede incluir solo un archivo.

         Backup sets pueden incluir uno o mas datafiles, el control file, o  archivos de archived redo log. Se pueden generar backup set de dos formas:

-     Full backup: En un full backup, se respalda uno o más archivos. En un full backup, se respaldan todos los bloques  que contienen datos para los archivos especificados.

-     Backup Incremental: Un backup incremental es un respaldo de datafiles que incluye solo los bloques que han cambiado desde ultimo backup incremental. Un backup incremental requiere un respaldo de nivel 0  (o nivel  incremental 0), que respalda todos los bloques de datos que contienen los archivos especificados.  Un respaldo incremental  level 0 y full backups copian todos los bloques en los datafiles, pero  full backups no pueden ser usados en una estrategia de backup incremental.

Nota: Se pueden configurar respaldos automáticos de archivo de control de tal manera que cada vez que se usen los comandos BACKUP o COPY se respalden los archivos de control y archivo de parámetros.

 

 

Backup Sets

Un backup set consiste de uno o más archivos físicos almacenados en un formato especifico de RMAN, ya sea en disco o cinta. Se puede generar un backup set que contenga datafiles, control files, y archivelogs. También se puede respaldar un backup set. Los Backup sets pueden ser de dos tipos:

         Datafile: Puede contener datafiles y control files, pero no archivelogs

         Archived log: Contiene archivelogs, pero no contiene datafiles ni control files

 

Nota: Los Backup sets necesitan ser restaurados por el Recovery Manager antes que se pueda ejecutar la operación de  recovery (recuperación), a diferencia de las copias  imágenes que ya residen en disco.

 

Control Files en  Backup Sets del tipo Datafile

Cada archivo en un backup set debe tener el mismo tamaño de bloque  Oracle. Cuando se incluye un control file este se escribe en el último backup set. Se puede incluir un  archivo de control en un backup ya sea:

         Explícitamente usando la sintaxis  INCLUDE CONTROL FILE, o;

         Implícitamente respaldando el datafile  1 (el datafile de tablespace system)

El comando  BACKUP se usa para respaldar datafiless, archived redo log files, y control files.  El comando  BACKUP respalda los archivos en uno o más backup sets sobre  disco o cinta. Se pueden realizar los respaldos cuando la BD está abierta o cerrada . Los respaldos pueden ser incrementales o full.

 

Respaldo de Archivos de Base de Datos

Utilice el comando BACKUP para respaldar archivos de base de datos. Normalmente, antes se tendrán configurado los dispositivos por defecto y los canales. El comando BACKUP respalda los datos hacia el dispositivo por defecto y canales que hayan sido configurados para el tipo respaldo requerido.

Si se especifica  BACKUP AS COPY, entonces RMAN copia los archivos como copias imágenes, es decir, copias bit-por-bit de la base de datos, las cuales pueden ser creadas solo en disco.

Este  comando crea respaldos copias imagen de todos los datafiles en la base de datos:

RMAN> BACKUP AS COPY DATABASE;
 

Si se especifica BACKUP AS BACKUPSET, entonces RMAN almacena sus respaldos en backup sets. Un backup set consiste de una o más piezas o backup pieces, archivos físicos que contienen los datos. Usualmente un backup set contiene solo una pieza. Solo RMAN puede crear y restaurar  backup sets.

El siguiente comando crea un respaldo de la base de datos y archivos de archivelogs  sobre cinta, en formato de backup set, usando los canales configurados:

RMAN> BACKUP DEVICE TYPE sbt DATABASE PLUS ARCHIVELOG;
Respaldo de archivos individuales

You can back up individual tablespaces, database files, server parameter files, and backup sets with various options, as in these examples:

Se pueden respaldar en forma individual las siguientes estructuras o archivos de la base de datos: tablespaces, archivos de base datos, archivos de archivelogs, archivos de parámetro, y backup sets. Por ejemplo :

RMAN> BACKUP ARCHIVELOG COMPLETION TIME BETWEEN 
        'SYSDATE-31' AND 'SYSDATE-7';
RMAN> BACKUP TABLESPACE system, users, tools;
RMAN> BACKUP AS BACKUPSET DATAFILE 
        'ORACLE_HOME/oradata/trgt/users01.dbf', 
        'ORACLE_HOME/oradata/trgt/tools01.dbf';
RMAN> BACKUP CURRENT CONTROLFILE TO '/backup/curr_cf.copy';
RMAN> BACKUP SPFILE;
RMAN> BACKUP BACKUPSET ALL;

Observe que en los ejemplos anteriores se debe ingresar el directorio de su propio Oracle home en lugar de “ORACLE_HOME”.

Opciones del comando Backup

Aquí están algunas opciones de uso frecuente del comando BACKUP:

Parametro

Ejemplo

Explicación

FORMAT

FORMAT '/tmp/%U'

Especifica una ubicación y un nombre para las piezas y copias de respaldos. Se deben utilizar variables de substitución para generar nombres de archivos únicos.

TAG

TAG 'full_bak'

Especifica un string definido por el usuario como etiqueta para el respaldo. Si no se especifica una etiqueta, entonces RMAN asigna una etiqueta por defecto con la fecha y la hora.

Los comandos BACKUP siguientes ilustran estas opciones:

RMAN> BACKUP FORMAT='ARCH_%d/%t/%s/%p' ARCHIVELOG LIKE '%arc_dest%';
RMAN> BACKUP TAG 'bkup_bd_full_semanal' DATABASE MAXSETSIZE 512M;
RMAN> BACKUP COPIES 2 DEVICE TYPE sbt BACKUPSET ALL;
Respaldos Incrementales

Si se especifica BACKUP INCREMENTAL, RMAN creará backups incrementales de su base de datos. Los respaldos incrementales capturan a nivel de bloque los cambios de la base de datos desde el último backup incremental. El punto de partida para una estrategia de respaldo incremental es un respaldo incremental de nivel 0, que respalda todos los bloques en la base de datos. Los respaldos incrementales de Nivel 1 , tomados a intervalos regulares, contienen solamente los bloques que han cambiado desde el respaldo incremental anterior. Éstos respaldos pueden ser acumulativos (todos los bloques que han cambiado desde el último respaldo de nivel 0) o diferencial (incluir solamente bloques que han cambiado desde el respaldo incremental más reciente, ya sea de nivel 0 o nivel 1 ).

Los respaldos incrementales son generalmente más pequeños y más rápidos que los respaldos full de la base de datos. La recuperación de un respaldo incremental es más rápida que la recuperación que usa solamente archivos de archivelogs. Durante una restauración de un respaldo incremental, se utiliza el respaldo del nivel 0 como el punto de partida, luego los bloques que han cambiado son actualizados basado en el respaldo de nivel 1 en lo posible para evitar reaplicar uno a uno los cambios desde archivos de archivelogs. La recuperación con respaldos incrementales no requiere ningún esfuerzo adicional de su parte. Si los respaldos incrementales están disponibles, RMAN las utilizará durante la recuperación.

La característica de respaldos actualizados incrementalmente  de RMAN permite una rutina de respaldo incremental más eficiente. Los cambios desde el  respaldo de nivel 1 se pueden utilizar para hacer avanzar un respaldo de copia imagen incremental del nivel 0, de modo que incluya todos los cambios hasta  el SCN en el cual el respaldo incremental del nivel 1 fue creado. La recuperación que usa el respaldo  incremental del nivel 0 actualizada es más rápida, porque todos los cambios del respaldo incremental del nivel 1 ya se han aplicado.

Ejemplo Respaldo Incremental

Usted está manteniendo una base de datos de 800 GB, que está creciendo continuamente. Basado en el hardware existente, se determina que un respaldo completo de la  base de datos toma 4 horas. La base de datos está en línea 24 horas al día, 7 días a la semana y los respaldos están consumiendo demasiados recursos de sistema durante este período del tiempo. Los respaldos de nivel 0 no se pueden realizar más que una vez por semana, pero se requiere recuperación rápida en caso de falla. Usted por lo tanto toma la decisión siguiente como estrategia de respaldo y  recuperación:

         Se ejecutará un respaldo del nivel 0  cada semana en el día con la menos actividad. Usted determina que ese día es el domingo.

               RMAN> BACKUP INCREMENTAL level 0 database;

         En forma diaria se ejecutarán respaldos incrementales de nivel 2, excepto el miércoles en que se realizará un respaldo de nivel 1. De esta manera, los respaldos serán rápidos porque solamente serán copiados los bloques que han cambiado a partir del día anterior:

               RMAN> BACKUP INCREMENTAL level 2 database;

 

 

 

Vistas Dinámicas RMAN

Se pueden usar las siguientes vistas para obtener informacion RMAN almacenanada en el control file :

 

       V$ARCHIVED_LOG muestra qué archivos se han creado, respaldado, y se han limpiado en la base de datos.

       V$BACKUP_CORRUPTION muestra qué bloques se han encontrado corruptos durante un respaldo de un backup set.

       V$COPY_CORRUPTION muestra qué bloques se han encontrado corruptos durante un respaldo de copia imagen (comando COPY).

       V$DATABASE_BLOCK_CORRUPTION Despliega información sobre los bloques de la base de datos que se corrompieron después del último backup.

       V$BACKUP_DATAFILE es útil para crear backup sets de  igual tamaño  determinando el número de bloques en cada datafile. Puede también ser útil para encontrar el número de bloques corruptos para el datafile.

       V$BACKUP_REDOLOG muestra archivos de archivelogs almacenados en backup sets.

       V$BACKUP_SET muestra backup sets que han sido creados.

       V$BACKUP_PIECE muestra piezas de  backup  creadas para backup sets.

 


2.4 Backups Lógicos

Este tipo de backups copian el contenido de la BD pero sin almacenar la posición física de los datos. Se realizan con la herramienta export que copia los datos y la definición de la BD en un archivo en un formato interno de Oracle.

Para realizar un export la BD debe estár abierta. Export asegura la consistencia en la tabla, aunque no entre tablas. Si se requiere consistencia entre todas las tablas de la BD entonces no se debe realizar ninguna transacción durante el proceso de export. Esto se puede conseguir si se abre la BD en modo RESTRICT.

Entre las ventajas de efectuar un export están las siguientes:

  • Se puede detectar la corrupción en los bloques de datos, ya que el proceso de export fallará.
  • Protege de Fallas de usuario, por ejemplo si se borra una fila o toda una tabla por error es fácil recuperarla por medio de un import.
  • Se puede determinar los datos a exportar con gran flexibilidad.
  • Se pueden realizar exports completos, incrementales y acumulativos.
  • Los backups relizados con export son portables y sirven como formato de intercambio de datos entre BDs y entre máquinas.

Una de las desventajas de realizar backups lógicos con export es que son mucho más lentos que los backups físicos.

Parámetros de Export

[oracle@hercules ~]$ exp help=y
 
Export: Release 10.2.0.3.0 - Production on Thu Jun 28 09:06:09 2007
 
Copyright (c) 1982, 2005, Oracle.  All rights reserved.
 
You can let Export prompt you for parameters by entering the EXP
command followed by your username/password:
 
     Example: EXP SCOTT/TIGER
 
Or, you can control how Export runs by entering the EXP command followed
by various arguments. To specify parameters, you use keywords:
 
     Format:  EXP KEYWORD=value or KEYWORD=(value1,value2,...,valueN)
     Example: EXP SCOTT/TIGER GRANTS=Y TABLES=(EMP,DEPT,MGR)
               or TABLES=(T1:P1,T1:P2), if T1 is partitioned table
 
USERID must be the first parameter on the command line.
 
Keyword    Description (Default)      Keyword      Description (Default)
--------------------------------------------------------------------------
USERID     username/password          FULL         export entire file (N)
BUFFER     size of data buffer        OWNER        list of owner usernames
FILE       output files (EXPDAT.DMP)  TABLES       list of table names
COMPRESS   import into one extent (Y) RECORDLENGTH length of IO record
GRANTS     export grants (Y)          INCTYPE      incremental export type
INDEXES    export indexes (Y)         RECORD       track incr. export (Y)
DIRECT     direct path (N)            TRIGGERS     export triggers (Y)
LOG        log file of screen output  STATISTICS   analyze objects (ESTIMATE)
ROWS       export data rows (Y)       PARFILE      parameter filename
CONSISTENT cross-table consistency(N) CONSTRAINTS  export constraints (Y)
OBJECT_CONSISTENT    transaction set to read only during object export (N)
FEEDBACK             display progress every x rows (0)
FILESIZE             maximum size of each dump file
FLASHBACK_SCN        SCN used to set session snapshot back to
FLASHBACK_TIME       time used to get the SCN closest to the specified time
QUERY                select clause used to export a subset of a table
RESUMABLE            suspend when a space related error is encountered(N)
RESUMABLE_NAME       text string used to identify resumable statement
RESUMABLE_TIMEOUT    wait time for RESUMABLE
TTS_FULL_CHECK       perform full or partial dependency check for TTS
VOLSIZE              number of bytes to write to each tape volume
TABLESPACES          list of tablespaces to export
TRANSPORT_TABLESPACE export transportable tablespace metadata (N)
TEMPLATE             template name which invokes iAS mode export

 

Parámetro

Defecto

Descripción

USERID

indefinido

el username/password del usuario que efectua el export.

BUFFER

dependiente del SO

El tamaño en bytes del buffer utilizado.

FILE

expdat.dmp

el nombre del archivo destino.

GRANTS

Yes

indica si se exportan también los derechos.

INDEXES

Yes

indica si se exportan también los índices.

ROWS

Yes

indica si se exportan también las filas de las tablas, o sólo las definiciones de las tablas.

CONSTRAINTS

Yes

indica si se exportan también las restricciones.

COMPRESS

Yes

indica si se exporta en modo comprimido.

FULL

No

indica si se exporta la BD entera.

OWNER

usuario actual

una lista de usuarios cuyos objetos se quieren exportar.

TABLES

indefinido

la lista de tablas a exportar.

RECORDLENGTH

dependiente del SO

la longitud en bytes del registro del archivo.

INCTYPE

indefinido

el tipo de export incremental.

RECORD

Yes

indica si se anota el export incremental en las tablas SYS.INCVID y en SYS.INCEXP.

PARFILE

indefinido

el archivo de parámetros, donde se pueden definer todas las opciones anteriores.

Modos de Export

Existen tres modos de realizar una exportación de datos:

Modo Tabla

Exporta las definiciones de tabla, los datos, los derechos del propietario, los índices del propietario, las restricciones de la tabla y los disparadores asociados a la tabla.

Modo Usuario

Exporta todo lo del modo de Tabla más los clusters, enlaces de BD, vistas, sinónimos privados, secuencias, procedimientos, etc. del usuario.

Modo BD Entera

Además de todo lo del modo Usuario, exporta los roles, todos los sinónimos, los privilegios del sistema, las definiciones de los tablespaces, las cuotas en los tablespaces, las definiciones de los segmentos de rollback, las opciones de auditoría del sistema, todos los disparadores y los perfiles.

El modo BD entera puede ser dividido en tres casos: Completo, Acumulativo e Incremental. Estos dos últimos se toman menos tiempo que el completo, y permiten exportar sólo los cámbios en los datos y en las definiciones.

Completo

Exporta todas las tablas de la BD e inicializa la información sobre la exportación incremental de cada tabla. Después de una exportación completa, no se necesitan los archivos de exportaciones acumulativas e incrementales de la BD anteriores.

 
·                $ exp userid=system/manager full=y inctype=complete constraints=Y
·                file=full_export_filename

Acumulativo

Exporta solo las tablas que han sido modificadas o creadas desde la última exportación Acumulativa o Completa, y registra los detalles de exportación para cada tabla exportada. Después de una exportación acumulativa, no se necesitan los archivos de exportaciones incrementales de la BD anteriores.

 
·                $ exp userid=system/manager full=y inctype=cumulative constraints=Y
·                file=cumulative_export_filename

Incremental

Exporta todas las tablas modificadas o creadas desde la última exportación Incremental, Acumulativa o Completa, y registra los detalles de exportación para cada tabla exportada. Son interesantes en entornos en los que muchas tablas permanecen estáticas por periodos largos de tiempo, mientras que otras varían y necesitan ser copiadas. Este tipo de exportación es útil cuando hay que recuperar rápidamente una tabla borrada por accidente.

 
·                $ exp userid=system/manager full=y inctype=incremental constraints=Y
·                file=incremental_export_filename

La política de exportación puede ser la siguiente: realizar una exportación completa el día 1 (por ejemplo el domingo), y luego realizar exportaciones incrementales el resto de la semana. De este modo de lunes a sábado sólo se exportarán aquellas tablas exportadas, ahorrando tiempo en el proceso.


3 Principios de la Recuperación


Para entender los principios de la recuperación, se necesita entender las estructuras de datos subyacentes utilizadas en la recuperación.


3.1 Definiciones y Conceptos

Los archivos redo log contienen los cambios realizados sobre la BD. Conviene presentar algunos conceptos relacionados con ellos.

Vector de Cambio

describe un cambio simple en un bloque de datos de la BD. Entre otros datos, contiene el número de versión, el código de la transacción, y la dirección del bloque afectado.

Registro Redo log

es un conjunto de vectores de cambio que describen un cambio atómico sobre la BD. La transacción es también la unidad de recuperación.

Evolución de Redo log por día

se puede calcular ejecutando el comando archive log list en dos días consecutivos y calculando la diferencia del número de secuencia de los archivos redo log, multiplicado por el tamaño de un archivo redo log:

 
·                SQL> archive log list;
·                Database log mode              No Archive Mode
·                Automatic archival             Disabled
·                Archive destination            /opt/app/oracle/admin/demo/arch/arch.log
·                Oldest online log sequence     3
·                Current log sequence           5

 

System Change Number, SCN

es un dato que define la versión confirmada (commit) de la BD en este instante de tiempo. Cuando una transacción es confirmada, se le asigna un SCN que la identifica unívocamente. Los archivos redo log son marcados con dos SCN. Cuando se abre un nuevo archivo redo log se le marca con un SCN, low SCN, que es uno mas que el SCN mayor del anterior archivo redo log; y su high SCN es puesto a infinito. Los SCN también se asocian al archivo de control, ya que cuando se para una BD, un tablespace o archivo de datos, se almacena para cada archivo de datos su stop SCN en el archivo de control.

Cambio de redo log

es el proceso mediante el cual se deja de utilizar un archivo redo log y el LGWR combia al siguiente archivo redo log disponible. Se puede hacer con el comando alter system switch logfile;.

Checkpoints

son activados automáticamente durante el funcionamiento normal de la instancia, pero pueden ser activados manualmente con el comando alter system checkpoint local o alter system checkpoint global dependiendo si nos referimos a la instancia en la que estamos, o si queremos que afecte a todas las instancias activas, respectivamente. Cada checkpoint lleva implicito un SCN, y Oracle asegura que todos los cambios con un SCN menor que el del checkpoint dado han sido escritos en el disco.


3.2 Métodos de Recuperación

Existen varios métodos de recuperación, pero todos ellos se basan en la aplicación de los registros de redo log.

Aplicación de Redo Log

Cuando una BD se arranca con el comando startup, la BD pasa por los estados nomount, mount y open. En este tercer estado, se verifica que se pueden abrir todos los archivos de log y de datos. Si la BD se arranca por primera vez después de una caída o falla, se necesitará efectuar una recuperación que consiste en dos pasos: avanzar la BD hacia adelante aplicando los registros redo log (roll forward), deshacer las transacciones no confirmadas (rolback).

Cada archivo de datos tiene en su cabecera el último checkpoint efectuado, así como el archivo de control también lleva esa cuenta. El checkpoint lleva incluido el SCN. Este es conocido como SCN de inicio de archivo. Asociado a cada archivo de datos el archivo de control tiene el SCN de final, puesto inicialmente a infinito. El SCN de inicio se incrementa con cada checkpoint.

Cuando la BD se para en modo normal o inmediato iguala el SCN de parada para cada archivo de datos al SCN almacenado en cada archivo de datos. Cuando se abre otra vez la BD se realizan dos comprobaciones. La primera es mirar si el contador de checkpoints en la cabecera de los archivos de datos coincide con el correspondiente del archivo de control. Si es así, se compara el SCN de inicio de cada archivo de datos con el SCN de final almacenado en el archivo de control. Si son iguales no se necesita recuperación en este archivo de datos. Como parte de la apertura se pone a infinito el SCN de final para ese archivo de datos.

Si la BD se paró con en modo abort no se ejecutó el checkpoint y el SCN de fin para los archivo de datos está a infinito. Así, durante la BD se abre, y suponiendo que el contador de checkpoints coincide, se comparan los SCN de inicio y de final, y como el último es infinito se efectura una recuperación aplicando los cambios almacenados en los archivos redo log en línea para avanzar la BD, y los registros de roll back de los segmentos de roll back para deshacer las transacciones no confirmadas.

Si después de parar la BD se reemplaza un archivo de datos por su copia de seguridad, al arrancar la BD Oracle detecta que el contador de checkpoints del archivo de datos no coincide con el almacenado en el archivo de control. Así, se tendrá que echar mano a los archivos redo log archivados (archivelogs), empezando por aquel cuyo número de secuencia aparece en la cabecera del archivo de datos.


3.3 Recuperación Física

La utilización de una copia de backup de archivos de datos siempre necesita de una recuperación física. También es así cuando un archivo de datos se pone offline sin un checkpoint.

Oracle detecta que se necesita una recuperación física cuando el contador de checkpoints de la cabecera del archivo de datos no coincide con el correspondiente contador de checkpoints del archivo de control. Entonces se hace necesario el comando recover. La recuperación comienza en el SCN menor de los archivos de datos en recuperación, aplicando los registros de redo log a partir de él, y parando en el SCN de final mayor de todos los archivos de datos.

Existen tres opciones para realizar una recuperacion física. La primera es una recuperación de BD donde se restaura la BD entera. La segunda es una recuperación de tablespace donde, mientras una parte de la BD está abierta, se puede recuperar un tablespace determinado. Esto significa que serán recuperados todos los archivos de datos asociados al tablespace. El tercer tipo es la recuperación de un archivo de datos específico mientras el resto de la BD está abierta.

Requisitos para Utilizar Recuperación Física

La primera condición que se ha de poner para poder recuperar físicamente una BD es que ésta se esté utilizando en modo ARCHIVELOG. De otro modo, una recuperación completa puede que no sea posible. Si trabajamos con la BD en modo NOARCHIVELOG, y se hace una copia semanal de los archivos de la BD, se debería estar preparado para perder, en el peor de los casos, el trabajo de la última semana si sucede un fallo. Ya que los archivos de redo log contendrían un agujero y no se podia avanzar la BD hasta el intante anterior al fallo. En este caso el único medio para reconstruir la BD es hacerlo desde un export completo, recreando el esquema de la BD e importando todos los datos.

Recuperación de la BD

La BD debe estar montada pero no abierta. El comando de recuperación es el siguiente:

 
·                RECOVER [AUTOMATIC] [FROM 'localizacion'] [BD]
·                   [UNTIL CANCEL]
·                   [UNTIL TIME fecha]
·                   [UNTIL CHANGE entero]
·                [USING BACKUP CONTROLFILE]

Las opciones entre corchetes son opcionales:

  • AUTOMATIC hace que la recuperación se haga automáticamente sin preguntar al DBA por el nombre de los archivos redo log. También se puede utilizar para este cometido el comando set autorecovery on/off. Los archivos redo log deben estar en la localización fijada en LOG_ARCHIVE_DEST y el formato del nombre de los archivos debe ser el fijado en LOG_ARCHIVE_FORMAT.
  • FROM se utiliza para determinar el lugar donde están los archivos redo log, si es distinto del fijado en LOG_ARCHIVE_DEST.
  • UNTIL sirve para indicar que se desea realizar una recuperación incompleta, lo que implica perder datos. Solo se dará cuando se han perdido redo log archivados o el archivo de control. Cuando se ha realizado una recuperación incompleta la BD debe ser abierta con el comando alter database open resetlogs, lo que produce que los redo log no aplicados no se apliquen nunca y se inicialice la secuencia de redo log en el archivo de control. Existen tres opciones para parar la recuperación:
    • UNTIL CANCEL permite recuperar un redo log cada vez, parando cuando se teclea CANCEL.
    • UNTIL TIME permite recuperar hasta un instante dado dentro de un archivo de redo log
    • UNTIL CHANGE permite recuperar hasta un SCN dado.
    • USING BACKUP CONTROLFILE utiliza una copia de seguridad del archivo de control para gobernar la recuperación.

Recuperación de un tablespace

La BD debe estar abierta, pero con el tablespace a recuperar offline. El comando de recuperación es el siguiente:

 
·                RECOVER [AUTOMATIC] [FROM 'localizacion'] 
·                   TABLESPACE nombre_tablespace [, nombre_tablespace]

Recuperación de un Archivo de Datos

La BD debe estar abierta o cerrada, dependiendo del archivo a recuperar. Si el archivo a recuperar es de un tablespace de usuario la BD puede estar abierta, pero con el archivo a recuperar offline. Si el archivo es del tablespace SYSTEM la BD debe estar cerrada, ya que no puede estar abierta con los archivos del SYSTEM offline. El comando de recuperación es el siguiente:

 
·                RECOVER [AUTOMATIC] [FROM 'localizacion'] 
·                   DATAFILE nombre_archivo [, nombre_archivo]

Creando un Archivo de Control

Si el archivo de control ha resultado dañado y se ha perdido se puede utilizar una copia de seguridad del mismo o crear uno nuevo. El comando de creación de un nuevo archivo de control es CREATE CONTROLFILE. Este comando se puede ejecutar sólo con la BD en estado nomount. La ejecución del comando produce un nuevo archivo de control y el montaje automático de la BD.

Un comando interesante que ayuda a mantener los archivos de control a salvo es el siguiente:

·                SQL>alter database backup controlfile to trace;
·                SQL>alter database backup controlfile to trace as '/algun/directorio/';
·                SQL>alter database backup controlfile to trace as '/algun/directorio ' reuse;
·                 

que produce un script que puede ser utilizado para generar un nuevo archivo de control y recuperar la BD, en caso necesario. El archivo de traza generado es el siguiente:

 
-- The following are current System-scope REDO Log Archival related
-- parameters and can be included in the database initialization file.
--
-- LOG_ARCHIVE_DEST=''
-- LOG_ARCHIVE_DUPLEX_DEST=''
--
-- LOG_ARCHIVE_FORMAT=orion_%t_%s_%r.dbf
--
-- DB_UNIQUE_NAME="orion"
--
-- LOG_ARCHIVE_CONFIG='SEND, RECEIVE, NODG_CONFIG'
-- LOG_ARCHIVE_MAX_PROCESSES=2
-- STANDBY_FILE_MANAGEMENT=MANUAL
-- STANDBY_ARCHIVE_DEST=?/dbs/arch
-- FAL_CLIENT=''
-- FAL_SERVER=''
--
-- LOG_ARCHIVE_DEST_1='LOCATION=/u02/oradata/orion/archive'
-- LOG_ARCHIVE_DEST_1='OPTIONAL REOPEN=300 NODELAY'
-- LOG_ARCHIVE_DEST_1='ARCH NOAFFIRM NOEXPEDITE NOVERIFY SYNC'
-- LOG_ARCHIVE_DEST_1='REGISTER NOALTERNATE NODEPENDENCY'
-- LOG_ARCHIVE_DEST_1='NOMAX_FAILURE NOQUOTA_SIZE NOQUOTA_USED NODB_UNIQUE_NAME'
-- LOG_ARCHIVE_DEST_1='VALID_FOR=(PRIMARY_ROLE,ONLINE_LOGFILES)'
-- LOG_ARCHIVE_DEST_STATE_1=ENABLE
 
--
-- Below are two sets of SQL statements, each of which creates a new
-- control file and uses it to open the database. The first set opens
-- the database with the NORESETLOGS option and should be used only if
-- the current versions of all online logs are available. The second
-- set opens the database with the RESETLOGS option and should be used
-- if online logs are unavailable.
-- The appropriate set of statements can be copied from the trace into
-- a script file, edited as necessary, and executed when there is a
-- need to re-create the control file.
--
--     Set #1. NORESETLOGS case
--
-- The following commands will create a new control file and use it
-- to open the database.
-- Data used by Recovery Manager will be lost.
-- Additional logs may be required for media recovery of offline
-- Use this only if the current versions of all online logs are
-- available.
 
-- After mounting the created controlfile, the following SQL
-- statement will place the database in the appropriate
-- protection mode:
--  ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE
 
STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "ORION" NORESETLOGS  ARCHIVELOG
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    MAXINSTANCES 8
    MAXLOGHISTORY 292
LOGFILE
  GROUP 1 '/u02/oradata/orion/redo01.log'  SIZE 50M,
  GROUP 2 '/u02/oradata/orion/redo02.log'  SIZE 50M,
  GROUP 3 '/u02/oradata/orion/redo03.log'  SIZE 50M
-- STANDBY LOGFILE
 
DATAFILE
  '/u02/oradata/orion/system01.dbf',
  '/u02/oradata/orion/undotbs01.dbf',
  '/u02/oradata/orion/sysaux01.dbf',
  '/u02/oradata/orion/users01.dbf',
  '/u02/oradata/orion/designer6i_data01.DBF',
  '/u02/oradata/orion/designer6i_index01.dbf'
CHARACTER SET WE8ISO8859P1
;
 
-- Configure RMAN configuration record 1
VARIABLE RECNO NUMBER;
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('CONTROLFILE AUTOBACKUP','ON');
-- Configure RMAN configuration record 2
VARIABLE RECNO NUMBER;
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('DEFAULT DEVICE TYPE TO','DISK');
-- Configure RMAN configuration record 3
VARIABLE RECNO NUMBER;
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('CHANNEL','1 DEVICE TYPE DISK FORMAT   ''/home/oracle/rman/spfile_bck_%U''');
-- Configure RMAN configuration record 4
VARIABLE RECNO NUMBER;
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('RETENTION POLICY','TO REDUNDANCY 2');
-- Configure RMAN configuration record 5
VARIABLE RECNO NUMBER;
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE','DISK TO ''/home/oracle/rman/cf_orion_%F.bck''');
-- Configure RMAN configuration record 6
VARIABLE RECNO NUMBER;
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('CHANNEL','DEVICE TYPE DISK FORMAT   ''/home/oracle/rman/spfile_bck_%U''');
-- Commands to re-create incarnation table
-- Below log names MUST be changed to existing filenames on
-- disk. Any one log file from each branch can be used to
-- re-create incarnation records.
-- ALTER DATABASE REGISTER LOGFILE '/u02/oradata/orion/archive/orion_1_1_562360180.dbf';
-- ALTER DATABASE REGISTER LOGFILE '/u02/oradata/orion/archive/orion_1_1_603045878.dbf';
-- Recovery is required if any of the datafiles are restored backups,
-- or if the last shutdown was not normal or immediate.
RECOVER DATABASE
 
-- All logs need archiving and a log switch is needed.
ALTER SYSTEM ARCHIVE LOG ALL;
 
-- Database can now be opened normally.
ALTER DATABASE OPEN;
 
-- Commands to add tempfiles to temporary tablespaces.
-- Online tempfiles have complete space information.
-- Other tempfiles may require adjustment.
ALTER TABLESPACE TEMP ADD TEMPFILE '/u02/oradata/orion/temp01.dbf'
     SIZE 39845888  REUSE AUTOEXTEND ON NEXT 655360  MAXSIZE 32767M;
-- End of tempfile additions.
--
--     Set #2. RESETLOGS case
--
-- The following commands will create a new control file and use it
-- to open the database.
-- Data used by Recovery Manager will be lost.
-- The contents of online logs will be lost and all backups will
-- be invalidated. Use this only if online logs are damaged.
 
-- After mounting the created controlfile, the following SQL
-- statement will place the database in the appropriate
-- protection mode:
--  ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE
 
STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "ORION" RESETLOGS  ARCHIVELOG
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    MAXINSTANCES 8
    MAXLOGHISTORY 292
LOGFILE
  GROUP 1 '/u02/oradata/orion/redo01.log'  SIZE 50M,
  GROUP 2 '/u02/oradata/orion/redo02.log'  SIZE 50M,
  GROUP 3 '/u02/oradata/orion/redo03.log'  SIZE 50M
-- STANDBY LOGFILE
 
DATAFILE
  '/u02/oradata/orion/system01.dbf',
  '/u02/oradata/orion/undotbs01.dbf',
  '/u02/oradata/orion/sysaux01.dbf',
  '/u02/oradata/orion/users01.dbf',
  '/u02/oradata/orion/designer6i_data01.DBF',
  '/u02/oradata/orion/designer6i_index01.dbf'
CHARACTER SET WE8ISO8859P1
;
 
-- Configure RMAN configuration record 1
VARIABLE RECNO NUMBER;
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('CONTROLFILE AUTOBACKUP','ON');
-- Configure RMAN configuration record 2
VARIABLE RECNO NUMBER;
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('DEFAULT DEVICE TYPE TO','DISK');
-- Configure RMAN configuration record 3
VARIABLE RECNO NUMBER;
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('CHANNEL','1 DEVICE TYPE DISK FORMAT   ''/home/oracle/rman/spfile_bck_%U''');
-- Configure RMAN configuration record 4
VARIABLE RECNO NUMBER;
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('RETENTION POLICY','TO REDUNDANCY 2');
-- Configure RMAN configuration record 5
VARIABLE RECNO NUMBER;
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE','DISK TO ''/home/oracle/rman/cf_orion_%F.bck''');
-- Configure RMAN configuration record 6
VARIABLE RECNO NUMBER;
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('CHANNEL','DEVICE TYPE DISK FORMAT   ''/home/oracle/rman/spfile_bck_%U''');
-- Commands to re-create incarnation table
-- Below log names MUST be changed to existing filenames on
-- disk. Any one log file from each branch can be used to
-- re-create incarnation records.
-- ALTER DATABASE REGISTER LOGFILE '/u02/oradata/orion/archive/orion_1_1_562360180.dbf';
-- ALTER DATABASE REGISTER LOGFILE '/u02/oradata/orion/archive/orion_1_1_603045878.dbf';
-- Recovery is required if any of the datafiles are restored backups,
-- or if the last shutdown was not normal or immediate.
RECOVER DATABASE USING BACKUP CONTROLFILE
 
-- Database can now be opened zeroing the online logs.
ALTER DATABASE OPEN RESETLOGS;
 
-- Commands to add tempfiles to temporary tablespaces.
-- Online tempfiles have complete space information.
-- Other tempfiles may require adjustment.
ALTER TABLESPACE TEMP ADD TEMPFILE '/u02/oradata/orion/temp01.dbf'
     SIZE 39845888  REUSE AUTOEXTEND ON NEXT 655360  MAXSIZE 32767M;
-- End of tempfile additions.
--


3.4 Recuperación Lógica

Oracle dispone de la herramienta import para restaurar los datos de una BD a partir de los archivos resultados de un export. Import lee los datos de los archivos de exportación y ejecuta las sentencias que almacenan creando las tablas y llenándolas de datos.

Parámetros del Import

 
[oracle@hercules ~]$ imp help=y
 
Import: Release 10.2.0.3.0 - Production on Thu Jun 28 09:16:19 2007
 
Copyright (c) 1982, 2005, Oracle.  All rights reserved.
 
 
You can let Import prompt you for parameters by entering the IMP
command followed by your username/password:
 
     Example: IMP SCOTT/TIGER
 
Or, you can control how Import runs by entering the IMP command followed
by various arguments. To specify parameters, you use keywords:
 
     Format:  IMP KEYWORD=value or KEYWORD=(value1,value2,...,valueN)
     Example: IMP SCOTT/TIGER IGNORE=Y TABLES=(EMP,DEPT) FULL=N
               or TABLES=(T1:P1,T1:P2), if T1 is partitioned table
 
USERID must be the first parameter on the command line.
 
Keyword  Description (Default)       Keyword      Description (Default)
--------------------------------------------------------------------------
USERID   username/password           FULL         import entire file (N)
BUFFER   size of data buffer         FROMUSER     list of owner usernames
FILE     input files (EXPDAT.DMP)    TOUSER       list of usernames
SHOW     just list file contents (N) TABLES       list of table names
IGNORE   ignore create errors (N)    RECORDLENGTH length of IO record
GRANTS   import grants (Y)           INCTYPE      incremental import type
INDEXES  import indexes (Y)          COMMIT       commit array insert (N)
ROWS     import data rows (Y)        PARFILE      parameter filename
LOG      log file of screen output   CONSTRAINTS  import constraints (Y)
DESTROY                overwrite tablespace data file (N)
INDEXFILE              write table/index info to specified file
SKIP_UNUSABLE_INDEXES  skip maintenance of unusable indexes (N)
FEEDBACK               display progress every x rows(0)
TOID_NOVALIDATE        skip validation of specified type ids
FILESIZE               maximum size of each dump file
STATISTICS             import precomputed statistics (always)
RESUMABLE              suspend when a space related error is encountered(N)
RESUMABLE_NAME         text string used to identify resumable statement
RESUMABLE_TIMEOUT      wait time for RESUMABLE
COMPILE                compile procedures, packages, and functions (Y)
STREAMS_CONFIGURATION  import streams general metadata (Y)
STREAMS_INSTANTIATION  import streams instantiation metadata (N)
VOLSIZE                number of bytes in file on each volume of a file on tape
 
The following keywords only apply to transportable tablespaces
TRANSPORT_TABLESPACE import transportable tablespace metadata (N)
TABLESPACES tablespaces to be transported into database
DATAFILES datafiles to be transported into database
TTS_OWNERS users that own data in the transportable tablespace set
 
Import terminated successfully without warnings.
[oracle@hercules ~]$
 

Parámetro

Defecto

Descripción

USERID

indefinido

el username/password del usuario que efectua el import.

BUFFER

dependiente del SO

El tamaño en bytes del buffer utilizado.

FILE

expdat.dmp

el nombre del archivo de exportación a importar.

SHOW

No

indica si se muestran los contenidos del archivo de exportación, sin importar ningún dato.

IGNORE

Yes

indica si ignorar los errores producidos al importar un objeto que ya existe en la BD.

GRANTS

Yes

indica si se importan también los derechos.

INDEXES

Yes

indica si se importan también los índices.

ROWS

Yes

indica si se importan también las filas de las tablas.

FULL

No

indica si se importan el archivo entero.

FROMUSER

Indefinido

una lista de los usuarios cuyos objetos se han exportado.

TOUSER

Indefinido

una lista de los usuarios a cuyo nombre se importan los objetos.

TABLES

indefinido

la lista de tablas a importar.

RECORDLENGTH

dependiente del SO

la longitud en bytes del registro del archivo.

INCTYPE

indefinido

el tipo de import incremental (SYSTEM o RESTORE).

COMMIT

No

indica si se efectua un commit después de importar cada fila. Por defecto, import efectua un commit después de cargar cada tabla.

PARFILE

indefinido

el archivo de parámetros.

Para importar un export incremental se puede efectuar la siguiente secuencia de pasos:

  1. Utilizar la copia más reciente del import para restaurar las definiciones del sistema:
 
$ imp userid=sys/passwd inctype=system full=Y file=export_filename
  1. Poner los segmentos de rollback online.
  2. Importar el archivo de exportación completa más reciente:
 
$ imp userid=sys/passwd inctype=restore full=Y file=filename
  1. Importar los archivos de exportación en modo acumulación desde la exportación completa más reciente, en orden cronológico:
 
$ imp userid=sys/passwd inctype=restore full=Y file=filename
  1. Importar los archivos de exportación en modo incremental desde la exportación completa o acumulativa más reciente, en orden cronológico:
 
$ imp userid=sys/passwd inctype=restore full=Y file=filename

 

3.5 Recuperación Física usando RMAN

 

Restoration and Datafile Media Recovery Using RMAN

RMAN automates the procedure for restoring files. When you issue the RESTORE command, RMAN uses a server session to restore the correct backups and copies. The RMAN repository is used to select the best available backup set or image copies to use in the restoration. By default, RMAN does not restore a file if the file is already in the correct place and its header contains the correct information. In releases before Oracle9i, the files were always restored.

When you issue the RMAN RECOVER command, RMAN applies changes from online redo log files and archived redo log files, or uses incremental backups to recover the restored files.

Using RMAN you can perform recovery at the following levels:

·   Database

·   Tablespace

·   Datafile

In complete recovery, all of the redo entries in the archived redo logs files and online redo log files are used to recover the database. The damaged files are restored from a backup and the log files are used to update the datafiles to the current point in time.

Por ejemplo

rman target /
RMAN> STARTUP MOUNT
RMAN> RESTORE DATABASE;
RMAN> RECOVER DATABASE;
RMAN> ALTER DATABASE OPEN;

In this example you use RMAN to restore and recover the whole database.

This example assumes that:

         A full backup taken using RMAN is available on disk.

         The current control files were not damaged and do not need to be restored.

         All datafiles are damaged or lost. 

Restoring Datafiles to a New Location

If you have experienced media failure such as the loss of a disk drive, you may need to restore the datafiles to a new location.

Example

1.            Connect to RMAN.

            rman target 

2.            Mount the database.

          RMAN> STARTUP MOUNT

3.            Use RMAN to restore the datafile to the new location and record the change in the control file.

          run{
          set newname for datafile 1 to '/<newdir>/system01.dbf';
          restore database;
          switch datafile all;
          recover database;
          alter database open; }

Using RMAN to Recover a Tablespace

If you have determined that you need to restore and recover the users tablespace, issue the RMAN commands as follows:

    run{
    sql "alter tablespace users offline immediate";
    restore tablespace users;
    recover tablespace users;
    sql "alter tablespace users online";
    }
 

Using RMAN to Relocate a Tablespace

If a datafile cannot be accessed because of disk failure, you need to restore it to a new location or switch to an existing image copy.

The same procedure is useful when you want to relocate the tablespace, because you are running short of disk space in one drive or you are reorganizing the database to improve performance.

Example: You notice that u03 has been corrupted and the database is still open. Occasionally users complain that they cannot access information in datafile number 3.

The following is the procedure to restore the datafiles to a new location:

1.            Check the location and size of the datafile on u03 , using the following command:

    SQL> SELECT file#, name, bytes FROM v$datafile;
    FILE#  NAME                               BYTES
    ----- ------------------------      ----------
       1 /ORADATA/u01/system01.dbf      120586240
       2 /ORADATA/u02/undotbs.dbf        31457280
       3 /ORADATA/u03/users01.dbf         5242880

               ...

               You determine that there is enough space on u04 for datafile 3.

2.            Make sure that the file (tablespace if necessary) is offline so that it can be restored successfully using the RESTORE command.

3.            Because the file was copied to a new location (using SET NEWNAME), the file must be made current by notifying the Oracle server of the new file location using the SWITCH command.

4.            Use the RECOVER command to start applying the combination of incremental backups, cumulative backups, archived redo log files and online redo logs to the restored file to synchronize the database.

5.            When recovery is finished, bring the datafile online. Notify users that the database is available for use, and that they should reenter any data that was not committed before system failure.

               The following command can be used:

    RUN{
    SQL "alter tablespace users offline immediate";
    SET NEWNAME FOR DATAFILE '/ORADATA/u03/users01.dbf' TO '/ORADATA/u04/users01.dbf'; #Specify where to restore the file
    RESTORE TABLESPACE users; #Restore the datafile
    SWITCH datafile 3;#Update the control file and recovery catalog
    RECOVER TABLESPACE users; #Recover the tablespace
    SQL "alter tablespace tbs1 online";}

Using RMAN Incomplete Recovery

Perform an incomplete database recovery by  using UNTIL TIME

Perform an incomplete database recovery by using UNTIL SEQUENCE

Pasos

 

1.            Mount the database.

2.            Allocate multiple channels for parallelization.

3.            Restore all datafiles.

4.            Recover the database by using UNTIL TIME, UNTIL SEQUENCE, or UNTIL SCN.

5.            Open the database by using RESETLOGS.

6.            Perform a whole database backup.

Ejemplo de Recuperacion Incompleta usando UNTIL TIME

RMAN> RUN {
   2> ALLOCATE CHANNEL c1 TYPE DISK;
   3> ALLOCATE CHANNEL c2 TYPE DISK;
   4> SET UNTIL TIME = ‘2001-12-09:11:44:00';
   5> RESTORE DATABASE;
   6> RECOVER DATABASE;
   7> ALTER DATABASE OPEN RESETLOGS; }

Ejemplo de Recuperación Incompleta usando UNTIL SEQUENCE

RMAN Incomplete Recovery UNTIL SEQUENCE: Example
The UNTIL SEQUENCE clause specifies a redo log sequence number and thread as an upper limit. RMAN selects only files that can be used to recover up to but not including the specified log sequence number. This example assumes that log sequence 120 was lost due to a disk crash and the database needs to be recovered using the available archived redo logs. 
 
 
 
RMAN> RUN {
   2> SET UNTIL SEQUENCE 120 THREAD 1; 
   3> ALTER DATABASE MOUNT;  
   4> RESTORE DATABASE;  
   5> RECOVER DATABASE; # recovers through log 119
   6> ALTER DATABASE OPEN RESESTLOGS;
   7> }