7 Min. de lectura

Recuperación y Restauración en modo NO ARCHIVELOG

En la mayoría de las páginas de documentación de Oracle, podemos encontrar siempre el consejo de tener nuestra base de datos en modo archivelog, si usted o su empresa, son aventurados a las expriencias extremas, entonces, seguramente este escenario es el que posiblemente experimentará en alguna ocasión.

En este escenario, presentare, que es lo que sucede cuando pierde uno o más archivos de datos de importancia critica o no critica en una base de datos que no se encuentra en modo ARCHIVELOG.

Para esta recuperación es importante y critico tener al menos un backup full de la base de datos o nivel 0 y preferentemente con incrementales, de lo contrario será imposible realizar recuperación alguna, al menos por este método.

¿ Que tanto se ha perdido?

Podría asegurarle que todo, hasta el último backup, y esto es tan sencillo de explicar como decir, que sin la implementación de ARCHIVELOG, no es posible que la base de datos aplique nuevamente todas las transacciones desde el último backup, hasta el punto en el tiempo de la falla.

En el milagroso caso que la falla se haya presentado instantes después de su ultimo backup, en este escenario podría recuperarse hasta el instante de la falla, o si la falla se presento cuando aún no se ha dado la vuelta completa a los grupos de REDOLOG, por lo cual ninguno ha sido sobre escrito, en estas únicas dos circunstancias posiblemente podría recuperase hasta el punto en que fallo su base de datos.

Sea realista del escenario y las consecuencias . . .

Antes de comenzar con la restauración, me gustaría ser completamente sincero con usted y hacerle saber el estado final de su base de datos y las consecuencias que conllevara esta operación:

1.-Tiempo de recuperación demorado: El gestor tendrá que recuperar todos los archivos de datos incluyendo los controlfiles, por lo que dependiendo del tamaño de su base, del sistema de archivos y de la tasa de I/O, el tiempo de recuperación será demorado.

2 .Bienvenido a la encarnación: Perderá todas las transacciones echas desde el punto de la falla hasta el momento de la recuperación, así que no será posible, recuperar información anterior a la falla y el SCN será reiniciado.

3.- Imposibilidad de mineria: Será imposible utilizar LogMiner como método de sincronizanación o recuperación de su base de datos, posterior al fallo.

4.-Baja de los servicios: La base de datos no podrá encontrarse activa hasta que se haya realizado la recuperación por completo.

5.-Reingrese todos sus cambios: Deberá re hacer todos los cambios que se hayan perdido de forma manual, para poder llevar su base de datos a un estado similar al de antes de la pérdida.

Caso práctico

En el siguiente escenario se muestra la recuperación de una base de datos en arquitectura multitenant, release 1 v2, de la cual se borrara un archivo de datos de forma intencionada y se realizará la recuperación completa de la base de datos en moodo NORARCHIVELOG.

Pre requisitos :

Tener al menos un backup nivel 0 o full de la base de datos, de preferencia tener incrementales diferenciales nivel 1.

En marcha:

Se creará un tablespace en un medio extraible el cual será desconectado para simular la perdida del archivo,.

Connected.

SQL> create tablespace PERDIDO DATAFILE 'M:\ARCHIVO_DESCONECTADO'SIZE 1M;

Tablespace created.

SQL> SELECT TABLESPACE_NAME FROM DBA_TABLESPACES;

TABLESPACE_NAME ------------------------------ SYSTEM SYSAUX UNDOTBS1 TEMP USERS PERDIDO

6 rows selected.

Ahora desconectaré el medio extraible para causar la falla, para mostrar la falla se intentará crear una tabla en el tablespace del que ya se ha perdido su archivo.

SQL> CREATE TABLE EJEMPLO_PERDIDA( 2 NOMBRE VARCHAR2(7)) TABLESPACE PERDIDO;

Table created.

La creación de la tabla ha sido posible debido a que la creación de segmentos es diferida, por lo que el datafile ausente aún no ha sido identificado, sin embargo al intentar borrarla, se presentará el problema.

DROP TABLE EJEMPLO_PERDIDA;

DROP TABLE EJEMPLO_PERDIDA

ERROR at line 1:

ORA-03113: fin de archivo en el canal de comunicaci¾n

Identificador de Proceso: 10132

Identificador de Sesi¾n: 3 N·mero de Serie: 8286

Y la instancia por seguridad, se ha terminado de forma abrupta, revisando el alert log, entre los distintos errores nos encontraremos:

ORA-63999: el archivo de datos ha sufrido un fallo del medio f├¡sico ORA-01114: error de E/S al escribir el bloque en el archivo 174 (bloque n├║mero 2) ORA-01110: archivo de datos 174: 'M:\ARCHIVO_DESCONECTADO' ORA-27070: fallo de la lectura/escritura as├¡ncrona OSD-04016: Error queuing an asynchronous I/O request. O/S-Error: (OS 1006) El volumen para un archivo ha sido alterado externamente, por lo que el archivo abierto ya no es vßlido. USER (ospid: 11288): terminating the instance due to error 63999 System state dump requested by (instance=1, osid=11288 (DBW0)), summary=[abnormal instance termination].

Si intentamos, iniciarla nuevamente, no nos permitirá la apertura de la instancia, por lo que es momento de poner manos a la obra.

1.- Forzar la apertura de la instancia "STARTUP FORCE NOMOUNT;" :

rman target "'/ as sysbackup'"

Recovery Manager: Release 12.1.0.2.0 - Production on MiÚ Abr 11 20:40:01 2018

connected to target database (not started)

RMAN> STARTUP FORCE NOMOUNT;

Oracle instance started

Total System Global Area 2415919104 bytes

Fixed Size 3855608 bytes Variable Size 671091464 bytes Database Buffers 1736441856 bytes Redo Buffers 4530176 bytes

2.- Realizar la recuperación del/los controlfile "RESTORE CONTROLFILE FROM AUTOBACKUP":

RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP;

Starting restore at 11/04/18 using channel ORA_DISK_1

recovery area destination: D:\app\margueta\fast_recovery_area database name (or database unique name) used for search: CSIIV2 channel ORA_DISK_1: AUTOBACKUP D:\APP\MARGUETA\FAST_RECOVERY_AREA\CSIIV2\AUTOBACKUP\2018_04_11\O1_MF_S_973194546_FDXDLCG1_.BKP found in the recovery area AUTOBACKUP search with format "%F" not attempted because DBID was not set channel ORA_DISK_1: restoring control file from AUTOBACKUP D:\APP\MARGUETA\FAST_RECOVERY_AREA\CSIIV2\AUTOBACKUP\2018_04_11\O1_MF_S_973194546_FDXDLCG1_.BKP

channel ORA_DISK_1: control file restore from AUTOBACKUP complete

output file name=D:\APP\MARGUETA\ORADATA\CSIIV2\CONTROL01.CTL output file name=D:\APP\MARGUETA\FAST_RECOVERY_AREA\CSIIV2\CONTROL02.CTL

Finished restore at 11/04/18

3.- Montar la base de datos con los nuevos controlfiles "ALTER DATABASE MOUINT":

RMAN> ALTER DATABASE MOUNT;

Statement processed released channel: ORA_DISK_1

4.- Restaurar todos los archivos de datos "RESTORE DATABASE":

RMAN> RESTORE DATABASE;

Starting restore at 11/04/18 Starting implicit crosscheck backup at 11/04/18 allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=122 device type=DISK Crosschecked 4 objects Finished implicit crosscheck backup at 11/04/18

List of Cataloged Files ======================= File Name: D:\APP\MARGUETA\FAST_RECOVERY_AREA\CSIIV2\AUTOBACKUP\2018_04_11\O1_MF_S_973194546_FDXDLCG1_.BKP

using channel ORA_DISK_1

.channel ORA_DISK_1: restored backup piece 1channel ORA_DISK_1: restore complete, elapsed time: 00:00:45

failover to previous backupFinished restore at 11/04/18

5.- Realizar la recuperación de los archivos restaurados, es importante utilizar la opción NOREDO para indicar que no se utilicen los REDOLOGS actuales para la recuperación, de lo contrario, la recuperación será errónea "RECOVER DATABASE NOREDO":

RMAN> RECOVER DATABASE NOREDO;

Starting recover at 11/04/18 using channel ORA_DISK_1

Finished recover at 11/04/18

6.- Encarnar la base de datos, o en otras palabras, abrir la base de datos reiniciando el SCN "ALTER DATABASE OPEN RESETLOGS":

RMAN> ALTER DATABASE OPEN RESETLOGS;

Statement processed.

Y si revisamos el registro del log de alertas:

