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.
- Detener la sincronización de la base de datos standby
- Obtener el SCN al cual se ha llegado en la base de datos standby
- Obtener un backup incremental de la base de datos primaria con RMAN, a partir del SCN obtenido en el paso previo
- Catalogar el backup del paso previo en la base de datos standby
- Recuperar la base de datos standby con el backup ya catalogado
- En la base de datos primaria crear un nuevo standby controlfile
- Detener la base de datos standby y levantarla con nomount
- Restaurar el standby controlfile obtenido en el paso (6) en la base de datos standby
- Detener la base de datos standby levantarla con mount
- Limpiar los standby redo logs en la base de datos standby
- Si estaba activo Flashback Database, reiniciarlo
- Reiniciar el recovery de la base de datos standby
STDB> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
STDB> SELECT CURRENT_SCN FROM V$DATABASE;
RMAN> BACKUP INCREMENTAL FROM SCN <SCN from previous step> DATABASE FORMAT '/tmp/ForStandby_%U' tag 'FORSTANDBY';
RMAN> CATALOG START WITH '/tmp/ForStandby';
RMAN> RECOVER DATABASE NOREDO;
RMAN> BACKUP CURRENT CONTROLFILE FOR STANDBY FORMAT '/tmp/ForStandbyCTRL.bck';
RMAN> SHUTDOWN; RMAN> STARTUP NOMOUNT;
RMAN> RESTORE STANDBY CONTROLFILE FROM '/tmp/ForStandbyCTRL.bck';
RMAN> SHUTDOWN; RMAN> STARTUP MOUNT;
STDB> ALTER DATABASE CLEAR LOGFILE GROUP 1; STDB> ALTER DATABASE CLEAR LOGFILE GROUP 2; STDB> ALTER DATABASE CLEAR LOGFILE GROUP 3;
STDB> ALTER DATABASE FLASHBACK OFF; STDB> ALTER DATABASE FLASHBACK ON;
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!
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);
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.
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
Hola Natalia,
En efecto, que estes usando el broker no es impedimento para seguir este procedimiento.
Gracias por participar!
Enrique, gracias por tu respuesta. Si llego a probarlo, te comento mis resultados.
Saludos
Natalia.
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
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.
Enrique:
Muchas gracias por tus aclaraciones, ya no me quedan mas dudas al respecto.
Saludos.
Natalia
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!
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
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 ??????
Hola Anónimo, el procedimiento debe funcionar igual, solamente te estas evitando el paso (3).
Este metodo es aplicable para un logical standby?
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?
@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.
@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.
funcionó la raja
vale
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
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.
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.
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
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
@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.
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
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.
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;
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
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
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
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.
Publicar un comentario