15
Exchange 2010 Transaktions Logs entfernen
Hallo Admins,
habe mal testhalber auf unserem Exchange 2010 geschaut warum die Platten so langsam immer voller werden, dabei ist mir aufgefallen dass im Verzeichnis:
inetpub\servers\exchange\v14\Mailbox\Mailbox Database
EXTREM viele Logfiles vorhanden sind - über 39.000 Files. (40GB)
kann ich die FIles einfach löschen ?
Muss ich ein spezielles Backupmachen, damit diese "files" gelöscht werden?
Ich nehme an, dass de Files für den Betrieb der Datenbank nicht benötigt werden ?
Über eure Praxistipps freue ich mich
viele Grüße
Fabio
habe mal testhalber auf unserem Exchange 2010 geschaut warum die Platten so langsam immer voller werden, dabei ist mir aufgefallen dass im Verzeichnis:
inetpub\servers\exchange\v14\Mailbox\Mailbox Database
EXTREM viele Logfiles vorhanden sind - über 39.000 Files. (40GB)
kann ich die FIles einfach löschen ?
Muss ich ein spezielles Backupmachen, damit diese "files" gelöscht werden?
Ich nehme an, dass de Files für den Betrieb der Datenbank nicht benötigt werden ?
Über eure Praxistipps freue ich mich
viele Grüße
Fabio
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 206270
Url: https://administrator.de/contentid/206270
Printed on: April 18, 2024 at 20:04 o'clock
15 Comments
Latest comment
Hallo.
Nein
Ja, ein tägliches Backup (am besten Vollbackup) mit einem geeigneten Programm (z.B. Windows Backup).
LG Günther
kann ich die FIles einfach löschen ?
Nein
Muss ich ein spezielles Backupmachen, damit diese "files" gelöscht werden?
Ja, ein tägliches Backup (am besten Vollbackup) mit einem geeigneten Programm (z.B. Windows Backup).
LG Günther
Hallo Fabio,
Die werden normalerweise beim Backup gelöscht. Alternativ kannst du auch die Umlaufprotokollierung für die Datenbank aktivieren: PS> Set-MailboxDatabase -Identity <Datenbank> -CircularloggingEnabled $true
Etwas Lektüre hierzu: Understanding the Exchange 2010 Store
Ich würde dir empfehlen Backups einzurichten.
BTW, man kann die Postfachdatenbanken natürlich ablegen wo man will, aber das IIS-Verzeichnis finde ich schon außergewöhnlich
Gruß,
gemini
dass im Verzeichnis:
inetpub\servers\exchange\v14\Mailbox\Mailbox Database
EXTREM viele Logfiles vorhanden sind - über 39.000 Files. (40GB)
wenn diese Dateien im Format E0000000001.log und exakt 1024 KB groß sind handelt es sich um die Transaktionslogs.inetpub\servers\exchange\v14\Mailbox\Mailbox Database
EXTREM viele Logfiles vorhanden sind - über 39.000 Files. (40GB)
Die werden normalerweise beim Backup gelöscht. Alternativ kannst du auch die Umlaufprotokollierung für die Datenbank aktivieren: PS> Set-MailboxDatabase -Identity <Datenbank> -CircularloggingEnabled $true
Etwas Lektüre hierzu: Understanding the Exchange 2010 Store
Ich würde dir empfehlen Backups einzurichten.
BTW, man kann die Postfachdatenbanken natürlich ablegen wo man will, aber das IIS-Verzeichnis finde ich schon außergewöhnlich
Gruß,
gemini
Hallo GunterH,
vielen Dank - dachte ich mir.
Datensicherung lief bisher so: - wurde die VM heruntergefahren und wegkopiert. Warum das so gemacht wurde kann nur vermutet werden. Nun gut - ich erkenne, dass hier dringender Handlungsbedarf ist.
Jetzt habe ich in die VM eine "zweite" VHD eingehängt. Diese wird erstmal als Backupmedium von Windows Server Backup genutzt. Ich sichere C: voll mit VSS-COPY-SERVICE.
- das Backup ist nicht durchgelaufen.
Es gibt 3 Datenbanken, davon eine Publicfolder DB.
Fragen:
Da Exchange scheinbar nicht ordentlich gesichert ist - wie bekomme ich das nun "repariert" und "aufgeräumt".
Bei MS habe ich folgenden Artikel gefunden:
http://support.microsoft.com/kb/2616952 [Windows Server Backup May fail the Exchange Consistency Check]
Bevor ich damit loslege wären mir noch ein paar Praxistipps von euch um spätere Probleme zu vermeiden.
Der Konsistenzcheck von Exchange ist fehlgeschlagen. Das Backup wurde zwar "erfolgreich" erstellt aber mit dem Hinweis, dass Exchange nicht zurückgesichert werden kann.
Hier ein Auszug der Meldungen:
The consistency check for the component '24bbe684-7840-4580-b53f-faa60f3c145d'\'Microsoft Exchange Server\Microsoft Information Store\SERVERxx' has failed. The application 'Exchange' will not be available in the backup created at '2013-05-09T22:30:07.379637300Z'. Review the event details for information about consistency check issues.
The description for Event ID 519 from source ESE cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.
If the event originated on another computer, the display information had to be saved with the event.
The following information was included with the event:
eseutil
6560
JetDBUtilities - 6928:
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2\inetpub\servers\exchange\v14\Mailbox\Mailbox Database 0306672614\E0000026725.log
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2\inetpub\servers\exchange\v14\Mailbox\Mailbox Database 0306672614\E0000026726.log
-528
The specified resource type cannot be found in the image file
**
vielen Dank - dachte ich mir.
Datensicherung lief bisher so: - wurde die VM heruntergefahren und wegkopiert. Warum das so gemacht wurde kann nur vermutet werden. Nun gut - ich erkenne, dass hier dringender Handlungsbedarf ist.
Jetzt habe ich in die VM eine "zweite" VHD eingehängt. Diese wird erstmal als Backupmedium von Windows Server Backup genutzt. Ich sichere C: voll mit VSS-COPY-SERVICE.
- das Backup ist nicht durchgelaufen.
Es gibt 3 Datenbanken, davon eine Publicfolder DB.
Fragen:
Da Exchange scheinbar nicht ordentlich gesichert ist - wie bekomme ich das nun "repariert" und "aufgeräumt".
Bei MS habe ich folgenden Artikel gefunden:
http://support.microsoft.com/kb/2616952 [Windows Server Backup May fail the Exchange Consistency Check]
Bevor ich damit loslege wären mir noch ein paar Praxistipps von euch um spätere Probleme zu vermeiden.
Der Konsistenzcheck von Exchange ist fehlgeschlagen. Das Backup wurde zwar "erfolgreich" erstellt aber mit dem Hinweis, dass Exchange nicht zurückgesichert werden kann.
Hier ein Auszug der Meldungen:
The consistency check for the component '24bbe684-7840-4580-b53f-faa60f3c145d'\'Microsoft Exchange Server\Microsoft Information Store\SERVERxx' has failed. The application 'Exchange' will not be available in the backup created at '2013-05-09T22:30:07.379637300Z'. Review the event details for information about consistency check issues.
The description for Event ID 519 from source ESE cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.
If the event originated on another computer, the display information had to be saved with the event.
The following information was included with the event:
eseutil
6560
JetDBUtilities - 6928:
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2\inetpub\servers\exchange\v14\Mailbox\Mailbox Database 0306672614\E0000026725.log
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2\inetpub\servers\exchange\v14\Mailbox\Mailbox Database 0306672614\E0000026726.log
-528
The specified resource type cannot be found in the image file
**
Hallo gemini,
danke für den Tipp und Hinweis zum MS Artikel - habe jetzt im großen und ganzen Verstanden was diese "logs" bedeuten.
Vor längerer Zeit hatte ich mir das bereits mal angeschaut...
Leider lief das Backup bisher nicht erfolgreich durch - was passiert jetzt wenn ich die Umlaufprotokollierung aktiviere?
Kann es sein, dass Exchange dann irgendwann den Dienst verweigert?
Was passiert bei einem Reboot - wenn Transaktionslogs fehlen? Kann ggf. dann der Dienst nicht neugestartet werden?
wenn ich 40.000 Logs habe? Bedeutet, dass diese Logs NICHT in die EDB Datenbank geschrieben wurden? Kann ich mir eigentlich nicht vorstellen, denn die EDB hat eine vernünftige Größe.
Über eure Tipps bin ich sehr dank
freundliche Grüße
danke für den Tipp und Hinweis zum MS Artikel - habe jetzt im großen und ganzen Verstanden was diese "logs" bedeuten.
Vor längerer Zeit hatte ich mir das bereits mal angeschaut...
Leider lief das Backup bisher nicht erfolgreich durch - was passiert jetzt wenn ich die Umlaufprotokollierung aktiviere?
Kann es sein, dass Exchange dann irgendwann den Dienst verweigert?
Was passiert bei einem Reboot - wenn Transaktionslogs fehlen? Kann ggf. dann der Dienst nicht neugestartet werden?
wenn ich 40.000 Logs habe? Bedeutet, dass diese Logs NICHT in die EDB Datenbank geschrieben wurden? Kann ich mir eigentlich nicht vorstellen, denn die EDB hat eine vernünftige Größe.
Über eure Tipps bin ich sehr dank
freundliche Grüße
Hallo.
Das ist aber keine Sicherung
- Umschalten auf Umlaufprotokollierung. Die alten, nicht mehr benötigten Transaktionslogs sollten dann automatisch gelöscht werden.
- Backup druchführen
- Umlaufprotokollierung wieder deaktivieren
- Backup durchführen
- Pfade für Datenbanken und Transaktionslogs anpassen. Im inetpup haben die nun wirklich nichts zu suchen.
LG Günther
Datensicherung lief bisher so: - wurde die VM heruntergefahren und wegkopiert
Das ist aber keine Sicherung
Leider lief das Backup bisher nicht erfolgreich durch
- Umschalten auf Umlaufprotokollierung. Die alten, nicht mehr benötigten Transaktionslogs sollten dann automatisch gelöscht werden.
- Backup druchführen
- Umlaufprotokollierung wieder deaktivieren
- Backup durchführen
- Pfade für Datenbanken und Transaktionslogs anpassen. Im inetpup haben die nun wirklich nichts zu suchen.
LG Günther
Das ist aber keine Sicherung
ja vollkommen richtig - ich habe gerade nochmals nachgehakt - ich glaube hier hat man an Datensicherungssoftware "sparen" wollen, daher wurde dies entsprechend so umgesetzt.
- Umschalten auf Umlaufprotokollierung. Die alten, nicht mehr benötigten Transaktionslogs sollten dann automatisch
gelöscht werden.
Das sehe ich noch als relativ gefährlich an... in unserem Stadium ist es bekannt, dass bereits einig logs "defekt" sind oder "fehlen". Hast du in einem solchen Szenario schonmal die Umlaufprotokollierung aktiviert?gelöscht werden.
The description for Event ID 518 from source ESE cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.
If the event originated on another computer, the display information had to be saved with the event.
The following information was included with the event:
eseutil
6560
JetDBUtilities - 6928:
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2\inetpub\servers\exchange\v14\Mailbox\Mailbox Database 0306672614\E0000028888.log
-528
The following information was included with the event:
eseutil
6560
JetDBUtilities - 6928:
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2\inetpub\servers\exchange\v14\Mailbox\Mailbox Database 0306672614\E0000026729.log
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2\inetpub\servers\exchange\v14\Mailbox\Mailbox Database 0306672614\E000002672A.log
-528
The specified resource type cannot be found in the image file
eseutil
6560
JetDBUtilities - 6928:
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2\inetpub\servers\exchange\v14\Mailbox\Mailbox Database 0306672614\E0000026725.log
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2\inetpub\servers\exchange\v14\Mailbox\Mailbox Database 0306672614\E0000026726.log
-528
The specified resource type cannot be found in the image file
The following information was included with the event:
eseutil
6560
JetDBUtilities - 6928:
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2\inetpub\servers\exchange\v14\Mailbox\Mailbox Database 0306672614\E0000007876.log
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2\inetpub\servers\exchange\v14\Mailbox\Mailbox Database 0306672614\E0000026722.log
-528
The specified resource type cannot be found in the image file
- Backup druchführen
- Umlaufprotokollierung wieder deaktivieren
- Backup durchführen
- Pfade für Datenbanken und Transaktionslogs anpassen. Im inetpup haben die nun wirklich nichts zu suchen.
LG Günther
- Umlaufprotokollierung wieder deaktivieren
- Backup durchführen
- Pfade für Datenbanken und Transaktionslogs anpassen. Im inetpup haben die nun wirklich nichts zu suchen.
LG Günther
die Pfade werde ich natürlich noch wenn alles wieder überschaubar ist anpassen.
--- ok ich habe das hier gelesen:
Verwenden der Umlaufprotokollierung
http://technet.microsoft.com/de-de/library/bb124857%28v=exchg.65%29.asp ...
- wie kann ich sicherherstellen ,dass die transaktionslogs in die Datenbanken geschrieben wurden.
Wäre das nicht der 1. Schritt?
viele Grüße
Fabio
--- ok ich habe das hier gelesen:
Verwenden der Umlaufprotokollierung
http://technet.microsoft.com/de-de/library/bb124857%28v=exchg.65%29.asp ...
- wie kann ich sicherherstellen ,dass die transaktionslogs in die Datenbanken geschrieben wurden.
Wäre das nicht der 1. Schritt?
viele Grüße
Fabio
Hallo.
Deshalb aktiviert man ja die Umlaufprotokollierung.
Ja. Und auch schon öfter jemanden geraten es zu tun - hier z.B.einer der vielen Beiträge zu diesem Thema - http://www.mcseboard.de/topic/171835-problem-mit-einer-fehlenden-protok ...
Würde es micht so sein, hättest du schon lange eine defekte, nicht mehr mountbare Datenbank
Wie denn? Wenn die Logs fehlen oder defekt sind.
Woran scheitert es bei deinem Vorhaben? Fahre den Exchange Server herunter und kopiere die VM weg. Dann hast du ein Notfall Backup, und dann bereinige dein Problem.
LG Günther
Das sehe ich noch als relativ gefährlich an... in unserem Stadium ist es bekannt, dass bereits einig logs "defekt" sind oder "fehlen".
Deshalb aktiviert man ja die Umlaufprotokollierung.
Hast du in einem solchen Szenario schonmal die Umlaufprotokollierung aktiviert?
Ja. Und auch schon öfter jemanden geraten es zu tun - hier z.B.einer der vielen Beiträge zu diesem Thema - http://www.mcseboard.de/topic/171835-problem-mit-einer-fehlenden-protok ...
wie kann ich sicherherstellen ,dass die transaktionslogs in die Datenbanken geschrieben wurden
Würde es micht so sein, hättest du schon lange eine defekte, nicht mehr mountbare Datenbank
Wäre das nicht der 1. Schritt?
Wie denn? Wenn die Logs fehlen oder defekt sind.
Woran scheitert es bei deinem Vorhaben? Fahre den Exchange Server herunter und kopiere die VM weg. Dann hast du ein Notfall Backup, und dann bereinige dein Problem.
LG Günther
Hallo Günther,
danke nochmals für deine kritischen Anmerkungen. Ich werde das dann über "Nacht" genauso durchführen.
1. Server herunterfahren.
2. Server vhd wegkopieren
3. Umlaufprotokollierung aktivieren.
- ich vermute, dass dann die Menge der Dateien innerhalb von Minuten nach Aktivierung der Uml. Protokollierung "drastisch" reduziert wird.
- ich würde dann Versuchen im Windows Server Backup ein backup, mit aktivierter Umlaufprotokollierung zu starten, ist dies erfolgreich möglich würde ich die
4. Umlaufprotokollierung wie empfohlen deaktivieren und im "Normalebtrieb" ein Backup durchführen.
5. Im Anschluss werde ich mich melden und von meinen Ergebnissen berichten.
letzte Frage: ich habe mir vor ca. 1h die edb Größe der Datenbank notiert. leider hat sich an der Größe der 40.519.232 kb mailbox...edb nichts verändert -diese bleibt konstant bei 40.519.232 kb - ich hätte vermutet, dass neue Transaktionslogs relativ zügig in die edb geschrieben werden oder schreibt Exchange periodisch alle x-Stunden in die edb?
danke nochmals für deine kritischen Anmerkungen. Ich werde das dann über "Nacht" genauso durchführen.
1. Server herunterfahren.
2. Server vhd wegkopieren
3. Umlaufprotokollierung aktivieren.
- ich vermute, dass dann die Menge der Dateien innerhalb von Minuten nach Aktivierung der Uml. Protokollierung "drastisch" reduziert wird.
- ich würde dann Versuchen im Windows Server Backup ein backup, mit aktivierter Umlaufprotokollierung zu starten, ist dies erfolgreich möglich würde ich die
4. Umlaufprotokollierung wie empfohlen deaktivieren und im "Normalebtrieb" ein Backup durchführen.
5. Im Anschluss werde ich mich melden und von meinen Ergebnissen berichten.
letzte Frage: ich habe mir vor ca. 1h die edb Größe der Datenbank notiert. leider hat sich an der Größe der 40.519.232 kb mailbox...edb nichts verändert -diese bleibt konstant bei 40.519.232 kb - ich hätte vermutet, dass neue Transaktionslogs relativ zügig in die edb geschrieben werden oder schreibt Exchange periodisch alle x-Stunden in die edb?
Moin,
die Größe der .edb ändert sich kaum ohne Online/Offline Defragmentierung, ansonsten wächst sie nur, kleiner wird sie von allein nie...
Gruß
24
die Größe der .edb ändert sich kaum ohne Online/Offline Defragmentierung, ansonsten wächst sie nur, kleiner wird sie von allein nie...
Gruß
24
JA also dasss Sie automatisch nicht kleiner wird, ist mir schon klar..
jedoch wollte ich einfach nur wissen, ob es normal ist, dass die edb in meinem Fall seit einigen Stunden immer exakt gleich groß ist.
ist das bei dir auch so 24?
jedoch wollte ich einfach nur wissen, ob es normal ist, dass die edb in meinem Fall seit einigen Stunden immer exakt gleich groß ist.
ist das bei dir auch so 24?
ja,
auftretende Lücken werden neu befüllt, keine Änderung der Größe...
Gruß
24
auftretende Lücken werden neu befüllt, keine Änderung der Größe...
Gruß
24
ah ok das ist ja sehr interessant und effizient - erwartet man von MS nicht immer;)
Hallo Günther, ich hatte versprochen mich nochmals zurückzumelden.
ok also habe jetzt die Umlaufprotokollierung aktiviert. Ich konnte beobachten, dass direkt nach der Aktivierung und erneutem Mounten der Datenbank alle Transaktionslogs sofort weg waren.
Das lief wirklich super.
Im Anschluss habe ich die DB erneut dismounted.
die Umlaufprotokollierung deakvitiviert.
die DB erneut gemounted. Alle Protokolle waren bereinigt. Die Datenbanken und Exchange liefen einwandfrei.
vielen Dank für eure Infos, eine entsprechende Windows Server Sicherung habe ich eingerichtet und werde dann beobachten, ob die Transaktionslogs nach der Sicherung automatisch gelöscht werden - ich gehe davon aus, dass dies dann perfekt funktionieren wird.
ok also habe jetzt die Umlaufprotokollierung aktiviert. Ich konnte beobachten, dass direkt nach der Aktivierung und erneutem Mounten der Datenbank alle Transaktionslogs sofort weg waren.
Das lief wirklich super.
Im Anschluss habe ich die DB erneut dismounted.
die Umlaufprotokollierung deakvitiviert.
die DB erneut gemounted. Alle Protokolle waren bereinigt. Die Datenbanken und Exchange liefen einwandfrei.
vielen Dank für eure Infos, eine entsprechende Windows Server Sicherung habe ich eingerichtet und werde dann beobachten, ob die Transaktionslogs nach der Sicherung automatisch gelöscht werden - ich gehe davon aus, dass dies dann perfekt funktionieren wird.
Hallo,
kannst Du dann bitte den Beitrag als gelöst markieren?
Danke
24
kannst Du dann bitte den Beitrag als gelöst markieren?
Danke
24