alter database open RESETLOGS RESETLOGS after complete recovery through change 12603522069 Clearing online redo logfile 1 D:\APP\MARGUETA\ORADATA\CSIIV2\REDO01.LOG Clearing online log 1 of thread 1 sequence number 1144 Clearing online redo logfile 1 complete Clearing online redo logfile 2 D:\APP\MARGUETA\ORADATA\CSIIV2\REDO02.LOG Clearing online log 2 of thread 1 sequence number 1145 2018-04-12 10:28:07.362000 -05:00 Clearing online redo logfile 2 complete Clearing online redo logfile 3 D:\APP\MARGUETA\ORADATA\CSIIV2\REDO03.LOG Clearing online log 3 of thread 1 sequence number 1146 Clearing online redo logfile 3 complete Resetting resetlogs activation ID 1541231951 (0x5bdd554f)

La base de datos se ha iniciado correctamente, pero se ha perdido el registro del tablespace que se creo posterior al backup:

SQL> SELECT TABLESPACE_NAME FROM DBA_TABLESPACES;

TABLESPACE_NAME ------------------------------ SYSTEM SYSAUX UNDOTBS1 TEMP USERS

5 rows selected.

La misma situación sucederia pero a nivel de PDB, el siguiente ejemplo pierde intencionalmente una PDB creada posterior a un respaldo.

Pre requisitos :

Tener al menos un backup nivel 0 o full de la base de datos, de preferencia tener incrementales diferenciales nivel 1.

1.- Creamos la PDB que ya no podrá ser recuperada posterior al fallo.

SQL> create pluggable database PDB_LOST ADMIN USER PDBADMIN IDENTIFIED BY "12345";

Pluggable database created.

SQL> alter pluggable database PDB_LOST open;

Pluggable database altered.

SQL> show pdbs;

CON_ID CON_NAME OPEN MODE RESTRICTED ---------- ------------------------------ ---------- ---------- 2 PDB$SEED READ ONLY NO 3 IPNTEST1 MOUNTED 4 IPNTEST2 MOUNTED 5 PDB_LOST READ WRITE NO

.2.- Ahora causaremos la falla bajando la instancia y borrando cualquier datafile, para este caso será el diccionario del CDB, el error mapeado es el siguiente:

Total System Global Area 5133828096 bytes Fixed Size 3842712 bytes Variable Size 1174408552 bytes Database Buffers 3942645760 bytes Redo Buffers 12931072 bytes Database mounted. ORA-01157: no se puede identificar/bloquear el archivo de datos 1 - consulte el archivo de rastreo del DBWR ORA-01110: archivo de datos 1: 'D:\APP\ORACLE\ORADATA\IPNCDB\SYSTEM01.DBF'

3.- Seguiremos los mismos pasos de la recuperación del ejemplo anterior, ahora serán todas en un solo bloque RUN:

RMAN > run{

SHUTDOWN ABORT; (OPCIONAL, SOLO SI LA BD NO ESTA ABAJO)

STARTUP FORCE NOMOUNT;

RESTORE CONTROLFILE FROM AUTOBACKUP;

ALTER DATABASE MOUNT;

RESTORE DATABASE;

RECOVER DATABASE NOREDO;

ALTER DATABASE OPEN RESETLOGS;

}

Oracle instance started

Total System Global Area 5133828096 bytes

Fixed Size 3842712 bytes Variable Size 1174408552 bytes Database Buffers 3942645760 bytes Redo Buffers 12931072 bytes

Starting restore at 12/04/18

allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=198 device type=DISK

recovery area destination: D:\app\oracle\fast_recovery_area database name (or database unique name) used for search: IPNCDB

channel ORA_DISK_1: AUTOBACKUP D:\APP\ORACLE\FAST_RECOVERY_AREA\IPNCDB\AUTOBACKUP\2018_04_12\O1_MF_S_973278121_FDZX8ROC_.BKP found in the recovery area channel ORA_DISK_1: looking for AUTOBACKUP on day: 20180412 channel ORA_DISK_1: restoring control file from AUTOBACKUP D:\APP\ORACLE\FAST_RECOVERY_AREA\IPNCDB\AUTOBACKUP\2018_04_12\O1_MF_S_973278121_FDZX8ROC_.BKP channel ORA_DISK_1: control file restore from AUTOBACKUP complete output file name=D:\APP\ORACLE\ORADATA\IPNCDB\CONTROL01.CTL output file name=D:\APP\ORACLE\FAST_RECOVERY_AREA\IPNCDB\CONTROL02.CTL

