4 votes

Est-ce qu'un défragmenteur ESEUTIL d'un magasin Exchange effectue également une vérification/réparation d'intégrité sur celui-ci?

Plus tôt ce matin, store.exe a bugé d'une manière ou d'une autre, ce qui a nécessité un redémarrage de notre serveur Exchange. Il est revenu en ligne sans erreurs ni problèmes, tous les journaux de transactions ont été rejoués avec succès, et tous les magasins se sont montés normalement. Pour moi, c'était juste un de ces crashes aléatoires; cependant, notre consultant soupçonne qu'il a été causé par une corruption dans l'un des magasins. Peut-être a-t-il raison, étant donné qu'il a bien plus d'expérience que moi, mais ce n'est pas le point.

Pour corriger les erreurs suspectées, il prévoit d'exécuter une défragmentation ESEUTIL (via PerfectDisk) pour les corriger, ce qui, selon lui, corrigera également toutes les erreurs présentes.

D'après ce que je comprends, défragmenter, vérifier et réparer sont 3 actions distinctes, et une défragmentation n'implique aucune vérification d'intégrité. Est-ce correct? Y a-t-il des dangers à exécuter une simple défragmentation sur une base de données qui pourrait être corrompue?

Édition :

Voici la première erreur dans le journal des événements, qui indiquait le début des problèmes que nous rencontrions. Est-ce que quelqu'un sait ce qu'elle pourrait indiquer?

Type d'événement : Erreur
Source de l'événement :   Microsoft Exchange Server
Catégorie de l'événement : Aucun
Identifiant de l'événement :   1000
Date :       23/11/2011
Heure :       8:15:47 AM
Utilisateur :       N/A
Ordinateur :   SERVEUR
Description :
Application en faute exsp.dll, version 6.5.7638.1, tampon 430e735b, module en faute kernel32.dll, version 5.2.3790.4480, tampon 49c51f0a, débogage ? 0, adresse de l'erreur 0x0000bef7.

Pour plus d'informations, consultez le Centre d'aide et de support à l'adresse http://go.microsoft.com/fwlink/events.asp.
Données :
0000: 41 00 70 00 70 00 6c 00   A.p.p.l.
0008: 69 00 63 00 61 00 74 00   i.c.a.t.
0010: 69 00 6f 00 6e 00 20 00   i.o.n. .
0018: 46 00 61 00 69 00 6c 00   F.a.i.l.
0020: 75 00 72 00 65 00 20 00   u.r.e. .
0028: 20 00 65 00 78 00 73 00    .e.x.s.
0030: 70 00 2e 00 64 00 6c 00   p...d.l.
0038: 6c 00 20 00 36 00 2e 00   l. .6...
0040: 35 00 2e 00 37 00 36 00   5...7.6.
0048: 33 00 38 00 2e 00 31 00   3.8...1.
0050: 20 00 34 00 33 00 30 00    .4.3.0.
0058: 65 00 37 00 33 00 35 00   e.7.3.5.
0060: 62 00 20 00 69 00 6e 00   b. .i.n.
0068: 20 00 6b 00 65 00 72 00    .k.e.r.
0070: 6e 00 65 00 6c 00 33 00   n.e.l.3.
0078: 32 00 2e 00 64 00 6c 00   2...d.l.
0080: 6c 00 20 00 35 00 2e 00   l. .5...
0088: 32 00 2e 00 33 00 37 00   2...3.7.
0090: 39 00 30 00 2e 00 34 00   9.0...4.
0098: 34 00 38 00 30 00 20 00   4.8.0. .
00a0: 34 00 39 00 63 00 35 00   4.9.c.5.
00a8: 31 00 66 00 30 00 61 00   1.f.0.a.
00b0: 20 00 66 00 44 00 65 00    .f.D.e.
00b8: 62 00 75 00 67 00 20 00   b.u.g. .
00c0: 30 00 20 00 61 00 74 00   0. .a.t.
00c8: 20 00 6f 00 66 00 66 00    .o.f.f.
00d0: 73 00 65 00 74 00 20 00   s.e.t. .
00d8: 30 00 30 00 30 00 30 00   0.0.0.0.
00e0: 62 00 65 00 66 00 37 00   b.e.f.7.
00e8: 0d 00 0a 00               ....

6voto

Evan Anderson Points 140581

Une défragmentation hors ligne utilisant eseutil échouera si elle rencontre une corruption au niveau de la page dans la base de données. Vous devriez utiliser l'option /p (Réparation) pour jeter les pages corrompues.

La corruption des données au niveau logique (pensez aux dommages causés aux "données" dans la base de données, pas à la "structure" de la base de données) ne peut pas être réparée par eseutil. L'outil isinteg peut trouver des incohérences logiques dans la base de données des versions d'Exchange jusqu'à 2007. Dans Exchange 2010, isinteg a été remplacé par la cmdlet new-MailboxRepairRequest (plus de détails sont disponibles sur le blog de l'équipe Exchange).

