Comment résoudre l’erreur « Impossible de monter la base de données (hr=0x80004005, ec=1108) » ?

Au cours d’une journée de travail normale, vous verrez certainement que certains ou tous les utilisateurs du serveur Exchange sont incapables d’envoyer ou de recevoir des e-mails et même d’accéder à leur messagerie. Après avoir examiné le problème, vous remarquez que les bases de données des messageries ne sont pas montées. Lorsque vous essayez de monter les bases de données, vous obtenez une erreur, comme indiquée ci-dessous.

Impossible de monter la base de données que vous avez spécifiée. Base de données spécifiée : base de données de messagerie Exchange ; Code d’erreur : Une opération Active Manager a échoué. Erreur : L’action de la base de données a échoué. Erreur : L’opération a échoué avec le message : MapiExceptionDatabaseError : Impossible de monter la base de données. (hr=0x80004005, ec=1108) Diagnostic context:    Lid: 65256      Lid: 10722   StoreEc: 0x454         Lid: 1494    ?- Remote Context Beg ?-    Lid: 45120   dwParam: 0x569817    Lid: 57728   dwParam: 0x56995F    Lid: 46144   dwParam: 0x569A97    Lid: 34880   dwParam: 0x569A97    Lid: 34760   StoreEc: 0xFFFFFE0B    Lid: 46144   dwParam: 0x56A13F    Lid: 34880   dwParam: 0x56A13F    Lid: 54472   StoreEc: 0x1388        Lid: 42184   StoreEc: 0x454         Lid: 1750    ?- Remote Context End ?-    Lid: 1047    StoreEc: 0x454      [Database: Mailbox Database Exchange, Server: R-FS1.webrooster.local]

Dans cette situation, la première chose à faire est d’examiner la mémoire du disque. En général, l’erreur « Impossible de monter la base de données » « (hr=0x80004005, ec=1108) » apparaît lorsque le disque est plein. Maintenant, si vous avez la base de données et les registres sur des disques séparés, vous pouvez vérifier les deux lecteurs. Si le disque de la base de données est plein, vous devez augmenter le stockage ou déplacer la base de données sur un disque plus grand. Il n’y a aucun moyen de compresser la base de données car elle est déjà dans un format compressé.

Si l’emplacement du journal est plein, le coupable serait un logiciel antivirus qui interfère avec la sauvegarde ou les sauvegardes et ne sauvegarde pas correctement votre base de données Exchange et purgent les bases de données. Une autre raison pour laquelle les fichiers journaux ne sont pas purgés est que le logiciel de sauvegarde n’est pas adapté à l’application ou au serveur Exchange. Dans ce cas, vous devez déplacer les fichiers journaux vers un autre emplacement avec plus d’espace de stockage ou augmenter l’espace du disque si le serveur est une machine virtuelle.

Si la base de données ne peut toujours pas être montée, après avoir augmenté l’espace, vérifiez si la base de données est endommagée ou non. Pour ce faire, utilisez l’outil ESEUTIL.

En exécutant la commande ci-dessous, vous pouvez identifier l’état de la base de données.

EseUtil /MH <votre chemin de fichier edb>

Si la base de données est en état d’arrêt non planifié (sale), vous pourriez être dans une situation un peu délicate, car la base de données pourrait être endommagée ou il pourrait y avoir un fichier journal manquant.

Dans un tel cas, vous pouvez utiliser EseUtil pour effectuer une récupération douce ou une récupération dure. Cependant, il n’y a aucune garantie que la base de données sera fixée par la suite.

Tout d’abord, vous devez exécuter la commande ci-dessous pour identifier les journaux requis,

eseutil /ml <emplacement du chemin du journal>

Une fois que vous avez le numéro du journal, généralement comme E00, vous devez utiliser le paramètre R pour initier une récupération douce :

Eseutil /r e00 /l <Emplacement du chemin du journal>/d <Emplacement du chemin de la base de données>

Ceci lancera le processus de récupération. Selon la taille et les dommages subis par la base de données, le processus prendra un certain temps. Une fois qu’il est terminé, vous devez réexécuter la commande Eseutil avec le paramètre / MH pour vérifier l’état de la base de données. Si l’état de la base de données est sain, vous serez en mesure de monter votre base de données.

Si l’état d’arrêt non planifié (sale) persiste, vous avez deux options :

ATTENTION : Si vous effectuez une récupération dure, vous devez accepter la perte de données car le processus purge les données endommagées, quelle que soit leur quantité. D’autre part, après avoir effectué ce processus, Microsoft ne fournira pas d’assistance. En effet, lorsqu’une base de données est récupérée par le biais de la récupération dure, certaines informations sont codées en dur. Lorsque Microsoft s’en aperçoit, il refuse de fournir une assistance.

Pour effectuer la récupération dure, exécutez la commande ci-dessous :

Eseutil /P <Chemin complet de l'emplacement du fichier de la base de données>

Une fois exécutée, vous serez averti de la perte de données et vous devez l’accepter avant de poursuivre. Cette récupération doit être utilisée en dernier recours.

Une fois fait, vous obtiendrez un écran comme ci-dessous.

Vous devrez exécuter à nouveau le logiciel EseUtil avec le paramètre MH pour voir si l’état de la base de données est sain. Si la base de données est saine, vous serez en mesure de fixer la base de données.

La solution simple

La solution manuelle ci-dessus prendra un temps considérable, sans savoir si elle résoudra le problème avec succès. Cependant, il existe une solution facile. Vous pouvez utiliser le Meilleur logiciel de récupération Exchange ? Stellar Repair for Exchange qui peut ouvrir n’importe quelle version de la base de données du serveur Exchange. Si la base de données est endommagée, vous pouvez créer une nouvelle base de données et y déplacer les utilisateurs avec une messagerie vierge. Vous pouvez joindre le fichier EDB à Stellar Repair for Exchange et exporter toutes les messageries vers la nouvelle base de données live Exchange Server. Cette solution vous permet de restaurer le service en un rien de temps, sans récupération complexe.

Related Post