Voltar

Por que eu devo ler este artigo:Este artigo apresenta como podemos realizar o recover do banco de dados em uma situação onde não temos um backup consistente, seus archives foram perdidos, ou não possui todos os archives necessários ou, ainda, seu banco está sem o modo de arquivamento ativo e você precisa recuperá-lo caso contrário sua empresa continuará com as operações interrompidas.

Utilizaremos o parâmetro “_allow_resetlogs_corruption”. Este parâmetro propõe que a base de dados seja aberta sem consistência, ou seja, nem todos os datafiles precisam estar no mesmo SCN.

O conteúdo deste artigo também é válido para situações como um restore/recover de banco de dados iniciado que ficou incompleto devido ao número insuficiente de archives aplicados para tornar o datafile consistente.

Este artigo apresentará uma situação real de uma empresa que utiliza banco de dados Oracle Standard 11g. O ambiente citado neste artigo possui uma arquitetura de banco de dados single instance, não possui redundância e se utilizasse Oracle Dataguard, teria evitado o problema que abordaremos. Ainda não havia monitoração, manutenção e nem gerenciamento do ambiente de banco de dados.

Um certo dia ocorreu uma parada inesperada do servidor devido a uma queda de energia e consequente falha do nobreak. Assim que o servidor retornou para sua normalidade, foram constatados danos no banco de dados. Verificamos os erros no banco através do alert log e pudemos constatar que seria necessário seu restore e recover.

Nesse momento começou o problema, aliás um enorme problema. Verificamos o backup e para dificultar a situação não tínhamos backup físico e muito menos backup lógico do banco de dados. Havia um único backup existente, porém não era consistente, não estava atualizado e além disso tudo ainda não tinha os archives necessários para a recuperação do banco.

Para a recuperação do ambiente devemos tentar todas as formas indicadas pela Oracle, mas existem casos como este que estamos apresentando no artigo que não há soluções previstas (ou pelo menos bem documentadas) e ficamos restritos a casos emergenciais. Para lidar com ele utilizamos o parâmetro “allow_resetlogs_corruption=true”. Este parâmetro não é documentado pela Oracle e deve ser utilizado apenas em casos emergenciais. Ele permite que a base de dados seja aberta sem consistência, ou seja, nem todos os datafiles precisam estar no mesmo SCN (system change number).

Alguns pontos que serão citados no artigo são: control files, SCN, Redo Log File, multiplexação de redo log files, e estágios de inicialização de um banco de dados Oracle. Além disso, mostrarem ...

Quer ler esse conteúdo completo? Tenha acesso completo