Corrupção e Recuperação de bases de dados Exchange
Por Rodrigo Sebben
Publicado em: 14 de setembro de 2006
Nesse artigo vou demonstrar uma situação de “catástrofe” onde a base do Exchange corrompe e o como podemos analisá-la e corrigí-la.
Nesta página
Análise do estado da base antes
Analisando o estado da base depois da “catástrofe”
Recuperação com perda de dados
Conclusão
Análise do estado da base antes
Para iniciar os testes e analisar a situação do Exchange Server, vou primeiro parar o serviço Exchange Information Store para então analisar a base e os logs do Exchange.
Parando o Information Store para execução dos testes com ESEUTIL
Vamos agora até o bin do Exchange Server para fazermos a checagem da integridade da base do Exchange.
Start -> Run -> CMD.EXE [ENTER]
Depois vamos até o diretório bin do Exchange, se for uma instalação padrão é
Vamos agora executar o comando eseutil /g C:\program files\exchsrvr\mdbdata\priv1.edb
Aqui podemos ver que a verificação de integridade está OK.
Agora vamos rodar um outro comando para analisarmos o header da base e verificar como se está tudo certo.
Execute agora o “eseutil /mh C:\program files\exchsrvr\mdbdata\priv1.edb” >esemh.txt
Já em seguida ao comando vamos abrir com o notepad o esemh.txt gerado com a saida do comando eseutil /mh.
Podemos ver aqui, no item STATE, que a base está “clean shutdown”, significa que está OK. Log Required também informando que está tudo ok. Repare que aqui também é possível encontrar as informações de quando foi a última vez que ela se encontrou consistente mais abaixo.
Agora vou demostrar como seria a base corrompida durante um shutdown da base de modo brusco. Para isso precisamos primeiro iniciar novamente o Information Store.
Iniciando o Information Store para corrempermos a base.
Para fazermos isso, agora que o serviço está iniciado, vamos abrir o Outlook e realizar uma grande carga para dentro da base, no meu teste eu vou estar fazendo a copia da pasta archive para a minha inbox.
Aqui eu estou copiando todos e-mails da pasta archive para dentro da pasta INBOX – Upload para o Exchange.
Agora, enquanto ele começa a fazer a carga dos e-mails para dentro do Exchange Server, vamos “derrubar” o Information Store de forma brusca usando taskkill.
Taskkill /f /im store.exe
Repetir o mesmo comando para o outlook.
Analisando o estado da base depois da “catástrofe”
Agora que o store.exe foi derrubado, ou seja, o information store foi parado de forma brusca, podemos ir novamente até o diretório bin do Exchange e executar novamente o eseutil para checar a integridade da base.
A mensagem é exatamento o processo que estamos testando, podemos clicar em CANCEL para não abortar a operação e podemos continuar.
Após a execução pode-se concluir que a base está corrompida.
Agora vamos executar o eseutil /mh para fazer o dump do header da base para termos mais detalhes e abrir depois com o notepad. Caso não lembre do comando, “eseutil /mh C:\program files\exchsrvr\mdbdata\priv1.edb” >esemh.txt
Repare agora que o STATE está como “Dirty Shutdown” e o Log Required informando quais arquivos logs sã necessários para ter a base up-to-date.
Vamos iniciar novamente agora o serviço do Information Store.
Nesse momento em que o serviço é iniciado, podemos analisar pelo Event Viewer que inínio da recuperação, pelo evento 300.
E a reaplicação dos logs que estavam faltando pelo evento 301.
E finalmente o evento informando que o processo foi realizad com sucesso, evento 302.
Pronto, aqui já termos a base atualizada novamente.
Recuperação com perda de dados
Mas fica aqui uma outra questão, quando ocorreu nossa “catástrofe”, o aconteceria se tivesses perdido nosso transaction log corrente, onde estavam as informações a serem atualizadas na base. Ou mesmo caso o antivirus de sua empresa tenha deletado ele.
Vou descrever aqui como podemos fazer nessa questão.
Antes disso precisamos seguir os mesmo passos para popular a base e durante o upload dos e-mails para a base do Exchange, realizamos o taskkill no store e outlook.
Depois de “derrubado” o store e outlook durante uma atualização, vamos elimiar as informações que estavam no log de transação.
Renomear o arquivo e00.log para e00.old (log de transação corrente).
Vamos iniciar o Information Store e analisar como se comportará.
Podemos ir até o Event Viewer e ver os eventos 455 informando que o e00.log está faltando.
E o evento 9518, informando que falhou para inicializar as bases.
Analisando o System Manager, veremos que as bases não subiram.
Se tentarmos montar as bases teremos a seguinte mensagem de erro informando que não possível executar essa operação.
Agora vou executar o parametro do ESEUtil para reparar essa base. Esse comando deve ser a última opção, deve-se primeiro testar todas as outras alteranativas antes de executa-lo.
Executar o “eseutil /p C:\program files\exchsrvr\mdbdata\priv1.edb /s C:\program files\exchsrvr\mdbdata\priv1.stm”.
Inicializando o modo de reparação, podendo clicar em OK. Nesse caso nós não temos escolha.
Aqui ele terminou conseguindo realizar a recuperação e já aproveita para fazer a recomendação do backup – IMPORTANTE!!
NÃO ESQUEÇA DE REALIZAR O MESMO PROCEDIMENTO PARA BASE DESTINADA AS PASTAS PÚBLICAS
Agora nós podemos deletar os logs de transação, pois o exchange irá criar os arquivos novamente.
Deixando apenas as bases.
Vou agora reinicar o serviço do Information Store.
Agora podemos ver que as bases já podem ser montadas.
Conclusão
Podem haver vários tipos de desastres que podem ocorrer com a base do Exchange Server, mas a Microsoft disponibilizou o ESEUtil para verificação da integridade da base, reparação, etc.
A utilização do parâmetro /p (repair mode) deve ser executado em última ocasião.