Compréhension et analyse -1018, -1019 et -1022 Exchange database errors

Traductions disponibles Traductions disponibles
Numéro d'article: 314917 - Voir les produits auxquels s'applique cet article
Ancien nº de publication de cet article : F314917
Agrandir tout | Réduire tout

Sommaire

Résumé

Cet article fournit des informations pour vous aider à comprendre et analyser les erreurs de base de données Exchange-1018, -1019 et -1022. Cet article décrit les différences entre ces trois erreurs et les types de problèmes dans la base de données qui provoquent chacune de ces trois erreurs doivent être déclarées.

Plus d'informations

Exchange comprend une fonctionnalité pour détecter des dommages au niveau des fichiers vers les pages dans ses bases de données. Trois erreurs les plus courantes qui sont associées aux dommages au niveau des fichiers à une base de données Exchange sont les suivantes :
  • -1018 JET_errReadVerifyFailure
  • -1019 JET_errPageNotInitialized
  • -1022 JET_errDiskIO
Les trois niveaux suivants de dommage peuvent se produire dans une base de données Exchange :
  • Niveau page (système de fichiers)
  • Niveau de la base de données (moteur de base de données JET)
  • Niveau de l'application (banque d'informations Exchange)
L'utilitaire Esefile.exe peut détecter des erreurs dans les bases de données au niveau de la page. L'utilitaire Eseutil.exe peut détecter et réparer les problèmes au niveau de la page et le niveau de base de données. L'utilitaire Isinteg.exe détecte et répare les problèmes au niveau de l'application.

Dommages à un moindre niveau (niveau de la page) presque toujours entraîne des problèmes aux niveaux supérieurs (niveau de base de données ou de l'application). Par conséquent, après avoir réparé une base de données avec Eseutil, vous devez presque toujours utiliser Isinteg.

Dommages au niveau de base de données et de l'application sont lié à des problèmes dans le code Exchange ou dans des programmes tiers qui s'intègrent avec Exchange. Dommages au niveau de la page sont généralement dû par le pilote, de microprogramme ou de problèmes liés au matériel, bien que les dommages au niveau de la page peuvent également être provoqué par des problèmes dans Exchange.

Vous presque toujours rechercher la cause d'une erreur -1018 dans un des systèmes sous-jacents dont dépend Exchange, pas dans le code Exchange lui-même. Il existe très peu d'exceptions à cette règle. Les exceptions à ce jour ont été à Exchange signale une condition -1018, pas parce que Exchange lui-même provoque une erreur -1018. Pour plus d'informations, cliquez sur les numéros ci-dessous pour afficher les articles correspondants dans la Base de connaissances Microsoft :
237953-1018 Erronée renvoyée durant la sauvegarde en ligne
230215 Total de contrôle de sauvegarde non effectuée sur les ordinateurs monoprocesseurs
Bien que la majorité des erreurs-1019 et -1022 soient aussi provoquées par une défaillance dans un système sous-jacent, vous ne pouvez pas exclure la possibilité que des erreurs-1019 et -1022 peuvent se produire en raison d'une erreur dans Exchange code plus rapidement.

Erreur -1018 est l'erreur la plus couramment affichée, ce qui indique qu'une base de données Exchange a subi des dommages au niveau du système de fichiers. Par conséquent, la majeure partie de cet article porte sur l'erreur -1018.

Il existe trois manières fondamentales que les données sur le disque peuvent être endommagées :
  • Données incorrectes sont écrites dans le support de stockage.
  • Sur le support de stockage, les données sont écrites au mauvais endroit.
  • Données sont endommagées ou modifiées après avoir été stockées.
Il est très difficile à prévenir ou à corriger les 100 pour cent de tout dommage, mais il est relativement facile à détecter un problème s'est produite. Exchange détecte des données incorrectes et mal placées dans ses fichiers de base de données et signale une erreur -1018 ou -1019. Si un fichier est gravement endommagé et des parties sont manquantes ou inaccessibles lorsque Exchange tente de lire le fichier, une erreur -1022 est signalée.

Comment Exchange calcule les totaux de contrôle et les Pages de base de données de numéros

Pour comprendre comment fonctionnent les mécanismes qui déclenchent les erreurs 1018 et -1019, vous devez comprendre comment une base de données Exchange stocke les pages de données.

Au niveau logique plus bas, vous pouvez afficher un fichier de base de données Exchange comme un ensemble de 4 kilo-octets (Ko) pages, numérotées par ordre séquentiel. Données sont lues et écrites sur une page d'une base de données Exchange à la fois.

Chaque page qui contient des données stocke son propre numéro de page, ainsi que d'un checksum est calculé à partir de toutes les données sur la page. La valeur de somme de contrôle elle-même est la seule partie de la page qui n'est pas incluse dans ce calcul.

Algorithmes de somme de contrôle, y compris l'algorithme de checksum par Exchange, sont compréhensibles et relativement simple. Ils sont conçus afin qu'il est probable que la somme de contrôle même salaire pour les deux pages différentes est faibles, même si la différence entre les pages n'est qu'un seul bit.

Bien qu'un test de somme de contrôle soit suffisant pour déterminer si Oui ou non la page a été modifiée depuis son écriture, un test de somme de contrôle ne suffit pas pour vous assurer que la page est au bon endroit. En conséquence, Exchange affecte à chaque page son propre numéro de page, ainsi qu'une somme de contrôle.

Les deux premières pages de 4 Ko dans la base de données sont réservées pour la base de données « en-tête ». Lorsque la base de données est arrêté, vous pouvez utiliser l'utilitaire Eseutil /MH commutateur pour afficher cet en-tête. L'en-tête contient des informations d'identification sur la base de données dans son ensemble.

Une fois ces tout d'abord deux pages d'en-tête, toutes les autres pages de la base de données. Toutes les pages de données partagent une structure commune. Chaque page possède son propre en-tête de page qui contient les informations d'identification sur la page en question, suivie des données réelles.

Dans la mesure où la première page de données dans une base de données Exchange se trouve après les premier deux pages d'en-tête, page physique 3 dans la base de données est logique page 1. 2 est le numéro de page logique de page physique 4 et ainsi de suite.

Numéros de page logique de la base de données mappent directement aux numéros de page physique par la formule suivante :
numéro de page logique = numéro de page physique - 2
Les structures de page physique et logique du fichier de base de données étant si étroitement liées, Exchange peut facilement déterminer si chaque page logique se trouve au bon emplacement physique dans le fichier.

Les seules pages de la base de données pour laquelle une somme de contrôle n'est pas calculé sont « pages non initialisées ». Il s'agit des blocs de pages qui sont créés lorsque la taille de la base de données est étendue pour accueillir davantage de données. Une page non initialisée est celui qui possède une somme de contrôle et un numéro de page zéro. En règle générale, chaque octet d'une page non initialisée est rempli de caractère 0 x 00.

Lorsqu'une page non initialisée est utilisée pour la première fois, elle ne retourne pas à l'état non initialisé, même s'il est vidé. Au lieu de cela, un indicateur est défini sur la page vidée pour marquer peut être réutilisé. La page porte toujours un numéro de page et la somme de contrôle, même lorsqu'elle est vide.

Exchange Server 2003 Service Pack 1 (SP1) de modifier l'algorithme de checksum et le format de page sont utilisés. En outre, Exchange Server 2003 SP1 Introduit un algorithme ECC (code) pour détecter et corriger automatiquement les erreurs mono bit de correction d'erreurs.Pour plus d'informations sur cette nouvelle fonctionnalité, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
867626Erreur du nouveau code de correction est inclus dans Exchange Server 2003 Service Pack 1

Ce qui provoque une erreur -1018

Exchange signale une erreur -1018 lorsqu'une page non initialisée dans le fichier de base de données présente une des conditions suivantes :
  • La somme de contrôle qui est stocké sur la page ne correspond pas le résultat du recalcul checksum effectuée lors de la lecture de la page.
  • Le numéro de page est stocké sur la page ne correspond pas au numéro de page doit se trouver sur la page, compte tenu de l'emplacement physique de la page dans le fichier de base de données.
Exchange est responsable de la génération d'une erreur -1018 si Exchange effectue l'une des opérations suivantes :
  • Construit une page qui contient le total de contrôle incorrect.
  • Construit une page correctement, mais indique au système d'exploitation d'écrire la page dans le mauvais emplacement.
Lorsqu'un administrateur système rencontre une erreur -1018, si l'administrateur exécute les tests de diagnostic matériels sur le serveur et que ces tests ne signalent aucun problème, l'administrateur peut en conclure qu'Exchange est responsable du problème puisque le matériel satisfait l'analyse initiale.

Toutefois, dans le cas après cas, analyses approfondies menées par Microsoft ou du matériel fournisseurs non couverts problèmes subtils de pilotes de matériel, de microprogramme ou de périphérique qui sont en fait responsables de l'endommagement du fichier de base de données.

Tests de diagnostic peuvent ne pas détectent toutes les défaillances temporaires pour plusieurs raisons. Problèmes de microprogramme ou logiciel pilote peuvent dépasser les capacités des programmes de diagnostic. Tests de diagnostic peuvent être incapables de simuler de façon adéquate les durées d'exécution ou des charges complexes. En outre, l'ajout de l'enregistrement des diagnostics de surveillance ou de débogage peut modifier suffisamment le système pour empêcher la réapparition du problème.

La simplicité et la stabilité des mécanismes Exchange qui génèrent les totaux de contrôle et écrivent les pages dans le fichier de base de données est une autre raison est peu probable que la cause d'une erreur -1018 est un problème d'Exchange. La somme de contrôle et les mécanismes de détection de page incorrecte sont simples, fiables et sont demeurés fondamentalement les mêmes depuis la première version d'Exchange, à l'exception des modifications mineures pour s'adapter aux modifications de format de page de base de données entre les versions de base de données.

Pour approfondir l'explication, qu'une somme de contrôle est généré pour une page qui va être écrite sur disque une fois que toutes les autres données ont été écrites sur la page, y compris de la page numéro de lui-même. Une fois qu'Exchange ajoute la somme de contrôle sur la page, Exchange demande au système d'exploitation Microsoft Windows pour écrire la page sur disque à l'aide de publiées, standard Windows interfaces de programmation (API).

La somme de contrôle peut être générée correctement pour une page, mais ensuite la page peut-être être écrites au mauvais endroit sur le disque dur. Cela peut provenir d'une erreur de mémoire temporaire, comme une "inversion de bits. Par exemple, Qu'exchange crée une nouvelle version de la page 70. La page elle-même ne connaît pas d'erreur, mais la copie le numéro de page qui est utilisé par le contrôleur de disque ou par le système d'exploitation est modifiée de façon aléatoire. Ce problème peut se produire si 70 (100110 en binaire) a été modifié à 6 (000110 en binaire) par une cellule mémoire instable. Somme de contrôle de la page est toujours correct, mais l'emplacement de la page dans la base de données est maintenant erroné. Exchange signale une erreur -1018 pour la page lorsqu'il détecte que le numéro de page logique ne correspond pas à l'emplacement physique de la page. Un autre type d'erreur (provoquée par Exchange) de numérotation de page peut se produire si Exchange écrit le mauvais numéro de page sur la page elle-même. Mais cela entraîne d'autres erreurs, pas l'erreur -1018. Si Exchange écrit 71 sur la page 70 et fait ensuite la somme de contrôle sur la page correctement, la page est écrite à l'emplacement 71 et réussit à la fois les page nombre et du checksum tests.

Souvent, une seule erreur -1018 signalée dans une base de données Exchange ne provoque pas la base de données d'arrêter ou de symptômes autres que la présence de l'erreur -1018 elle-même. Cette page peut être dans un dossier qui est rarement (par exemple, les dossiers Éléments envoyés ou éléments supprimés) ou dans une pièce jointe rarement ouverte ou même vide.

Bien qu'une seule erreur -1018 soit peu susceptible de provoquer des pertes de données importantes, erreurs 1018 restent préoccupantes car une erreur -1018 est la preuve que votre système de stockage a échoué pour le stockage ou de récupération des données au moins une fois. L'erreur -1018 peut être un problème transitoire qui ne se produira à nouveau, mais il est plus probable que cette erreur est un avertissement annonçant un problème qui va en s'aggravant. Même si la première erreur-1018 se trouve sur une page vide de la base de données, vous ne pouvez pas savoir quelle pourrait être prochaine page endommagée. Si une table globale critique est endommagée, la base de données l'endommagement et réparation de la base de données peut échouer ou réussir seulement en partie.

Après qu'une erreur -1018 est consignée, vous devez prendre en compte et envisagez la possibilité de panne imminente ou de dégâts aléatoires supplémentaires sur la base de données jusqu'à trouver et éliminer la cause.

Récupération à partir des erreurs 1018

Exchange traite une page qui échoue avec une erreur -1018 comme entièrement illisible pour empêcher l'action sur des données aléatoires provoque des problèmes supplémentaires dans la base de données.

Une page qui échoue avec une erreur -1018 ne peut pas être réparée ou préservée. Il doit être supprimée de la base de données. Il existe trois méthodes que vous pouvez utiliser afin d'éliminer la page à partir de la base de données :
  • Restaurez la base de données à partir d'une sauvegarde en ligne.
  • Utilisez l'utilitaire Eseutil.exe /D commutateur pour effectuer une défragmentation hors connexion de la base de données.
  • Utilisez l'utilitaire Eseutil.exe /P commutateur pour réparer la base de données.

Restaurer la base de données à partir d'une sauvegarde en ligne

Si une erreur -1018 est trouvée pendant la sauvegarde en ligne, la sauvegarde s'arrête. Cela garantit que la page endommagée n'existe pas dans la dernière sauvegarde réussie. Si l'enregistrement circulaire est désactivé, vous pouvez restaurer la sauvegarde complète disponible la plus récente et puis restaurer la base de données à partir des journaux des transactions suivants.

Utilisez l'utilitaire Eseutil.exe commutateur « / D » pour effectuer une défragmentation hors connexion de la base de données

Cette méthode est efficace si l'erreur -1018 est signalée sur une page vide. Si l'erreur -1018 se produit uniquement lors de la sauvegarde en ligne ou de maintenance en ligne nocturne, cela indique que la page est rarement accessible ou qu'il peut même être vide. Défragmentation hors ligne ignore toutes les pages vides et les index secondaires dans une base de données.

Utilisez l'utilitaire Eseutil.exe "/ P" pour réparer la base de données

Une page incorrecte n'est pas réparée si vous utilisez cette méthode, mais la page incorrecte est ignorée. Si la page en question est une "page feuille", une perte de données se produit. Une page de feuille dans la base de données est une page qui contient les données réelles. Les pages intérieures contiennent des informations uniquement structurelles et logiques. Dans la plupart des cas, Eseutil peut recréer la totalité une table si une page intérieure est perdue. Toutefois, la plupart des pages dans une base de données sont des pages de niveau feuille.

Fonctionne de la fonctionnalité de réparation d'Eseutil également et dans la plupart des cas peut restaurer une base de données avec une perte minimale de données. Toutefois, si le nombre de pages est endommagé ou les tables système critiques sont perdues, la perte de données peut s'avérer catastrophique ou la base de données peut être irréparable.

Réparation d'une base de données est généralement une stratégie inférieure par rapport à la restauration à partir d'une sauvegarde et de reprise la base de données car généralement dure plus longtemps que la restauration et réparation plus risquée. Choisissez réparer uniquement si :
  • Vous n'avez pas d'une sauvegarde.
  • Vous ne pouvez pas récupérer intégralement à partir de votre sauvegarde.
Avant de réparer ou restaurer une base de données, effectuez toujours une copie de sauvegarde des fichiers de base de données en cours. Si la restauration ne fonctionne pas, vous pouvez réparer la base de données existante. Si la réparation ne fonctionne pas, mais la copie précédente de la base de données est encore Démarrer, vous pourrez pour récupérer des données qui seraient perdues.

Important Après avoir réparé une base de données, vous devez vérifier le nombre de réparations dans l'en-tête de la base de données. Si le nombre est supérieur à zéro, vous devez effectuer une défragmentation hors connexion en utilisant Eseutil et ensuite, vous devez réparer la base de données au niveau de la banque d'informations avec l'utilitaire Isinteg. Si vous ne le faites pas, les utilisateurs peuvent rencontrer des problèmes, tels que l'incapacité d'ouvrir des messages ou les pièces jointes ou les références dans leurs boîtes aux lettres à des éléments qui n'existent plus.

Pour vérifier le nombre de réparations, observez la sortie écran qui est générée lorsque vous exécutez la commande suivante :
ESEUTIL /MH [nom_fichier_base_données]
Pour effectuer une défragmentation hors connexion de la base de données réparée, exécutez la commande suivante :
ESEUTIL /D [nom_fichier_base_données]
Pour faire une correction Isinteg complète après une réparation dans Exchange 2000, vous devez exécuter le service de banque d'informations, mais la base de données que vous voulez réparer doit être démontée. Exécutez la commande suivante pour le correctif de base de données :
[-S ISINTEGnom_serveur]-FIX - TEST ALLTESTS
Pour faire une correction Isinteg complète après une réparation dans Exchange Server 5.5, la banque d'informations de service doit être arrêté. Exécutez la commande suivante, en utilisant le commutateur approprié)-PRI ou -PUB), selon que vous exécutez réparer une base de données privée ou publique :
ISINTEG-PRI|PUB-FIX - TEST ALLTESTS
Remarque Vous pouvez exécuter Eseutil et Esefile sur des fichiers de base de données brutes indépendamment de leur fichier emplacements du système. Les fichiers de base de données est même inutile d'être sur un serveur Exchange. Mais vous devez exécuter Isinteg alors que la base de données est en place sur un serveur Exchange entièrement configuré, car Isinteg fonctionne au niveau de la banque d'informations et utilise le service de banque d'informations pour accéder à la base de données.

Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
244525Comment faire pour exécuter Eseutil sur un ordinateur sans Exchange Server

Récupération à partir d'une erreur -1019

Une erreur -1019 (JET_errPageNotInitialized) est signalée lorsqu'une page censée être en cours d'utilisation est non initialisée ou vide. Si le champ numéro de page sur une page en cours d'utilisation est 0 x 00000000, une erreur -1019 est signalée au lieu d'une erreur -1018, même si la page peut échouer également son test de somme de contrôle.

Les méthodes pour corriger une erreur -1019 sont les mêmes que celles utilisées pour corriger une erreur -1018. Notez qu'une erreur 1019 peut plus qu'une erreur 1018 dans la mesure où les problèmes -1019 ne sont pas détectés par la sauvegarde en ligne.

Bien que la cause d'une erreur -1018 soit très probablement en dehors d'Exchange, une erreur -1019 peut être provoquée par Exchange si les pointeurs logiques ou les liens entre les pages ne sont pas valides.

Toutefois, il est plus courant qu'une erreur -1019 provient du fait que le système de fichiers a été endommagé ou pages mappées dans le fichier de base de données qui n'appartiennent pas dans le fichier.

Récupération à partir d'une erreur -1022

Si Exchange demande au système d'exploitation une page dans la base de données et une erreur se produit au lieu des données de la page renvoyées, une erreur -1022 (JET_errDiskIO) se produit. L'erreur 1022 est une erreur générique qui apparaît chaque fois qu'un disque d'entrée/sortie problème empêche Exchange d'accéder à une page demandée dans la base de données.

La raison la plus courante d'une erreur 1022 est un fichier de base de données qui a été gravement endommagé ou tronqué. Si ce problème se produit, Exchange demande un numéro de page plus grand que le nombre de pages dans le fichier de base de données et une erreur -1022. Ce problème peut se produire à cause de problèmes dans le système de fichiers ou en raison de la relecture du journal des transactions incorrecte.

Exchange 2000 contient de nombreuses protections pour empêcher la relecture du journal des transactions susceptibles d'endommager la base de données, mais dans Exchange Server 5.5 il était possible de jouer à un jeu incomplet des fichiers journaux et endommager la base de données. Par exemple, ce problème peut se produire si la relecture doit démarrer à partir de journal 9, mais est forcée à démarrer à partir de journal 10. La relecture peut être forcée si un administrateur supprime le fichier de point de contrôle et le journal 9. Si une transaction du journal 9 augmente la taille de la base de données, mais le journal 9 n'est pas lu dans la base de données, une référence dans le journal 10 aux nouvelles pages sont ajoutés aux bases de données provoque une erreur -1022. Des blocages soudains (négatif), et des violations d'accès sont également des symptômes courants de la relecture d'un jeu de journaux de transaction incomplète dans une base de données.

Comprendre et dépanner la cause d'une erreur -1022 sont plus complexe que la résolution d'une erreur-1018 ou -1019. Si l'erreur est provoquée par un endommagement de la base de données du système de fichiers, vous devez vérifier ou réparer le système de fichiers, puis restaurez Exchange à partir d'une sauvegarde. Bien que la réparation de la base de données est toujours une option, la réparation est moins probable de réussite qu'avec les autres erreurs, car une erreur -1022 signale souvent des dommages importants.

De loin le plus souvent une erreur -1022 avec une base de données non endommagée une autre application maintient des fichiers ouverts et en empêchant la banque d'informations du service d'y accéder. Dans ce cas, vous pouvez également voir des erreurs 1032 (JET_errFileAccessDenied). Le redémarrage de tous les services Exchange ou le serveur peut supprimer le verrouillage.

Les programmes tiers, tels que les scanneurs de virus, peuvent empêcher Exchange d'accéder aux données Exchange. Configurez toujours au niveau des fichiers antivirus pour exclure des fichiers de données Exchange à partir du fichier opération d'analyse. Il existe plusieurs logiciels antivirus qui tirent parti de l'analyse d'interface de programmation d'application (API) pour analyser les messages et pièces jointes dans la banque d'informations des virus de Exchange.

Analyse des erreurs 1018 et -1019

Les informations contenues dans cette section sont destinées principalement pour le support technique et au personnel impliqué dans l'analyse des causes.

Une fois un administrateur détecte une erreur-1018 ou -1019, l'administrateur doit savoir au moins trois choses :
  • Quel était sur la page endommagée
  • Quelle est la probabilité de réparation réussie
  • Ce qui a causé le dommage en premier lieu
-erreurs 1018 et -1019 peuvent se produire au niveau de la ligne de commande lorsque vous démarrez le service, dans le journal des événements Application ou dans la sortie d'utilitaires Exchange tels que Eseutil. Une erreur -1018 dans le journal des événements applications peuvent ne pas être déclarée lors de l'exécution d'un contrôle d'intégrité avec les Eseutil /G commande. Dans ce cas, il est probable que la page endommagée est vide.

Dans la plupart des cas, les erreurs sont signalées dans un formulaire qui vous permet d'identifier la page signalant le problème. Vous pouvez aussi analyser la base de données entière avec Esefile pour identifier les pages endommagées. Pour plus d'informations sur Esefile, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
248406Utilitaire de support Esefile pour Exchange Server 5.5 et Exchange 2000
Les exemples suivants sont des descriptions d'erreur -1018 classique dans le journal des événements pour les différentes versions d'Exchange, ainsi que l'analyse des détails de chaque erreur.
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.
					
Dans l'exemple précédent, vous pouvez interpréter les nombres entre parenthèses comme suit :
  • (3106 310013) représente la page dans la base de données a été demandée (page 3106) et le numéro de page qui a été trouvé écrit sur la page (page 3106). Le 1: indique qu'il s'agit de base de données 1, c'est-à-dire Priv.edb pour Exchange Server 5.5. Base de données 2 est Pub.edb.
  • (0-310013) représente la dbtime valeur qui est actuellement écrite sur la page. Le dbtime valeur est une valeur 64 bits qui est écrit sur chaque page qui correspond à peu près avec combien de temps écoulé depuis la page a été modifiée.
  • (0-312215) représente le courant dbtime valeur de la base de données dans son ensemble : probablement le dbtime valeur qui serait écrite sur cette page si la page était modifiée maintenant. Le dbtime valeur déjà sur la page doit toujours être inférieure à celle de l'actuel dbtime valeur.
Étant donné que le numéro de page a été lu correctement à partir de la page et le dbtime les valeurs sont raisonnables (la première dbtime valeur inférieure à la seconde), cette page n'a pas été entièrement remplacée par une page depuis l'extérieur de la base de données ou une autre page.

Vous pouvez utiliser Esefile pour sortir la page avec une commande semblable à celui-ci :
Esefile /d database.edb 3106 > 3106.txt
Cette page semblant être presque intacte quant à sa structure, vous pourrez également utiliser Eseutil pour afficher des informations plus logiques sur la page. Vous pouvez utiliser la version Exchange 2000 d'Eseutil pour afficher des informations sur la page structure de bases de données Exchange 2000 et Exchange Server 5.5.

Avertissement N'utilisez pas la version de Exchange 2000 d'Eseutil sur une base de données Exchange Server 5.5 dans un mode qui écrit dans la base de données. Pour plus de sécurité, utilisez uniquement le /M les commutateurs et ne jamais utiliser le /P, / G, ou /R. En outre, ne copiez pas les versions Exchange 2000 de Eseutil.exe et Ese.dll sur un ordinateur Exchange Server 5.5. Au lieu de cela, copiez ces fichiers sur un serveur distant et fournir un chemin d'accès UNC (Universal Naming Convention) de ligne de commande explicite pour la base de données que vous examinez.

Une commande semblable à la commande suivante génère des informations logiques d'une page dans un fichier texte :
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
À partir de cette sortie, vous pouvez voir que la page est une page de feuille, ce qui signifie qu'il contient des données réelles. Si vous réparez cette base de données, la réparation entraînera la perte d'au moins ces données. Pour plus d'informations sur la façon de savoir à quelle table ou de la boîte aux lettres de la page appartient à, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
262196Comment faire pour déterminer quelle boîte aux lettres possède une page particulière dans une base de données
Si la sortie de Eseutil ne répertorie pas la page de feuille de la page, il est probable que la réparation sera sont élevées. Plus les pages structurelles ou intérieures peuvent être entièrement recréées par le processus de réparation.

La sortie peut également l'afficher en tant que « Page vide ». Dans ce cas, une défragmentation hors ligne supprimera la page endommagée de la base de données.

N'oubliez pas que si une page a été entièrement remplacée par un bloc de données qui n'appartient pas dans le fichier de base de données, la sortie de Eseutil risquent d'être incompréhensibles.

L'erreur suivante est un autre exemple :
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.
Dans cet exemple, le numéro de page qui est lu à partir de la page (3688618971) ne correspond pas à la page demandée, ce qui signifie que la zone d'en-tête de page où se trouve le numéro de page est endommagée. Il est probable que le numéro de page n'existe pas encore dans la base de données. Pour déterminer si c'est le cas, multipliez le nombre de page par 4 096 et comparez ce numéro à la taille en octets du fichier de base de données. Dans ce cas, le numéro de page est peu probable à que Exchange a écrit à l'origine, sauf si la base de données est de 15 téraoctets (3 688 618 971 x 4 096 = 15,108,583,305,216).

Notez également que le premier dbtime valeur répète le modèle de numéro de page exactement. Obtenez si vous convertissez 3688618971 hexadécimale (utilisez Calc.exe en mode scientifique), 0xDBDBDBDB. Dans Exchange 2000 et Exchange Server 5.5, l'octet de 8 dbtime valeur est stockée immédiatement après la valeur de numéro de page de 4 octets. De ce fait, vous savez qu'au moins douze octets contigus pour deux champs différents ont été remplacé par un modèle spécifique. Si vous utilisez Esefile pour consulter directement cette page, vous découvrirez probablement que la page entière a été remplacée par la structure 0xDB. Un autre octets fréquemment observée 0xFF est. Si c'était le cas pour l'erreur ci-dessus, le dbtime valeur serait 4294967295.

L'erreur suivante fournit des informations sur la page comme un offset d'octet dans le fichier et non comme un numéro de page :
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.
					
Vous pouvez convertir le premier offset dans le numéro de page en supprimant trois zéros de fin, en soustrayant 1 et en convertissant le résultat à la décimale. Dans cet exemple, 0x00000000000db - 1 = 0xda = 218 en décimal. Vous pouvez utiliser ce numéro de page décimal avec Esefile ou Eseutil.

Remarque Vous devez soustraire 1 uniquement, au lieu de 2, pour tenir compte de deux pages d'en-tête dans la base de données, car les décalages commencent à 0 x 0 au lieu de 0 x 1. Si vous souhaitez vérifier les pages d'en-tête avec Esefile ou Eseutil, référencez pages -1 et 0.

En fait, un en-tête de base de données Exchange ne requiert qu'une seule page. La deuxième page est un « cliché » de l'en-tête. Les totaux de contrôle est signalées lorsque vous utilisez le Esefile /D fonction de vidage de page doit toujours être le même pour les pages -1 et 0 une fois la base de données est arrêtée proprement. Si l'en-tête est réécrit durant un blocage, Exchange utilise la copie de l'en-tête avec un total de contrôle propre lors de son redémarrage.

En reprenant l'exemple précédent, les totaux de contrôle est très voisines, différant par seulement deux caractères. Lorsque les sommes de contrôle sont proches, cela indique que les modifications sur la page ont été minimes : par exemple un seul bit erreur. Il est très probable que cette page contient encore suffisante de sa structure logique pour le rendre intéressant d'analyser avec Eseutil /M /P.

Le checksum attendu dans le message d'erreur est la somme de contrôle qui est lu à partir de la page telle qu'elle existe maintenant dans la base de données. La somme de contrôle réelle dans le message d'erreur est la somme de contrôle Exchange recalcule dynamiquement lorsqu'il lit la page.

Si la somme de contrôle réelle sur une page est 0x89abcdef, la page contient des caractères 0 x 00. Si la somme de contrôle réelle est 76543210, la page contient des caractères 0xFF.

L'exemple suivant est une erreur -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.
					
En fonctionnement normal, si une page peut signaler une erreur -1019 ou une erreur -1018, l'erreur -1019 est prioritaire et est signalée. Souvenez-vous qu'une erreur -1019 se produit chaque fois que le numéro de page est écrite sur une page est 0 x 00000000, mais Exchange s'attend à la page en cours d'utilisation. Il peut être difficile de prouver si une erreur -1019 est due, car le système de fichiers a mappé un bloc de zéros dans le fichier de base de données ou dans la mesure où Exchange a commis une erreur et référencé une page inutilisée en tant que "utilisation".

Vous ne pouvez pas savoir à partir de l'erreur précédente si la page est non initialisée ou dans un autre état. Vous devez utiliser Esefile et Eseutil pour examiner plus attentivement la page. Dans cet exemple, le numéro de page est 408 en décimal (dérivé de 0 x 199).

Vous pouvez utiliser Eseutil pour examiner plus attentivement la page. Le pgnoThis valeur doit correspondre au numéro de page qui est interrogé, et le ulChecksumParity valeur des rapports supplémentaires ** checksum calculé valeur si la somme de contrôle sur la page est incorrect. Vous pouvez utiliser le fichier Esefile /D commutateur consulter la page brute et déterminer s'il est non initialisée (tous les caractères 0 x 00).

Fausses erreurs -1018

Une « fausse » erreur -1018 se produit lorsque la page sur disque est correcte, mais le système d'e/S récupère les données de manière incorrecte. Ces erreurs sont souvent transitoires et difficiles à isoler. Mais même une « false » erreur -1018 mérite une attention particulière. La fiabilité du système de stockage est compromise, et le système peut être en danger d'autres problèmes ou de défaillance.

Si vous pensez que les erreurs de lecture transitoires dans votre système, utilisez le fichier Esefile /D basculer ou Eseutil /M /P Pour vérifier les pages individuelles qui sont impliqués. Si vous utilisez un utilitaire pour analyser la base de données entière, RUDE sur le système d'e/S qui peut donner lieu à plus de faux positifs.

Exchange Server 5.5 Service Pack 2 (SP2) de nouvelles fonctionnalités pour aider à identifier les erreurs de lecture transitoires. Exchange relit une page 16 fois après un échec de vérification de lecture. Si la page lire finalement réussit après plusieurs tentatives, il indique qu'il existe un problème de système de lecture de façon fiable à partir du disque. Même si toutes les 16 lectures échouent, il ne pas obligatoirement en conclure que la page est incorrecte. Effectuez un second test avec Esefile ou Eseutil.

Réinitialisation de la base de données

Réinitialisation de la base de données est destiné à masquer les informations supprimées dans une base de données Exchange afin qu'il ne peut pas être récupérée ou lues par un examen direct du fichier de base de données. Pour plus d'informations sur la réinitialisation de la base de données, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
223161Informations sur la mise à zéro de l'ESE
Si la mise à zéro de la base de données est activée, des sections de pages vides ou partiellement vides peuvent être remplacées par des séquences de caractères spécifique, mais la page n'est toujours pas retournée à l'état non initialisé.

Propriétés

Numéro d'article: 314917 - Dernière mise à jour: mardi 24 mai 2011 - Version: 0.1
Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • 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
Mots-clés : 
kbinfo kbmt KB314917 KbMtfr
Traduction automatique
IMPORTANT : Cet article est issu du système de traduction automatique mis au point par Microsoft (http://support.microsoft.com/gp/mtdetails). Un certain nombre d?articles obtenus par traduction automatique sont en effet mis à votre disposition en complément des articles traduits en langue française par des traducteurs professionnels. Cela vous permet d?avoir accès, dans votre propre langue, à l?ensemble des articles de la base de connaissances rédigés originellement en langue anglaise. Les articles traduits automatiquement ne sont pas toujours parfaits et peuvent comporter des erreurs de vocabulaire, de syntaxe ou de grammaire (probablement semblables aux erreurs que ferait une personne étrangère s?exprimant dans votre langue !). Néanmoins, mis à part ces imperfections, ces articles devraient suffire à vous orienter et à vous aider à résoudre votre problème. Microsoft s?efforce aussi continuellement de faire évoluer son système de traduction automatique.
La version anglaise de cet article est la suivante: 314917
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.

Envoyer des commentaires

 

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