Reparo de EDB na troca SBS 2003

1

Uma semana antes, em nosso servidor HP PROLIANT ML370 G5 com RAID5, um disco rígido ficou amarelo e nós o removemos e ele está funcionando em estado degradado até agora.

Ontem de manhã, nossos usuários no domínio reclamaram que os e-mails não estão saindo de seu OUTLOOK conectado à nossa troca sbs 2003.Todos os usuários estão configurados com psts. Não. Depois de verificar o ESM verificou-se que todos os e-mails estavam em fila e conectividade com a Internet e smtp host inteligente todos alcançáveis.Assim, os serviços de troca foram reiniciados, em que descobrimos que o armazenamento de informações está começando no último momento ele pára com erro 1068.

Nós reiniciamos o servidor, demorou muito tempo para chegar ao desktop e descobriu-se que o armazenamento de informações não foi iniciado. O que é observado é que quando o serviço de armazenamento de informações é iniciado, o servidor fica totalmente travado; Tivemos que fazer um hard reset no servidor algumas vezes quando estamos solucionando problemas.

Após pesquisar na Internet, descobrimos que a corrupção de arquivos edb do armazenamento de informações leva a esse sintoma a partir do link link

e agora estamos consertando o banco de dados de acordo com este documento; ele cruzou priv1 .edb com sucesso, mas nas últimas 4 horas o catálogo de banco de dados de varredura pub1.edb e stm está em andamento.

Por favor, me avisem sobre como prosseguir, já que tenho que prepará-lo amanhã de manhã para este servidor de produção

N.B: o banco de dados priv1.edb e seus arquivos relacionados - 9 GB & arquivos pub1.edb e stm -2 GB

Obrigado & Atenciosamente

S.Swaminathan

por Swaminathan Shanmugam 06.02.2012 / 17:27

2 respostas

2

Parece-me que você tem problemas de hardware (provavelmente mais erros no RAID já degradado).

O serviço Armazenamento de Informações não tornará o servidor "totalmente travado", não importa o quão "corrompidos" estejam os arquivos de banco de dados. Se a máquina estiver travando ao tentar montar o armazenamento de informações, você não conseguirá executar um reparo bem-sucedido nesse hardware.

Mesmo que você consiga reparar o banco de dados, não é uma boa idéia continuar executando uma instalação do Exchange de produção a partir de um banco de dados que foi reparado. Se você conseguir repará-lo, seria melhor mover as caixas de correio do servidor para outra instância do Exchange e jogar fora esse banco de dados reparado.

Neste ponto, eu estaria executando uma instalação de recuperação de desastres do Exhcange, restaurando seu backup mais recente do Exchange em um novo servidor (máquina virtual, etc.) e afastando-se do hardware com falha que provavelmente causou seus problemas começar com. Continuar a fornecer um serviço de produção em hardware que já causou tempo de inatividade e corrupção de dados é uma má ideia.

Se você não tiver um backup, pelo menos, espero que tenha feito o backup dos arquivos do banco de dados antes de tentar repará-los. Você poderia tentar reparar esses arquivos em outra máquina (o Exchange não precisa ser instalado para que o ESEUTIL funcione - uma cópia do diretório "Bin" do Exchange fará para fornecer os arquivos necessários para executá-lo).

Se você não tiver nenhum backup, poderá ter perdido seu Armazenamento de Informações Públicas (pub1.edb e pub1.stm). Como você disse que o seu Armazenamento de Informações Privadas não foi reparado com êxito (priv1.edb e priv1.stm), você ainda poderá obter dados da caixa de correio do usuário.

    
por 06.02.2012 / 17:47
1

Confira a seção Recuperação de desastres deste link.

link

Você precisará executar o ISINTEG no final para garantir que você tenha um bom reparo com o ESEUTIL.

    
por 06.02.2012 / 17:39