CASOS DE BACKUP Y RECUPERACIÓN


CASO 1: MODO NOARCHIVELOG Y RECUPERACIÓN
CASO 2: BORRADO DE DATAFILES SIN DATOS EN NOARCHIVELOG
CASO 3: PÉRDIDA DE UN DATAFILE DE SYSTEM EN ARCHIVELOG
CASO 4: PÉRDIDA DE UN DATAFILE QUE NO ES DEL SYSTEM Y SIN SEGMENTOS DE ROLLBACK, EN ARCHIVELOG
CASO 5: PÉRDIDA DE UN DATAFILE QUE NO ES DEL SYSTEM PERO CONTIENE SEGMENTOS DE ROLLBACK ACTIVOS EN ARCHIVELOG CASO 6: PÉRDIDA DE UN ARCHIVO DE LOG ONLINE NO ARCHIVADO
CASO 7: FALLO DE LA BD DURANTE BACKUPS EN CALIENTE
CASO 8: RECUPERACIÓN CON UN CONTROLFILE DE UN BACKUP
 

MODO ARCHIVELOG
Se puede crear directamente la BD en modo Archivelog. Si se ha creado en NoArchivelog la forma de activar este modo con archivado automático es cambiar los siguientes parámetros del init.ora (también se puede hacer con alter system):

Log_archive_start = true 
Log_archive_dest = (sin comillas ni /    al final) 
Log_archive_format = “%t_%s.arc” (por ejemplo)
Esto activa el archivado automático y fija el directorio y formato de los nombres de los ficheros archived logs. Se puede usar el comando: archive log list para comprobarlo. Aún falta activar el modo Archivelog, para ello usar el comando: Alter database archivelog; (teniendo la BD en modo mount). Volver a comprobarlo con archive log list. Para forzar el archivado de todos los redo logs online que aún no hayan sido archivados hasta el momento de la activación, usar el comando: Archive log all
 

CASO 1: MODO NOARCHIVELOG Y RECUPERACIÓN
Sólo se recupera al momento del backup.

Backup:
Hacer backup de todos los datafiles, redo logs online, init.ora y controlfiles.

Recuperación:

  1. Hacer backup de la bd actual por si el backup que vamos a aplicar está mal.
  2. Borrar todos los datafiles, controlfiles, redo logs online e init.ora actuales.
  3. Restablecer todos los ficheros del backup.
  4. Arrancar la BD.
Nota 1: Si el datafile no contiene ningún dato, por ejemplo es del tablespace temporary, se puede arrancar la BD poniendo offline el datafile y reconstruyendo posteriormente el tablespace: alter database datafile ‘....’ offline drop; (es el siguiente caso de estudio).
 
 

CASO 2: BORRADO DE DATAFILES SIN DATOS EN NOARCHIVELOG
En este caso se puede salvar el problema sin pérdida de datos.
Ejemplo: Se pierde un datafile del tablespace temporal.

Solución: Borrar el datafile con:

alter database datafile ‘....’ offline drop;
después de abrir de nuevo la BD el tablespace y el resto de sus ficheros están online por lo que pueden seguir siendo utilizados, pero el datafile eliminado está offline y Oracle recomienda volver a crear el tablespace.

Prueba desde el svrmgrl:

Connect internal
Startup mount
Archive log list (para ver si está en archivelog)
Alter database noarchivelog;
Alter database open;
Alter system switch logfile; (checkpoint)
Alter system switch logfile;
Shutdown abort (fallo)
Host del tmp1orcl.ora (borro datafile del tablespace temporal)
Startup mount Alter database open; (error, no encuentra el fichero)
Alter database datafile ‘...../tmp1orcl.ora’ offline; (error, no está en archivelog)
Alter database datafile ‘...../tmp1orcl.ora’ offline drop;
Alter database open;
Drop tablespace temp including contents;
Create tablespace temp ....
Nota: Si sucede esto con un tablespace de datos, recrearlo con todos sus objetos. Con uno de índices: volver a crear los índices.

Nota 2: Oracle recomienda no hacer backup de los redo logs online ni en backups en frío ni en caliente, ya que siempre se puede arrancar la BD con la opción resetlogs para crearlos nuevos aunque se pierdan las modificaciones que estaban en los redo logs online.
 

CASO 3: PÉRDIDA DE UN DATAFILE DE SYSTEM EN ARCHIVELOG
Es posible poner un datafile offline y luego arrancar la BD, salvo en el caso de un datafile del system. Hace falta recuperar el/los ficheros dañados de un backup online anterior y realizar la recuperación sobre ellos. Antes de que se pueda abrir la BD, es necesario que esté montada y después se tiene que ejecutar el comando recover database.
 

CASO 4: PÉRDIDA DE UN DATAFILE QUE NO ES DEL SYSTEM Y SIN SEGMENTOS DE ROLLBACK, EN ARCHIVELOG
Existen 3 opciones:

1.- recover database: con la BD montada pero no abierta, por tanto es una recuperación offline.
2.- recover datafile: con la BD montada o abierta y el datafile offline, por tanto es una recuperación online.
3.- recover tablespace: con la BD abierta y el tablespace offline, por tanto es una recuperación online.

Prueba desde el svrmgrl:

Connect internal
Create table caso4 (c1 number) tablespace users;
Insert into caso4 values (1); Insert into caso4 values (2); Commit;
Alter system switch logfile;
Shutdown abort
Host rm usr1orcl.ora (borrar datafile donde se encuentra la tabla caso4)
Host cp \backup\usr1orcl.ora (traer copia antigua de un backup online u offline)
Startup (error: Oracle reconoce que el datafile procede de un backup y solicita una recuperación)

Métodos de Recuperación:

1.- Con Recover database:
startup mount recover database (sugiere los redo logs archivados a aplicar)
alter database open;
select * from caso4; (me devuelve 1 y 2)

2.- Con Recover datafile:
startup mount alter database open; (error)
alter database datafile ‘..../usr1orcl.ora’ offline;
alter database open; (funciona)
recover datafile ‘..../usr1orcl.ora’
select * from caso4; (error porque el datafile está offline, inaccesible)
alter database datafile ‘..../usr1orcl.ora’ online;
select * from caso4; (devuelve 1 y 2)

3.- Con Recover tablespace:
startup mount
alter database open; (error)
alter database datafile ‘..../usr1orcl.ora’ offline; (para cada uno de los ficheros que falle)
alter database open; (funciona)
alter tablespace users offline;
recover tablespace users
select * from caso4; (error: tablespace y datafiles offline)
alter tablespace users online; select * from caso4; (devuelve 1 y 2)
 
 

CASO 5: PÉRDIDA DE UN DATAFILE QUE NO ES DEL SYSTEM PERO CONTIENE SEGMENTOS DE ROLLBACK ACTIVOS EN ARCHIVELOG
Ejemplo:
Fallan todos los datafiles que contienen los segmentos de rollback de la BD. Se pretende hacer una recuperación online: después de poner offline todos los datafiles y abrir la BD, se lanza una consulta de una tabla sobre la que existía una transacción activa antes del fallo, y da el siguiente error: el fichero n no puede ser leido en este momento (n es el número de datafile donde estaba el segmento de rollback asignado a dicha transacción).

Esto es porque mientras se realiza la recuperación de los datafiles no se puede acceder a ninguna fila implicada en transacciones activas que apunten a segmentos de rollback.

Hasta que se recuperen los datafiles, hay que crear unos cuantos segmentos de rollback adicionales que permitan el procesamiento de las nuevas transacciones.

Prueba desde el svrmgrl:
Connect internal
Create table caso5 (c1 number) tablespace users;
Set transaction use rollback segment rb1;
Insert into caso5 values (5);
Shutdown abort
Host rm rbs1orcl.ora (pérdida de los datafiles de rollback)
Host cp /backup/rbs01orcl.ora (traer copia de los ficheros de un backup online u offline)

