Após uma queda de energia recente em nosso site de DR, descobri que um standby havia parado de aplicar logs. Aparentemente, nos redo logs arquivados, havia uma transação que aumentou um arquivo de dados, mas o disco no site de espera não tinha espaço em disco suficiente para permitir que essa transação fosse concluída. Portanto, o standby encerrou a recuperação gerenciada, como deveria.

Normalmente, mantemos os redo logs arquivados por 7 dias. Infelizmente, quando descobri essa situação, 15 dias haviam se passado e os redo logs arquivados estavam “ausentes”. Sem redo logs arquivados para aplicar, a única solução foi reconstruir o banco de dados do zero. Esse banco de dados tem aproximadamente 7 TB de tamanho, portanto, a reconstrução do zero não é uma tarefa trivial.

O primário é um banco de dados RAC 11.2.0.2 de 3 nós executado no Linux. O standby é um banco de dados RAC de dois nós, obviamente as mesmas versões do Oracle e do SO.

Veja como conseguimos reconstruir o modo de espera:

1. Colocamos o primário no modo de backup dinâmico e tiramos um instantâneo do banco de dados baseado em disco.
2. O instantâneo foi copiado para mídia externa. Observação:o envio pela WAN consumia muito tempo.
3. A mídia externa foi transportada manualmente para o site de DR.
4. O LOG_ARCHIVE_DEST_STATE_n para o modo de espera foi definido como DEFER.
5. O banco de dados standby foi removido da configuração do DG Broker:   REMOVE DATABASE standby PRESERVE DESTINATIONS;
6. Os pontos de montagem do banco de dados em espera foram apagados. Afinal, o banco de dados era essencialmente inútil neste momento.
7. Novos pontos de montagem foram criados e o instantâneo foi gravado no disco no site de recuperação de desastres.
8. Depois que as transferências de arquivos foram concluídas (cerca de 5 dias), instruímos nosso armazenamento a atualizar o instantâneo no site de DR com um instantâneo mais atual. Isso foi feito pela WAN, pois apenas as alterações foram enviadas, o que era muito, muito menor que o banco de dados.
9. Um arquivo de controle em espera foi criado:   ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/dir/path';
10. Para simplificar, queríamos usar um modo de espera de instância única até colocá-lo em funcionamento. Então, criamos um PFILE a partir do RAC SPFILE do standby e, em seguida, usamos um editor de texto para modificar o arquivo de parâmetro para remover qualquer parâmetro compatível com RAC. Removemos CLUSTER_DATABASE, definimos um parâmetro UNDO_TABLESPACE específico da instância a ser usado para todas as instâncias “*.”, removemos os parâmetros THREAD, etc. Nosso banco de dados standby normal tem duas instâncias, STANDBY1 e STANDBY2. No nó 1, colocamos o pfile em $ORACLE_HOME/dbs/initstandby.ora em vez de initstandby1.ora para que o banco de dados de instância única possa encontrar seu arquivo de parâmetro. Fizemos algo semelhante para o arquivo de senhas.
11. Copiamos o arquivo de controle em espera da etapa 9 sobre os arquivos de controle no instantâneo do banco de dados.
12. Com os arquivos pfile e pswd em vigor para um banco de dados de instância única, fizemos STARTUP MOUNT.
13. Criamos todos os logs de redo em espera necessários. No nosso caso, o primário também possui redo logs de espera para facilitar as operações de switchover e os redo logs de espera do primário não faziam parte do snapshot. Então tivemos que remover os SRLs que não fizeram a viagem.
14. No primário, defina LOG_ARCHIVE_DEST_STATE_n como ENABLE.
15. Nas instâncias primárias, executou ALTER SYSTEM SWITCH LOGFILE;
16. Verificou nos logs de alerta do principal e do standby que o standby estava recebendo logs, ou seja, verificou se o transporte de log estava funcionando.
17. Ativado o modo de espera gerenciado:ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
18. Verificado no registro de alerta do standby que os registros estavam sendo aplicados, ou seja, a aplicação verificada estava funcionando.

Nesse ponto, tínhamos um banco de dados em espera funcionando novamente. Criamos uma tabela simples no primário e inserimos uma linha de dados nela, realizamos as trocas de log novamente e, em seguida, abrimos o modo de espera no modo READ ONLY para verificar se a transação foi reproduzida no modo de espera como deveria. Quando estivermos convencidos de que o banco de dados standby estava funcionando, precisamos torná-lo um banco de dados RAC. Bem, já está tudo pronto para que este seja um banco de dados RAC porque já foi. Para finalizar o trabalho, apenas encerramos o banco de dados standby de instância única (SHUTDOWN ABORT) no SQL*Plus e, em seguida, usamos srvctl para iniciar o standby como um banco de dados RAC:

srvctl start database -d standby -o mount

A única coisa que restava neste momento era adicionar o standby de volta à configuração do DG Broker (no DGMGRL):   ADD DATABASE standby

Quando isso aconteceu pela primeira vez, eu estava nervoso como seria um banco de dados tão grande. Nenhuma das operações acima depende do tamanho, exceto copiar os arquivos de e para a mídia. Mas tudo correu bem.

Para garantir que não tenhamos essa situação no futuro, adicionamos alertas ao nosso Oracle Enterprise Manager Grid Control. Agora, receberei um alerta de AVISO quando o envio de logs ou a aplicação de logs estiver 12 horas atrasado e um alerta CRÍTICO quando estiver 24 horas atrasado. Isso deve nos dar tempo suficiente para corrigir quaisquer problemas antes que os redo logs arquivados sejam removidos automaticamente após 7 dias ou, no mínimo, altere o processo para manter mais dias de redo logs arquivados até corrigirmos a situação.