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:
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 internalNota: Si sucede esto con un tablespace de datos, recrearlo con todos sus objetos. Con uno de índices: volver a crear los índices.
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 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