Un clásico: El poderoso _ALLOW_RESETLOGS_CORRUPTION=TRUE

Saludos amigos y amigas, decidí, volver a publicar este post, que había incorporado en el blog en el mes de julio del 2009, ya que gracias a él, esta es la segunda ocasión, que una base de datos con problemas, puede ser recuperada de manera éxitosa.

La primera vez solventó un problema en una versión 10gR2 en Windows y ahora fue en una base de datos 8i 8.1.7.4 en Unix.

Aplica para: Oracle Server - Version: 8.1.7.4 to 10.2.0.4

Basado en: RECOVER A DATAFILE WITH MISSING ARCHIVELOGS
Doc ID: 418476.1
Type: PROBLEM
Modified Date: 03-JUN-2009

Síntoma: ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: 'c:\ORACLE\ORADATA\SYSTEM01.DBF'

Cuál puede ser el escenario más desastrozo que puede usted enfrentar.?

Su servidor de base de datos sufre la pérdida repentida de unos de los discos duros. El servidor tiene un arreglo 0+1, ó peor, no existe arreglo de discos.

Después de darse cuenta que su disco no sirve, llama a su soportista de hardware y le solicita reparar el daño.

Cuando el equipo está arriba nuevamente, hace un repaso de su instalación y el inventario le indica, que perdió, el motor de la base de datos. Los datafiles de la base de datos estaban dichosamente en otro disco duro. Instala el motor de la base de datos nuevamente, configura los nuevos servicios y a la hora de levantar la base de datos, le indica que la base de datos esta inconsistente y que requiere realizar una recuperación de uno ó más datafiles.

Por motivos especiales, usted no tiene la base de datos en modo archive. Toma la decisión de recuperar desde uno de los respaldos en frío que realiza todos los días. Sorpresa, el respaldo en frío no existe, revisa el histórico en disco y se da cuenta que el respaldo más reciente, es de hace 1 mes y medio. Revisa la cinta de respaldos y sí, efectivamente, el respaldo tampoco existe en cintas.

Revisa la ubicación de los "dmps", y "Ups!!!", no tenemos "exports" de la base de datos.

Al intentar realizar un "recovery database", da como resultado, que no puede abrir los 1 ó mas datafiles de un tablespaces de datos, el tablespace temporal y el datafile de "SYSTEM", requiere recuperación.

NO HAY RESPALDOS DISPONIBLES.
Qué podemos hacer.?

A pesar del panorama tan poco positivo, les cuento, que logré recuperar una base de datos, en estas condiciones.

• Los tablespaces de índices, no eran tan críticos, por tanto, lo más fácil, eran borrarlos para poder continuar con la recuperación.
• El tablespace temporal, no hay problema. En todo caso se crea otro tablespace temporal y listo.
• Esta es la parte interesante del problema. Los datafiles de datos, fueron revisados con el utilitario "DBV", y ninguno presentaba problemas, incluyendo el datafile de SYSTEM. Sin embargo, al darle "startup", me indica que el datafile de SYSTEM, requiere recuperación, porque se encuentra inconsistente y me pide, un archivo de archivelog, para poder realizar la recuperación. La base de datos queda en estado montada, pero no abierta. La base de datos, les recuerdo, no está en modo ARCHIVE. Intento varias opciones encontradas en "metalink.oracle.com", sin embargo, ninguna funciona. Una nota me indica que debo, recuperar el datafile de un respaldo consistente en frío. - No hay respaldos en frío -. Apoyado en la nota 418476.1, de cómo realizar una recuperación de un datafile con pérdida de archivelogs, hago lo siguiente:
• Bajo la base de datos con "shutdown abort".
• Monto la base de datos "startup mount"
• Hago un respaldo del controlfile de la base de datos.
• Edito el archivo generado del respaldo del controlfile y dejo la opción de "Create controlfile" con la opción de resetlogs.
• Creó un archivo de parámetros de tipo pfile del SPFILE actual de la instancia.
• Se agrega la línea: _allow_resetlogs_corruption=TRUE
• Recreó el archivo SPFILE de la instancia con el contenido del nuevo archivo pfile.
• Bajo la base de datos y la vuelvo a montar
• Ejecuto el archivo creado para recreación de los controlfiles con la opción de resetlogs.
• Ejecuto "recover database", si el resultado es satisfactorio, procedo a ejecutar "alter database open"
• La ejecución del comando "alter database open", puede llevar su tiempo en concluir. Puede ser que no concluya satisfactoriamente. Si falla, baje la base de datos con "shutdown abort", monte la base de datos y vuelva a ejecutar "recover database" y luego "alter database open".
• Cuando el resultado del "alter database open", sea satisfactorio, proceda a crear un "dmp" de la base de datos. Baje de manera consistente la base de datos "shutdown immediate" y genere un respaldo en frío de todos los datafiles.
• Cuando haga el dmp, puede ser que le indique con no existe el tablespace temporal. Proceda a crear un nuevo tablespace temporal y definalo como default.

Como resultado de este procedimiento, el recover, recuperó los datafiles de los tablespaces con índices dañados y la base de datos quedó consistente.

No olviden leer detenidamente la nota a la que hago referencia para el parámetro "_ALLOW_RESETLOGS_CORRUPTION". Lo peor que le puede suceder, es que no le funcioné. De todos modos, la única salida con respuesta certificada en metalink, es que proceda a recrear la base de datos, desde cero.

A mi me sirvió, espero que a ustedes les pueda ayudar. Sin embargo, tomen las medidas necesarias, para evitar este tipo de escenario.

1. Verifique que sus respaldos diarios estan funcionando correctamente.
2. Verifique que los respaldos a cinta, son funcionales.
3. Configure su base de datos en modo archive
4. No olvide, validar que sus respaldos funcionan. Haga periódicamente, recuperación de la base de datos en un servidor de pruebas, con los archivos respaldados en sus cintas.