Cela dit, je m'inquiète de votre conseil consultant. Voyez-vous des événements dans le journal des événements d'application provenant des services ESE ou Exchange, indiquant une quelconque corruption de base de données ? En général, Exchange ne "plante" pas aléatoirement, et un problème avec un pilote de matériel ou le matériel lui-même semble être une cause plus probable qu'un problème avec Exchange. De plus, puisque les journaux ont été rejoués sans problème, il me semble un peu improbable que vous ayez une corruption au niveau de la page.

Enfin, si vous avez une corruption au niveau de la page, nettoyer cette corruption seule n'est pas une solution. Vous devez trouver la cause racine (matériel défectueux, etc.) qui provoque la corruption et l'éliminer. Faire autre chose, c'est simplement vous exposer à un risque continu.

La défragmentation hors ligne n'est en soi pas un risque majeur. Vous devez immédiatement effectuer une sauvegarde complète après la fin de la défragmentation hors ligne car toutes les sauvegardes incrémentielles et différentielles précédentes ne peuvent pas être restaurées (car la nouvelle base de données est exactement cela - une toute nouvelle base de données). Bien sûr, votre serveur sera inaccessible aux utilisateurs pendant la période de défragmentation.

Je rechercherais ce qui s'est passé ce matin en détail et en tirer une conclusion sur la cause racine (ou du moins une hypothèse très probable) avant de commencer à dépenser de l'argent pour le "réparer".

J'ai récemment eu un cas où un serveur Exchange 2003 refusait de prendre des instantanés VSS et signalait diverses erreurs JET lors des sauvegardes tentées. J'ai choisi de mettre en place une nouvelle installation d'Exchange sur une autre machine, de déplacer toutes les boîtes aux lettres des utilisateurs vers la nouvelle machine, puis de supprimer la base de données problématique sur le serveur d'origine et de permettre la création d'une nouvelle. Après avoir effectué des tests de stress et vérifié que le serveur d'origine fonctionnait correctement, nous avons déplacé toutes les boîtes aux lettres de retour. Je préfère cette stratégie dans la situation que vous décrivez (si j'avais suffisamment de messages d'erreur dans le journal des événements indiquant une réelle "corruption" dans la base de données des boîtes aux lettres de l'ordinateur serveur Exchange d'origine).

Édition :

L'entrée que vous avez postée ci-dessus est un défaut dans le fournisseur Exchange pour la recherche Microsoft (qui crée des index textuels complets des bases de données Exchange). Je serais intéressé de voir ce qui s'est passé par la suite, ainsi que tous les événements immédiatement avant celui-ci dans le Journal des événements système. Aviez-vous une condition de faible espace disque sur l'un des volumes de l'ordinateur serveur ?

0 votes

Il semble que sa suspicion de corruption est un "pressentiment" basé sur ses expériences antérieures. Bien qu'il y ait des entrées de journal d'événements concernant le crash, il s'agit simplement de quelques erreurs dans store.exe et exsp.dll. Rien n'indique une corruption de la base de données (de mon point de vue). Je peux ajouter les détails du journal d'événements à mon message original si vous le souhaitez.

0 votes

@Bigbio2002 : Ça ne me dérangerait pas de les voir même s'ils pourraient ne pas nous donner d'informations concrètes. Je serais beaucoup plus enclin à exécuter eseutil en mode intégrité avant de me lancer dans une défragmentation hors ligne.

0 votes

C'est aussi ce que je pense; cependant, il a pris en charge ce problème et insiste pour faire une défragmentation lui-même. Il a dit que c'était pour me protéger de toute responsabilité en cas de problème, mais je suis du genre possessive et collante et je ne veux pas que quelqu'un fasse quelque chose sur "mon" réseau sans mon autorisation.

0voto

Eric Simson Points 70

La défragmentation ESEUTIL n'est pas dédiée uniquement à la réparation étendue de la base de données Exchange. La fonction de défragmentation consiste à récupérer de l'espace libre dans la base de données et à optimiser les performances de la base de données en créant un nouveau fichier de base de données compacté.

Pendant que vous exécutez la défragmentation, elle peut également effectuer certaines réparations sur la base de données lorsqu'elle trouve des incohérences ou des problèmes. Cela fait partie du processus global de défragmentation et peut résoudre des problèmes mineurs.

Si votre base de données Exchange Server est corrompue, il est recommandé de d'abord exécuter la commande ESEUTIL /mh pour vérifier l'état complet de votre base de données. Si vous constatez que la base de données est dans un état sale, vous pouvez ensuite utiliser les commandes ESEUTIL /P ou ESEUTIL /R en fonction des dommages de la base de données. Assurez-vous d'avoir sauvegardé votre base de données avant d'effectuer des opérations de réparation.

Je conseille de consulter le support de Microsoft pour garantir des étapes de récupération appropriées.

Vous pouvez consulter ces articles Microsoft:

https://techcommunity.microsoft.com/t5/exchange-team-blog/repairing-exchange-databases-with-eseutil-when-and-how/ba-p/610276

https://social.technet.microsoft.com/wiki/contents/articles/53450.how-to-check-exchange-database-health.aspx

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X