Ramificações da execução do comando eseutil /p ou edbutil /d /r no Exchange

Uma reparação forçada ocorre quando executa um comando eseutil /p ou edbutil /d /r num ficheiro de base de dados do Exchange Server, tal como a base de dados Priv.edb, Pub.edb ou Dir.edb. A reparação percorre a base de dados e verifica e repara as estruturas críticas dentro da base de dados (tais como tabelas de sistema, tabelas de anexos, etc.) e verifica se existem páginas danificadas nas bases de dados.

Se a reparação encontrar uma página danificada (por exemplo, uma soma de verificação inválida causada por uma modificação na página que não foi efectuada por Jet), a página é eliminada (-1018). Quando isto ocorrer, os dados críticos poderão perder-se depois de a reparação terminar. Estes dados poderão fazer parte de uma mensagem de correio electrónico, de um compromisso de calendário, de uma nota, de um anexo ou, no pior dos cenários, de uma tabela de sistema.

Se essa tabela de sistema for a tabela de anexos, todos os utilizadores no servidor poderão perder os anexos das respectivas mensagens. Este é apenas um dos cenários possíveis, mas se existirem páginas danificadas na base de dados, serão perdidos dados após uma reparação forçada.

Importante: é sempre aconselhável restaurar a partir de uma cópia de segurança sempre que for possível.

Se restaurar a partir de uma cópia de segurança, garante que tem uma base de dados correcta, limpa e estável que será iniciada e executada no servidor. Em quase todas as circunstâncias, é mais rápido e mais fiável restaurar a partir de uma cópia de segurança do que executar uma reparação forçada na base de dados. Isto porque a reparação é executada a uma velocidade de 4 a 6 gigabytes (GB) por hora, aproximadamente, e o utilizador terá de executar o processo Isinteg depois da reparação, que é executado a uma velocidade de 3 a 6 GB por hora, aproximadamente. (Estes valores correspondem à média; o desempenho poderá variar consoante o número de vezes que a reparação tiver de percorrer a base de dados e consoante a velocidade do hardware.)

Por exemplo, se utilizar a configuração de hardware mais rápida possível, uma base de dados de 50 GB requer aproximadamente 8 horas de reparação e aproximadamente 8 horas para o processo Isinteg, perfazendo um total de 16 horas. Se utilizar uma banda linear digital (DLT, digital linear tape) 35/70 normal com ligação Wide SCSI, cuja média de restauro é de cerca de 3 megabytes (MB) por segundo, a mesma base de dados precisará de aproximadamente 5 horas de restauro. Isto constitui uma poupança de tempo de 11 horas. Os sistemas de cópia de segurança do tipo "instantâneo" de velocidade extremamente elevada, tal como o sistema da EMC Corporation, podem restaurar uma base de dados deste tamanho em minutos.

Se não tiver nenhuma cópia de segurança e se a única hipótese for a execução de uma reparação forçada na base de dados, siga estes passos:

1. Execute uma reparação forçada na base de dados utilizando Eseutil /p ou Eseutil /d /r.
2. Desfragmente a base de dados utilizando Eseutil /d. A desfragmentação offline cria uma nova estrutura de base de dados física e move os dados existentes para essa estrutura.
3. Verifique a consistência da base de dados utilizando Isinteg -fix. Poderá ter de executar Isinteg diversas vezes até o relatório de resumo não devolver nenhum erro.

Para obter mais informações, clique no número de artigo que se segue para visualizar o artigo na base de dados de conhecimento da Microsoft (KB, Microsoft Knowledge Base):
O utilitário Isinteg corrige os problemas lógicos que podem surgir quando executa uma reparação forçada:

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

Nota: não pode executar o comando Isinteg -fix numa base de dados Dir.edb. Além disso, é recomendável não executar um directório com reparação forçada num ambiente de produção.

Para obter mais informações sobre a recuperação de desastres do Exchange, clique no número de artigo que se segue para visualizar o artigo na base de dados de conhecimento da Microsoft (KB, Microsoft Knowledge Base): Depois de executar o comando eseutil /p ou edbutil /d /r nas bases de dados Priv.edb ou Pub.edb, as bases de dados poderão apresentar os seguintes sintomas:

• O arquivo de informações não pára ou deixa de responder.
• O arquivo de informações deixa de aceitar correio do agente de transferência de mensagens (MTA, message transfer agent).
• O correio electrónico permanece nas pastas A enviar (Outbox) dos utilizadores.
• O programa Store.exe é executado com uma utilização da CPU muito elevada sem carga no servidor.
• O programa Store.exe gera uma violação de acesso se existir uma carga pesada.
• Os utilizadores não conseguem abrir anexos de correio electrónico nem mensagens de correio electrónico.

Depois de executar uma reparação forçada numa base de dados com muitos danos, não é aconselhável a utilização num ambiente de produção até ter efectuado também a desfragmentação offline seguida de isinteg. Execute uma reparação forçada na base de dados apenas como último recurso; se for possível, restaure sempre a partir de uma cópia de segurança.

Se executar Isinteg múltiplas vezes e não corrigir os danos da base de dados, tem de utilizar o utilitário Exmerge para extrair dados de uma base de dados e colocá-los noutra base de dados:

Para determinar se uma reparação forçada foi executada na base de dados, copie o cabeçalho utilizando a seguinte linha de comandos (a contagem da reparação ficará a zeros se as bases de dados não tiverem sido reparadas): O seguinte é um exemplo de um cabeçalho de Priv.edb: