Heute Morgen ist store.exe irgendwie abgestürzt, was einen Neustart unseres Exchange-Servers erforderlich machte. Er ging ohne Fehler oder Probleme wieder online, alle Transaktionsprotokolle wurden erfolgreich wiedergegeben und alle Stores wurden wie gewohnt gemountet. Für mich war es nur einer dieser zufälligen Abstürze; unser Berater vermutet jedoch, dass es durch eine Beschädigung in einem der Stores verursacht wurde. Vielleicht hat er recht, da er viel mehr Erfahrung hat als ich, aber darum geht es nicht.
Um die vermuteten Fehler zu beheben, plant er, eine ESEUTIL-Defragmentierung (über PerfectDisk) auszuführen, wodurch seiner Aussage nach auch alle vorhandenen Fehler behoben werden.
So wie ich es verstehe, handelt es sich bei Defragmentieren, Überprüfen und Reparieren um drei separate Aktionen. Eine Defragmentierung beinhaltet keinerlei Integritätsprüfung.Ist das richtig? Besteht die Gefahr, eine direkte Defragmentierung einer möglicherweise beschädigten Datenbank durchzuführen?
Bearbeiten:
Hier ist der erste Fehler im Ereignisprotokoll, der den Beginn unserer Probleme anzeigte. Weiß jemand, was das bedeuten könnte?
Event Type: Error
Event Source: Microsoft Exchange Server
Event Category: None
Event ID: 1000
Date: 11/23/2011
Time: 8:15:47 AM
User: N/A
Computer: SERVER
Description:
Faulting application exsp.dll, version 6.5.7638.1, stamp 430e735b, faulting module kernel32.dll, version 5.2.3790.4480, stamp 49c51f0a, debug? 0, fault address 0x0000bef7.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 41 00 70 00 70 00 6c 00 A.p.p.l.
0008: 69 00 63 00 61 00 74 00 i.c.a.t.
0010: 69 00 6f 00 6e 00 20 00 i.o.n. .
0018: 46 00 61 00 69 00 6c 00 F.a.i.l.
0020: 75 00 72 00 65 00 20 00 u.r.e. .
0028: 20 00 65 00 78 00 73 00 .e.x.s.
0030: 70 00 2e 00 64 00 6c 00 p...d.l.
0038: 6c 00 20 00 36 00 2e 00 l. .6...
0040: 35 00 2e 00 37 00 36 00 5...7.6.
0048: 33 00 38 00 2e 00 31 00 3.8...1.
0050: 20 00 34 00 33 00 30 00 .4.3.0.
0058: 65 00 37 00 33 00 35 00 e.7.3.5.
0060: 62 00 20 00 69 00 6e 00 b. .i.n.
0068: 20 00 6b 00 65 00 72 00 .k.e.r.
0070: 6e 00 65 00 6c 00 33 00 n.e.l.3.
0078: 32 00 2e 00 64 00 6c 00 2...d.l.
0080: 6c 00 20 00 35 00 2e 00 l. .5...
0088: 32 00 2e 00 33 00 37 00 2...3.7.
0090: 39 00 30 00 2e 00 34 00 9.0...4.
0098: 34 00 38 00 30 00 20 00 4.8.0. .
00a0: 34 00 39 00 63 00 35 00 4.9.c.5.
00a8: 31 00 66 00 30 00 61 00 1.f.0.a.
00b0: 20 00 66 00 44 00 65 00 .f.D.e.
00b8: 62 00 75 00 67 00 20 00 b.u.g. .
00c0: 30 00 20 00 61 00 74 00 0. .a.t.
00c8: 20 00 6f 00 66 00 66 00 .o.f.f.
00d0: 73 00 65 00 74 00 20 00 s.e.t. .
00d8: 30 00 30 00 30 00 30 00 0.0.0.0.
00e0: 62 00 65 00 66 00 37 00 b.e.f.7.
00e8: 0d 00 0a 00 ....
Antwort1
Eine Offline-Defragmentierung eseutilschlägt fehl, wenn in der Datenbank eine Beschädigung auf Seitenebene festgestellt wird. Sie müssen die /pOption (rePair) verwenden, um beschädigte Seiten zu verwerfen.
Beschädigungen von Daten auf logischer Ebene (denken Sie an Schäden an den „Daten“ in der Datenbank, nicht an der „Struktur“ der Datenbank) können nicht durch repariert werden eseutil. Das isintegTool kann logische Inkonsistenzen in der Datenbank in Exchange-Versionen bis 2007 finden. In Exchange 2010 wurde es durch das Cmdlet ( isintegersetzt .new-MailboxRepairRequestweitere Details finden Sie im Blog des Exchange-Teams).
Abgesehen davon mache ich mir Sorgen um den Rat Ihres Beraters. Sehen Sie im Anwendungsereignisprotokoll Ereignisse von ESE oder Exchange-bezogenen Diensten, die auf eine Beschädigung der Datenbank hinweisen? Im Allgemeinen stürzt Exchange nicht „zufällig“ ab und ein Problem mit einem Hardwaretreiber oder der Hardware selbst scheint eine wahrscheinlichere Ursache zu sein als ein Problem mit Exchange. Da die Protokolle außerdem ohne Probleme wiedergegeben wurden, halte ich es für ziemlich unwahrscheinlich, dass Sie eine Beschädigung auf Seitenebene haben.
Wenn Sie eine Beschädigung auf Seitenebene haben, ist es keine Lösung, diese Beschädigung einfach zu bereinigen. Sie müssen die Grundursache (fehlerhafte Hardware usw.) finden, die die Beschädigung verursacht, und diese beseitigen. Alles andere setzt Sie nur einem anhaltenden Risiko aus.
Die Offline-Defragmentierung stellt an sich kein großes Risiko dar. Sie müssen unmittelbar nach Abschluss der Offline-Defragmentierung eine vollständige Sicherung durchführen, da alle vorherigen inkrementellen und differenziellen Sicherungen nicht wiederhergestellt werden können (da die neue Datenbank eben genau das ist – eine brandneue Datenbank). Natürlich ist Ihr Server während der Defragmentierung auch für Benutzer nicht zugänglich.
Ich würde im Detail untersuchen, was heute Morgen passiert ist, und zu einem Schluss bezüglich der Grundursache (oder zumindest einer sehr wahrscheinlichen Hypothese) gelangen, bevor ich anfange, Geld für die „Behebung“ des Problems auszugeben.
Ich hatte kürzlich einen Fall, bei dem ein Exchange Server 2003-Rechner keine VSS-Snapshots erstellte und bei versuchten Backups verschiedene JET-Fehler meldete. Ich entschied mich, eine neue Exchange-Installation auf einem anderen Rechner zu starten, alle Benutzerpostfächer auf den neuen Rechner zu verschieben, dann die problematische Datenbank auf dem ursprünglichen Server zu löschen und die Erstellung einer neuen zu ermöglichen. Nachdem wir einige Stresstests durchgeführt und überprüft hatten, dass der ursprüngliche Server ordnungsgemäß funktionierte, haben wir alle Postfächer zurück verschoben. In der von Ihnen beschriebenen Situation würde ich diese Strategie bevorzugen (wenn ich genügend Ereignisprotokollmeldungen hätte, die auf eine echte „Beschädigung“ in der Postfachdatenbank des ursprünglichen Exchange Server-Rechners hinweisen).
Bearbeiten:
Der Eintrag, den Sie oben gepostet haben, ist ein Fehler im Exchange-Anbieter für Microsoft Search (der Volltextindizes von Exchange-Datenbanken erstellt). Mich würde interessieren, was danach passiert ist, sowie alle Ereignisse, die diesem unmittelbar vorausgingen, aus dem Systemereignisprotokoll. Hatten Sie auf einem der Volumes des Servercomputers wenig Speicherplatz?
Antwort2
Die ESEUTIL-Defragmentierung ist nicht speziell für die umfangreiche Reparatur von Exchange-Datenbanken gedacht. Die Defragmentierungsfunktion dient dazu, freien Speicherplatz in der Datenbank freizugeben und die Datenbankleistung durch die Erstellung einer neuen komprimierten Datenbankdatei zu optimieren.
Während der Defragmentierung werden möglicherweise auch bestimmte Reparaturen an der Datenbank durchgeführt, wenn Inkonsistenzen oder Probleme festgestellt werden. Dies ist Teil des gesamten Defragmentierungsprozesses und kann kleinere Probleme beheben.
Wenn Ihre Exchange Server-Datenbank beschädigt ist, wird empfohlen, zuerst den Befehl ESEUTIL /mh auszuführen, um den vollständigen Status Ihrer Datenbank zu überprüfen. Wenn Sie festgestellt haben, dass die Datenbank beschädigt ist, können Sie später je nach Datenbankschaden die Befehle ESEUTIL /P oder ESEUTIL /R verwenden. Stellen Sie sicher, dass Sie eine Sicherungskopie Ihrer Datenbank erstellt haben, bevor Sie Reparaturvorgänge durchführen.
Ich empfehle, den Microsoft-Support zu konsultieren, um die richtigen Schritte zur Wiederherstellung sicherzustellen.
Sie können diese Microsoft-Artikel lesen: