APLICANDO ARCHIVES EN UN FULL RECOVERY

El respaldo y recuperación de bases de datos Oracle es uno de los puntos más criticos dentro de la labor de un DBA.

Este ejercicio tiene como objetivo realizar un respaldo completo en frio  o 'cold full backup' .  Posterior a la realización del respaldo se van a generar dos tablas 'TEST1' y 'TEST2'  las cuales deberán ser respaldadas en automático por los 'ARCHIVE LOGS'.

Se va a realizar un 'full recovery', posteriormente se aplicaran  los  'ARCHIVE LOGS'. Oracle recomienda realizar los respaldos por medio de la herramienta 'RECOVER MANAGER' o 'RMAN'.   Este ejercicio se va a realizar por medio de copias de 'datafiles', 'redo logs' y 'control files' a nivel sistema operatívo.

El primer paso es  verificar que la instancia se encuentre en modo 'ARCHIVE LOG'

SQL> archive log list
Database log mode                      Archive Mode
Automatic archival                      Enabled
Archive destination                      USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence          6
Next log sequence to archive      8
Current log sequence                  8

Verificamos el nombre de la instancia a respaldar, en este caso 'test'

SQL> SELECT   instance_name FROM v$instance;

           INSTANCE_NAME
           ----------------
            test

Generamos un listado de todos los 'datafiles' a respaldar y que componen la instancia 'test'

SQL> SELECT NAME from v$datafile order by name;

NAME
--------------------------------------------------------------------------------
C:\APP12\BD\ORADATA\TEST\DATAFILE\O1_MF_SYSAUX_9OX3J7DO_.DBF
C:\APP12\BD\ORADATA\TEST\DATAFILE\O1_MF_SYSTEM_9OX3LLWQ_.DBF
C:\APP12\BD\ORADATA\TEST\DATAFILE\O1_MF_UNDOTBS1_9OX3OB5M_.DBF
C:\APP12\BD\ORADATA\TEST\DATAFILE\O1_MF_USERS_9OX3O8J6_.DBF
C:\APP12\BD\ORADATA\TEST\DATAFILE\TBS_01.DBF
C:\APP12\BD\ORADATA\TEST\DATAFILE\TBS_02.DBF

6 rows selected.

Se genera un listado con los 'REDO LOGS' de la instancia, donde se tienen 3 grupos de 'redo logs' con dos miembros por grupo

SQL> SELECT group#, status, substr(member,1,100) FROM  v$logfile order by 1;

    GROUP# STATUS  SUBSTR(MEMBER,1,100)
---------- ------- ----------------------------------------------------------------------------------------------------
         1         C:\APP12\BD\ORADATA\TEST\ONLINELOG\O1_MF_1_9OX3ST80_.LOG
         1         C:\APP12\BD\FAST_RECOVERY_AREA\TEST\ONLINELOG\O1_MF_1_9OX3SVGR_.LOG
         2         C:\APP12\BD\ORADATA\TEST\ONLINELOG\O1_MF_2_9OX3SXC6_.LOG
         2         C:\APP12\BD\FAST_RECOVERY_AREA\TEST\ONLINELOG\O1_MF_2_9OX3SYL4_.LOG
         3         C:\APP12\BD\ORADATA\TEST\ONLINELOG\O1_MF_3_9OX3T03B_.LOG
         3         C:\APP12\BD\FAST_RECOVERY_AREA\TEST\ONLINELOG\O1_MF_3_9OX3T4SM_.LOG

6 rows selected.

Se genera un listado con los 'CONTROL FILES' de la instancia. Tenemos dos controlfile 'multiplexados' para fines de disponibilidad

SQL> SELECT substr(NAME, 1,80) FROM  v$controlfile;

SUBSTR(NAME,1,80)
--------------------------------------------------------------------------------
C:\APP12\BD\ORADATA\TEST\CONTROLFILE\O1_MF_9OX3SPDX_.CTL
C:\APP12\BD\FAST_RECOVERY_AREA\TEST\CONTROLFILE\O1_MF_9OX3SPQK_.CTL

