domingo, 12 de octubre de 2008

¿Archive log perdido? No reconstruya su Standby

Otro problema recurrente con las bases de datos standby es la pérdida de uno o más archive logs aún no aplicados. La solución era usualmente el reconstruir nuevamente la base de datos standby, lo cual si bien es relativamente fácil, puede consumir bastante tiempo. Esto fue lo que algunos sugirieron a un afligido DBA que pedía ayuda en el foro de Oracle Technet, afortunadamente si estás usando Oracle 10gR2 la solución es mucho más simple y rápida, ¿suena bien? entonces vamos con el procedimiento.

  1. Detener la sincronización de la base de datos standby
  2. STDB> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
    
  3. Obtener el SCN al cual se ha llegado en la base de datos standby
  4. STDB> SELECT CURRENT_SCN FROM V$DATABASE;
    
  5. Obtener un backup incremental de la base de datos primaria con RMAN, a partir del SCN obtenido en el paso previo
  6. RMAN> BACKUP INCREMENTAL FROM SCN <SCN from previous step>
    DATABASE FORMAT '/tmp/ForStandby_%U' tag 'FORSTANDBY';
    
  7. Catalogar el backup del paso previo en la base de datos standby
  8. RMAN> CATALOG START WITH '/tmp/ForStandby';
    
  9. Recuperar la base de datos standby con el backup ya catalogado
  10. RMAN> RECOVER DATABASE NOREDO;
    
  11. En la base de datos primaria crear un nuevo standby controlfile
  12. RMAN> BACKUP CURRENT CONTROLFILE FOR STANDBY FORMAT '/tmp/ForStandbyCTRL.bck';
    
  13. Detener la base de datos standby y levantarla con nomount
  14. RMAN> SHUTDOWN;
    RMAN> STARTUP NOMOUNT;
    
  15. Restaurar el standby controlfile obtenido en el paso (6) en la base de datos standby
  16. RMAN> RESTORE STANDBY CONTROLFILE FROM '/tmp/ForStandbyCTRL.bck';
    
  17. Detener la base de datos standby levantarla con mount
  18. RMAN> SHUTDOWN;
    RMAN> STARTUP MOUNT;
    
  19. Limpiar los standby redo logs en la base de datos standby
  20. STDB> ALTER DATABASE CLEAR LOGFILE GROUP 1;
    STDB> ALTER DATABASE CLEAR LOGFILE GROUP 2;
    STDB> ALTER DATABASE CLEAR LOGFILE GROUP 3;
    
  21. Si estaba activo Flashback Database, reiniciarlo
  22. STDB> ALTER DATABASE FLASHBACK OFF;
    STDB> ALTER DATABASE FLASHBACK ON;
    
  23. Reiniciar el recovery de la base de datos standby
  24. STDB> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
    

Este procedimiento aplica no sólo cuando un archive log se ha perdido, sino también cuando se han realizado operaciones con nologging en la base de datos principal o cuando hay un gran retraso en la sincronización. Puedes revisar el texto completo en el manual Oracle Data Guard Concepts and Administration.

Posts Relacionados:

¿Te pareció interesante este artículo?, ¿te quedaron algunas dudas?, ¿quieres sugerirme un tema a tratar?, pues déjame tus comentarios o envíame un email y para que NO te pierdas ningún Post, suscríbete por email ahora mismo!

30 comentarios, agrega el tuyo!

Williams dijo...

En un caso muy particular, no tengo una instancia para catalogo de RMAN y tenia datos inconsistentes en Standby Control File, seccion Datafile Copy.
Esta inconsistencia no me permitia ejecutar el paso de catalogar el backup incremental.

1. Con la siguiente instruccion, se puede observa las secciones que tiene el control file.
=> select rownum-1 , type from v$controlfile_record_section;

2. Con la siguiente instruccion, se puede resetear una seccion del control file.
=> execute sys.dbms_backup_restore.resetcfilesection(16);

Enrique Orbegozo dijo...

Muy interesante Williams, con tu colaboración es posible que, en un próximo Post, tratemos el detalle del problema que encontraste, así como su solución.

Anónimo dijo...

Hola, me parece muy interesante este método. Quisiera saber si se puede aplicar a un ambiente de dataguard que es administrado con Broker. Me da la sensación que deberia funcionat igual. Desde ya muchas gracias por tu respuesta.

Saludos

Natalia

Enrique Orbegozo dijo...

Hola Natalia,
En efecto, que estes usando el broker no es impedimento para seguir este procedimiento.
Gracias por participar!

Anónimo dijo...

