Ao trabalhar em um banco de dados de espera recentemente, fui ao DG Broker para verificar o status e recebi isso:
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… meu standby não está aplicando redo. Quando tentei iniciar a recuperação gerenciada, obtive o seguinte no log de alerta de 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)
Então o ORA-38868 está me dizendo que eu tenho uma estrutura de diretório ruim. Meu primeiro pensamento foi que isso estava relacionado ao trabalho sobre o qual escrevi ontem. Mas esse trabalho estava no lado primário. Olhei para o log de alerta de espera e encontrei a primeira ocorrência desse erro cerca de 2,5 meses atrás. Se este fosse um sistema de produção, eu poderia ter grandes problemas deixando esse problema passar despercebido por esse período de tempo. Mas tenho medidas em vigor para me alertar se minha espera de produção ficar atrás do primário por um período de tempo inaceitável. Este é apenas um sistema de teste que posso explodir e começar do zero, se necessário. Mas que graça teria? Vamos ver se conseguimos resolver o problema.
Minha primeira parada foi Metalink. Mas obtive zero acertos para o erro ORA-38868. Ao fazer uma pesquisa na web, recebi um hit relevante que oferecia uma solução de simplesmente reiniciar a instância e reiniciar a aplicação de redo. Eu estava cético, mas tentei a solução fácil. Não deve ser surpresa que uma simples reinicialização da instância não tenha resolvido o problema. O erro está me dizendo que meu arquivo de controle está corrompido. Reiniciar a instância não corrigirá a corrupção do arquivo de controle. Como o Metalink e a Internet são inúteis, acho que cabe a mim consertar isso. Se tudo mais falhar, simplesmente abandonarei o modo de espera e o recriarei.
Minha solução inicial é voltar ao primário e criar um arquivo de controle de espera. Em seguida, inicie o standby com o arquivo de controle standby. Tenho confiança de que um novo arquivo de controle do primário resolverá o problema. Porém, preciso aplicar 2,5 meses de refazer dos quais não tenho mais disponível.
Estou tentando investigar o uso do RMAN para avançar um modo de espera por meio de um backup incremental. Mas isso parece cair na minha lista de prioridades de coisas a fazer. Eu tenho um próximo projeto onde precisarei saber como fazer isso e esse projeto está agora a menos de um mês de distância. Portanto, este parece ser o momento perfeito para praticar essa técnica para meu próximo projeto e corrigir meu problema atual. As etapas para fazer isso estão em:
Metalink Note 836986.1 Steps to Perform for Rolling Forward a Standby Database Using RMAN Incremental Backups
As etapas neste documento não apenas avançaram meu modo de espera, mas também recriaram os arquivos de controle, corrigindo assim meu problema.
