Hallo Freunde der Sonne,
diesmal schneide ich das Thema – Datenbank-Reparatur an.
Was kann ein Admin tun, wenn eine dreckige Datenbank in seinem Vorgarten liegt?
Ok, löschen – aber es gibt meist auch noch andere Wege!
Beispiel:
Wir haben ein Datenbank-Backup von Nutzdaten oder eine Exchange-Datenbank von einem defekten Exchange-Server zur Verfügung und wollen diese Überprüfen/Reparieren.
Was gehört eigentlich alles zu einer Exchange-Datenbank? (.edb)
Zu erst einmal die Datenbank selbst: „Mailbox Database 1122334455.edb“.
Diese Datei beinhaltet alle darin gespeicherten Postfächer.
Des Weiteren werden bei einer ausgeführten Datenbank folgende Dateien angelegt:
Ein Ordner für Katalog-Daten: „CatalogData-<bla bla>“.
Optional auch Steaming-Dateien: „Mailbox Database 1122334455.stm“,
oder in seltenen Fällen eine Datenbank für temporäre Daten: „tmp.edb“.
Außerdem sollte man nicht die Protokolldateien vergessen:
E0?.log
E0?*.log
Checkpoint-Dateien:
E0?.CHK
All diese Dateien könnten bei einer Wiederherstellung neben der eigentlichen EDB relevant sein,
also bei einer Sicherung berücksichtigen.
Da ich etwas faul bin was dieses Thema angeht:
Siehe MSXFAQ: http://www.msxfaq.de/admin/database.htm
Überprüfen einer Datenbank
Herangehensweise: erst gucken, dann schießen.
Gibt es eigentlich Unterschiede zwischen Datenbanken für Postfächer und öffentliche Ordner?
Ja die gibt es, diese liegen aber ehr innerhalb der Struktur von Exchange.
Bei Postfach-Datenbanken werden die allgemeinen Daten im Active Directory gespeichert und nur den Postfächern intern zugeordnet die dann die Struktur abbilden.
Bei öffentlichen Ordnern liegt die gesamte Hierarchie in der EDB.
Für das prüfen der Datenbank gibt es aber keine Unterschiede.
Wie kann ich nun die Daten einer nicht im Exchange eingebundenen Datenbank abfragen?
(möglichst ohne diese zu verändern)
eseutil /mh <EDB-Datei>
Was ist der wichtigste Wert für das einbinden einer Datenbank?
Status: Clean Shutdown
Sollte es doch ein „Dirty Shutdown“ sein, könnte man sich die Frage stellen woher dieser kommt:
Fehlende Dateien?
Unsaubere Sicherung? (Dateisicherung per VSS ohne Rücksicht auf den Status der Datenbank)
Kaputter Exchange? (meist ist dann auch kein sauberes Herunterfahren möglich gewesen)
Wie kann man dem entgegenwirken?
Folgende Möglichkeiten:
Datenbank Dump (/M)
Datenbank defragmentieren (/D)
Datenbank Prüfsummen testen (K)
Datenbank Integrität prüfen (/G)
Datenbank-Protokolle einspielen (/R)
Datenbank reparieren (/P)
Bei welchem Weg könnte am schnellsten etwas kaputt gehen?
Datenbank reparieren.
Grund hierfür ist: bei der Reparatur wird nicht nur ggf. ein Datenfehler falsch korrigiert oder gelöscht,
es werden auch fehlende Protokolldaten einfach für nichtig erklärt – also gelöscht.
In diesem Falle müsste mit einem Datenverlust gerechnet werden.
Reparatur einer Datenbank
Wie repariere ich eine Exchange-Datenbank?
Mit folgendem Kommando:
eseutil /p <EDB-Datei>
Dieser Vorgang kann einige Zeit in Anspruch nehmen, kommt ganz auf die Größe der Datenbank an.
Ein eiliges Abbrechen bei dem Punkt: Reparaturdaten löschen sorgt dafür, dass ESEUTIL den Status nicht auf: „Clean Shutdown“ zurücksetzt.
Egal wie eilig es ist – abwarten.
Sobald der Status der Datenbank wieder auf: „Clean Shutdown“ steht, sollte es kein Thema sein diese wieder in einem Exchange-Server einzubinden.
(in dem Exchange-Server sollte diese Datenbank dann mit passendem Namen etc. hinterlegt sein)
Für die nicht angesprochenen Funktionen siehe hier:
http://technet.microsoft.com/de-de/library/aa998249(v=exchg.80).aspx
Ein kompletter Weg über Logfiles und ENV siehe hier:
http://msexchangeguru.com/2009/07/12/exchange-database-recovery-using-eseutil-commands/
Dieser Artikel/Post ist für einen größeren Artikel zur Behandlung der Reparatur geschrieben,
entschuldigt bitte, dass ich nicht auf alle Funktionen von ESEUTIL eingegangen bin.
In einem separaten Post könnte ich ja einen Nachtrag formulieren.
Grüße Sid