none
ESEUTIL - migration boite POP3 vers Exchange Server 2010 et ‘Espace disque saturé par les logs : comment s’en sortir ? RRS feed

  • Discussion générale

  • Bien le bonjour,

     

    Ceci est un petit partage d'expérience qui je pense aura largement sa place dans le forum.

     

    Je tiens à situer un petit peu le contexte, il s'agit d'une migration de boites POP3 vers un serveur Exchange 2010. Tout s'est bien déroulé jusqu'au moment où la partition de fichiers de transaction est arrivée à saturation d'espace. J'ai fait la grossière erreur d'effacer les journaux de transactions sans avoir préalablement "eseutil /MH"... Evidemment, aucun backup de ces fichiers... le backup étant prévu quelques heures après. Vous l'aurez compris, impossible de remonter la base de données, et surtout inaccessibilité des utilisateurs à leurs messages... (Terminal server, histoire d'en rajouter).

     

    Bien évidemment le stress qui a accompagné cette bourde fut relativement énorme, pas facile de gérer ça. J'ai passé l'après-midi à chercher un moyen de réparer mes erreurs... Sans succès. Suite à ce magistral coup de génie (je n'aime pas la dérision... :)), j'ai eu la bonne idée d'appeler le support Microsoft, on y a le droit "gratuitement", partenariat oblige. Je commence à reprendre des couleurs avec le support de niveau 2, on met en place une base de données "tonale" qui permet à nouveau aux utilisateurs de travailler... Ouf !

    Là où ça se gatte, c'est quand l'on a voulu réparer la base. Bien évidemment, la seule solution envisageable (au niveau Microsoft) est l'utilisation de eseutil /p... Et là, c'est le drame ! L'outil crash systématiquement (Microsoft Exchange Server Database Storage Engine Utilities a cessé de fonctionner) au niveau "Deleting unicode fixup table". On a essayé plusieurs version de eseutil et de ses dll associées... La peau du slip !

    Le support Microsoft niveau 2 me fait donc installer un outil de dump afin de générer un fichier contenant les erreurs. Ce fichier fut envoyé au support niveau 3... Cela fait une semaine, aucune nouvelle depuis. Je commence à réfléchir à utiliser un outil tiers, je pense me procurer Kroll Powercontrols, je crois qu'il est très puissant mais onéreux... :(

    Je ne peux que recommander à tous les débutants de lire cet article pour ne pas tomber dans le même scénario catastrophe que moi :

    http://laubel.wordpress.com/2009/03/31/espace-disque-sature-par-les-logs-comment-sen-sortir/

     

    Si quelqu'un avait un éclair de génie sur cette affaire, j'en serai que plus que reconnaissant, bien que je doute fort qu'on puisse y faire grand chose...

     

    Merci de votre lecture. (ne riez pas trop)

    mardi 13 avril 2010 06:19

Toutes les réponses

  • Bonjour,

    Merci pour la pub ;)...et pour la remontée de bug. Voir aussi:

    http://social.technet.microsoft.com/Forums/en/exchange2010/thread/e680b2ff-7faf-42f9-9dcb-41998586f32d

    Sinon vous êtes bien en Rollup 2 ? En tout cas avec le support vous êtes entre de bonnes mains...maintenant il faut juste être patient et bien sauvegarder E2010 ;))

     


    http://laubel.wordpress.com/
    mardi 13 avril 2010 14:18
  • Bonjour,

     

    Je connaissais ce thread, je me suis senti moins seul quand je l'ai lu ! :) Mais bon il n'y a pas eu de solution à son problème... Je suis bien en rollup 2.

    J'ai eu une réponse du support ce matin, il s'agit bien d'un bug eseutil. Je dois leur fournir d'autres dumps de l'éxécutable ! Je vous tiens au courant de l'évolution de mon problème !

     

    Effectivement, les sauvegardes sont primordiales, mais j'ai eu la poisse ce jour là !

     

    Jérôme.

     

    PS : pas de problème pour la pub, quand il y a des blogs intéressants, complets et surtout en français, on est obligé d'en faire profiter un plus grand nombre ! :)

    mardi 13 avril 2010 21:24
  • Réponse du support niveau 3, impossible de réparer la base.

     

    Conclusion : ne jamais perdre les journaux de transaction.

    vendredi 23 avril 2010 00:26
  • Bonjour Jérome,

    Merci pour votre retour d’expérience.

    Je vais placer un lien vers votre retour dans l’ : « Appel à la contribution ». Si aucun article jusqu’à 15 mai, vous partagerez un sticky thread  avec Frédéric J

    Merci à Frédéric pour cet article J

    Cordialement,

    Roxana

     

     


    Roxana Panait, MSFT ________ Votez l’article qui vous est utile ou postez un pour participer au concours : Appel a la contribution! Publiez un tip ou un petit tutorial (comment faire) sur la technologie que vous connaissez le mieux ! - http://social.technet.microsoft.com/Forums/fr-FR/1635/thread/c0fc6847-a4b0-4253-85e9-8eac0cc95aa0
    vendredi 23 avril 2010 08:21
  •  

    Espace disque saturé par les logs : comment s’en sortir ?? - Frédéric Laubel

    Dans cet article je vais traiter d’un problème vieux comme Exchange 5.5 :) …il s’agit de la gestion des logs et plus précisément du problème d’espace disque qu’ils peuvent poser en cas de dysfonctionnement de la sauvegarde.

    Si la sauvegarde se déroule correctement, les logs sont supprimés après chaque sauvegarde complète ou incrémentielle. Les logs ne sont pas supprimés après une copie ou une sauvegarde différentielle.

    Dans le cas où la sauvegarde  ne se déroule pas correctement, les logs ne sont pas supprimés et ils peuvent prendre toute la place au point de saturer le disque. Les bases sont alors démontées et il n’y a plus de messagerie… se pose la question des logs : que faire ? supprimer tous les logs ? Seulement quelques logs ? les déplacer ?

    Tout d’abord petite explication sur le fonctionnement des logs dans Exchange.

    Les logs sont là pour enregistrer dans la base Exchange toutes les modifications (transaction) : envoi  d’un email par exemple. Tous les fichiers de logs ont la même taille : 5Mo pour Exchange 2000/2003 et 1Mo depuis Exchange 2007. Dans le cas d’un envoi d’un email l’information est stockée dans un fichier de log (un fichier texte) avant d’être enregistrée dans la base Exchange (base de type ESE). Or si les services Exchange s’arrêtent de manière inattendu (par manque d’espace disque par exemple) Exchange n’a pas eu le temps d’enregistrer tous les logs dans ses bases…Il n’est donc pas question de supprimer tous les logs sans discernement !! Il faut différencier précisément les logs qui peuvent être supprimés pour gagner de l’espace disque, des logs qui sont indispensables à la reprise des bases (le montage des bases).

    Nous allons voir comment récupérer cette information cruciale.

    Je vais prendre un cas concret : Une infrastructure où les services Exchange 2007 SP1 ne fonctionne plus. L’administrateur constate que les disques sont remplis à 100% à cause des logs. On peut penser que le serveur à crashé lamentablement…donc les bases doivent être en état « dirty shutdown »…Comment procéder ?

    Et bien c’est très simple et très rapide : il faut lancer ESEUTIL avec les options permettant de récupérer les informations pertinentes, à savoir eseutil /MH :

    eseutil

    Pour mémoire l’utilitaire ESEUTIL se trouve dans le répertoire \Bin d’Exchange.

    La commande renvoi des informations très utiles. La ligne qui nous intéresse ici est celle qui se nomme « Log Required » :

    resultateseutil

    Il y a deux possibilités, soit la base est dans un état inconsistant (il y a de forte chance), soit la base est dans un état consistant (vous êtes chanceux !).

    • La base est dans un état inconsistant (arrêt non propre) : la ligne State est en état « Dirty Shutdown ».

    La  ligne Log Required renvoi l’information suivante : 368-377 (0×170-0×179)
    Kesako ?? et bien c’est la réponse à notre problème ! :)

    Un état inconsistant (dirty shutdown) signifie que certains logs n’ont pas été enregistrés dans la base. Si vous supprimez tous les logs, y compris les logs qui ne sont pas encore enregistrés, Exchange ne pourra pas redémarrer (remonter les bases). Il vous faudra passer par une réparation, donc une perte de données… à éviter.

    La ligne Log Required (que l’on pourrait traduire par logs en attente) indique précisément quels sont les logs qui ne sont pas enregistrés. L’information est donnée sous forme décimal et hexadécimal (uniquement depuis Exchange 2007 SP1). Ici le serveur Exchange est en attente des logs 368 à 377, ou formulé de manière hexadécimal des logs 0×170 à 0×179.

    Dans les deux cas on arrive bien au même nombre de logs (neuf), ouf :)

    Après avoir récupérer cette information il faut aller dans le répertoire des logs :

    logrequired

    Nous retrouvons bien nos neuf logs qui ne sont pas encore enregistrés en base. Maintenant nous pouvons déplacer en toute sécurité tous les autres logs, à l’exception de ces neuf fichiers, du log courant (Enn.log) et du checkpoint (.chk). Simple :)

    Et concernant l’état des bases me direz vous ? Et bien lors du remontage le processus de restauration va automatiquement se lancer pour enregistrer les logs manquant. Le processus est transparent. Encore une fois cela fonctionne uniquement grâce à la présence des logs indispensables au montage ! Si votre base est dans un étant inconsistant et que les logs requis sont absent il faudra réparer les bases (avec ESEUTIL ou ISINTEG).

    Si je reprend mon serveur Exchange et que je monte les bases, tout ce déroule correctement. Si je relance ESEUTL /MH je constate que la base est bien en état consistant ! Vous voyez que la ligne Log Required est à zéro, donc tous mes logs sont bien enregistrés en base :)

    eseutilfix1

    En allant dans le journal système on constate des événements de source ESE et d’ID 301 :

    eventese

    On retrouve nos logs 0×170 à 0×179 !

    • La base est dans un état consistant : la ligne State est en état « Clean Shutdown »

    Dans ce cas, tous les logs sont enregistrés en base, vous pouvez déplacer (au pire supprimer) tous les logs, toujours à l’exception du log en cours (Enn.log) et du fichier de chekpoint (Enn.chk).

    Voilà j’espère avoir était clair. Et surveillez le bon déroulement de vos sauvegardes  !


    Roxana Panait, MSFT ________ Votez l’article qui vous est utile ou postez un pour participer au concours : Appel a la contribution! Publiez un tip ou un petit tutorial (comment faire) sur la technologie que vous connaissez le mieux ! - http://social.technet.microsoft.com/Forums/fr-FR/1635/thread/c0fc6847-a4b0-4253-85e9-8eac0cc95aa0
    vendredi 14 mai 2010 14:47