none
Récupération base de données Exchange RRS feed

  • Discussion générale

  • Bonjour,

    On a un serveur windows 2012R2 avec exchange 2016 15.1 build 1979.3.

    Il est partitionné avec une partition système qui héberge exchange, une partition pour les bases de données en ReFS, une partition pour les journaux de transaction, une partition dédiée au pagefile.

    Suite à une saturation de la partition accueillant les journaux de transaction on cherche à remettre les bases en services
    Pour remettre les bases en état on a utilisé eseutil.
    Un eseutil /mh indique Dirty Shutdown (avec log à 0x0).


    Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
    Version 15.01
    Copyright (C) Microsoft Corporation. All Rights Reserved.

    Initiating FILE DUMP mode...
             Database: .\Boites personnel administratif.edb


    DATABASE HEADER:
    Checksum Information:
    Expected Checksum: 0xac4989a4
      Actual Checksum: 0xac4989a4

    Fields:
            File Type: Database
             Checksum: 0xac4989a4
       Format ulMagic: 0x89abcdef
       Engine ulMagic: 0x89abcdef
     Format ulVersion: 0x620,60,120  (attached by 9040)
     Engine ulVersion: 0x620,60,120  (efvCurrent = 9040)
    Created ulVersion: 0x620,20
         DB Signature: Create time:08/14/2020 13:47:15.561 Rand:290435157 Computer:
             cbDbPage: 32768
               dbtime: 1207671559 (0x47fb9b07)
                State: Dirty Shutdown
         Log Required: 0-0 (0x0-0x0)
        Log Committed: 0-0 (0x0-0x0)
       Log Recovering: 0 (0x0)
       Log Consistent: 0 (0x0)
      GenMax Creation: 00/00/1900 00:00:00.000 LOC
             Shadowed: Yes
           Last Objid: 891878
         Scrub Dbtime: 0 (0x0)
           Scrub Date: 00/00/1900 00:00:00.000 LOC
         Repair Count: 38
          Repair Date: 08/14/2020 13:47:15.561 UTC
     Old Repair Count: 0
      Last Consistent: (0x0,0,0)  00/00/1900 00:00:00.000 LOC
          Last Attach: (0x0,0,0)  08/14/2020 13:47:15.592 UTC
          Last Detach: (0x0,0,0)  00/00/1900 00:00:00.000 LOC
        Last ReAttach: (0xCA319,2,268)  08/13/2020 08:47:43.817 UTC
                 Dbid: 1
        Log Signature: Create time:00/00/1900 00:00:00.000 Rand:0 Computer:
           OS Version: (6.2.9200 SP 0 NLS 6020e.6020e)

    Previous Full Backup:
            Log Gen: 0-0 (0x0-0x0)
               Mark: (0x0,0,0)
               Mark: 00/00/1900 00:00:00.000 LOC

    Previous Incremental Backup:
            Log Gen: 0-0 (0x0-0x0)
               Mark: (0x0,0,0)
               Mark: 00/00/1900 00:00:00.000 LOC

    Previous Copy Backup:
            Log Gen: 0-0 (0x0-0x0)
               Mark: (0x0,0,0)
               Mark: 00/00/1900 00:00:00.000 LOC

    Previous Differential Backup:
            Log Gen: 0-0 (0x0-0x0)
               Mark: (0x0,0,0)
               Mark: 00/00/1900 00:00:00.000 LOC

    Current Full Backup:
            Log Gen: 0-0 (0x0-0x0)
               Mark: (0x0,0,0)
               Mark: 00/00/1900 00:00:00.000 LOC

    Current Shadow copy backup:
            Log Gen: 0-0 (0x0-0x0)
               Mark: (0x0,0,0)
               Mark: 00/00/1900 00:00:00.000 LOC

         cpgUpgrade55Format: 0
        cpgUpgradeFreePages: 0
    cpgUpgradeSpaceMapPages: 0

           ECC Fix Success Count: none
       Old ECC Fix Success Count: none
             ECC Fix Error Count: none
         Old ECC Fix Error Count: none
        Bad Checksum Error Count: none
    Old bad Checksum Error Count: none

      Last Database Maintenance Finish Date: 00/00/1900 00:00:00.000 LOC
    Current Database Maintenance Start Date: 02/13/2020 06:48:37.112 UTC
          Highest Continuous Database Maintenance Page: 0
          Highest Database Maintenance Page: 0

      Database Header Flush Signature: Create time:08/14/2020 13:47:15.592 Rand:534315225 Computer:
     Flush Map Header Flush Signature: Create time:08/14/2020 13:47:15.592 Rand:3204927594 Computer:


    Operation completed successfully in 0.15 seconds.

    Pour une première base, un eseutil /p a permis de la remettre en service. Elle est à présent montée et fonctionnelle.

    Pour une seconde base eseutil /p plante.

    La base de données fait 92Go et il reste 131Go sur la partition.

    Avez-vous une solution/idée ?

    Merci



    vendredi 14 août 2020 13:53