Enrique, gracias por tu respuesta. Si llego a probarlo, te comento mis resultados.

Saludos

Natalia.

Anónimo dijo...

Enrique,
Probé el método, pude rearmar la standby en un ambiente administrado con por el Broker. Con la particularidad que luego de haber restaurado el standby control file, se presento un error de que no estaba presente un datafile de un tablespace que se creó en la base primaria pero no en la standby. Entoces restauré dicho datafile desde el backup incremental baje y subi la base standby para que continue con el recovery y los procesos del broker sincronizen y finalmente quedó sincronizada.

Ahora se me presentan unas dudas, que tal vez puedas ayudarme a aclarar.

1) El datafile faltante, no se restauró al hacer el paso 5. Supongo que el motivo, es que el control file no contenia la definición de ese datafile, creado en el lado primario durante el período que la base standby estuvo desincronizada. Es correcto esto?

2) Porque es necesario limpiar los standby redo logs en el punto 10?

Desde ya muchas gracias por tu colaboración.

Saludos

Natalia

Enrique Orbegozo dijo...

Hola Natalia,
Qué bueno que haya funcionado todo bien. En efecto, al momento de hacer el recovery en el controlfile no hay referencia a la existencia de nuevos datafiles, pues esta desfasado con respecto al de producción, recién cuando copias uno nuevo a partir del de producción (paso 8) se nota su ausencia. Puedes ver algo similar en este post.
Luego de haber hecho la sincronización los contenidos de los standby redo logs ya no son necesarios, sus contenidos han perdido vigencia por lo que es necesario limpiarlos para que reciban información fresca desde la base de datos de producción.

Saludos.

Anónimo dijo...

Enrique:
Muchas gracias por tus aclaraciones, ya no me quedan mas dudas al respecto.

Saludos.

Natalia

Jimy Godoy dijo...

Hola Enrique!, muy bueno el articulo!, creo importante es mencionar que para evitar estos tipos de problemas los archivelogs deben ser borrados solo con RMAN, luego el peor escenario que podríamos tener es perder un archivelog en el destino, en ese caso la solución es muy simple: copiar por la vía que estimes conveniente al servidor donde se encuentra la base de datos standby y registrar el archivelog con "ALTER DATABASE REGISTER LOGFILE..."
Un Abrazo!

edison dijo...

Hola Enrique, felicitaciones por tu blog. Me ineresó mucho el tema acerca de archivelogs, sin embargo no se parece a un problema que tengo, necesito teenr un reporte de la actividad realizada un dia anterior a cambiar de ARCHIVELOG a NOARCHIVELOG. Tengo todos los archivos: datafiles, archivelog, control files, pero no se cómo obtener las activisades como SELECTS, TRANSACCIONES, PICOS, ETS.
mo se si me pueden ayudar al respecto

Anónimo dijo...

Hola me parce muy bueno tu comentario. Yo tengo un caso parecido pero no tengo backup incremental sino un full en ese caso que deberìa hacer ??????

Enrique Orbegozo dijo...

Hola Anónimo, el procedimiento debe funcionar igual, solamente te estas evitando el paso (3).

BB dijo...

Este metodo es aplicable para un logical standby?

Javier dijo...

Hola recién inicio como DBA de Oracle y tengo un problema muy peculiar con respecto a los archives, los respaldos se hacen por medio de Veritas Symantec, el problema es que a veces fallan los respaldos y la base de datos se colgo debido a la cantidad de archives, asi que anteriormente los movian (la persona anterior) manualmente a otro lugar eliminandolos de su ubicacion actual(esto es lo que en relidad inicio todo el problema desde entonces no se hacen los respaldos), me han dicho que tengo que reiniciar los apuntadores (pero sobre eso no encuentro nada) lo que me parece es que el tema es con algun catalogo. Algun consejo?

Enrique Orbegozo dijo...

@Javier
Ya que has manipulado los archive logs Oracle no esta al tanto de su nueva ubicacion de alli que los backups no funcionen. Te recomiendo actualizar el catalogo mediante: crosscheck archivelog all

Saludos.

Enrique Orbegozo dijo...

@BB
Tanto el logical como el physical standby se fundamentan en el redo por lo que, si bien no lo he probado, asumo que debe funcionar.

Saludos.

Anónimo dijo...

funcionó la raja
vale

Jose dijo...

Buenas Tardes, yo tengo un problema realice el procedimiento pero me esta saliendo este error, por favor si me pueden ayudar se los agredeceria ORA-19909: datafile 1 belongs to an orphan incarnation, ya revise el primary y el standby y estan iguales, que puedo hacer. Gracias de antemano