Como se va realizar un respaldo en frío o 'COLD BACKUP' se da de baja la base de datos para que el respaldo sea consistente.

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.

Finalizado el  shutdown respaldamos los 'datafiles'

C:\>COPY  C:\APP12\BD\ORADATA\TEST\DATAFILE\O1_MF_SYSAUX_9OX3J7DO_.DBF C:\BACKUP_TEST
        1 file(s) copied.

C:\>COPY  C:\APP12\BD\ORADATA\TEST\DATAFILE\O1_MF_SYSTEM_9OX3LLWQ_.DBF C:\BACKUP_TEST
        1 file(s) copied.

C:\>COPY C:\APP12\BD\ORADATA\TEST\DATAFILE\O1_MF_UNDOTBS1_9OX3OB5M_.DB C:\BACKUP_TEST
        1 file(s) copied.

C:\>COPY  C:\APP12\BD\ORADATA\TEST\DATAFILE\O1_MF_USERS_9OX3O8J6_.DBF C:\BACKUP_TEST
        1 file(s) copied.

C:\>COPY  C:\APP12\BD\ORADATA\TEST\DATAFILE\TBS_01.DBF C:\BACKUP_TEST
        1 file(s) copied.

C:\>COPY  C:\APP12\BD\ORADATA\TEST\DATAFILE\TBS_02.DBF C:\BACKUP_TEST
        1 file(s) copied.

Se respaldan los seis 'redo logs':

C:\>COPY  C:\APP12\BD\ORADATA\TEST\ONLINELOG\O1_MF_1_9OX3ST80_.LOG C:\BACKUP_TEST
        1 file(s) copied.

C:\>COPY C:\APP12\BD\FAST_RECOVERY_AREA\TEST\ONLINELOG\O1_MF_1_9OX3SVGR_.LOG C:\BACKUP_TEST
        1 file(s) copied.

C:\>COPY  C:\APP12\BD\ORADATA\TEST\ONLINELOG\O1_MF_2_9OX3SXC6_.LOG C:\BACKUP_TEST
        1 file(s) copied.

C:\>COPY  C:\APP12\BD\FAST_RECOVERY_AREA\TEST\ONLINELOG\O1_MF_2_9OX3SYL4_.LOG C:\BACKUP_TEST
        1 file(s) copied.

C:\>COPY C:\APP12\BD\ORADATA\TEST\ONLINELOG\O1_MF_3_9OX3T03B_.LOG C:\BACKUP_TEST
        1 file(s) copied.

C:\>COPY C:\APP12\BD\FAST_RECOVERY_AREA\TEST\ONLINELOG\O1_MF_3_9OX3T4SM_.LOG C:\BACKUP_TEST
        1 file(s) copied. 

Respaldamos los 'control files'

C:\>COPY C:\APP12\BD\ORADATA\TEST\CONTROLFILE\O1_MF_9OX3SPDX_.CTL C:\BACKUP_TEST
        1 file(s) copied.

C:\>COPY C:\APP12\BD\FAST_RECOVERY_AREA\TEST\CONTROLFILE\O1_MF_9OX3SPQK_.CTL C:\BACKUP_TEST
        1 file(s) copied.

Posterior al respaldo vamos a generar las tablas 'TEST1' y 'TEST2' con 8860 y 8880 registros respectivamente

SQL> show user
USER is "TEST"

SQL> CREATE TABLE test1 AS SELECT * FROM dba_extents;

Table created.

SQL> CREATE TABLE test2 AS SELECT * FROM dba_extents;

Table created.

SQL> SELECT count(*) FROM test1;

    COUNT(*)
   ----------
      8860

SQL> SELECT count(*) FROM test2;

  COUNT(*) 
   ----------
      8880

Unicamente se generaron dos 'archive logs'. El 'archive log' 'O1_MF_1_8_9P2HOYM9_.ARC' va a contener los datos de las tablas 'TEST1' y 'TEST2', que fueron creadas posterior al respaldo de los 'datafiles'

 Directory of C:\app12\BD\fast_recovery_area\TEST\ARCHIVELOG\2014_04_30

30/04/2014  01:21 p.m.    <DIR>          .
30/04/2014  01:21 p.m.    <DIR>          ..
30/04/2014  01:19 p.m.        13,605,888 O1_MF_1_8_9P2HOYM9_.ARC
30/04/2014  01:21 p.m.            12,288 O1_MF_1_9_9P2HRH8F_.ARC
               2 File(s)     13,618,176 bytes
 
Vamos a simular la pérdida de todos los 'datafiles' por lo que tenemos que realizar un 'FULL RECOVERY' realizando los siguientes pasos:

 1.- Se copian los 'datafiles' del directorio respaldo al directorio origen
 2.- Se copian los 'redo logs' del directorio respaldo al directorio origen
 3.- Se copian los 'control files' del directorio respaldo al directorio origen

Copia de 'datafiles'

C:\APP12\BD\ORADATA\TEST\DATAFILE\

C:\>cd back*

C:\BACKUP_TEST>copy *.dbf c:\app12\BD\ORADATA\TEST\DATAFILE\
O1_MF_SYSAUX_9OX3J7DO_.DBF
O1_MF_SYSTEM_9OX3LLWQ_.DBF
O1_MF_UNDOTBS1_9OX3OB5M_.DBF
O1_MF_USERS_9OX3O8J6_.DBF
TBS_01.DBF
TBS_02.DBF
        6 file(s) copied.

Copia de 'redo logs'

C:\BACKUP_TEST>copy *.LOG c:\app12\BD\ORADATA\TEST\DATAFILE\
O1_MF_1_9OX3ST80_.LOG
O1_MF_1_9OX3SVGR_.LOG
O1_MF_2_9OX3SXC6_.LOG
O1_MF_2_9OX3SYL4_.LOG
O1_MF_3_9OX3T03B_.LOG
O1_MF_3_9OX3T4SM_.LOG
        6 file(s) copied.

Copia de 'controlfiles'

C:\BACKUP_TEST>copy *.CTL c:\app12\BD\ORADATA\TEST\DATAFILE\
O1_MF_9OX3SPDX_.CTL
O1_MF_9OX3SPQK_.CTL
        2 file(s) copied.

Reiniciamos la instancia recordando que Oracle realiza las siguientes pasos durante el proceso de 'startup'

1.- NOMOUNT .- Ejecutada con el comando 'STARTUP NOMOUNT' .-  Oracle lee el archivo de inicio 'init.ora' y únicamente se inicia la memoria de la instancia.

2.- MOUNT.- Se lee el archivo de control o 'control file'. Todas las recuperaciones 'o recoverys' de una instancia Oracle se realizan en este modo.

3.- OPEN.- Todos los 'datafiles' se encuentran sincronizados y la base de datos es consistente y se encuentra operativa

Iniciamos la instancia en modo 'MOUNT'

SQL> startup mount
ORACLE instance started.

Total System Global Area  417546240 bytes
Fixed Size                  2403352 bytes
Variable Size             322962408 bytes
Database Buffers           83886080 bytes
Redo Buffers                8294400 bytes
Database mounted.

Vamos a suponer el que el 'full backup fue realizado a las 10:00 AM y la creación de las tablas 'TEST1' y 'TEST2' a las 11:00 AM,  por lo que el 'full backup' no contiene las transacciones generadas entre las 10:00 AM y las 11:AM.

Una vez recuperados los 'datafiles', se realiza la siguiente consulta sobre la vista dinámica del sistema 'v$datafile_header', donde se muestra que los 'datafiles' se encuentra sincronizados con el número 2330727 que corresponde  a las 10:00 AM 

