Uma desfragmentação offline usando eseutil
falhará se encontrar corrupção no nível da página no banco de dados, porque. Você teria que usar a opção /p
(rePair) para descartar páginas corrompidas.
Corrupção de dados em um nível lógico (pense que os danos aos "dados" no banco de dados, não a "estrutura" do banco de dados) não podem ser reparados por eseutil
. A ferramenta isinteg
pode encontrar inconsistências lógicas no banco de dados nas versões do Exchange até 2007. No Exchange 2010 isinteg
foi substituído pelo new-MailboxRepairRequest
cmdlet ( mais detalhes estão disponíveis no blog da equipe do Exchange ).
Dito tudo isso, estou preocupado com o conselho do seu consultor. Você está vendo eventos no log de eventos do aplicativo do ESE ou serviços relacionados ao Exchange que indicam qualquer dano no banco de dados? Em geral, o Exchange não "falha aleatoriamente" e o problema com um driver de hardware ou o hardware em si parece ser uma causa mais provável do que um problema com o Exchange. Além disso, como os registros são reproduzidos sem problemas, acho um pouco improvável que você esteja sofrendo corrupção no nível da página.
Por fim, se você está sofrendo corrupção no nível da página, apenas limpar essa corrupção não é uma solução. Você precisa encontrar a causa raiz (hardware defeituoso, etc) que está causando a corrupção e eliminá-lo. Fazer qualquer outra coisa é apenas expô-lo a riscos contínuos.
A desfragmentação offline não é, por si só, um grande risco. Você deve fazer um backup completo imediatamente após a conclusão da desfragmentação offline porque todos os backups incrementais e diferenciais anteriores não podem ser restaurados (porque o novo banco de dados é apenas isso - um novo banco de dados). Obviamente, seu servidor ficará inacessível para os usuários durante o período de desfragmentação também.
Eu estaria pesquisando o que aconteceu nesta manhã em detalhes e chegando a uma conclusão de causa raiz (ou pelo menos uma hipótese muito provável) antes de começar a gastar dinheiro "consertando" isso.
Eu tive um caso recente em que uma máquina do Exchange Server 2003 não tirava instantâneos do VSS e relatava vários erros do JET durante tentativas de backup. Eu optei por criar uma nova instalação do Exchange em outra máquina, mover todas as caixas de correio do usuário para a nova máquina, depois excluir o banco de dados problemático no servidor original e permitir que um novo seja criado. Depois que fizemos alguns testes de estresse e verificamos que o servidor original estava funcionando corretamente, movemos todas as caixas de correio de volta. Eu preferiria essa estratégia na situação que você está descrevendo (se eu tivesse mensagens de log de eventos suficientes que indicavam "corrupção" real no banco de dados de caixa de correio do computador original do Exchange Server).
Editar:
A entrada que você postou acima é uma falha no provedor do Exchange para o Microsoft Search (que faz índices de texto completo dos bancos de dados do Exchange). Eu estaria interessado em ver mais do que aconteceu depois, bem como quaisquer eventos imediatamente anteriores a este no log de eventos do sistema. Você tem uma condição de pouco espaço em disco em qualquer um dos volumes do computador servidor?