Exchange 2013 EDB Datenbankgesundheit aufrecht erhalten/herstellen

[Dirk-HH-83 14]

Hallo, 

 

ich wollte nur mal kurz ansprechen,  wodurch korrupte Exchangedatenbanken entstehen könnten, weil ich diesbzgl. nicht auf dem neusten Stand bin.

 

• 4 Poweruser haben eine 220 GB Exchange 2013 Datenbank. (läuft auf HyperV) (alle haben Vollzugriff auf alle 10 Postfächer und sind immer im Büro und nicht mit Notebooks unterwegs)
• ist es wegen der Exchange Datenbank Gesundheit wichtig, ob für das eigene Postfach und die freigegebenen Postfächer der Cache Modus an oder aus ist?
• Ich befürchte das jeder eine lokale 220 GB OST Datei bekommt.  (je nach Einstellung, ob Outlook 2016 nur die letzten 3 Monate oder ALLES anzeigen soll)
• mit Cachemodus sollte Outlook 2016 etwas schneller sein und bei einer Exchange Offline Situation sieht man zumindest die alten Mails soweit ich weiß.
  
   

 

• habe gerade ein langes Wochenende wegen einer nicht entdeckten korrupten Datenbank. Es wurde sogar Outlook upgedated von 2010 auf 2016 wegen der merkwürdigen Langsamkeit im Outlook.
• gestern mit eseutil /p  + einfügen der fehlenden Umlaufprotokollierungs-Logs und diesem Befehl wird nun alles in eine neue Datenbank verschoben:

• Zitat

  foreach($mailbox in Get-MailboxStatistics -Database RDB) { New-MailboxRestoreRequest -SourceDatabase RDB -SourceStoreMailbox $mailbox.DisplayName -TargetMailbox $mailbox.DisplayName -baditemlimit unlimited -AcceptLargeDataLoss }

   

• Die korrupte Datenbank hatte repaircount = 0, allerdings war die Backupsoftware falsch konfiguriert und hatte die alten Umlaufprotokollierungs Logs nicht bereinigt wodurch in der Vergangenheit 2-3x die Datenbank dismounted war wegen voller Festplatte.
• ferner gab es auch mal einen Datenbankwechsel auf Dateiebene (aus dem Backup) wegen mißglückter Zertifikatserneuerung.  (powershell+owa lief nicht)
• das ESET Mail Security die Datenbank korrumpiert hat schätze ich als eher unwahrscheinlich ein.
• Stromausfälle und Bluescreens hatte der Exchange Server nicht nicht.

 

Vermute das die Frage ob Outlook Cachemodus an/aus absolut egal ist.

Sehe ich ich folgendes Fazit richtig?  Die EDB Datenbankgesundheit wird durch die ..

-Größe der EDB (max.200GB)  bzw. der Postfächer (wohl max. 2 GB am besten) , bzw. der Anzahl Emails je Ordner beeinflusst
-die ordnungsgemäße Online-Defragmentierung

-genaue Beobachtung des Anwendungslogs (gibt es noch spezielle Logordner die mit der Datenbankgesundheit im Zusammenhang stehen?)

-Bereinigung der Umlaufprotokollierungs Logs müsste egal sein? Es ist nur Platzverschwendung und 200000 Dateien stören das System...die Datebank braucht nur die aktuellen Logs von heute?

-jegliche 3rd Party Anwendungen auf dem Exchange Server

-Emailarchivierung beeinflusst...

....

 

danke, gruß dirk

 

 

 

 

bearbeitet 18. März 2018 von Dirk-HH-83

[NorbertFe 2.035]

Eine ost Datei kann afaik maximal 50gb groß werden.

[magheinz 110]

vor 5 Stunden schrieb Dirk-HH-83:

 

Sehe ich ich folgendes Fazit richtig?  Die EDB Datenbankgesundheit wird durch die ..

 

-Größe der EDB (max.200GB)  bzw. der Postfächer (wohl max. 2 GB am besten) , bzw. der Anzahl Emails je Ordner beeinflusst
-die ordnungsgemäße Online-Defragmentierung

-genaue Beobachtung des Anwendungslogs (gibt es noch spezielle Logordner die mit der Datenbankgesundheit im Zusammenhang stehen?)

-Bereinigung der Umlaufprotokollierungs Logs müsste egal sein? Es ist nur Platzverschwendung und 200000 Dateien stören das System...die Datebank braucht nur die aktuellen Logs von heute?

-jegliche 3rd Party Anwendungen auf dem Exchange Server

-Emailarchivierung beeinflusst...

Keines der genannten Kriterien darf sich auf die Funktionsfähigkeit der Datenbank auswirken.

Die 200GB-Grenze ist eine Empfehlung von MS afaik aus Performancegründen. 2GB als Postfachgröße sind ein Witz, oder?

Wenn die Defragmentierung die Datenbank killt ist das Tool kaputt.

Die Protokolle werden ja für die Datenbank selber nicht benötigt, die dürfen sich also auch nicht auswirken.

3rd Party tools sollten definierte Schnittstellen nutzen. Ansonsten können die natürlich etwas kaputt machen.

Emailarchivierung sollte auch keine korrupte Datenbank erzeugen.

 

Ich tippe eher auf Dateisystemfehler, Plattenfehler oder ähnliches.

 

[djmaker 95]

GGF. auch eine Inkonsistenz im RAID. Das bekommt man meist nur sehr schwer heraus und ist ziemlich fies. Das Problem sollte im LOG der RAID-MGMT-SW auftauchen bzw. man findet sowas auch mit einem (cold?) - Backup auf Sectorebene.

[Dirk-HH-83 14]

vor 9 Stunden schrieb djmaker:

GGF. auch eine Inkonsistenz im RAID. Das bekommt man meist nur sehr schwer heraus und ist ziemlich fies. Das Problem sollte im LOG der RAID-MGMT-SW auftauchen bzw. man findet sowas auch mit einem (cold?) - Backup auf Sectorebene.

Hallo, 

 

Info:   der Exchange 2013  (ist eine HyperV VM Gen2 mit virutellem SCSI Ctrl) (win2012 r2)

der HyperV Host ist ebenfalls win2012r2

 

Gruß
Dirk

 

[NorbertFe 2.035]

vor 21 Stunden schrieb Dirk-HH-83:

Die korrupte Datenbank hatte repaircount = 0, allerdings war die Backupsoftware falsch konfiguriert und hatte die alten Umlaufprotokollierungs Logs nicht bereinigt wodurch in der Vergangenheit 2-3x die Datenbank dismounted war wegen voller Festplatte.

Eine Datenbank wird ja genau deswegen dismounted, damit eben keine Inkonsistenzen auftreten können. Also das würde ich als Grund mal

 

vor 21 Stunden schrieb Dirk-HH-83:

Sehe ich ich folgendes Fazit richtig?  Die EDB Datenbankgesundheit wird durch die ..

-Größe der EDB (max.200GB)  bzw. der Postfächer (wohl max. 2 GB am besten) , bzw. der Anzahl Emails je Ordner beeinflusst
-die ordnungsgemäße Online-Defragmentierung

-genaue Beobachtung des Anwendungslogs (gibt es noch spezielle Logordner die mit der Datenbankgesundheit im Zusammenhang stehen?)

-Bereinigung der Umlaufprotokollierungs Logs müsste egal sein? Es ist nur Platzverschwendung und 200000 Dateien stören das System...die Datebank braucht nur die aktuellen Logs von heute?

-jegliche 3rd Party Anwendungen auf dem Exchange Server

-Emailarchivierung beeinflusst...

....

Sehe ich ähnlich wie @magheinz. Keins deiner aufgeführten Kriterien sollte wirkliche Probleme verursachen. Größe der DB führt ja nicht zur Inkonsitenz. Und 2GB pro Postfach ist heute eher Kindergeburtstag. Die Online Defragmentierung läuft seit 2013 sowieso 24/7.

Die Umlaufprotokollierung hat Auswirkungen auf Performance und Backupszenarien. Es ist eben KEINE Platzverschwendung. Das wirst du merken, wenn du mal Logfiles benötigst. Aktive Umlaufprotokollierung erzeugt zwangsläufig höhere Last auf dem Storage. Ob das jetzt relevant ist, sei mal dahingestellt. Und ein funktionierendes Backup mit korrektem Abschneiden der Logfiles ist quasi schon eine Garantie für eine nicht korrupte Datenbank.

Am ehesten führt noch filebasierter oder externer Virenscanner zu Datenbankkorruption. Aber auch zu langsames Storage "kann" sowas verursachen.

Mir ist nicht so ganz klar, was dein eigentlicher Grund für das Posting oben ist. Also was genau ist jetzt deine Frage?

Bye
Norbert

[djmaker 95]

vor 10 Stunden schrieb Dirk-HH-83:

Hallo, 

 

Info:   der Exchange 2013  (ist eine HyperV VM Gen2 mit virutellem SCSI Ctrl) (win2012 r2)

der HyperV Host ist ebenfalls win2012r2

 

Gruß
Dirk

 

Unabhängig von den anderen Hinweisen liegt die VM trotzdem auf Storage (intern oder extern). Damit sind prinzipiell auch Inkonsistenzen möglich.

[Dirk-HH-83 14]

falls jemand an dem Exchange Powershell Transscript interessiert ist, bitte um Info.

 

Das war quasi eseutil von a-z.

 

bearbeitet 26. März 2018 von Dirk-HH-83

[magheinz 110]

Jetzt mal im ernst: liest das jemand?

[NorbertFe 2.035]

Was genau? :)

[magheinz 110]

falls du es nicht gesehen hast, du hast was verpasst. Für Internetaudrucker war das ein ganzer Wald.

[NorbertFe 2.035]

:) Wobei mir hier im Thread immer noch nicht klar ist, ob wir über Theoretische Probleme oder konkret auftretende Probleme reden. :)