Este número es originado por medio del 'System Change Number'  o 'SCN'.  Los datafiles tienen en su cabecero o 'header' el 'SCN' que indica la última vez que fueron actualizados por medio del 'checkpoint'.

EL 'SCN' es indispensable para el recovery, ya que le permite conocer al manejador el punto en el tiempo la base de datos es consistente. En este caso, los 6 datafiles tienen el mismo número, por lo cual son consistentes. El 'SCN' también es almacenado en el archivo de control o 'control file'

SQL> SELECT checkpoint_change#,  substr(name, 1,70) FROM v$datafile_header ORDER BY 1;

CHECKPOINT_CHANGE# SUBSTR(NAME,1,70)
------------------ ----------------------------------------------------------------------
           2330727      C:\APP12\BD\ORADATA\TEST\DATAFILE\O1_MF_SYSTEM_9OX3LLWQ_.DBF
           2330727      C:\APP12\BD\ORADATA\TEST\DATAFILE\TBS_01.DBF
           2330727      C:\APP12\BD\ORADATA\TEST\DATAFILE\O1_MF_USERS_9OX3O8J6_.DBF
           2330727      C:\APP12\BD\ORADATA\TEST\DATAFILE\TBS_02.DBF
           2330727      C:\APP12\BD\ORADATA\TEST\DATAFILE\O1_MF_UNDOTBS1_9OX3OB5M_.DBF
           2330727      C:\APP12\BD\ORADATA\TEST\DATAFILE\O1_MF_SYSAUX_9OX3J7DO_.DBF

6 rows selected.

Una vez finalizada la copia para recuperar todos los 'datafiles', 'redo logs' y 'control files' tendriamos una recuperación completa hasta las 10:00 AM que es la hora en que se realizo el respaldo 'full backup'. Sin embargo nos faltan las transacciones  (principalmente las tablas 'TEST1' y 'TEST2') que se crearon despues de las 10:00 AM. Estas transacciones faltantes, estan contenidas en los 'ARCHIVE LOGS', por lo cual hay que aplicarlos, para complementar el 'full recovery'

En modo 'MOUNT' damos el comando 'RECOVER DATABASE' , sin embargo vemos que no se realiza la recuperación o aplicación de los 'ARCHIVE LOGS' y el manejador dice 'no necesito ningún recovery, debido a que los datafiles son de las 10:00 AM y el archivo de control me indica que el respaldo corresponde  a las 10:00 AM'

SQL> RECOVER DATABASE
ORA-00283: recovery session canceled due to errors
ORA-01610: recovery using the BACKUP CONTROLFILE option must be done

Como la función 'RECOVER DATABASE' no aplico 'archive logs', hay que agregar la claúsula 'USING BACKUP CONTROLFILE', lo que le indica al manejador 'no hagas caso que el controlfile tiene un SCN de las 10:00 AM y aplica las transacciones posteriores a ese hora'. 

La sintáxis del comando 'USING BACKUP CONTROLFILE' se puede prestar a confusión, ya que en realidad no se esta utilizando ningún backup del  controlfile, lo único que se le esta indicando es que 'ignora la secuencia del controlfile '

  

Se ejecuta el comando y el manejador indica que 'archive logs' necesita aplicar para tener las transacciones faltantes entre las 10:00 y las 11:00 AM.  Se requiere el 'archive log' 'O1_MF_1_8_9P2HOYM9_.ARC'   para complementar el respaldo,  recordando que que las tablas 'TEST1' y 'TEST2'  se encuentran contenidas en este 'archive log'.  

Se aplica el 'archive log' y 'O1_MF_1_8_9P2HOYM9_.ARC' y nos indica que los demas 'archives' no son necesarios para la recuperación . Se puede autilizar la opción 'AUTO' para que se apliquen de forma automática los 'logs archive logs' requeridos, sin necesidad de especificarlos uno por uno.

