No início desta manhã, store.exe ficou confuso de uma forma ou de outra, o que exigiu a reinicialização de nosso servidor Exchange. Ele voltou a ficar online sem erros ou problemas, todos os logs de transações foram reproduzidos com êxito e todos os armazenamentos foram montados normalmente. Para mim, foi apenas uma daquelas falhas aleatórias; no entanto, o nosso consultor suspeita que tenha sido causado por corrupção numa das lojas. Talvez ele esteja certo, já que tem muito mais experiência do que eu, mas esse não é o ponto.
Para corrigir os erros suspeitos, ele planeja executar uma desfragmentação ESEUTIL (via PerfectDisk) para corrigi-los, que ele afirma também corrigirá quaisquer erros presentes.
Pelo que entendi, desfragmentar, verificar e reparar são três ações separadas, e uma desfragmentação não implica nenhum tipo de verificação de integridade.Isso está correto? Existe algum perigo em executar uma desfragmentação direta em um banco de dados que pode estar corrompido?
Editar:
Aqui está o primeiro erro no log de eventos, que indicava o início dos problemas que estávamos tendo. Alguém sabe o que isso pode indicar?
Event Type: Error
Event Source: Microsoft Exchange Server
Event Category: None
Event ID: 1000
Date: 11/23/2011
Time: 8:15:47 AM
User: N/A
Computer: SERVER
Description:
Faulting application exsp.dll, version 6.5.7638.1, stamp 430e735b, faulting module kernel32.dll, version 5.2.3790.4480, stamp 49c51f0a, debug? 0, fault address 0x0000bef7.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 41 00 70 00 70 00 6c 00 A.p.p.l.
0008: 69 00 63 00 61 00 74 00 i.c.a.t.
0010: 69 00 6f 00 6e 00 20 00 i.o.n. .
0018: 46 00 61 00 69 00 6c 00 F.a.i.l.
0020: 75 00 72 00 65 00 20 00 u.r.e. .
0028: 20 00 65 00 78 00 73 00 .e.x.s.
0030: 70 00 2e 00 64 00 6c 00 p...d.l.
0038: 6c 00 20 00 36 00 2e 00 l. .6...
0040: 35 00 2e 00 37 00 36 00 5...7.6.
0048: 33 00 38 00 2e 00 31 00 3.8...1.
0050: 20 00 34 00 33 00 30 00 .4.3.0.
0058: 65 00 37 00 33 00 35 00 e.7.3.5.
0060: 62 00 20 00 69 00 6e 00 b. .i.n.
0068: 20 00 6b 00 65 00 72 00 .k.e.r.
0070: 6e 00 65 00 6c 00 33 00 n.e.l.3.
0078: 32 00 2e 00 64 00 6c 00 2...d.l.
0080: 6c 00 20 00 35 00 2e 00 l. .5...
0088: 32 00 2e 00 33 00 37 00 2...3.7.
0090: 39 00 30 00 2e 00 34 00 9.0...4.
0098: 34 00 38 00 30 00 20 00 4.8.0. .
00a0: 34 00 39 00 63 00 35 00 4.9.c.5.
00a8: 31 00 66 00 30 00 61 00 1.f.0.a.
00b0: 20 00 66 00 44 00 65 00 .f.D.e.
00b8: 62 00 75 00 67 00 20 00 b.u.g. .
00c0: 30 00 20 00 61 00 74 00 0. .a.t.
00c8: 20 00 6f 00 66 00 66 00 .o.f.f.
00d0: 73 00 65 00 74 00 20 00 s.e.t. .
00d8: 30 00 30 00 30 00 30 00 0.0.0.0.
00e0: 62 00 65 00 66 00 37 00 b.e.f.7.
00e8: 0d 00 0a 00 ....
Responder1
Uma desfragmentação offline eseutilfalhará se encontrar corrupção no nível da página no banco de dados porque. Você teria que usar a /popção (rePair) para descartar páginas corrompidas.
A corrupção de dados em um nível lógico (pense em danos aos “dados” do banco de dados, não à “estrutura” do banco de dados) não pode ser reparada pelo eseutil. A isintegferramenta consegue encontrar inconsistências lógicas no banco de dados em versões do Exchange até 2007. No Exchange 2010 isintegfoi substituído pelo new-MailboxRepairRequestcmdlet (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 de serviços relacionados ao Exchange que indicam qualquer corrupção do banco de dados? Em geral, o Exchange não "trava aleatoriamente" e problemas com um driver de hardware ou com o próprio hardware parecem ser uma causa mais provável do que um problema com o Exchange. Além disso, como os logs foram reproduzidos sem problemas, acho um pouco improvável que você esteja corrompendo o nível da página.
Finalmente, se você estiver corrompida no nível da página, apenas limpá-la não é uma solução. Você precisa encontrar a causa raiz (hardware defeituoso, etc.) que está causando a corrupção e eliminá-la. Fazer qualquer outra coisa é apenas expor você 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 banco de dados totalmente novo). Obviamente, seu servidor também ficará inacessível aos usuários durante o período de desfragmentação.
Eu estaria pesquisando detalhadamente o que aconteceu esta manhã e chegando a uma conclusão sobre a causa raiz (ou pelo menos uma hipótese muito provável) antes de começar a gastar dinheiro "consertando" o problema.
Tive um caso recente em que uma máquina Exchange Server 2003 não tirava instantâneos do VSS e relatou vários erros de JET durante tentativas de backup. Optei por iniciar uma nova instalação do Exchange em outra máquina, mover todas as caixas de correio dos usuários para a nova máquina e, em seguida, excluir o banco de dados problemático no servidor original e permitir a criação de um novo. Depois de fazermos alguns testes de estresse e verificarmos se 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 suficientes do Log de Eventos que indicassem "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 cria índices de texto completo dos bancos de dados do Exchange). Eu estaria interessado em ver mais sobre o que aconteceu depois, bem como quaisquer eventos imediatamente anteriores a este no Log de Eventos do Sistema. Você teve uma condição de pouco espaço em disco em algum dos volumes do computador servidor?
Responder2
A desfragmentação ESEUTIL não é dedicada exclusivamente ao reparo extensivo do banco de dados do Exchange. A função de desfragmentação visa recuperar espaço livre no banco de dados e otimizar o desempenho do banco de dados criando um novo arquivo de banco de dados compactado.
Enquanto você executa a desfragmentação, ela também pode realizar alguns reparos no banco de dados ao encontrar alguma inconsistência ou problema. Esta é parte do processo geral de desfragmentação e pode corrigir pequenos problemas.
Se o seu banco de dados do Exchange Server estiver corrompido, é recomendável primeiro executar o comando ESEUTIL /mh para verificar o status completo do seu banco de dados. Se você encontrou, o banco de dados está em estado sujo. Posteriormente, você pode usar os comandos ESEUTIL /P ou ESEUTIL /R conforme o dano ao banco de dados. Certifique-se de fazer backup do seu banco de dados antes de tentar qualquer operação de reparo.
Aconselhei consultar o suporte da Microsoft para garantir as etapas de recuperação adequadas.
Você pode consultar estes artigos da Microsoft: