Recientemente, cuando trabajaba en una base de datos en espera, fui a DG Broker para verificar el estado y recibí esto:
DGMGRL> show configuration Configuration - resp_ress_config Protection Mode: MaxPerformance Databases: resp - Primary database ress - Physical standby database Error: ORA-16766: Redo Apply is stopped
Hmm... mi modo de espera no está aplicando rehacer. Cuando intenté iniciar la recuperación administrada, obtuve lo siguiente en el registro de alertas en espera:
Tue Dec 31 09:52:10 2013 Managed Standby Recovery starting Real Time Apply Tue Dec 31 09:52:10 2013 MRP0: Background Media Recovery terminated with error 38868 Errors in file /u01/app/oracle/diag/rdbms/ress/ress2/trace/ress2_pr00_13905.trc: ORA-38868: warning: the control file may have incorrect data file structure Managed Standby Recovery not using Real Time Apply Slave exiting with ORA-38868 exception Errors in file /u01/app/oracle/diag/rdbms/ress/ress2/trace/ress2_pr00_13905.trc: ORA-38868: warning: the control file may have incorrect data file structure Recovery Slave PR00 previously exited with exception 38868 MRP0: Background Media Recovery process shutdown (ress2)
Entonces, ORA-38868 me dice que tengo una estructura de directorios incorrecta. Lo primero que pensé fue que esto estaba relacionado con el trabajo sobre el que escribí ayer. Pero ese trabajo estaba en el lado primario. Volví a mirar el registro de alertas en espera y encontré la primera aparición de este error hace aproximadamente 2,5 meses. Si se tratara de un sistema de producción, podría estar en un gran problema al dejar que este problema pasara desapercibido durante ese período de tiempo. Pero tengo medidas para alertarme si mi producción en espera se retrasa con respecto a la principal durante un período de tiempo inaceptable. Este es solo un sistema de prueba que puedo eliminar y comenzar desde cero si es necesario. ¿Pero qué gracia tendría? Veamos si podemos solucionar el problema.
Mi primera parada fue Metalink. Pero no obtuve resultados para el error ORA-38868. Al realizar una búsqueda en la web, obtuve un resultado relevante que ofrecía una solución de simplemente reiniciar la instancia y reiniciar la aplicación de rehacer. Era escéptico, pero intenté la solución fácil. No debería sorprender que un simple reinicio de la instancia no solucione el problema. El error me dice que mi archivo de control está dañado. Reiniciar la instancia no solucionará la corrupción del archivo de control. Dado que Metalink e Internet no sirven de nada, supongo que depende de mí arreglar esto. Si todo lo demás falla, simplemente abandonaré el modo de espera y lo volveré a crear.
Mi solución inicial es volver al principal y crear un archivo de control en espera. A continuación, inicie el modo de espera con el archivo de control de modo de espera. Confío en que un nuevo archivo de control del primario resolverá el problema. Sin embargo, necesito aplicar 2.5 meses de rehacer de los cuales ya no tengo disponible.
He estado tratando de investigar el uso de RMAN para avanzar un modo de espera a través de una copia de seguridad incremental. Pero esto parece caer bajo en mi lista de prioridades de cosas que hacer. Tengo un próximo proyecto en el que necesitaré saber cómo hacer esto y ese proyecto está a menos de un mes de distancia. Así que este parece ser el momento perfecto para practicar esta técnica para mi próximo proyecto y solucionar mi problema actual. Los pasos para hacerlo están en:
Metalink Note 836986.1 Steps to Perform for Rolling Forward a Standby Database Using RMAN Incremental Backups
Los pasos de este documento no solo avanzaron en mi espera, sino que también recrearon los archivos de control, solucionando así mi problema.