SQL> RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE;
ORA-00279: el cambio 2330727 generado en 04/30/2014 12:29:32 es necesario para el thread 1
ORA-00289: sugerencia: C:\APP12\BD\FAST_RECOVERY_AREA\TEST\ARCHIVELOG\2014_04_30\O1_MF_1_8_9P2HOYM9_.ARCORA-00280: el cambio 2330727 para el thread 1 estß en la secuencia n·mero 8

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

ORA-00279: el cambio 2346630 generado en 04/30/2014 13:19:41 es necesario para el thread 1
ORA-00289: sugerencia: C:\APP12\BD\FAST_RECOVERY_AREA\TEST\ARCHIVELOG\2014_04_30\O1_MF_1_9_9P2HRH8F_.ARC
ORA-00280: el cambio 2346630 para el thread 1 estß en la secuencia n·mero 9
ORA-00278: el archivo log 'C:\APP12\BD\FAST_RECOVERY_AREA\TEST\ARCHIVELOG\2014_04_30\O1_MF_1_8_9P2HOYM9_.ARC' ya no es necesario para esta recuperaci¾n

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

ORA-00279: el cambio 2346667 generado en 04/30/2014 13:21:02 es necesario para el thread 1
ORA-00289: sugerencia: C:\APP12\BD\FAST_RECOVERY_AREA\TEST\ARCHIVELOG\2014_04_30\O1_MF_1_10_%U_.ARC
ORA-00280: el cambio 2346667 para el thread 1 estß en la secuencia n·mero 10
ORA-00278: el archivo log 'C:\APP12\BD\FAST_RECOVERY_AREA\TEST\ARCHIVELOG\2014_04_30\O1_MF_1_9_9P2HRH8F_.ARC' ya no es necesario para esta recuperaci¾n

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

Para iniciar la base de datos en modo 'OPEN' se da la opción 'RESETLOGS' para que los 'REDO LOGS'  se reinicien.

SQL> ALTER DATABASE OPEN RESETLOGS;

Database altered.

En la  vista dinámica del sistema 'v$datafile_header' se observa que la secuencia basada en el 'SCN' se incremento de 2330727   a 2346671  con la aplicación de los 'archive logs' y el reinicio de la instacia.


SQL> SELECT checkpoint_change#,  substr(name, 1,70) FROM v$datafile_header ORDER BY 1;

CHECKPOINT_CHANGE# SUBSTR(NAME,1,70)
------------------ ----------------------------------------------------------------------
           2346671 C:\APP12\BD\ORADATA\TEST\DATAFILE\O1_MF_SYSTEM_9OX3LLWQ_.DBF
           2346671 C:\APP12\BD\ORADATA\TEST\DATAFILE\TBS_01.DBF
           2346671 C:\APP12\BD\ORADATA\TEST\DATAFILE\O1_MF_USERS_9OX3O8J6_.DBF
           2346671 C:\APP12\BD\ORADATA\TEST\DATAFILE\TBS_02.DBF
           2346671 C:\APP12\BD\ORADATA\TEST\DATAFILE\O1_MF_UNDOTBS1_9OX3OB5M_.DBF
           2346671 C:\APP12\BD\ORADATA\TEST\DATAFILE\O1_MF_SYSAUX_9OX3J7DO_.DBF

6 rows selected.

Validamos la existencia de las tablas 'TEST1' y 'TEST2' , confirmando que ya fueron recuperadas a partir de los 'archive logs', con lo cual ya tenemos un recovery completo.

SQL> SELECT COUNT(*) FROM TEST.TEST1;

  COUNT(*)
----------
      8860

SQL> SELECT COUNT(*) FROM TEST.TEST2;

  COUNT(*)
----------
      8880

Conclusiones

Los 'archive logs' son un elemento clave en la recuperación de una base de datos Oracle.  Se debe tener especial cuidado en respaldarlos,  ya que en ocasiones, son el único mecanismo para lograr que la base de datos sea consistente en un momento en el tiempo.


José Manuel Vizcaíno Culebra

Contacto servicios profesionales:

jose.vizcainoculebra@gmail.com

5532439143 Ciudad de México