Uma desfragmentação ESEUTIL de um repositório do Exchange também executa uma verificação / reparo de integridade?

4

No início desta manhã, o store.exe ficou confuso de uma forma ou de outra, o que exigiu a reinicialização do nosso servidor Exchange. Ele voltou on-line sem erros ou problemas, todos os logs de transação foram reproduzidos com sucesso e todos os armazenamentos montados normalmente. Para mim, foi apenas um daqueles acidentes aleatórios; no entanto, nosso consultor suspeita que tenha sido causado por corrupção em uma das lojas. Talvez ele esteja correto, já que ele tem muito mais experiência do que eu, mas esse não é o ponto.

Para corrigir os erros suspeitos, ele está planejando executar uma desfragmentação ESEUTIL (via PerfectDisk) para consertá-los, o que ele alega também corrigirá quaisquer erros presentes.

Pelo que entendi, desfragmentar, verificar e reparar são 3 ações separadas, e uma desfragmentação não implica em nenhum tipo de verificação de integridade. Isso está correto? Há algum perigo de executar uma desfragmentação direta em um banco de dados que possa estar corrompido?

Editar:

Aqui está o primeiro erro no log de eventos, que indicou 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               ....    
    
por Bigbio2002 24.11.2011 / 00:09

1 resposta

6

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?

    
por 24.11.2011 / 00:24

Tags