Exchange Kaltstart - Database Validation ?

[PowerShellAdmin 169]

Guten Morgen,

wir hatten gestern einen Ausfall unseres Hauptservers - der Exchange wurde dadurch im laufenden Betrieb stromlos->Kaltstart

Jetzt wollte ich euch nochmal kurz anfragen, ob der Ablauf so ok ist.

 

Version:Exchange 2010 SP2 CU 4 (August)

 

Das Anfahren der Systeme lief problemlos, auch die Datenbanken wurden wieder gemounted.

Nun habe ich festgestellt, dass ich von der folgenden Windowssicherung nicht auf die Festplatte mit der ExchangeDB zugreifen kann. Das Backupfile lässt sich nicht mounten - Die vorherigen Tage gehen problemlos. Ich wollte mir dort die EDB kopieren und ESUTIL hierdrauf ausführen.

 

Ich wollte jetzt wie folgt vorgehen:

-neues Windowsbackup - Hoffe diesmal erfolgreich

-ESUTIL /g => DB überprüfen

-Alternativ produktive DB offline nehmen und mit esutil /g prüfen

-Anschließend bei Fehlerfall Softrecovery:esuitil /r /E00 ausführen

=> hoffentlich erfolgreich

Sollte /r nicht erfolgreich sein kommt man wohl zu /p.

Ist es dann sinnvoll alle Mailboxes nochmal zu exportieren z.B. pst, oder eine neue DB anzulegen, die MBs dahin zu verschieben ?

Grüße Admin

[RobertWi 81]

Moin,

 

wenn die Datenbank erfolgreich gemounted wurde, dann wurde dabei automatisch ein Softrecovery-Vorgang gestartet. Du solltest beim Start des Server Informations-Einträge im Eventlog sehen, die sinngemäß etwas mit "Wiederherstellung wurde gestartet" und "Wiederherstellung wurde erfolgreich beendet" beeinhalten ("Wiederherstellung ist hier eine unglückliche ober wörtlich korrekte Übersetzung von "Recovery").

 

Exchange führt Softrecovery immer beim Start durch, wenn es die Datenbank im Dirty Shutdown-Status vorfindet (was normalerweise nicht der Fall ist, da die Datenbank beim Runterfahren schon bereinigt werden).

 

Nur in wenigen Ausnahmefällen, wenn z.B. sehr viele Log-Dateien vorliegen, die innerhalb eines gewissen Zeitrahmens nicht eingearbeitet werden können, wird der Recovery-Vorgang abgebrochen.

 

Wenn Du Deine oberen Schritte ausführst, ist die Datenbank "Dirty Shutdown", weil eine Sicherung diese immer so sichert und die fehlenden Log-Dateien mitnimmt.

 

Du gewinnst also keine Aussagekraft.

 

Wenn Du wirklich Angst um die Datei hast, dann nimm sie offline und führe im Offline-Zustand eine Prüfung "/g" und eine Defragmentierung "/d" durch. Danach löschst Du alle Log- und CHK-Dateien und kannst sicher sein, dass alles ok ist.

 

Eine Reparatur würde man dann mit "/p" durchführen.

 

Ich persönlich würde aber erstmal GAR nichts machen und das Event-Log beobachten. Mit sehr hoher Wahrscheinlichkeit ist alles ok. Datenbankfehler treten fast nur noch bei Storage-Fehlern auf, aber sehr sehr selten bei Stromausfällen.

[PowerShellAdmin 169]

Hallo Robert,

vielen Dank für deine Rückmeldung.

Also viele Logdateien sind nicht vorhanden, da ich den Exchange täglich sichere und dadurch die Logs abgeschnitten werden - ich gehe davon aus dass es hier keine Probleme gab.

 

Bzgl. "Dirty Shutdown" betrifft das aber nur die EDB aus dem Backup und nicht die Liveedb -> Diese sollte beim Offline nehmen keinen DirtyShtudown als Status haben oder ?

 

Bzgl. Reparatur, ja die Reparatur wird mit dem P Flag ausgeführt, aber da werden die Daten ja teils auch "abgeschnitten".

Ein Recovery mit R sollte doch ebenfalls zu geheilten Datenbank führen, ohne so große Verluste - Oder sehe ich das falsch ?

 

Nun zu den Details selbst:

Also im Log sind genau nach dem Neustart folgende Fehler:

Fehler ID:3154, Quelle MS ExchangeRepl

Active Manager konnte die Datenbank 'Mailbox DB ***' nicht auf dem Server 'PSRV15.ffm.***.biz' einbinden. Fehler: Vorübergehender Fehler bei Active Manager-Vorgang. Wiederholen Sie den Vorgang. Fehler Vorübergehender Fehler bei Datenbankvorgang. Fehler: Vorübergehender Fehler bei einem Datenbankvorgang. Fehler: MapiExceptionNetworkError: Unable to make admin interface connection to server. (hr=0x80040115, ec=-2147221227)
Diagnostic context:
   ......
   Lid: 12696   dwParam: 0x6D9      Msg: EEInfo: Generation Time: 2012-10-30 16:09:14:484
   Lid: 10648   dwParam: 0x6D9      Msg: EEInfo: Generating component: 2
   Lid: 14744   dwParam: 0x6D9      Msg: EEInfo: Status: 1753
   Lid: 9624    dwParam: 0x6D9      Msg: EEInfo: Detection location: 501
   Lid: 13720   dwParam: 0x6D9      Msg: EEInfo: Flags: 0
   Lid: 11672   dwParam: 0x6D9      Msg: EEInfo: NumberOfParameters: 4
   Lid: 8856    dwParam: 0x6D9      Msg: EEInfo: prm[0]: Unicode string: ncalrpc
   Lid: 8856    dwParam: 0x6D9      Msg: EEInfo: prm[1]: Unicode string: 
   Lid: 12952   dwParam: 0x6D9      Msg: EEInfo: prm[2]: Long val: -1988875570
   Lid: 12952   dwParam: 0x6D9      Msg: EEInfo: prm[3]: Long val: 382312662
   Lid: 24060   StoreEc: 0x80040115
   Lid: 23746  
   Lid: 31938   StoreEc: 0x80040115
   Lid: 19650  
   Lid: 27842   StoreEc: 0x80040115
   Lid: 20866  
   Lid: 29058   StoreEc: 0x80040115

 

Wenigspäter stehen Informationen ESE und folgen weitere Hinweise zu Wiederherstellungen (aber keine Warnungen)

Information Store (3532) Mailbox DB ***: Die Datenbank initiiert Schritte zur Wiederherstellung. 

Weitere Informationen erhalten Sie unter http://www.microsoft.com/contentredirect.asp.

 

Anschließend kommen viele Warnungen - ähnlich wie diese (Quelle MSEXchangeIS Mailbox Store IID 1114)

Die Tabelle war als 'In Gebrauch' markiert, während die Datenbanksitzung für Datenbank 'Mailbox DB ***' freigegeben wurde. Das Problem wird automatisch behoben.
Der Typ der Tabelle war 'tbtBody'; der Name 'Body-1-1A' und die Transaktionsstufe '0'.

 

Heute Morgen kamen nochmal einige 1114er Meldungen - Sieht für mich erstmal unkritisch aus oder ?

 

Edit: Habe die Sicherung nun nochmal ausgeführt und kann nun die vhd Files mounten - scheint wieder alles zu gehen.

Möchte die DB dann eigentlich ungern offline nehmen- Was ja auch in etwa deiner Aussage entspricht - Ausgenommen die Meldungen sind wirklich als kritisch zu werten.

[RobertWi 81]

Also viele Logdateien sind nicht vorhanden, da ich den Exchange täglich sichere und dadurch die Logs abgeschnitten werden - ich gehe davon aus dass es hier keine Probleme gab.

 

Ich auch.

 

Bzgl. "Dirty Shutdown" betrifft das aber nur die EDB aus dem Backup und nicht die Liveedb -> Diese sollte beim Offline nehmen keinen DirtyShtudown als Status haben oder ?

 

Korrekt. Die Sicherung ist Dirty Shutdown, die EBD nach dem Aufheben der Bereitstellung sollte "Clean Shutdown" sein (Einschränkung wie oben, sehr viele Log-Dateien).

 

Wenn Du eine Datenbank im Dirty Shutdown sehen willst, musst Du die store.exe im Taskmanager abschießen (don't do this at home.... :)).

 

Bzgl. Reparatur, ja die Reparatur wird mit dem P Flag ausgeführt, aber da werden die Daten ja teils auch "abgeschnitten".

 

Ja, darum sollte das auch nur im Notfall angewendet werden:

- DB ist Clean Shutdown, hat aber Fehler

- DB ist Dirty Shutdown und die Log-Dateien fehlen

 

Bei einer Reparatur werden keine Log-Dateien eingearbeitet und daher gibt es damit eventuell einen Datenverlust.

 

Ein Recovery mit R sollte doch ebenfalls zu geheilten Datenbank führen, ohne so große Verluste - Oder sehe ich das falsch ?

 

/r arbeitet die offenen Log-Dateien ein. Das geht aber nur, wenn die auch noch da sind und intakt sind. Sollten sie verloren gegangen sein, bleibt nur /p für eine Reparatur. Aber dann hat man den Datenverlust sowieso.

 

Fehler ID:3154, Quelle MS ExchangeRepl

Active Manager konnte die Datenbank 'Mailbox DB ***' nicht auf dem Server 'PSRV15.ffm.***.biz' einbinden. Fehler: Vorübergehender Fehler bei Active Manager-Vorgang. Wiederholen Sie den Vorgang. Fehler Vorübergehender Fehler bei Datenbankvorgang. Fehler: Vorübergehender Fehler bei einem Datenbankvorgang. Fehler: MapiExceptionNetworkError: Unable to make admin interface connection to server. (hr=0x80040115, ec=-2147221227)[/quote]

Hier lief vermutlich ein abhängiger Dienst noch nicht, oder AD antwortete nicht schnell genug (z.B. weil der DC nach dem Stromausfall länger für den Boot brauchtete. Ignorieren, wenn der Fehler nicht wiederkommt und EMC/EMS benutzen lassen.

[quote name='PowerShellAdmin']
Wenigspäter stehen Informationen ESE und  folgen weitere Hinweise zu Wiederherstellungen (aber keine Warnungen)
[code]Information Store (3532) Mailbox DB ***: Die Datenbank initiiert Schritte zur Wiederherstellung. [/quote]

Das sind die, von denen ich sprach.

Anschließend kommen viele Warnungen - ähnlich wie diese (Quelle MSEXchangeIS Mailbox Store IID 1114)
[code]Die Tabelle war als 'In Gebrauch' markiert, während die Datenbanksitzung für Datenbank 'Mailbox DB ***' freigegeben wurde. Das Problem wird automatisch behoben.
Der Typ der Tabelle war 'tbtBody'; der Name 'Body-1-1A' und die Transaktionsstufe '0'.

 

"Fehler" erkannt (muss nichts kritisch sein) und automatisch behoben worden, vermutlich durch einarbeiten der Log-Files.

 

Das ist jetzt schwierig zu sagen. Eventuell hilft es, wenn Du das Backup an einem anderen Ziel-Ort neu einrichtest.

[PowerShellAdmin 169]

Hi Robert,

danke für dein umfassendes Feedback - Jetzt bin ich (mal) wieder schlauer.

 

Da wir hier eine recht kleine Umgebung haben, wäre es unverhältnismäßig das System zu rekonstruieren. Die betroffene Datenbank ist "kleine" 26GB groß.

 

Ich bin daher am abwegen - ob ich "Laufen lasse" oder die Datenbank "Offline" nehme und den Check durchführe (Womöglich am Wochenende)

Wie lange wäre da etwa die Zeitspanne ?

 

viele Grüße Admin

[RobertWi 81]

Die zeit für den Check hängt natürlich von der Performance des Plattensystems ab.

 

Ich würde 1 bis 2 Stunden erwarten.

 

Wenn Du wirklich mal nebenbei ein Check machen willst, steuere diskshadow manuell. Du legst Dir damit eine Schattenkopie an, die kannst Du wegkopieren und an anderer Stelle dann mit eseutil bearbeiten (dann musst die Du absoluten Pfade mit den passenden Schaltern mit angeben!).

 

Beispiel siehe hier: 245. Exchange 2007 Backup auf Windows Server 2008 mit Bordmitteln (reloaded) « Wolfgang on the Road

[PowerShellAdmin 169]

Also ich habe mir eben mal die DB lokal kopiert und ESEUTIL ausgeführt.

Hier kamen natürlich direkt Fehlermeldungen.

ESEUTIL /p ging allerdings - dauerte 45Minuten.

 

Direkt /r oder /g gaben aber Fehler - meldung bzgl. Datums.

"The Database is not up-to-date.Integrity check may find this database is corrupt because data from the log files has yet to be placed in the database."

 

Edit:

Auf einen Win8 Rechner habe ich die DB kopiert, sowie die ESEUTIL Dateien.

Anschließend habe ich im Ordner der Datenbank ESETUIL ausgeführt:

eseutil /r e00 /d

eseutil /mh "\\..."

Der Status ist "Cleanshutdown" damit gehe scheint alles ok.

Zuvor hatte ich eseutil /r e00 /i /l "D:\Mailbox Database 1769938273" /s "D:\Mailbox Database 1769938273" /d "D:\Mailbox Database 1769938273" ausgeführt-> War zwar angeblich erfolgreich, hat aber nicht funktioniert.

bearbeitet 31. Oktober 2012 von PowerShellAdmin