Exchange 2007 Transaktionslogfiles

[paddy89 10]

Morgen,

 

mal eine Grundsätzliche Frage, die ich mit Hilfe vom Web nicht klären konnte (oder falsch gesucht habe).

In meinem Fall habe ich aber tausende .log Files im Exchange Verzeichnis. Transaktionslogs?!.

(Umlaufprotokollierung war interessanter weise ganze Zeit an).

Was wird wirklich in diesen Gespeichert? Ich weis das Änderungen in diesen stehen. Aber ist es so zu verstehen, das wenn ich die lösche bzw wegschieben, das dann auch diese Mails in dem Sinne weg wären?

Mir fehlt da etwas das Verständnis.

 

Zum Problem:

Seit Ewigkeiten lief keine Sicherung mehr. Dies ist mir zum Glück aufgefallen.

Log sind mittlerweile 130GB groß. Sicherungsprogramm meldete zuletzt Integritäts Prüfung fehlerhaft.

Exchange DB überprüft/repariert/defragmentiert erneut überprüft -> ok

Sicherung meldete immer noch das selbe Problem.

Habe dann recherchiert und einen Lösungsansatz von Arcserve selbst gefunden -> die Logs sollen verschoben werden, Sicherung durchlaufen lassen und wieder zurück schieben.

Dann sollten sich ja eig die .log Dateien von allein löschen/zusammen fügen oder?

 

Passiert aber leider nicht. In der DB selbst steht drin, das gestern eine erfolgreiche Vollsicherung durchgeführt wurde.

 

Was muss ich nun machen, um die .logs weg zu bekommen??

 

Achso... hatte auch versucht die Umlaufprotokollierung zu deaktivieren, DB neu einbinden und wieder zu starten -> kein Unterschied :(

 

Danke soweit =)

bearbeitet 22. Juli 2014 von paddy89

[RobertWi 81]

Moin,

 

zum einen kann ich mir nicht vorstellen, dass man dazu keine Informationen findet. Eventuell fehlt Dir das Wissen, diese richtig zu deuten und umzusetzen. Das ist nicht schlimm, aber dann solltest Du Dir jemanden ins Haus holen, der davon Ahnung hat.

 

Wenn die Umlaufprotokollierung wirklich die gesamte Zeit aktiv war und die Log-Dateien NICHT gelöscht worden sind, dann suchst Du entweder an der falsche Stelle oder Du hast ein massives Problem mit Deiner Datenbank. Dann gilt wieder Absatz 1 Satz 2.

 

Im Normalbetrieb ist die Umlaufprotokollierung deaktiviert und die Logs verschwinden nach dem Backup. Tun sie das nicht, ist das Backup fehlerhaft.

 

Auf keinen Fall solltest Du ohne fundiertes Wissen irgendwelche Log-Dateien löschen oder verschieben. Schon durch das Verschieben kann es nun sein, dass Du Inkonsitenzen hast. Das ist keine Raketentechnikg, aber die Gefahr eines Datenverlustes ist hoch.

[Alith Anar 40]

Schau mal hier: http://technet.microsoft.com/de-de/library/bb331951.aspx

Norbert oder Robert werden dir da aber mehr aus ausführlicher was zu sagen können.

Angesichts von 130 GB Logfiles solltest du aber sehr genau gucken.

bearbeitet 22. Juli 2014 von Alith Anar

[paddy89 10]

Hm ok. Les ich mir gleich mal durch.

Backup ist definitiv ok. Bericht Logs von Arcserve sind ok und die Exchange DB sagt es selbst auch.

Habe auch gesehen das einmal der Exchange auf DB Ebene gesichert wird und zusätzlich nochmal das gesamte Exchange Verzeichnis.

 

Wieso kann man die Zusammenführung nicht manuell erzwingen? -> Vorausgesetzt die DB ist ok.

 

Mir fällt ein, nachdem ich die Files verschoben hatte, war der DB check (Integrität/sauberes Shutdown) noch immer ok... heißt das dann nicht auch, das ich diese löschen kann? Dann müssten doch alle Infos zurückgeschrieben sein.

bearbeitet 22. Juli 2014 von paddy89

[RobertWi 81]

Das Exchange Verzeichnis muss nicht gesichert werden, nur die Datenbank als Datenbank.

 

Hebe die Bereitstellung der Datenbank auf.

Wechsel in den Pfad mit der EDB-Datei und führe aus:

 

eseutil /mh NAME_DER_EDB_DATEI.edb

 

Dann suchst Du die Zeile "State". In der muss "Clean Shutdown" stehen.

In der Zeile darunter "Log Required" muss stehen "0-0"

 

Wenn Du diese beiden Zeilen siehst, kannst Du die ZU DIESER DATENBANK GEHÖRENDEN Log Dateien löschen. Aber keine anderen! 

 

Wenn Du Dir nicht sicher bist, ruf in der EMS folgenden Befehl auf:

 

Get-Mailboxdatabase NAME_DER_DATENBANK | fl *path*

 

Darin findest Du eine Exx.log und diverse Exx0000xx.log Dateien und eine Exx.chk (xx ist ein Prefix, das in allen Dateien gleich ist). Diese kannst Du löschen, wenn der Status Clean Shutdown ist.

 

Danach schaltest Du noch die Umlaufprotokollierung wieder ab und stellst die DB wieder bereit. Anschließen führst Du ein Vollbackup durch.

 

Und wie gesagt: Wenn Du Dir nicht sicher bist, hol jemanden dazu. 

[paddy89 10]

Danke RobertWi, werde es heute Abend in aller Ruhe durchgehen.

 

Wenn in der Exchange Console nur eine DB angezeigt wird, ist auch nur eine da?! -First

 

Zusätzlich gibt es noch die DB für öffentliche - Second.. die Logs liegen aber in einem anderen Verzeichnis.

 

Im First DB Verzeichnis liegen 2 Dateien mit E00resXXXXX.jrs. Für was sind diese?

Eine exx.chk und eine exx.log sowie tausende E00000xxxx.log

[RobertWi 81]

Die jrs Dateien sind Platzhalten, können auch gelöscht werden.

 

Wenn Du nur eine Mailbox- und eine ÖÖ-DB hast, da lautet das Prefix für die Mailbox-DB normalerweise "E00" und das für die ÖO-DB lautet "E01". 

[paddy89 10]

Genau so ist es. Präfix ist anders sowie das Verzeichnis. 

Dann werde ich das später oder heute Abend mal überprüfen.

 

Was ist wenn:

In der Zeile darunter "Log Required" muss stehen "0-0"

dies nicht so drin steht?

[RobertWi 81]

Was ist wenn:

In der Zeile darunter "Log Required" muss stehen "0-0"

dies nicht so drin steht?

 

Dann hast Du ein mächtiges Problem, hoffen wir, dass es nicht so ist (glaube ich auch zu 99% nicht, aber sicher muss man trotzdem sein).

[paddy89 10]

So,
kam nun doch dazu.

Schaut ja dann alles gut aus.

Habe die DB heruntergefahren und das Verzeichnis umbenannt. Dann das eigentliche Verzeichnis neu erstellt und wieder bereit gestellt. Umlaufprotokollierung habe ich zuvor bereits ausgestellt.

Im neuen Verzeichnis sind direkt Exx.chk / Exx.log / E00...1.log / Exxresxxxxx1.jrs / Exxresxxxxx2.jrs

tmp.edb.

Nun hat er innerhalb von 5 min die 3. .log Datei erstellt.

 

Hier noch der Auszug

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

Initiating FILE DUMP mode...
         Database: Mailbox Database.edb

        File Type: Database
   Format ulMagic: 0x89abcdef
   Engine ulMagic: 0x89abcdef
 Format ulVersion: 0x620,12
 Engine ulVersion: 0x620,12
Created ulVersion: 0x620,12
     DB Signature: Create time:07/20/2014 17:10:51 Rand:158681478 Computer:
         cbDbPage: 8192
           dbtime: 19544156 (0x12a385c)
            State: Clean Shutdown
     Log Required: 0-0 (0x0-0x0)
    Log Committed: 0-0 (0x0-0x0)
   Streaming File: No
         Shadowed: Yes
       Last Objid: 4538
     Scrub Dbtime: 0 (0x0)
       Scrub Date: 00/00/1900 00:00:00
     Repair Count: 2
      Repair Date: 07/16/2014 22:54:57
 Old Repair Count: 2
  Last Consistent: (0x31204,C9,CF)  07/22/2014 10:29:40
      Last Attach: (0x311D5,9,86)  07/22/2014 08:57:44
      Last Detach: (0x31204,C9,CF)  07/22/2014 10:29:40
             Dbid: 1
    Log Signature: Create time:11/04/2009 12:57:08 Rand:2816760 Computer:
       OS Version: (6.0.6002 SP 2 NLS 500100.50100)

Previous Full Backup:
        Log Gen: 201107-201109 (0x31193-0x31195) - OSSnapshot
           Mark: (0x31196,8,16)
           Mark: 07/21/2014 19:51:12

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

Operation completed successfully in 0.47 seconds.

[RobertWi 81]

Bitte prüfe die Sicherheitsberechtigungen der beiden Verzeichnisse, weil Du eventuell nicht die richtigen hast.

 

Ansonsten sieht das doch gut aus. Warte noch ein paar Log-Dateien ab und dann wirf das Backup an.

bearbeitet 22. Juli 2014 von RobertWi

[paddy89 10]

oh... wie kommst du drauf? Meinst du die für die Logs?

 

- sollten dann nach dem Backup die Logs wieder weg sein?

bearbeitet 22. Juli 2014 von paddy89

[RobertWi 81]

Die Berechtigungen für das Verzeichnis. Du hat es ja neu angelegt und machst das mit anderen Berechtigungen als Exchange.

 

Ja, nach dem Backup sollten die nicht mehr benötigten Logs verschwinden (siehe auch meinen Post #2). Allerdings muss erst ein wenig Arbeit auf der Datenbank gewesen sein, sonst ist noch nichts in der EDB-Datei gelandet und alle Logs werden noch benötigt und keine verschwindet.

[Daniel -MSFT- 129]

BTW: Was mir grundsätzlich hier immer wieder auffällt, ist die falsche Vorgehensweise des OP, die Datenbank zu reparieren und damit kleinere bis grössere Datenverluste in Kauf zu nehmen.

 

Wozu gibt es eigentlich das Backup?

 

Die vielen Logs entstehen, wenn die Umlaufprotokollierung NICHT eingeschaltet ist (so sollte das auch sein) und das Backup nicht ordentlich läuft.

 

Du hast also auf jeden Fall Optimierungsbedarf beim Backup kontrollieren, wenn das keinem auffällt, obwohl fleissig Tapes gewechselt werden.

 

Bei Exchange löscht das Vollbackup nur dann die Logs, wenn die DB in Ordnung ist und das Backup erfolgreich durchlief. Tut es das nicht, liegt in der Regel ein Hardwaredefekt vor beim Tape oder beim Festplattensystem. Den gilt es zu finden und zu lösen.

 

Danach spielt man die letzte erfolgreiche Sicherung wieder zurück mit Roll Forward Recovery. Exchange spielt die Logs erneut ab und man erleidet keinen Datenverlust.

 

Wenn man das über die Recovery Storage Group macht, dann geht das mit minimaler Downtime (2 min wenn man weiss, was man tut) im laufenden Betrieb.

 

Für Exchange 2003 hatte ich das mal sehr schön erklärt: Hier https://msevents.microsoft.com/cui/eventdetail.aspx?culture=de-DE&EventID=118771083 und hier http://blogs.technet.com/b/dmelanchthon/archive/2005/09/01/webcast-exchange-troubleshooting.aspx und hier http://blogs.technet.com/b/dmelanchthon/archive/2005/03/04/exchange-server-2003-problembehandlung-und-systemwiederherstellung.aspx

[RobertWi 81]

Dazu passt übrigens nicht, dass laut Aussage des OP die Datenbank sich selbst als gesichert betrachtet, bestätigt durch die Kopie der eseutil-Ausgabe. ;)

 

Ich bin sicher, wenn man sich die Dateien anschaut wird man sehen, dass es Lücken in der Nummerierung und dem Erstellungsdatum gibt und die Logs als Reste von irgendwann früher übrig geblieben sind.

bearbeitet 22. Juli 2014 von RobertWi