Finished restore at 12/04/18

Statement processed released channel: ORA_DISK_1

Starting restore at 12/04/18 Starting implicit crosscheck backup at 12/04/18 allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=198 device type=DISK Crosschecked 4 objects Finished implicit crosscheck backup at 12/04/18

Starting implicit crosscheck copy at 12/04/18 using channel ORA_DISK_1 Finished implicit crosscheck copy at 12/04/18

searching for all files in the recovery area cataloging files... cataloging done

List of Cataloged Files ======================= File Name: D:\APP\ORACLE\FAST_RECOVERY_AREA\IPNCDB\AUTOBACKUP\2018_04_12\O1_MF_S_973278121_FDZX8ROC_.BKP

using channel ORA_DISK_1

skipping datafile 2; already restored to file D:\APP\ORACLE\ORADATA\IPNCDB\PDBSEED\SYSTEM01.DBF skipping datafile 4; already restored to file D:\APP\ORACLE\ORADATA\IPNCDB\PDBSEED\SYSAUX01.DBF skipping datafile 7; already restored to file D:\APP\ORACLE\ORADATA\IPNCDB\IPNTEST1\SYSTEM01.DBF skipping datafile 8; already restored to file D:\APP\ORACLE\ORADATA\IPNCDB\IPNTEST1\SYSAUX01.DBF skipping datafile 9; already restored to file D:\APP\ORACLE\ORADATA\IPNCDB\IPNTEST1\IPNTEST1_USERS01.DBF skipping datafile 10; already restored to file D:\APP\ORACLE\ORADATA\IPNCDB\IPNTEST2\SYSTEM01.DBF skipping datafile 11; already restored to file D:\APP\ORACLE\ORADATA\IPNCDB\IPNTEST2\SYSAUX01.DBF skipping datafile 12; already restored to file D:\APP\ORACLE\ORADATA\IPNCDB\IPNTEST2\IPNTEST2_USERS01.DBF channel ORA_DISK_1: starting datafile backup set restore channel ORA_DISK_1: specifying datafile(s) to restore from backup set channel ORA_DISK_1: restoring datafile 00001 to D:\APP\ORACLE\ORADATA\IPNCDB\SYSTEM01.DBF channel ORA_DISK_1: restoring datafile 00003 to D:\APP\ORACLE\ORADATA\IPNCDB\SYSAUX01.DBF channel ORA_DISK_1: restoring datafile 00005 to D:\APP\ORACLE\ORADATA\IPNCDB\UNDOTBS01.DBF channel ORA_DISK_1: restoring datafile 00006 to D:\APP\ORACLE\ORADATA\IPNCDB\USERS01.DBF channel ORA_DISK_1: reading from backup piece D:\APP\ORACLE\FAST_RECOVERY_AREA\IPNCDB\BACKUPSET\2018_04_12\O1_MF_NNND0_TAG20180412T190704_FDZX58MC_.BKP channel ORA_DISK_1: piece handle=D:\APP\ORACLE\FAST_RECOVERY_AREA\IPNCDB\BACKUPSET\2018_04_12\O1_MF_NNND0_TAG20180412T190704_FDZX58MC_.BKP tag=TAG20180412T190704 channel ORA_DISK_1: restored backup piece 1 channel ORA_DISK_1: restore complete, elapsed time: 00:00:35

Finished restore at 12/04/18

Starting recover at 12/04/18 using channel ORA_DISK_1

Finished recover at 12/04/18

Statement processed

4.- Posterior a esto, consultamos nuevamente las PDBs en el CDB, y encontraremos que ya no contamos con la PDB creada despues del backup.

SQL> show pdbs;

CON_ID CON_NAME OPEN MODE RESTRICTED ---------- ------------------------------ ---------- ---------- 2 PDB$SEED READ ONLY NO 3 IPNTEST1 MOUNTED 4 IPNTEST2 MOUNTED

Después del desastre

Dependiendo de la cantidad de perdidas y las implicaciones que estas conlleven, será su reflexión, pero piense seriamente en utilizar el ARCHIVELOG para las recuperaciones de bases de datos, de lo contrario la vida de la instancia estará en constante peligro.

También le recomiendo hacer un respaldo completo de la instancia posterior a la recuperación, si no es posible habilitar el uso de ARCHIVELOG, entonces realice respaldos constantes de la base de datos, principalmente después de cada cambio que considere importante.