En un sistema Unix HP-UX y una base datos Oracle 10g (10.2.0.4.0) el fichero system01.dbf se encuentra dañado. Al intentar arrancar la base de datos nos sale el siguiente error (ORA-01113):
Ante esta situación y sabiendo, según me informó el cliente de que la Base de datos estaba en modo NOARCHIVELOG, probablemente no me quedaría más remedio que tirar de Backup y asumir pérdida de datos. En resumen, me dicen que recupere esta base de datos, pero que no se sabe desde cuando tienen el último backup y que además, da el error anterior.
“Importante marronazo”, aunque hay que decir, que por suerte era un entorno Pre-productivo y que por tanto, tampoco pasaba nada si no se resolvía sin recurrir al backup.
Pero me ha parecido interesante abrir esta entrada de Blog, ya que gracias a esta incidencia prové una serie de cosas para intentar restaurar la Base de datos, hecho que conseguí despues de unos intentos fallidos que me hicieron descubrir en que estado se encontraba realmente la Base de datos.
Volviendo con el tema. Me encuentro con el error mencionado y miro de restaurar teniendo en cuenta que la Base de datos estaba en modo NOARCHIVELOG (informado por el cliente). Como se trata del tablespace SYSTEM intento restaurar la Base de datos usando “backup controlfile until cancel” y como no tengo “archivers” en lugar de especificar la ruta del primer Archiver, especifico la ruta y el nombre de los logfiles.
Antes de todo me conecto como sysdba y arranco y monto la instancia:
$ sqlplus /nolog
SQL> connect /as sysdba
Para saber que logfiles tengo en la Base de datos ejecuto la siguiente consulta:
SQL> select member from v$logfile;
Con el resultado obtenido intento recuperar el datafile, pero ejecutando la siguiente sentencia que no es la que se usa para recuperar un datafile, sino que se usa para restaurarar el controlfile guardado en el último backup:
SQL> recover database using backup controlfile until cancel;
Y cuando nos solicita el fichero de recuperación de archiver, introducimos en su lugar el de logfile. En definitiva se hizo esto:
Según el mensaje parecía que todo había ido bien. Por tanto se intenta arrancar usando la opción “open resetlogs”. ¿ Porqué usé Open Resetlogs ?
La opción “resetlogs” se suele usar cuando se dan estas dos situaciones:
O bien, en la recuperación se ha partido de un backup del controlfile y no del controlfile actual. Por tanto, el controlfile no tiene la última información sobre los archivelogs generados y la base de datos no puede saber hasta que archivelog se debe aplicar. O el segundo caso, no se ha recuperado hasta la última transacción, ya sea porque no hemos querido (RECOVER UNTIL) o bien porque faltaban archivelogs (hecho que se daba en este caso porque la base estaba en modo NOARCHIVELOG) y no se han podido recuperar hasta el final.
¿ Que implica abrir con resetlogs ?
A efectos de Backup podemos decir que la Base de datos es distinta, por tanto, se debería realizar un backup después de usar esta opción. Ya que técnicamente la ”nueva” base de datos está sin backup. Y si la base de datos estuviese en modo ARCHIVELOG, si se tuviese que restaurar no podríamos usar los backupsets de antes y después del resetlogs ya que tenemos una discontinuidad en el backup.
Después de ejecutar resetlogs, salta la alarma y me hace tomar otro camino. He aquí el error …
Este error se produce cuando Oracle realiza un seguimiento de la pila. Y nos advierte de que algún error producido anteriormente será probablemente la causa de este fallo. Cosa que me hace sospechar de que probablemente o bien la base de datos, no está realmente en modo NOARCHIVELOG o bien al restaurar con USING BACKUP CONTROLFILE el controlfile que existía en el backup estaba configurado en modo ARCHIVELOG.
Pues pasé a comprobarlo:
SQL> select archiver from v$instance;
ARCHIVE
——-
STARTED
o también
SQL> archive log list;
Modo log de la base de datos Modo de Archivado
Archivado automático Activado
Destino del archivo USE_DB_RECOVERY_FILE_DEST
Secuencia de log en línea más antigua 15
Secuencia de log actual 17
Efectivamente, la Base de datos estaba en modo ARCHIVELOG. Pues este hecho me hizo tomar otro camino en la recuperación y ejecuté las siguientes instrucciones para intentar recuperarla. (Hay que tener en cuenta, que cómo probablemente la base de datos estubo en algún momento configurada en modo archivelog, hecho que lo demuestra al restaurarla con using backup controlfile me hizo pensar, que probablemente se podría restaurar datafile a datafile y luego abriendo de manera normal).
SOLUCIÓN:
Decido recuperarla datafile a datafile:
Pero para ello necesito saber que número corresponde a cada datafile:
$ sqlplus /nolog
SQL> connect /as sysdba
SQL> shutdown immediate;
SQL> startup force mount;
SQL> desc v$datafile;
select name, file#, status, enabled from v$datafile
/
NAME
——————————————————————————–
FILE# STATUS ENABLED
———- ——- ———-
/oracle/oradata/system01.dbf
1 SYSTEM DISABLED
/oracle/oradata/undotbs01.dbf
2 ONLINE DISABLED
/oracle/oradata/sysaux01.dbf
3 ONLINE DISABLED
Empiezo con el de system que es el que estaba erróneo …
SQL> recover datafile 1;
Recuperación del medio físico terminada.
Intento abrir la Base de datos …
SQL> alter database open;
alter database open
*
ERROR en línea 1:
ORA-01113: el archivo 2 necesita recuperación del medio físico
ORA-01110: archivo de datos 2: ‘/oracle/oradata/undotbs01.dbf’
Nos da error y nos pide que lo hagamos en más ficheros…. Pues procedo a hacerlo en todos los que nos solicita.
SQL> recover datafile 2;
Recuperación del medio físico terminada.
SQL> alter database open;
Base de datos modificada.
Para la base de datos de manera abort para que no realice rollback de ninguna transacción pendiente.
SQL> shutdown abort;
Instancia ORACLE cerrada.
Intento arrancarla ..
SQL> startup
Instancia ORACLE iniciada.
Total System Global Area 2147483648 bytes
Fixed Size 2070624 bytes
Variable Size 973080480 bytes
Database Buffers 1157627904 bytes
Redo Buffers 14704640 bytes
Base de datos montada.
ORA-16038: no se puede archivar el log 1 secuencia número 1
ORA-19809: se ha excedido el límite para los archivos de recuperación
ORA-00312: log online 1 thread 1: ‘/oracle/oradata/redo01a.log‘
Este error ya me gusta más, porque lo da en los ficheros redo y los podremos rehacer… Continuo con …
SQL> alter database open resetlogs;
Ahora cambio a modo NOARCHIVELOG ..
SQL> alter database noarchivelog;
Base de datos modificada.
SQL> alter database open;
Base de datos modificada.
SQL> archive log list;
Modo log de la base de datos Modo de No Archivado
Archivado automático Desactivado
Destino del archivo USE_DB_RECOVERY_FILE_DEST
Secuencia de log en línea más antigua 2
Secuencia de log actual 4
SQL> alter system switch logfile;
Sistema modificado.
SQL> shutdown immediate;
Base de datos cerrada.
Base de datos desmontada.
Instancia ORACLE cerrada.
SQL> startup
Instancia ORACLE iniciada.
Total System Global Area 2147483648 bytes
Fixed Size 2070624 bytes
Variable Size 973080480 bytes
Database Buffers 1157627904 bytes
Redo Buffers 14704640 bytes
Base de datos montada.
Base de datos abierta.
SQL>
Resultado: Base de datos recuperada. Pero con pérdida de datos. Pero no nos importa, porque era una Base de datos de pre-producción. Ahora se tendría que hacer un backup e importar datos de producción.