Toutes les réponses

  • Bonsoir,

    d'après le message, il reste des fichiers Logs à intégrer à la base.

    https://www.codetwo.com/admins-blog/how-to-use-exchange-extensible-storage-engine-utilities-eseutil-tool/

    Une réparation Soft : (ESEUTIL /R) qui se chargera d'intégrer les fichiers logs encore accessibles.

    Une vérification d'intégrité : (ESEUTIL /G)

    Ensuite si nécessaire, utiliser ESEUTIL /P, après suppression des logs qui ont été intégrés.

    En cas de gros soucis (et optimisation), il est possible de transférer l'utilitaire et la base sur un autre serveur où Exchange n'est pas installé pour éviter que les logs et autres clés de registre n'interfére avec la réparation uniquement liée à la base de donnée.

    Ne pas oublier d'utiliser l'utilitaire "isinteg -test alltests" jusqu'au moment où plus aucune erreur n'apparait.

    Dans tous les cas, toute base réparée reste suspecte. Il est fortement conseillé de créer une nouvelle base propre et d'y transférer les boites, puis de supprimer la base suspecte.

    A bientôt,


    Thierry DEMAN-BARCELO. Office Apps&Services MVP. MCSE:Enterprise admin, Messaging, Server Infrastructure 2016(89 MCPs). MCSA Office 365,Microsoft 365 Certified: Messaging Administrator Associate,Modern Desktop Administrator Associate, Security Admin https://base.faqexchange.info

    samedi 15 août 2020 20:06
    Modérateur
  • j'ai testé récemment cette outil de réparation de base exchange, j'ai même travaillé sur une petite partie avec eux. tu peux l'essayer pour voir si cela t'aide, je pense qu'ils proposent une version trial 

    xxxxxxxxxxxxxx


    Dakhama Mehdi : Windwos developper https://github.com/dakhama-mehdi


    dimanche 16 août 2020 10:10
  • Bonsoir,

    d'après le message, il reste des fichiers Logs à intégrer à la base.

    https://www.codetwo.com/admins-blog/how-to-use-exchange-extensible-storage-engine-utilities-eseutil-tool/

    Une réparation Soft : (ESEUTIL /R) qui se chargera d'intégrer les fichiers logs encore accessibles.

    Une vérification d'intégrité : (ESEUTIL /G)

    Ensuite si nécessaire, utiliser ESEUTIL /P, après suppression des logs qui ont été intégrés.

    En cas de gros soucis (et optimisation), il est possible de transférer l'utilitaire et la base sur un autre serveur où Exchange n'est pas installé pour éviter que les logs et autres clés de registre n'interfére avec la réparation uniquement liée à la base de donnée.

    Ne pas oublier d'utiliser l'utilitaire "isinteg -test alltests" jusqu'au moment où plus aucune erreur n'apparait.

    Dans tous les cas, toute base réparée reste suspecte. Il est fortement conseillé de créer une nouvelle base propre et d'y transférer les boites, puis de supprimer la base suspecte.

    A bientôt,


    Thierry DEMAN-BARCELO. Office Apps&Services MVP. MCSE:Enterprise admin, Messaging, Server Infrastructure 2016(89 MCPs). MCSA Office 365,Microsoft 365 Certified: Messaging Administrator Associate,Modern Desktop Administrator Associate, Security Admin https://base.faqexchange.info

    Bonjour,

    Eseutil /g me confirme que la base est corrompue.

    Eseutil /p plante toujours.

    lundi 17 août 2020 07:55
  • Bonjour nickola,

    Si vous avez avancé dans votre problématique, veuillez ne pas oublier de marquer comme réponse les conseils qui vous ont aidé. 

    Je vous remercie par avance pour votre retour.

    Cordialement,

    Biliana


    Votez! Appel à la contribution TechNet Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votreproblème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution.

    lundi 24 août 2020 07:09