Ramificações ao executar o comando eseutil/p ou edbutil/d/r no Exchange

Um reparo (hard repair) ocorre ao executar um comando eseutil /p ou edbutil /d /r em um arquivo de banco de dados do Exchange Server, como por exemplo o banco de dados Priv.edb, Pub.edb ou Dir.edb. O reparo ocorre por todo o banco de dados, verifica e repara estruturas críticas internamente (como tabelas do sistema, tabelas de anexo e assim por diante) e procura por páginas danificadas nos banco de dados.

Se o reparo encontrar uma página danificada (por exemplo, um checksum inválido causado por uma modificação na página que não foi realizada pelo Jet) ele excluirá a página (-1018). Quando isso acontece, dados críticos podem ser perdidos após a conclusão dos reparos. Esses dados podem ser parte de uma mensagem de email, um compromisso do calendário, uma anotação, um anexo ou na pior das situações, parte de uma tabela do sistema.

Se essa tabela do sistema for a tabela de anexos, todo usuário no servidor pode perder os anexos de suas mensagens. Essa é somente uma das situações possíveis, mas se houver páginas danificadas no banco de dados, os dados serão perdidos após o reparo.

Importante É aconselhável fazer a restauração de um backup sempre que possível.

Se fizer isso, terá a certeza de que possui um banco de dados válido, limpo e estável que irá iniciar e ser executado no servidor. Em quase todas as circunstâncias, é mais rápido e confiável restaurar a partir de um backup do que realizar um reparo no banco de dados. Isso porque o reparo é executado em aproximadamente 4 a 6 gigabytes (GB) por hora e você deve executar o processo Isinteg após o reparo, que executa em aproximadamente 3 a 6 GB por hora. (Essas taxas são a média; o desempenho pode variar dependendo de quantas etapas o reparo deve realizar no banco de dados e a velocidade do hardware.)

Por exemplo, se você usar a configuração de hardware mais rápida possível, um banco de dados de 50 GB requer aproximadamente 8 horas para o reparo e aproximadamente 8 horas para o processo Isinteg, resultando em um total de 16 horas. Se você usar uma típica DLT (digital linear tape) 35/70 conectada a Wide SCSI, que realiza a restauração com uma média de 3 megabytes (MB) por segundo, o mesmo banco de dados precisará de aproximadamente 5 horas para a restauração. Isso é uma economia de tempo de 11 horas. Sistemas de backup do tipo "snapshot" com velocidade muito alta, como o sistema da EMC Corporation, podem restaurar um banco de dados desse tamanho em questão de minutos.

Se você não possuir um backup e não tiver nenhuma outra opção além de executar um reparo no banco de dados, execute as seguintes etapas:

1. Execute um reparo no banco de dados usando Eseutil /p ou Eseutil /d /r.
2. Desfragmente o banco de dados usando Eseutil /d. A desfragmentação offline cria uma nova estrutura física de banco de dados e move os dados existentes para essa estrutura.
3. Verifique a consistência do banco de dados usando Isinteg -fix. Pode ser necessário executar o Isinteg diversas vezes até que o relatório de resumo não retorne nenhum erro.

Para obter informações adicionais, clique no número abaixo para ler o artigo na Base de Dados de Conhecimento da Microsoft:
O utilitário Isinteg corrige os problemas lógicos que podem ocorrer ao executar um reparo:

• Para o armazenamento de informações particulares do Exchange Server 4.0 e 5.0, execute o seguinte comando:
  isinteg -fix -pri
• Para o armazenamento de informações públicas do Exchange Server 4.0 e 5.0, execute o seguinte comando:
  isinteg -fix -pub
• Para o armazenamento de informações particulares do Exchange Server 5.5, execute o seguinte comando:
  isinteg -pri -fix -test alltests
• Para o armazenamento de informações públicas do Exchange Server 5.5, execute o seguinte comando:
  isinteg -pub -fix -test alltests

Observação Não é possível executar o comando Isinteg -fix no banco de dados Dir.edb. Além disso, recomendamos que não execute um diretório que sofreu um reparo em um ambiente de produção.

Para obter informações adicionais a recuperação de erros do Exchange, clique no número abaixo para ler o artigo na Base de Dados de Conhecimento da Microsoft: Após executar o comando eseutil /p ou edbutil /d /r nos bancos de dados Priv.edb ou Pub.edb, eles devem exibir os seguintes sintomas:

• O armazenamento de informações irá parar de responder ou não.
• O armazenamento de informações para de aceitar email do agente de transferência de mensagens (MTA).
• Os emails permanecem nas caixas de saída dos usuários.
• O programa Store.exe executa com uso muito alto da CPU sem nenhuma carga no servidor.
• O programa Store.exe gera uma violação de acesso se houver uma carga pesada.
• Os usuários não podem abrir anexos ou mensagens de email.

Após executar um reparo em um banco de dados com muitos danos, ele não fica adequado para o uso na produção até que você realize a desfragmentação off-line seguida pelo isinteg. Apenas execute um reparo no banco de dados como última opção; se possível, sempre restaure a partir de um backup.

Se o Isinteg for executado diversas vezes e não corrigir a corrupção do banco de dados, será necessário usar o utilitário Exmerge para extrair os dados de um banco de dados e colocá-los em outro:

Para determinar se um reparo foi executado no banco de dados, despeje o cabeçalho usando a seguinte linha de comando (a contagem do reparo será zero se os bancos de dados não tiverem sido reparados): A seguir está um exemplo de um cabeçalho do Priv.edb: