Noções sobre e analisar -1018, -1019 e-1022 trocarem erros de base de dados

Traduções de Artigos Traduções de Artigos
Artigo: 314917 - Ver produtos para os quais este artigo se aplica.
Expandir tudo | Reduzir tudo

Nesta página

Sumário

Este artigo fornece informações para ajudar a compreender e analisar-1018, -1019 e-1022 erros de base de dados do Exchange. Este artigo descreve as diferenças entre estes três erros e os tipos de problemas na base de dados que fazem com que cada um destes três erros sejam comunicados.

Mais Informação

Exchange inclui a funcionalidade para detectar danos de nível de ficheiro para páginas nas suas bases de dados. Os três erros mais comuns que estão associados a danos de nível de ficheiro para uma base de dados do Exchange são os seguintes:
  • JET_errReadVerifyFailure -1018
  • JET_errPageNotInitialized -1019
  • -1022 JET_errDiskIO
Podem ocorrer os seguintes três níveis de danos numa base de dados do Exchange:
  • Nível de página (sistema de ficheiros)
  • Nível de base de dados (JET database engine)
  • Nível da aplicação (Exchange information store)
O utilitário Esefile pode detectar erros nas bases de dados ao nível da página. O utilitário Eseutil. exe pode detectar e reparar problemas a nível da página e o nível de base de dados. O utilitário Isinteg. exe detecta e repara problemas ao nível da aplicação.

Danos num valor mais baixo nível (o nível de página) quase sempre resultados em problemas aos níveis mais elevados (o nível da base de dados ou aplicação). Por conseguinte, depois de reparar uma base de dados com o Eseutil, quase sempre tiver de utilizar Isinteg mais tarde.

Danos ao nível da base de dados e a aplicação está relacionada com problemas no código do Exchange ou programas de outros fabricantes que integram com o Exchange. Danos ao nível da página é tipicamente causado por controladores, firmware ou problemas de hardware, apesar de danos de nível de página também podem ser causado por problemas do Exchange.

Quase sempre encontrar a causa raiz para um erro -1018 em um dos sistemas subjacentes que depende do Exchange e não código no Exchange propriamente dito. Existem muito poucas excepções a esta regra. As excepções a data foram no que diz respeito ao Exchange fornecer informações sobre uma condição -1018, não porque Exchange próprio provoca um erro -1018. Para mais informações, clique nos números de artigo que se segue para visualizar os artigos na Microsoft Knowledge Base:
237953Erro -1018 inadequadas devolvido durante a cópia de segurança online
230215 Checksuming cópia de segurança não efectuada em computadores de processador único
Embora a maioria dos erros-1019 e-1022 também são causados por uma falha num sistema subjacente, não é possível excluir a possibilidade que-1019 e-1022 erros poderão ocorrer no Exchange devido a um erro de código tão rapidamente.

Erro -1018 é o erro mais frequentemente visto, que indica que uma base de dados do Exchange tenha sofrido danos ao nível do sistema de ficheiro. Por conseguinte, a maior parte do presente artigo foca erro -1018.

Existem três formas fundamentais de que os dados no disco podem ficar danificados:
  • Dados errados são escritos no suporte de armazenamento.
  • Dados são escritos para o local errado no suporte de armazenamento.
  • Dados estão danificados ou alterados depois de ser armazenado.
Embora seja muito difícil de evitar ou corrigir a 100 por cento de todos os danos, é relativamente fácil detectar um problema que tenha ocorrido. Exchange detecta dados incorrectos e colocados em outros locais nos respectivos ficheiros de base de dados e comunica um erro -1018 ou erro -1019. Se um ficheiro tiver sido gravemente danificado e partes do mesmo faltam inteiramente ou caso contrário, estão inacessíveis quando o Exchange tenta ler o ficheiro, é comunicado um erro de-1022.

Como o Exchange calcula as somas de verificação e páginas de base de dados de números

Para compreender como funcionam os mecanismos que accionam-1018 e -1019 erros, tem de compreender como uma base de dados do Exchange armazena páginas de dados.

Ao mais baixo nível lógico, pode visualizar um ficheiro de base de dados do Exchange como um conjunto de páginas de 4 quilobytes (KB), numerados por ordem sequencial. Dados é lida e escritos para uma página de um do Exchange da base de dados ao mesmo tempo.

Cada página que contém dados armazena o próprio número de página, juntamente com uma soma de verificação que é calculado a partir de todos os dados na página. No próprio valor de soma de verificação é a única parte da página que não está incluída neste cálculo.

Algoritmos de soma de verificação, incluindo o algoritmo de soma de verificação que o Exchange utiliza, são bem definidos e relativamente simples. Serem concebidos para que é provável que a mesma soma de verificação irá resultar para quaisquer duas páginas diferentes é baixas, mesmo se a diferença entre as páginas é apenas um único bit.

Embora um teste de soma de verificação seja suficiente para determinar se é ou não a página foi alterada desde que foi escrito, um teste de soma de verificação não é suficiente para se certificar de que a página está no lugar correcto. Deste modo, o Exchange marca cada página com o próprio número de página, bem como uma soma de verificação.

As duas primeiras páginas de 4 KB na base de dados estão reservadas para a base de dados "cabeçalho". Quando a base de dados for parado, pode utilizar o utilitário Eseutil /MH mudar para a visualizar este cabeçalho. O cabeçalho contém informações de identificação sobre a base de dados como um todo.

Depois destas páginas duas primeiras cabeçalho, todas as outras páginas na base de dados são dados. Todas as páginas de dados partilham uma estrutura comum. Cada página tem o seu próprio cabeçalho de página, que contém informações de identificação sobre determinada página, seguida de dados reais.

Uma vez que a primeira página de dados numa base de dados do Exchange está localizada após as primeiras páginas do cabeçalho de dois, página física 3 na base de dados é página lógica 1. 2 é o número de página lógica da página física 4 e assim sucessivamente.

Números de página lógica na base de dados mapeiam directamente para números de página física pela seguinte fórmula:
número de página lógica = número de página física - 2
Uma vez que as estruturas lógica e física de página do ficheiro da base de dados estão tão intimamente relacionadas, o Exchange pode facilmente determinar se cada página lógica é na localização física correcta no ficheiro.

As páginas apenas na base de dados para o qual uma soma de verificação não é calculada são "páginas não inicializadas." Estes são os blocos de páginas que são criados quando o tamanho da base de dados é expandido para criar espaço para mais dados. Uma página não inicializada é aquele que tem uma soma de verificação zero e um número de página zero. Normalmente, cada byte de uma página não inicializada é preenchido com carácter 0x00.

Depois de uma página não inicializada é utilizada pela primeira vez, não regressa ao Estado não inicializada, mesmo que esta ser esvaziada. Em vez disso, é definido um sinalizador na página esvaziada para marcá-lo disponível para reutilização. A página ainda executa um número de página e a soma de verificação, mesmo quando está vazia.

Exchange Server 2003 Service Pack 1 (SP1) alterado o algoritmo de soma de verificação e o formato de página que são utilizados. Além disso, o Exchange Server 2003 SP1 Introduzido um erro com o algoritmo de código (ECC) para detectar e corrigir automaticamente erros de bit único a corrigir.Para mais informações sobre esta nova funcionalidade, clique no número de artigo seguinte para visualizar o artigo na Microsoft Knowledge Base:
867626Novo erro corrigir código está incluído no Exchange Server 2003 Service Pack 1

O que provoca um erro -1018

Exchange comunica um erro -1018 quando uma página inicializado no ficheiro de base de dados for encontrado com qualquer uma das seguintes condições:
  • A soma de verificação que está armazenada na página não correspondam ao resultado do novo cálculo de soma de verificação que é realizado tal como a página é de leitura.
  • O número de página que é armazenado na página não corresponde o número de página que deve estar na página, dada a localização física da página no ficheiro de base de dados.
Exchange poderá ser responsável pela self-generating um erro -1018 se Exchange executa um dos seguintes procedimentos:
  • Constrói uma página que tenha a soma de verificação incorrecta.
  • Constrói uma página correctamente, mas indica ao sistema operativo para escrever a página na localização errada.
Depois de um administrador de sistema encontra um erro -1018, se o administrador executa os testes de diagnóstico de hardware relativamente ao servidor e estes ensaios um relatório sem problemas, o administrador poderá celebrar que Exchange tem de ser responsável pela emissão porque o hardware transmitido a análise inicial.

No entanto, neste caso, após o caso, inquérito posterior pela Microsoft ou hardware fornecedores não estão destapados subtis problemas nos controladores de hardware, firmware ou dispositivo que são efectivamente responsáveis pela danificar o ficheiro de base de dados.

Testes de diagnóstico ordinário poderá detectar todas as falhas transitórias por diversas razões. Problemas no software do firmware ou do controlador poderão sai fora as capacidades de programas de diagnóstico. Testes de diagnóstico poderá ser possível simular adequadamente os tempos de execução longa ou complexas cargas. Além disso, a adição de registo de depuração ou de monitorização diagnóstico poderá alterar o sistema suficiente para impedir que o problema apareça novamente.

A simplicidade e a estabilidade dos mecanismos de Exchange que gerar somas de verificação e escrever páginas no ficheiro de base de dados é outra razão que a probabilidade de que a causa de raiz para um erro -1018 é um problema de Exchange é baixa. A soma de verificação e mecanismos de detecção incorrecta de página são simples, fiável e tem permanecido fundamentalmente o mesmo uma vez que o primeiro Exchange libertar, excepto para pequenas alterações se adaptem às alterações de formato de página de base de dados entre as versões de base de dados.

Para explicar além disso, que é gerada uma soma de verificação para uma página que está prestes a ser escritas no disco depois de todos os outros dados foram escritos para a página, incluindo a página número próprio. Depois do Exchange adiciona a soma de verificação para a página, o Exchange indica ao sistema operativo Microsoft Windows para escrever a página para o disco utilizando o padrão e publicadas Windows application programming interfaces (APIs).

A soma de verificação poderá ser gerada correctamente para uma página mas, em seguida, a página poderá ser escrita para a localização errada no disco rígido. Isto pode ser causado por um erro de memória transitória, tal como "flip de bit". Por exemplo, suponha que o Exchange constrói uma nova versão da página 70. A página propriamente dita não detectar um erro, mas a cópia do número de página que é utilizado pelo controlador de disco ou pelo sistema operativo aleatoriamente for alterada. Este problema poderá ocorrer se 70 (binário 100110) foi alterado para 6 (000110 binários) por uma célula de memória instável. Soma de verificação da página está correcta, mas a localização da página na base de dados agora está errada. Exchange comunica um erro -1018 da página quando detecta que o número de página lógica não corresponde a localização física da página. Outro tipo de numeração de páginas (causado pelo Exchange) de erro poderá ocorrer se o Exchange escreve o número de página errados na própria página. Mas isto faz com que outros erros, não o erro -1018. Se o Exchange escreve 71 na página 70 e, em seguida, faz a soma de verificação na página correctamente, a página é escrita para localização 71 e transmite tanto as página número e a soma de verificação ensaios.

Frequentemente, um erro -1018 único que é comunicado numa base de dados do Exchange faz com que a base de dados parar ou resultar um sintoma que não seja a presença do erro -1018 propriamente dito. A página pode estar numa pasta que está a ser acedidos com pouca frequência (por exemplo, as enviados ou itens eliminados pastas), ou num anexo que raramente é aberta ou até mesmo vazia.

Apesar de um único erro -1018 é susceptível de causar a perda de dados alargados, -1018 erros são ainda causa de preocupação porque um erro -1018 constitui prova de que o sistema de armazenamento falhou fiavelmente armazenar ou obter dados pelo menos uma vez. Apesar do erro -1018 poderá ser um problema transitório que nunca irá ocorrer novamente, é mais provável que este erro é um aviso antecipado de um problema que irá tornar-se progressivamente pior. Mesmo se o erro primeiro-1018 é numa página vazia na base de dados, não é possível saber qual a página seguinte poderá estar danificada. Se uma tabela global crítica estiver danificada, a base de dados poderá tornar-se unstartable e reparação de base de dados poderá ser apenas parcialmente bem ou mal sucedidas.

Depois de um erro -1018 é registado, tem de considerar e planear a possibilidade de falha iminente ou danos na base de dados suplementares aleatório até localizar e eliminar a causa raiz.

Recuperar de erros -1018

O Exchange trata de uma página que falha com um erro -1018 como completamente ilegíveis para impedir que a acção sobre dados aleatórios causar problemas adicionais na base de dados.

Uma página que falha com um erro -1018 não pode ser reparada ou recuperada. Deve ser expunged da base de dados. Existem três métodos que pode utilizar para expunge a página da base de dados:
  • Restaure a base de dados a partir de uma cópia de segurança online.
  • Utilizar o Eseutil. exe /D Mude para efectuar uma desfragmentação offline da base de dados.
  • Utilizar o Eseutil. exe /P mudar para reparar a base de dados.

Restaurar a base de dados a partir de uma cópia de segurança Online

Se for encontrado um erro -1018 durante a cópia de segurança online, a cópia de segurança pára. Isto garante que a página danificada não existe na última cópia de segurança com êxito. Se o registo circular estiver desactivado, pode restaurar a cópia mais recente disponível e, em seguida, anular a base de dados para a frente dos registos de transacções subsequentes.

