Si vous pensiez que les fichiers du journal des transactions ne sont qu’un moyen de garder une trace des processus, cet article changera votre façon de penser. Les fichiers journaux des transactions jouent un rôle crucial dans le bon fonctionnement de Exchange database, de sorte que leur incohérence peut entraîner un fonctionnement brutal ou un échec total de démarrage. Laissez-nous vous expliquer cela avec une brève introduction sur leur rôle vis-à-vis de Exchange server.
Le rôle crucial que jouent les fichiers du journal des transactions Exchange
Les journaux de transactions Exchange retracent toutes les modifications effectuées dans la database. Les données à mettre à jour dans les mailboxes des utilisateurs sont initialement sauvegardées dans les fichiers journaux, puis écrites dans la database. La taille du fichier journal étant fixe, une fois que le fichier journal est plein, un nouveau fichier est créé avec le numéro de séquence suivant.
Les fichiers journaux des transactions s’avèrent être un atout lorsque la database doit être restaurée à partir d’une version plus ancienne. Par conséquent, il est toujours conseillé aux administrateurs Exchange de ne pas supprimer définitivement les fichiers journaux. Au lieu de cela, ils doivent s’assurer que les fichiers journaux sont correctement sauvegardés dans des emplacements sûrs et ne doivent les supprimer que s’il est assuré qu’une ancienne version de la database ne sera plus nécessaire.
Quelle est leur importance du point de vue de Exchange Dirty shutdownError ?
Exchange Server ne démarrera correctement que lorsque Exchange database sera correctement arrêtée. Pour que la database s’éteigne correctement, vous devez vous assurer que toutes les données du journal des transactions sont validées dans des fichiers de database. Lorsque toutes les données du journal des transactions ont été validées, la database est considérée comme étant « détachée » de ces fichiers journaux, ce qui est un signal vert pour une fermeture complète. Lorsque le serveur démarre, il vérifie l’état de la database et, s’il est avéré que celle-ci est « attachée » aux fichiers journaux, la database est considérée comme étant « Dirty shutdownstate ». Par conséquent, le serveur « détache » d’abord la database en relisant les fichiers journaux disponibles, puis passe à d’autres tâches.
Un peu plus sur Dirty shutdownError
La database Microsoft Exchange Server utilise le Extensible Storage Engine (ESE), également appelé JET engine. Le moteur Jet utilise le cache de la database de messageries pour réduire le nombre d’opérations d’entrée-sortie. C’est ce moteur à réaction où sont stockés les fichiers du journal des transactions.
Ainsi, lorsqu’une modification ou une opération sur la database est chargée dans la mémoire cache mais qu’elle n’est pas validée, elle est marquée comme « sale » par Jet engine. Jusqu’à ce que toutes les transactions sales ne soient pas résolues, la database est considérée comme incohérente. Si le Exchange Server s’arrête de manière inattendue alors que la database est incohérente, l’erreur Dirty shutdownError est reçue.
Effets secondaires de Dirty shutdownError
Le clignotement de Dirty shutdownError indique que les fichiers de Exchange database (fichiers EDB or STM) est peut-être endommagé. Dans ce cas, si vous essayez d’utiliser ESEUTIL pour réparer les fichiers de database avec cette commande : Eseutil /k
Vous pouvez avoir des erreurs comme :
- ERREUR : la database n’a pas été arrêtée proprement (arrêt non planifié)
- L’opération s’est terminée avec error -550 (JET_errDatabaseDirtyShutdown, la database n’a pas été arrêtée proprement. La récupération doit d’abord être exécutée pour que la database se complète correctement
- Exchange ne parvient pas à monter la database que vous avez spécifiée
Comment réparer Dirty shutdownError
Dans un premier temps, vérifiez que Exchange est en état d’arrêt propre ou dirty shutdownstate. Pour cela, ouvrez l’invite de commande et entrez la syntaxe suivante : Eseutil /mh « Chemin de la database »
Sur l’écran des résultats, si DB state est indiqué comme « Clean Shutdown », la database est détachée du journal des transactions et est cohérente. Toutefois, si l’état DB indique « Dirty Shutdown », la database est toujours attachée au fichier journal et est incohérente.
Selon le scénario, les méthodes suivantes peuvent être utilisées pour corriger l’erreur HR=0X80004005 ou Dirty shutdownError.
1. Si la DB est cohérente avec les fichiers de nettoyage du journal
Si les fichiers journaux sont à l’état vierge, une recovery souple de la database devrait pouvoir résoudre l’erreur. Lors d’une recovery souple, après un arrêt inattendu de la database, les journaux de transactions sont relus pour remonter la database. Pour ce faire, l’utilitaire de ligne de commande ESEUtil est utilisé avec le commutateur /ml pour tout d’abord tester l’état des fichiers journaux à l’aide de la syntaxe suivante : eseutil /ml « Chemin d’accès aux fichiers journaux\préfixe de journal
Et puis, la récupération logicielle est effectuée via la syntaxe : eseutil /r enn /L[path to log files] /s[path to checkpoint file] /d[path to database file] /i
2. Si les fichiers journaux ne sont pas propres ou indisponibles
S’il est impossible d’accéder aux fichiers journaux, s’ils ne sont pas disponibles ou s’ils ne sont pas propres, vous devez tenter une récupération brutale de database. Lors d’une récupération brutale, les fichiers du journal des transactions sont relus en restaurant la database à partir d’une sauvegarde en ligne. C’est la seule différence entre une recovery brutale et souple.
Si une sauvegarde de database valide et récente est disponible, les fichiers EDB, LOG and STM peuvent être restaurés à partir de celle-ci. Une fois cette opération terminée, automatiquement, un fichier appelé « restore.env » sera créé dans un dossier temporaire sous le nom « C:\Temp ».
Important : Vous devez vous assurer de conserver une copie du fichier restore.env et des fichiers journaux. Le processus de recovery brutale implique parfois une perte de données et il est donc préférable d’être en sécurité.
Voici la syntaxe de la recovery brutale : Eseutil /cc « Chemin du dossier contenant le fichier restore.env ». Une fois la procédure terminée, le dossier temporaire contenant le fichier restore.env sera vide.
3. Si une sauvegarde valide n’est pas disponible
Si aucune des méthodes ci-dessus n’est possible, utilisez ESEUtil comme suit : eseutil /p
Appuyez sur « OK » dans la fenêtre contextuelle suivante qui s’affiche, puis le processus commencera. Une fois le processus terminé, exécutez eseutil avec le commutateur \mh pour vérifier à nouveau la cohérence de la database. Cette fois, la fermeture devrait être propre. La défragmentation de la database maintenant devrait résoudre l’erreur.
Défragmentation hors ligne
La dernière étape consiste à défragmenter la database pour la disposer sur le server et à supprimer les pages inutilisées afin de réduire l’espace disque. Une nouvelle database compacte est créée, sans anciennes données ni pages inutilisées. La syntaxe utilisée est la suivante : eseutil /d Database_Name
Solution recommandée
Si vous souhaitez utiliser une méthode autre que ESEUtil ou si vous souhaitez rendre l’ensemble du processus plus simple et sans risque, utilisez le logiciel Exchange database repair professionnel Stellar Repair for Exchange. Il répare le fichier EDB endommagé et extrait tout le contenu de la messagerie au format PST. Le fichier PST nouvellement créé peut ensuite être importé dans Outlook, puis sur un autre server fonctionnant correctement. Avec une procédure simple en 3 étapes, ce produit ramène les MS Exchange databases corrompues à l’état d’exécution.
Ce logiciel performant est compatible avec MS Exchange 2019, 2016, 2013, 2010, 2007, 2003, 2000 et 5.5.
A propos de l'auteur
Eric Simson is an Email Platform Consultant and is associated with Stellar Data Recovery from last 6 years. He writes about the latest technology tips and provides custom solutions related to MS Outlook, MS Exchange Server, Office 365, and many other Email Clients & Servers.
