Logdateien für Postfach können nicht gefunden werden

[BNO 10]

Hallo zusammen,

 

ich habe folgendes Problem mit einem Exchange 2010 Server auf einem SBS2011:

 

Im besagten Server ist das RAID heute down gegangen, wegen eines Festplatten Defekts, dieses konnte aber wiederbelebt werden und das eigentlich ohne Datenverluste.

 

Jedoch schmeißt mir der ESE Dienst den folgenden Fehler:

Information Store (2068) Mailbox Database 2011101616: Datenbank G:\Program Files\Microsoft\Exchange Server\V14\Mailbox\Mailbox Database 2011101616\Mailbox Database 2011101616.edb benötigt die Protokolldateien 22652-22673 für eine erfolgreiche Wiederherstellung. Es wurden nur Protokolldateien gefunden, die bei 22653 beginnen. 

Und danach den Fehler 454 vom ESE.

 

Nun habe ich die Anleitung

ESE 454 -515: Missing Required Transaction Log File

von Microsoft befolgt, jedoch mit mäßigem Erfolg. An der Stelle wo für Exchange 2007 beschrieben ist, wo der Log-Pfad ist, sind die Informationen nicht mehr aktuell für den 2010.

 

Nun hab ich mich selber auf die Suche gemacht und Log-Einträge unter

C:\Program Files\Microsoft Exchange\V14\Mailbox\Mailbox Database 2011101616

gefunden. Entsprechend habe ich auch

eseutil /ml ....

ausgeührt. Mit dem Ergebnis, dass die Log-Dateien in Takt sind. Jedoch ist die Datei mit der Ziffer 22653, die laut Fehlermeldung noch vorhanden sein soll nicht darunter und diese ist auf dem Server nicht zu finden.

 

Ich hab mir die Zeitstempel der Dateien auch mal angeschaut, diese scheinen auch alle durchgängig zu sein und auch die Nummerierung stimmt soweit auch.

 

Ich hab zu dem Thema noch diesen Artikel gefunden:

Source: ESE Event ID: 452 (Exchange 8.0) - Technet Events And Errors Message Center: Message Details

Wobei dort primär "radikale" Wege beschrieben werden. Hat einer einen Tipp für mich, wie ich das Problem vom Tisch kriege?

[GuentherH 61]

Hi.

 

Jedoch ist die Datei mit der Ziffer 22653, die laut Fehlermeldung noch vorhanden sein soll nicht darunter und diese ist auf dem Server nicht zu finden.

 

Dieses Transaktionslog ist wahrscheinlich beim Hardwarecrash hops gegangen. Es wird dir also nichts anderes übrig bleiben, als den von MS beschriebenen Weg zu gehen. Hier auch noch ein Beitrag dazu - Exchange Log File Missing

 

Allerdings solltest du dir Gedanken über dein RAID System machen. Wegen einem Plattenausfall, darf der Server nicht crashen.

 

LG Günther

[BNO 10]

Hi,

 

danke für die schnelle Antwort.

 

Das ist ja gerade der Witz. Die .edb liegt auf dem RAID, die Logs aber noch auf der System-Platte, auf der nichts passiert ist.

 

Ich hab jetzt mal ein eseutil /mh ausgeführt, hier das Ergebnis:

C:\Program Files\Microsoft\Exchange Server\V14\Bin>
\Microsoft\Exchange Server\V14\Mailbox\Mailbox Data
ase 2011101616.edb"

Extensible Storage Engine Utilities for Microsoft(R
Version 14.01
Copyright (C) Microsoft Corporation. All Rights Res

Initiating FILE DUMP mode...
        Database: G:\Program Files\Microsoft\Excha
x Database 2011101616\Mailbox Database 2011101616.e


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

Fields:
       File Type: Database
        Checksum: 0xda81422
  Format ulMagic: 0x89abcdef
  Engine ulMagic: 0x89abcdef
Format ulVersion: 0x620,17
Engine ulVersion: 0x620,17
Created ulVersion: 0x620,17
    DB Signature: Create time:10/16/2011 16:41:47
        cbDbPage: 32768
          dbtime: 10641939 (0xa26213)
           State: Dirty Shutdown
    Log Required: 22652-22672 (0x587c-0x5890)
   Log Committed: 0-22673 (0x0-0x5891)
  Log Recovering: 0 (0x0)
 GenMax Creation: 12/12/2011 10:07:53
        Shadowed: Yes
      Last Objid: 4671
    Scrub Dbtime: 0 (0x0)
      Scrub Date: 00/00/1900 00:00:00
    Repair Count: 0
     Repair Date: 00/00/1900 00:00:00
Old Repair Count: 0
 Last Consistent: (0x5234,8,1F)  12/01/2011 10:33:
     Last Attach: (0x5235,9,86)  12/01/2011 10:33:
     Last Detach: (0x0,0,0)  00/00/1900 00:00:00
            Dbid: 1
   Log Signature: Create time:10/16/2011 16:41:45
      OS Version: (6.1.7600 SP 0 NLS ffffffff.ffff

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

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

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

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

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

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

    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 checksum finish Date: 00/00/1900 00:00:00
Current checksum start Date: 00/00/1900 00:00:00
     Current checksum page: 0


Operation completed successfully in 0.141 seconds.

Wie zu sehen ist, ist die Checksumme okay.

Dank dieser Ausgabe bin ich aber einen Schritt weiter gekommen:

     Log Required: 22652-22672 (0x587c-0x5890)
   Log Committed: 0-22673 (0x0-0x5891)

Die Log mit der ID 5891 ist vorhanden, auch die Log 5890 ist vorhanden.

Ich werd mal schauen von welchem Zeitraum die 587c ist, vielleicht krieg eich die aus einer Sicherung wieder raus.

[BNO 10]

Okay, die Dateien sind alle vorhanden, auch die 587c.

[BNO 10]

Ich hab das Problem sauber beheben können. Grundvorraussetzung ist dabei aber ein existierendes Backup der Datenbank.

 

Hier mal mein Vorgehen für alle mit dem gleichen Problem:

 

 

Problematik:

 

Durch einen Ausfall des RAID Systems, auf dem die Postfachdatenbank unseres Exchange 2010 lag, geriet die Datenbank in den Status "Dirty Shutdown". Ein Softrepair brachte das Ergebnis, dass die Logdateien 589c - 589f fehlten. Der Exchange hatte aber, da die Log-Dateien auf C: liegen, weiter in die Logs geschrieben und bereits bei 58A0 weiter gemacht.

 

 

Lösung:

 

Grundvorraussetzung ist ein Backup der Postfachdatenbank, im Grunde ist es egal ob diese im "Dirty Shutdown" hängt oder diese sauber ist. Wichtig ist im Falle eines "Dirty Shutdown" Zustandes, dass die Log-Dateien, die von der Datenbank noch benötigt werden, vorhanden und intakt sind.

 

WICHTIG: Nachdem das Backup eingespielt wurde NICHT einfach ein Soft-Repair starten, da dann der aktuelle Log-Status in die Datenbank geschrieben wird und somit auch für die Datenbank die fehlenden Log-Einträge benötigt werden.

 

Wir gehen also wie folgt vor:

 

1. Aktuelle Datenbank sichern (nur für den Fall der Fälle)

 

2. Sichern Sie auch die Transaktions-Logs

 

3. Alte Sicherung der Datenbank einspielen

 

4. In das Verzeichnis mit den Log-Dateien wechseln

 

5. Den Befehl

eseutil /mh "Pfad zur Datenbank"

ausführen. Damit wird der Header der Datenbankdatei ausgelesen. Unter dem Punkt "Logs required" finden wir die Log-Einträge, die von dieser Datenbank benötigt werden. Steht hier 0-0 ist eh alles in Ordnung. Wir gehen hier aber jetzt davon aus, dass dort Einträge auftauchen, die Datenbank also im "Dirty Shutdown" Status hängt.

 

6. Die Zeile "Logs required" beinhaltet am Ende in Klammern die IDs der Log-Einträge die benötigt werden, bitte überprüfen ob diese vorhanden sind, wenn dies nicht der Fall ist muss die Datenbank entweder von einer Datenbank die "Clear Shutdown" ist ersetzt werden oder man muss eine Hard-Recovery machen.

 

7. Kommen wir nun zum wichtigen Teil:

Wir suchen uns die letzte Log-Datei von der wir wissen das bis zu Ihr die Log-Dateien konsistent sind. Nehmen wir als Beispiel die Einträge aus der Problematik, d.h. wir wissen, dass die Dateien 589c - 589f fehlen, daraus resultiert, dass die letzte konsistente Log-Datei 589b war. Um die Kollisionen mit den nicht vorhandenen Dateien zu beseitigen, löschen wir alle Dateien die nach 598b generiert wurden. In unserem Fall alles von 58A0 und neuer inkl. der E00.log (bzw. die Datei mit Ihrem Log-Datei Präfix, das Ihre Datenbank verwendet).

 

8. Löschen Sie auch die E00.chk, die sogenannte Checkpoint Datei.

 

9. Benennen Sie nun die Datei 598b in E00.log um (oder in das Log-Datei Präfix, das Ihre Datenbank verwendet).

 

10. Führen Sie nun den Befehl

eseutil /ml

aus. Dies bewirkt eine Prüfung der Log-Konsistenz. Wenn keine anderen Dateien Fehlen oder beschädigt sind, sollte der Vorgang erfolgreich abgeschlossen werden. Sollte dies nicht der Fall sein, wiederholen Sie entsprechend die Schritte 7 bis 9 mit den neuen Informationen und führen danach den genannten Befehl erneut aus. Beachten Sie, dass im Falle einer "Dirty Shutdown" Datenbank die benötigten Log-Dateien erhalten bleiben müssen.

 

11. Sobald die Log-Dateien wieder konsistent sind können wir dazu über gehen das Soft-Repair auszuführen.

eseutil /r E00

Je nach Größe der Datenbank kann dieser Vorgang eine ganze Weile dauern. E00 entspricht hier wieder ihrem Log-Datei Präfix. Der Vorgang sollte nun erfolgreich durchgeführt werden und Ihre Datenbank "Clear Shutdown" sein, dies kann mit dem Befehl aus Schritt 5 überprüft werden.

 

12. Fahren Sie Ihre Exchange Dienste hoch, die Datenbank sollte einwandfrei eingebunden werden.

 

 

Disclaimer:

 

Diese Anleitung basiert auf meinen Erfahrungen und ich garantiere nicht, dass diese zum Erfolg führen muss. Anwendung auf eigene Gefahr.

[GuentherH 61]

Hi.

 

Danke für die ausführliche Rückmeldung.

 

LG Günther