Enrique Orbegozo dijo...

Hola José, tu problema es muy específico y está relacionado con que la base de datos se abrió con resetlogs en algún momento y por tanto se creo una nueva "incarnation", o quizás se trate también de un bug, que hay algunos mencionados en MOS. Te recomiendo probar con la creación de un nuevo standby controlfile o en su defecto recurrir a Oracle Support si no se te hace facil superar el problema.
Saludos.

Jose dijo...

Hola Enrique, el problema que tengo es que esa base de datos es demasiado grande, y el server standby esta en otro pais, el solo hecho de pasar el respaldo es vedaderamente un fastidio, tendre que empezar de cero esa standby, muchas gracias de todos modos.

Jose dijo...

Hola Enrique de nuevo, ya pude con el Standby, realice un full backup y ahi ya esta aplicando los archive logs que faltaban, muchisimas gracias por su ayuda, es un blog excelente. Saludos

wdevia dijo...

Buenas tardes Enrique... los pasos me funcionan bien hasta el 10 .. me sale este error...
SQL> alter database clear logfile group 1;
alter database clear logfile group 1
*
ERROR at line 1:
ORA-19527: physical standby redo log must be renamed
ORA-00312: online log 1 thread 1: '/u02/oradata/siuladrh/redo01.log'

que puede haber pasado.. gracias por tu ayuda

Enrique Orbegozo dijo...

@wdevia, es difícil saber que pasó sin tener mayores datos, pero quizás el Note 601835.1 ORA-00313, ORA-00312, ORA-27037 in Standby Database pueda ser de ayuda, allí se recomienda asignar un valor al parámetro log_file_name_convert. HTH.

Anónimo dijo...

Hola Enrique

Muy interesante tus articulos, en hora buena muchas felicidades y gracias por compartir informacion tan valiosa.

Actualmente he instalado un Data Guard, con solo la experiencia que he adquirido durante el proceso de la instalacion y configuracion, y mi situacion es que al momento de consultar los archives que no se han aplicando para mi SB en la vista v$archived_log, me aparecen N archivos con APPLIED = N y STATUS = A, quisiera saber si esto es correcto o incorrecto?

Gracias

Enrique Orbegozo dijo...

Hola "Anónimo", la vista v$archived_log debe reflejar que los archive logs han sido ya aplicados en la base de datos en standby, de no ser asi es posible que estes experimentando alguno de los bugs existentes, como el "Bug 7417614 APPLIED column in V$ARCHIVED_LOG can erroneously indicate a log was not applied" o el "Bug 4538727 - Applied column is not updated in V$ARCHIVED_LOG". Gracias por participar.

Anónimo dijo...

Excelente muchas gracias, revise los archivelogs aplicador con esta query:

select thread#, sequence#, applied,
to_char(first_time, 'mm/dd/yy hh24:mi:ss') first,
to_char(next_time, 'mm/dd/yy hh24:mi:ss') next,
to_char(completion_time, 'mm/dd/yy hh24:mi:ss') completion
from v$archived_log order by first_time;

Anónimo dijo...

Hola Enrique.

Y como sería el método en el caso de tener una BD secundaria con control file del tipo backup?

SQL> select controlfile_type from v$database;
CONTROL
-------
BACKUP

Lorena España dijo...

Hola Enrique, fijate que tengo el problema que mi secuencia de archive como lo mencionas en tu artículo se me ha perdido, ejecuté todo el procedimiento que tú indicas y excelente, pero el problema que al subir la sincronizacion de nuevo, me pone nuevamente la misma secuencia en wait_for_gap, como puedo hacer? creo que el backup incremental que hice de la SCN del sitio primario no realizó backup de esa secuencia y por eso la vuelve a pedir... gracias

Anónimo dijo...

Hola Enrique,

Funcionó muy bien lo que publicaste. Ahora tengo una duda, Que otra opción hay (sin recrear ni bajar la base de datos standby) para sincronizar cuando falta algún Archive?

Mil Gracias,
Juan C

Valdo Rivas dijo...

Buenas; me quedé en paso donde se hace el backup incremental, se doy el siguiente comando:

RMAN> BACKUP INCREMENTAL FROM SCN 6559841446 DATABASE FORMAT ‘/backup/prod/rman/ForStandby_%U’ tag ‘FORSTANDBY’;

Y me da el siguiente error:

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00558: error encountered while parsing input commands
RMAN-01005: syntax error: found “from”: expecting one of: “level”
RMAN-01007: at line 1 column 20 file: standard input

Te agradeceré cualquier ayuda.