EDB Dateien wachsen / explodieren
Diese Seite hilft ihnen, wenn ihre Exchange Datenbanken plötzlich stark anwachsen, d.h. die EDB/STM-Dateien wachsen anscheinend grundlos von Minute zu Minute.
Sollte ihr Exchange Server noch laufen, aber sich langsam dem Ende der Diskkapazität nähern, dann sollten Sie zuerst das Mailrouting stoppen. Dazu kann man den Windows SMTP-Dienst (Exchange 2000/2003) oder den Exchange Transport Service (2007) herunter fahren. Wenn dass noch keine Besserung bringt, dann ist es sicher legitim, den betroffenen Informationsspeicher offline zu nehmen, um in Ruhe den Fehler zu analysieren und zu beseitigen. Wenn die Festplatten erst einmal voll sind, ist die Lösung oft komplizierter, dafür bestimmte Aktionen eben etwas Kapazität benötigt wird,
Und dann schauen wir uns den Server einmal an.
Erwartete Datenzunahmen
Es gibt Situationen, bei denen ist ein Anwachsen "normal", z.B.
- Wiederherstellung aus einem Archiv
Wer aus einem Archiv sehr viele Elemente zurück holt, ersetzt dabei die eventuell vorhandenen Platzhalter durch die originalen Elemente ersetzt, was natürlich sowohl die Transaktionsprotokolle als auch Datenbank anschwellen lässt. Aber da keine Mails "übertragen" werden, bleibt das Messagetracking klein - Migration und Verschieben
Eher selten ist der Fall, dass durch Migrationen die Datenbanken wachsen. "Normalerweise" weiß ein Exchange Admin von solchen Vorgängen. Aber eine Prüfung ist es durchaus wert, welche Mailbox vielleicht dazu gekommen ist. Das kann man natürlich nur ermitteln, wenn man auch vorher schon wusste, welche Postfächer wo liegen und wie groß diese sind. - Import per Recovery Storage Group
Wenn ein Benutzer eine Mail oder gleich das Postfach löscht, dann ist es ein üblicher Weg, über die Recovery Storage Group die Daten wieder bereit zu stellen. Auch hier kann man beim Import ein "Merge" oder ein "COPY" wählen, Beim Copy werden die Elemente in einem Unterordner als Kopie bereit gestellt, so dass sich die Postfachgröße meist einfach mal verdoppelt.
Daher sollten Sie zuerst einmal solche bekannten Themen abklopfen. Gerade Migrationen etc. werden durch das kurzzeitige "Offline"-Schalten des Speichers unterbrochen und starten meist auch nicht mehr automatisch an.
Unerwartete Datenzunahmen
Wenn bei ihnen aber nichts von alledem zutrifft, dann können Sie ziemlich sicher sein, dass eine unerwünschte Aktivität ihren Postfachspeicher extrem wachsen lässt. Letztlich wird, wenn nicht schon geschehen, dies den Server in die Knie zwingt. Festplattenplatz ist nun mal nur begrenzt vorhanden. Hier eine kurze Stichpunktliste, wie sie das Problem einkreisen können.
- Größe des
Nachrichtentracking
Hier stehen, (sofern aktiviert), alle übertragenen Mails als Logeintrag. Schauen Sie sich erst mal einfach die Dateigröße an. Das ist oft schon ein erster Hinweis, ob sich die Datenmenge aktuell im normalen Größenordnungen bewegt. Oft sind Irrläufer und Schleifen die Ursache und die hinterlassen sich natürlich auch im Log. Auch die Öffentliche Ordner Replikation kann schuld sein. - Inhalt des
Nachrichtentracking
Wenn der Verdacht weiter besteht, dass es vielleicht nur eine Schleifenmail ist, dann ist ein Blick in die Logs natürlich ratsam. Es gibt sehr viele (kommerzielle) Tools, die umfangreiche Auswertungen erlauben. Notfalls tut es auch erst mal eine Testversion (z.B. Promodag). Aber auch ein einfacher Blick mit Notepad oder ein öffnen der letzten Zeilen des aktuellen Logs mit Excel und eine Pivot-Tabelle, Empfänger oder Größe kann schnell Gewissheit bringen.
Sollte sich hier der Verdacht bestätigen, dann muss man die Ursache finden und abschalten. Das kann eine Regel im Postfach oder auf dem AD-Konto sein. Im schlimmsten Fall wird man dem Postfach eben die Mailadresse für einige Zeit rauben oder auf dem Gateway den Absender blockieren.
Aber es gibt noch weitere Möglichkeiten, wie der Store schnell wachsen kann. Diesmal kann es ein Client sein. Leider bietet Exchange nicht wirklich ein Log der Client Zugriffe an, aber entsprechende Hilfsmittel gibt es schon:
- Internet Zugriffe / IISogs
Vielleicht ist ja ein wilder OWA, OMA oder ActiveSync Zugriffe das Übel. Auch ein Zugriff per WebDAV oder Webservices (ab 2007) kann den Store schnell wachsen lassen. Kontrollieren Sie einfach mal die Logdateien des Webservers (IISLOG). Ein erster Block gilt der Dateigröße und dem Vergleich zu den vorherigen Tagen. Bewegt sich die Dateigröße im normalen Rahmen, dann müssen wir weiter suchen. Ansonsten lohnt ein Blick in das IISLog hinein, um mit verschiedenen Webserver-Auswertetools (z.B. Webalizer o.ä.) mehr Details über die Anwender zu erfahren. Ein geübter Administrator wird aber auch mit einem einfachen Blick auf die letzten Kilobyte schon Ursachen erkennen können - Dumpster
Aus eigener Erfahrung habe ich schon gesehen, dass ein alter Outlook Client Dateien hochgeladen und aufgrund von Quota-Beschränkungen gleich wieder verworfen hat. Das Postfach ist dabei nicht mal gewachsen, aber man kann im Exchange 2003 System Manager zusätzlich auch die Größe des "Dumpster" anzeigen lassen. Das kostet nur ein paar Minuten aber hilft diesen Missbrauch zu erkennen. - MAPI-Zugriffe
Kniffliger ist die Protokollierung der MAPI-Zugriffe, die danke Cached Mode etc. durchaus Potential für ein Storewachstum mitbringen. Da der Store immer noch keine Logs schreiben kann, kann man nur mit Tools wie ExMon, ExInsight oder End2End Mailbox nachschauen, was gerade los ist und wer da aus der Rolle fällt.
Notfalls kann man mit MAPI-Zugriffe selektiv aussperren, indem man über einen Reg-Key die "Mindestversion" für Outlook hochsetzt.
Wenn all das noch nicht hilft, und ihr Store weiter wächst oder eine "live"-Analyse mit ExMon oder ExInsight nicht mehr möglich ist, weil der Store schon "down" ist, dann bleiben neben den vorhanden Protokolldateien nur noch die Logdateien der Datenbank:
Entgegen vieler anderslautender Aussagen kann man durchaus aus den binären Transaktionsprotokollen Rückschlüsse auf die Veränderungen der Datenbank ziehen. Es gibt sogar Archivprodukte, die genau dies komplett tun, d.h. Änderungen aus den Transactionlogs als Mails in das Archiv zu übertragen. In unserem Fall sollten Sie die Protokolldateien natürlich kopieren, ehe Sie mit einem Texteditor ihrer Wahl (Notepad kann auch 5 MB Dateien öffnen) einen Blick riskieren. Meist finden sich Bruchstücke von Mails und Einträgen und vielleicht finden Sie ja ein gehäuftes Aufkommen bestimmter Mails, die ihnen komisch vorkommen.
Ein Schritt zur Lösung
Ich hoffe Sie haben bis hier die Ursache gefunden und können das Wachstum stoppen. Um einen aus Platzmangel bereits gestoppten Store aber wieder "online" zu stellen, müssen Sie wohl oder übel erst etwas zusätzlichen Platz bereit stellen (Notfalls durch Löschen alter Logs), um dann in der laufenden Datenbank die unerwünschten Elemente zu löschen. Erst wenn diese "richtig" gelöscht sind, lohnt sich eine Offline Defragmentierung, um die EDB/STM-Dateien wieder schrumpfen zu lassen. Aber auch für den ESEUTIL-Lauf benötigen sie natürlich wieder temporär Platz.
Zukünftiger Schutz
Auch wenn Sie diesmal vielleicht mit einem blauen Auge davon gekommen sind, so möchten Sie das nächste Mal nicht wieder förmlich mit runtergelassenen Hosen erwischt werden. Und tatsächlich kann Exchange und Windows an vielen Stellen dem Administrator helfen, entsprechende Vorwarnungen zu erhalten und vor allem das unkontrollierte Volllaufen einer Partition zu verhindern
- Platzhalter
Wer noch mit Windows 2003 und älter arbeitet und die Mehrkosten eines Drittprodukts scheut, kann auf den Festplatten zumindest einige GB Große Dateien (z.B. DVD-Images) anlegen, die einiges an Platz belegen und im Notfall schnell gelöscht werden können. Natürlich sollten die Dateien im Backup ausgeschlossen werden.
Andere Administratoren belegen eine Festplatte nur partiell mit einer Partition um im Notfall schnell (z.B. mit DISKPART) den Platz an die bestehende Partition anfügen zu können. - Quotas auf Verzeichnisse
Wer schon Windows 2003 R2 oder neuer einsetzt, kann auch auf einzelne Verzeichnisse entsprechende Quotas legen. Damit können Sie sich erst einmal "Vorwarnungen" senden lassen, wenn ein Verzeichnis einen bestimmte Obergrenze überscheitet und sie können sogar harte Grenzen aktivieren. In Verbindung mit mehreren Speichergruppen kann damit eine Explosion meist auf eine einzelne Datenbank beschränkt werden. - Quotas auf Mailboxen und Datenbanken
Natürlich sollten sie NIEMALS einen Server ohne aktive Quotawerte betreiben. Es gibt nämlich immer eine Obergrenze und die lautet "Festplattenkapazität". Sie können die Grenzen auch bei den "wichtigen Postfächern" ja so hoch ansetzen, dass Sie faktisch nie zum tragen kommen und nur bei absichtlichem oder auch irrtümlichen Missbrauch schlimmeres verhindern. Es ist allemal besser, wenn nur ein wichtiges Postfach blockiert ist (und schnell wieder gelöst werden kann), anstatt dass dieses Postfach und alle anderen Postfächer auf dem Server gestört sind und die Lösung länger dauert. - Monitoring
Wer es noch nicht hat, sollte (ehe Sie Cluster ins Gespräch bringen) erst mal seine Systeme vernünftig überwachen. Dazu gehören nicht nur die Lüfter und Eventlogs sondern auch vitale Betriebsdaten, wie z.B.: die Warteschlagen aber auch Auswertungen des Nachrichtenflusses und der Zugriffe per HTTP. Einige der oben angeführten Datenquellen können durchaus live überwacht werden. Warum sollten Sie einen SMTP-Dienst nicht automatisch herunter fahren, wenn die durchschnittliche Anzahl der Mails pro Zeiteinheit sich plötzlich explosiv vermehrt ?
Nebenbei kann das Monitoring auch das Wachstum einzelner Mailboxen auswerten
Es gibt also durchaus effektive Hilfsmittel, um einem Wachstum der Datenbanken einhalt zu gebieten oder zumindest nicht mit dem Rücken an der Wand zu stehen.
Weitere Links
- Exchange NOTFALL - Festplatte voll
- ExMon
- ExInsight
- Nachrichtentracking
- End2End Mailbox
- Webalizer
- Rough and Tough” guide to identifying patterns in Transaction
Logs
http://blogs.msdn.com/scottos/archive/2007/07/12/rough-and-tough-guide-to-identifying-patterns-in-ese-transaction-log-files.aspx
Einsatz von Unix STRINGS um Texte aus Tsracking Logs zu extrahieren.