Ahora comentar (#) el parámetro rollback_segments del init.ora, si no durante la apertura de la BD intentará poner online los segmentos de rollback privados indicados en este parámetro y fallará ya que no están accesibles.

Startup mount
Alter database datafile ‘.../rbs1orcl.ora’ offline;
Alter database open;
Select * from caso5; (error: el datafile no está online y el s.r. necesita recuperación)
Select segment_name,status from dba_rollback_segs; (needs recovery)

Crear segmentos de rollback para ser usados temporalmente hasta finalizar la recuperación (después los borraremos):
Create rollback segment rbtemp1 tablespace system;
Create rollback segment rbtemp2 tablespace system;
Alter rollback segment rbtemp1 online;
Alter rollback segment rbtemp2 online;
Select * from caso5; (sigue dando el mismo error)
Recover tablespace rbs;
Select * from caso5; (error: el datafile está offline)
Alter tablespace rbs online;
Select * from caso5; (bien, la transacción se ha deshecho y no aparecen filas)
Select segment_name,status from dba_rollback_segs; (needs recovery)

Poner esos segmentos online de nuevo y los temporales que hemos creado ponerlos offline y borrarlos.
 
 

CASO 6: PÉRDIDA DE UN ARCHIVO DE LOG ONLINE NO ARCHIVADO
Ejemplo:
Se tiene una BD en Archivelog con 3 grupos de redo log no multiplexados (1 miembro cada uno). Se hacen backups online 2 veces por semana y una export completa de la BD 1 vez a la semana.
Debido a un corte de luz se pierden todos los redo logs online, los datafiles y controlfiles están intactos.

Solución:
Aunque los datafiles están bien después del fallo, no se pueden usar porque no se puede hacer recuperación automática de instancia ya que se han perdido los redo logs online.

Si se intenta forzar la apertura de la BD puede haber inconsistencias, hay que hacer una recuperación de dispositivo. Para ello se restablecerán todos los datafiles de un backup completo online u offline y se aplicarán los cambios almacenados en los archived redo logs hasta el último redo log archivado disponible. Al tratarse de una recuperación incompleta, no se puede hacer recuperación por datafiles o tablespaces, se debe usar recover database.

Prueba con el svrmgrl:
Shutdown abort (caída de la BD)
Host rm *.log (error o pérdida de redo logs online)
Host cp *.dbf (restablece backup de datafiles)
Startup mount
Recover database until cancel; (cancelar en el último archive log)
Alter database open resetlogs; (resetea los logs si existen, si no existen los crea)

Nota: Se podrían haber usado recover database until time ó until change si se hubiera querido rehacer hasta un punto en el tiempo o hasta un SCN determinado.
 
 

CASO 7: FALLO DE LA BD DURANTE BACKUPS EN CALIENTE
Ejemplo:

Se estropea la máquina mientras se está haciendo un backup online. Cuando se intenta arrancar de nuevo la BD pide una recuperación de dispositivo sugiriendo el número de secuencia 2300 y el redo log online actual tiene secuencia 2335, lo que supone aplicar unos 35 ficheros archivados antes de que se pueda abrir la BD.

Hasta la versión 7.2 de Oracle había que hacer este tipo de recuperación, pero a partir de esa versión se puede finalizar el backup de los datafiles que están en modo backup online mediante el comando alter database datafile ‘...’ end backup.
 

Prueba desde el svrmgrl:
Connect internal
Startup
Archive log list (oldest=53,next y current=55)
Alter tablespace prueba begin backup;
Host cp prueba01orcl.ora /backup (backup online del tablespace)
Create table caso7(c1 number) tablespace prueba;
Insert into caso7 values (7);
Commit;
Alter system switch logfile;
Shutdown abort (error BD)

Ahora se van a hacer 2 pruebas, la 1ª trata de abrir la BD con el datafile actual, la 2ª trata de reemplazarlo por su backup intentando engañar a Oracle para que crea que es el fichero actual:

Prueba 1: utilización del datafile actual:
Startup mount
Alter database open;
Alter database datafile ‘prueba01orcl.ora’ end backup;
Alter database open;
Select * from caso7; -> 7

Prueba 2: utilización del backup del datafile:
Host rm prueba01orcl.ora
Host cp /backup/prueba01orcl.ora ./prueba01orcl.ora
Startup mount
Alter database open; (Oracle indica que el datafile es de un backup por lo que es necesaria recuperación)
Alter database datafile ‘prueba01orcl.ora’ end backup; Oracle detecta que es de un backup recover database -> recupera el datafile
alter database open;
Select * from caso7; -> 7

Nota: Se puede consultar la v$backup para saber qué datafiles están en modo backup:

Select file#, status from v$backup;

los que estén active están en modo backup.
 

CASO 8: RECUPERACIÓN CON UN CONTROLFILE DE UN BACKUP
Hacer una recuperación con un backup de un fichero de control puede ser difícil, siempre que sea posible intentar la recuperación con el controlfile actual, si no se puede crear un nuevo controlfile, la utilización del backup del controlfile debe ser la última opción a utilizar ya que es necesario abrir la BD con resetlogs.

Ejemplo:
Se tiene una BD de la que se hacen backups en frío copiando datafiles, redo logs online y controlfiles. Se borra accidentamente el controlfile y se restaura su copia, al intentar arrancar de nuevo la BD Oracle indica que se trata de un fichero antiguo.

Solución:
Hay 2 opciones: la 1ª es crear un controlfile con create controlfile (ya que los datafiles y redo logs están bien), realizar la recuperación si fuera necesario y arrancar la BD.

La 2ª es utilizar el backup del controlfile, con lo que se deberá realizar una recuperación de dispositivo, además Oracle forzará a usar la opción using backup controlfile, una vez realizada la recuperación se debe arrancar la BD con la opción resetlogs y hacer un backup completo (mejor la 1ª solución).

Prueba con el svrmgrl:
Connect internal
Startup open
Select name, status, enabled from v$datafile;
Create table caso8 (c1 number) tablespace users_data;
Insert into caso8 values (8);
Commit;
Alter system switch logfile;
Alter system switch logfile;
Alter system switch logfile;
Shutdown abort
Host cp /backup/control*.ctl ./ (traigo el controlfile del backup)
Startup mount
Alter database open; me avisa de que el controlfile es antiguo
Recover database -> sintaxis incorrecta
Recover database using backup controlfile;

1º poner offline los datafiles de los tablespaces de solo lectura:
Alter database datafile ‘....’ offline;
Recover database using backup controlfile;
Alter database open; error->resetlogs
Alter database open noresetlogs; error->resetlogs
Alter database open resetlogs;
Archive log list
Select name, status, enabled from v$datafile;

Poner el tablespace de sólo lectura online con sus datafiles:
Alter tablespace test online;
Select * from caso8; ->8