Utilizar o Eseutil. exe parâmetro "/a D" para efectuar uma desfragmentação Offline da base de dados

Este método é eficaz se for comunicado o erro -1018 numa página vazia. Se o erro -1018 ocorre apenas durante a cópia de segurança online ou manutenção online efectuadas durante a noite, isto indica que a página é acedida raramente ou que ainda pode estar vazia. Desfragmentação offline rejeita todas as páginas em branco e índices secundários numa base de dados.

Utilizar o Eseutil. exe "/ P" parâmetro para reparar a base de dados

Uma página com erros não for reparada se utilizar este método, mas a página com erros é rejeitada. Se a página que está envolvida for uma página"folha", ocorre perda de alguns dados. Uma página da folha na base de dados é uma página que transporta dados reais. Páginas interiores transportar informações apenas estruturais e lógicas. Na maioria dos casos, o Eseutil pode reconstruir completamente uma tabela se perde-se uma página interior. No entanto, a maioria das páginas numa base de dados são páginas de folha.

Obras de funcionalidade de reparação do Eseutil bem e na maioria dos casos podem restaurar uma base de dados para a operação com perda de dados mínima. No entanto, se muitas páginas danificadas ou tabelas de sistema críticos são perdidas, a perda de dados pode ser resultantes de catástrofes ou a base de dados pode ser unrepairable.

Reparar uma base de dados é normalmente uma estratégia de qualidade inferior em comparação comparada o restauro a partir de uma cópia de segurança e avance a base de dados porque reparação normalmente demora mais tempo do que o restauro e é estruturá. Escolha reparação apenas se:
  • Não tem uma cópia de segurança.
  • Não é possível rollforward completamente da cópia de segurança.
Antes de reparar ou restaurar uma base de dados, efectue sempre uma cópia de segurança dos ficheiros de base de dados actual. Se o restauro não funciona, é possível reparar a base de dados existente. Se a reparação não funciona, mas a cópia anterior da base de dados é ainda iniciável, talvez consiga para recuperar os dados que outro modo seriam perdidos.

Importante Depois de reparar uma base de dados, tem de verificar a contagem de reparação no cabeçalho da base de dados. Se a contagem é superior a zero, terá de efectuar uma desfragmentação offline utilizando o Eseutil e, em seguida, terá de reparar a base de dados ao nível do arquivo de informações com o utilitário Isinteg. Se não o fizer, os utilizadores podem encontrar problemas, tais como uma incapacidade de abrir mensagens e anexos ou referências nas respectivas caixas de correio para itens que já não existirem.

Para verificar a contagem de reparação, examine a saída do ecrã que é gerada quando executa o seguinte comando:
ESEUTIL /MH [nome_fich_base_dados]
Para efectuar uma desfragmentação offline da base de dados reparada, execute o seguinte comando:
ESEUTIL /D [nome_fich_base_dados]
Para efectuar uma correcção de Isinteg completa após uma reparação no Exchange 2000, o serviço de arquivo de informações deve estar em execução, mas tem de ser desmontado a base de dados que pretende reparar. Execute o seguinte comando para a correcção de base de dados:
ISINTEG -S [nome_servidor]-FIX - TEST ALLTESTS
Fazer uma abrangente Isinteg fixar após uma reparação no Exchange Server 5. 5, o arquivo de informações do serviço tem de ser parado. Execute o seguinte comando, utilizando no (de parâmetro adequadas-PRI ou -PUB), dependendo se estiver a executar reparação contra uma base de dados pública ou privada:
ISINTEG-PRI|PUB-FIX - TEST ALLTESTS
Nota Pode executar Eseutil e Esefile contra ficheiros de base de dados não processados independentemente do respectivo ficheiro localizações de sistema. Os ficheiros de base de dados não precisa sequer estar num servidor do Exchange. Mas tem de executar Isinteg enquanto a base de dados está no local num servidor Exchange completamente configurado porque Isinteg funciona ao nível do arquivo de informações e utiliza o serviço de arquivo de informações para aceder à base de dados.

Para mais informações, clique no número de artigo seguinte para visualizar o artigo na Microsoft Knowledge Base:
244525Como executar o Eseutil num computador sem o Exchange Server

Recuperar de um erro -1019

Um erro -1019 (JET_errPageNotInitialized) é reportado quando uma página que é suposta estar em utilização é não inicializado ou está vazio. Se o campo de número de página numa página em utilização for 0x00000000, é comunicado um erro -1019 em vez de um erro -1018, mesmo que a página também poderá falhar o teste de soma de verificação.

Os métodos para corrigir um erro -1019 são idênticas às para corrigir um erro -1018. Tenha em atenção que um problema -1019 pode ir não detectado mais do que um problema -1018 porque -1019 problemas não são detectados pela cópia de segurança online.

Apesar da causa raiz de um erro -1018 será muito provavelmente fora do Exchange, um erro -1019 poderá ser causado pelo Exchange se ponteiros lógicos ou hiperligações entre as páginas são inválidas.

No entanto, é mais comum que um erro -1019 é causado porque o sistema de ficheiros estava danificado ou mapeados páginas para o ficheiro de base de dados que não pertencem no ficheiro.

Recuperar de um erro de-1022

Se o Exchange coloca o sistema operativo para uma página na base de dados e, ocorre um erro em vez dos dados da página a devolver, resulta um erro de-1022 (JET_errDiskIO). O erro-1022 é um erro genérico que aparece sempre que um disco de entrada/saída (e/S) problema impede Exchange obtenham acesso a uma página na base de dados pedida.

A razão mais comum para um erro de-1022 é um ficheiro de base de dados que tenha sido gravemente danificado ou truncado. Se este problema ocorre, o Exchange pede um número de página que é maior do que o número de páginas no ficheiro de base de dados e produz um erro de-1022. Este problema pode ocorrer devido a problemas no sistema de ficheiros de ou devido a reprodução de registo de transacções incorrecto.

Exchange 2000 contém extensivas salvaguardas para impedir a reprodução de registo de transacções que pode danificar a base de dados, mas no Exchange Server 5. 5 foi possível reproduzir um conjunto incompleto de ficheiros de registo e danificar a base de dados. Por exemplo, este problema poderá ocorrer se a reprodução deve iniciar a partir de 9 de registo, mas em vez da reprodução é forçada a iniciar a partir de 10 de registo. Poderá ser forçada a reprodução se um administrador elimina o ficheiro de ponto de verificação e registo 9. Se uma transacção no registo 9 alarga o tamanho da base de dados, mas não é reproduzido registo 9 na base de dados, uma referência no registo 10 para as novas páginas são adicionadas às bases de dados provoca um erro de-1022. Falha súbita, pára (pendentes), e violações de acesso também são sintomas comuns de reproduzir um conjunto de registo de transacções incompletas numa base de dados.

Noções sobre e resolver a causa raiz de um erro de-1022 é mais complexo do que a resolução de problemas de um erro-1018 ou -1019. Se o erro é provocado por danos da base de dados no sistema de ficheiros, é necessário verificar ou reparar o sistema de ficheiros e, em seguida, restaurar o Exchange a partir de uma cópia de segurança. Apesar de reparar a base de dados ainda é uma opção, a reparação é menos provável ser bem sucedido, que, com os outros erros porque um erro de-1022 sinais frequentemente danos extensivos.

De longe a razão mais comum para um erro de-1022 com uma base de dados danificado noutra aplicação, mantendo os ficheiros abertos e impedir o arquivo de informações serviço acedam-los. Em tais casos, também poderá ver erros actualmente em (JET_errFileAccessDenied). Reiniciar todos os serviços do Exchange ou reiniciar o servidor poderá remover o bloqueio.

Programas de outros fabricantes, tais como detectores de vírus, podem bloquear o acesso do Exchange para dados do Exchange. Configure sempre detectores de vírus de nível de ficheiro para excluir ficheiros de dados do Exchange a partir do ficheiro de operação de digitalização. Estão disponíveis vários detectores de vírus que tirar partido do interface de programação de aplicações (API) para pesquisar mensagens e anexos no arquivo de informações de detecção de vírus do Exchange.

Analisar erros-1018 e -1019

As informações nesta secção destina-se principalmente para obter suporte técnico e análise de causa pessoal de fornecedor que estejam envolvido no raiz.

Depois de um administrador encontra um erro-1018 ou -1019, o administrador necessita de saber, pelo menos, três coisas:
  • O que estava na página danificada
  • O que é a probabilidade de reparação com êxito
  • O que causou o dano em primeiro lugar
-erros 1018 e -1019 poderão ocorrer na linha de comandos quando inicia o serviço no registo de eventos de aplicação, ou na saída de utilitários de Exchange, tais como o Eseutil. Não pode ser comunicado um erro -1018 no registo de eventos de aplicações quando executa uma verificação de integridade da base de dados com o Eseutil /G comando. Nesta situação, é provável que a página incorrecta está vazia.

Na maioria dos casos, os erros são reportados num formulário que permita identificar a página que está a comunicar o problema. Também pode pesquisar a base de dados completa com Esefile para identificar páginas danificadas. Para mais informações sobre Esefile, clique no número de artigo seguinte para visualizar o artigo na Microsoft Knowledge Base:
248406Utilitário de suporte Esefile para o Exchange Server 5. 5 e Exchange 2000
Os exemplos seguintes são as descrições de erro -1018 típica de registo de eventos de aplicação para várias versões do Exchange, juntamente com a análise dos detalhes de cada erro.
MSExchangeIS (248) Synchronous read page checksum error -1018
((1:3106 1:3106)(0-310013)(0-312215)) occurred.
Please restore the databases from a previous backup.
					
No exemplo anterior, pode interpretar os números entre parênteses do seguinte modo:
  • (1:3106 1:3106) representa a página na base de dados que foi pedida (página 3106) e o número de página que foi encontrado na realidade escrito na página (página 3106). 1: Indica que se trata de base de dados 1, que é o Priv. edb para o Exchange Server 5. 5. Base de dados 2 é Pub. edb.
  • (0-310013) representa o "dbtime" valor que actualmente é escrito na página. O "dbtime" valor é um valor de 64 bits que é escrito em cada página que aproximadamente correlaciona com quanto tempo decorrido desde que a página foi alterada.
  • (0-312215) representa a actual "dbtime" valor para a base de dados como um todo: susceptíveis do "dbtime" valor que seria escrito nesta página, se a página foi alterada agora. O "dbtime" valor já existentes na página deve ser sempre mais pequeno do que o actual "dbtime" valor.
Dado que o número de página foi lida correctamente a partir da página e o "dbtime" os valores são razoáveis (com o primeiro "dbtime" valor mais baixo do que o segundo), esta página não foi inteiramente substituída com uma página de fora da base de dados ou uma página diferente.

Pode utilizar Esefile para exportar a própria página com um comando semelhante à seguinte:
Esefile /d base_de_dados. edb 3106 > 3106.txt
Porque esta página parece estar substancialmente intacta no que respeita à estrutura, poderá também conseguir utilizar o Eseutil para ver mais lógicas informações acerca da página. Pode utilizar a versão do Exchange 2000 do Eseutil para visualizar informações de estrutura da página de bases de dados do Exchange 2000 e Exchange Server 5. 5.

Aviso Não utilize a versão do Exchange 2000 do Eseutil numa base de dados do Exchange Server 5. 5 em qualquer modo que o escreve a base de dados. Para ser seguro, utilize apenas a /M interruptores e nunca utilizar o /P, /G, ou /R. Além disso, não copie versões do Exchange 2000 do Eseutil. exe e Ese. dll para um computador com o Exchange Server 5. 5. Em vez disso, copiar estes ficheiros para um servidor remoto e fornecer um caminho de convenção de Nomenclatura Universal (UNC) de linha de comandos explícitas à base de dados que está a examinar.

Um comando semelhante ao seguinte comando exporta informações lógicas para uma página para um ficheiro de texto:
Eseutil /M \\exchange1\d$\exchsrvr\mdbdata\priv.edb /p3106 > 3106.txt

Initiating FILE DUMP mode...
      Database: priv.edb
          Page: 3106

                        pgnoThis <0x02360004,  4>:  3106 (0x00000c22)
                        objidFDP <0x02360018,  4>:  19 (0x00000013)
                ulChecksumParity <0x02360000,  4>:  4269350574 (0xfe791eae)
        ** computed checksum: 157180847 (0x095e63af)
                   dbtimeDirtied <0x02360008,  8>:  310013 (0x000000000004bafd)
                          cbFree <0x0236001c,  2>:  436 (0x01b4)
                       ibMicFree <0x02360020,  2>:  3608 (0x0e18)
                     itagMicFree <0x02360022,  2>:  3 (0x0003)
               cbUncommittedFree <0x0236001e,  2>:  0 (0x0000)
                        pgnoNext <0x02360014,  4>:  3108 (0x00000c24)
                        pgnoPrev <0x02360010,  4>:  3088 (0x00000c10)
                          fFlags <0x02360024,  4>:  2050 (0x00000802)
                Leaf page
                Primary page
A partir desta saída, pode ver que a página é uma página de folha, o que significa que tem dados reais no mesmo. Se reparar esta base de dados, a reparação irá resultar na perda de, pelo menos, estes dados. Para mais informações sobre como saber qual a tabela ou caixa de correio a página pertencem, clique no número de artigo seguinte para visualizar o artigo na Microsoft Knowledge Base:
262196Como determinar qual mailbox possui uma página específica numa base de dados
Se a saída do Eseutil não listar página folha para a página, é provável que reparam será trabalho completamente são elevados. Mais páginas interiores ou estruturais podem ser completamente reconstruídas pelo processo de reparação.

A saída pode também mostrar isto como "Página vazia". Neste caso, uma desfragmentação offline irá rejeitar a página da base de dados incorrecta.

Lembre-se de que se uma página tiver sido completamente substituída por um bloco de dados que não pertencem no ficheiro de base de dados, a saída do Eseutil poderão estar sem sentido.

O erro seguinte é outro exemplo:
MSExchangeIS ((247) ) Synchronous read page checksum error -1018
((1:1057816 1:3688618971) (3688618971-3688618971) (0-16815256)) occurred.
Please restore the databases from a previous backup.
Neste exemplo, o número de página que é realmente lido a partir da página (3688618971) não corresponde a página que foi pedida, que significa que a área de cabeçalho de página onde está armazenado o número de página está danificada. É provável que o número de página ainda não existe na base de dados. Para determinar se é este o caso, multiplicar o número de página por 4096 e, em seguida, compare esse número para o tamanho em bytes do ficheiro da base de dados. Neste caso, o número de página é susceptível de ser um que Exchange foi escrito originalmente, a menos que a base de dados é 15 terabytes de tamanho (3,688,618,971 x 4096 = 15,108,583,305,216).

Repare também que o primeiro "dbtime" valor repete exactamente o padrão de número de página. Se converter o 3688618971 em hexadecimal (utilize Calc. exe no modo Científico), torna-se 0xDBDBDBDB. No Exchange 2000 e Exchange Server 5. 5, 8 bytes "dbtime" valor é armazenado imediatamente após o valor do número de página de 4 bytes. Deste modo, o utilizador sabe que foram substituídas pelo menos doze bytes contíguas para dois campos diferentes com um padrão específico. Se utilizar Esefile para observar esta página directamente, provavelmente irá descobrir que a página inteira foi substituída com o padrão de 0xDB. Outro padrão de frequentemente viu byte inválido é 0xFF. Se este for o caso para o erro acima, o "dbtime" valor seria 4294967295.

O erro seguinte fornece informações de página como um desvio do byte no ficheiro e não como um número de página:
Information Store (2160) The database page read from the file
"d:\exchsrvr\MDBDATA\PRIV.EDB" at offset 897024 (0x00000000000db000)
for 4096 (0x00001000) bytes failed verification due to a page checksum
mismatch. The expected checksum was 2651583211 (0x9e0bf2eb) and the
actual checksum was 2651582996 (0x9e0bf214). The read operation will
fail with error -1018 (0xfffffc06). If this condition persists then
please restore the database from a previous backup.
					
Pode converter o primeiro desvio para o número de página removendo os zeros finais três, subtraindo 1 e converter o resultado para decimal. Neste exemplo, 0x00000000000db - 1 = 0xda = 218 decimal. Pode utilizar este número decimal página com Esefile ou Eseutil.

Nota Subtrair apenas 1, em vez de 2, para ter em conta as páginas do duas cabeçalho na base de dados porque os desvios começam a contar a partir de 0x0 em vez de 0x1. Se pretender verificar as páginas do cabeçalho com Esefile ou Eseutil, referência de página -1 e página 0.

Na realidade, um cabeçalho de base de dados do Exchange requer apenas uma única página. A segunda página é uma cópia de "sombra" do cabeçalho. As somas de verificação que são reportadas quando utilizar o Esefile /D função de informações de estado da página deve ser sempre o mesmo para páginas -1 e 0 depois da base de dados é encerrada correctamente. Se o cabeçalho é rescrito durante uma falha, o Exchange utiliza a cópia de cabeçalho com uma soma de verificação limpa quando o Exchange for reiniciado.

Continuar com o exemplo anterior, as somas de verificação estão efectivamente muito próximos uns dos outros, que difira em apenas dois caracteres. Quando fechar as somas de verificação, isto indica que as alterações na página eram insignificantes: talvez apenas um único erro de bit. É muito provável que esta página ainda contém suficiente da respectiva estrutura lógica para torná-lo património analisar com o Eseutil /M /P.

A soma de verificação esperada na mensagem de erro é a soma de verificação que é realmente lido a partir da página, tal como agora existe na base de dados. A soma de verificação real na mensagem de erro é a soma de verificação Exchange re-calculates dinamicamente à medida que lê a página.

Se a soma de verificação real numa página for 0x89abcdef, a página contém todos os caracteres de 0x00. Se a soma de verificação real for 0x76543210, a página contém todos os caracteres de 0xFF.

O exemplo seguinte é um erro -1019:
Information Store (3928) The database page read from the file
"d:\exchsrvr\MDBDATA\PRIV.EDB" at offset 1675264 (0x0000000000199000)
for 4096 (0x00001000) bytes failed verification because it contains
no page data.  The read operation will fail with error -1019 (0xfffffc05).
If this condition persists then please restore the database from a
previous backup.
					
Durante uma operação normal, se uma página pode comunicar um erro -1019 ou um erro -1018, o erro -1019 tem precedência e é comunicado. Lembre-se de que um erro -1019 ocorre sempre que o número de página que está escrito numa página é 0x00000000, mas Exchange espera que a página a ser utilizado. Poderá ser difícil de provar se um erro -1019 é causado porque o sistema de ficheiros mapeada um bloco de zeros no ficheiro de base de dados, ou porque Exchange cometeu um erro e referenciada uma página não utilizada como "em utilização".

Não consigo distinguir partir o erro anterior, se a página é inicializada ou em outro Estado de membro. Tem de utilizar Esefile e Eseutil para aprofundar a análise da página. Neste exemplo, o número de página é 408 decimal (derivados de 0x199).

Pode utilizar o Eseutil aprofundar a análise da página. O pgnoThis valor deve corresponder ao número de página que é consultado, e o ulChecksumParity valor relatórios adicionais ** soma de verificação calculada valor se a soma de verificação na página está errada. Pode utilizar o Esefile /D Mude para observar a página em bruto para determinar se é não inicializada (todos os caracteres de 0x00).

Falsos erros -1018

Quando a página no disco está correcta, mas o sistema de e/S obtém os dados incorrectamente, ocorre um erro de "false" -1018. Estes erros são normalmente transitória e difíceis de isolar. Mas mesmo um erro -1018 "false" merece atenção grave. Ainda está comprometida a fiabilidade do sistema de armazenamento e o sistema poderá estar em risco de problemas adicionais ou falha.

Se suspeitar que os erros de leitura transitórios no seu sistema, utilize o Esefile /D mudar ou Eseutil /M /P Para verificar as páginas individuais que estão envolvidas. Se utilizar qualquer utilitário para pesquisar toda a base de dados, coloque a estirpe do sistema de e/S que pode resultar em mais de falsos positivos.

Exchange Server 5. 5 Service Pack 2 (SP2) adicionada a funcionalidade para ajudar a identificar erros de leitura transitórios. Exchange re-reads uma página 16 horas após uma falha de verificação de leitura. Se a página de ler, eventualmente, tiver êxito após várias tentativas, indica que existe um problema de sistema fiavelmente ao ler o disco. Mesmo que todas as 16 leituras falharem, não conclusiva prova que a página é incorrecta. Efectue um teste secundário com Esefile ou Eseutil.

Regulação do zero da base de dados

Regulação do zero da base de dados se destina a obscurecer informações eliminadas numa base de dados do Exchange para que não podem ser recuperado ou lidos pelo exame directo do ficheiro da base de dados. Para mais informações sobre a reposição a zero da base de dados, clique no número de artigo seguinte para visualizar o artigo na Microsoft Knowledge Base:
223161Obter informações sobre a reposição a zero ESE
Se a reposição a zero da base de dados estiver activada, secções de páginas vazias ou parcialmente vazias podem ser substituídas com padrões de caracteres específicos, mas a página não continua a ser devolvida ao Estado não inicializada.

Propriedades

Artigo: 314917 - Última revisão: 24 de maio de 2011 - Revisão: 0.1
A informação contida neste artigo aplica-se a:
  • Microsoft Exchange Server 2003 Standard Edition
  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange 2000 Server Standard Edition
  • Microsoft Exchange Server 5.5 Standard Edition
Palavras-chave: 
kbinfo kbmt KB314917 KbMtpt
Tradução automática
IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine translation ou MT), não tendo sido portanto revisto ou traduzido por humanos. A Microsoft tem artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais. O objectivo é simples: oferecer em Português a totalidade dos artigos existentes na base de dados do suporte. Sabemos no entanto que a tradução automática não é sempre perfeita. Esta pode conter erros de vocabulário, sintaxe ou gramática? erros semelhantes aos que um estrangeiro realiza ao falar em Português. A Microsoft não é responsável por incoerências, erros ou estragos realizados na sequência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza actualizações frequentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 314917

Submeter comentários

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com