8
Exchange 2010 - Datenbankgröße unverhältnismäßig
Hallo liebe Mit-Administratoren,
mein Chef und ich sitzen hier und kommen nicht so ganz weiter. Daher hoffen wir, dass hier ein schlauer Kopf ist, der uns erleuchtet.
Folgendes Szenario und Problem.
Wir haben 2 Exchange Datenbanken:
Jetzt haben wir eine Auswertung der Postfachgrößen aller Datenbanken gemacht und im Access ausgerechnet, dass die tatsächliche Größe aller Postfächer, aller Datenbanken nur 226,277 GB beträgt.
Kann uns jemand erklären, wo die ~230 GB (=Summe DatabaseSize - Summe AvailableNewMailboxSpace - tatsächliche Postfachgröße) belegter Speicher sind? Wir wissen es einfach nicht.
Wir haben mal was von einem internen Index gelesen. Aber dazu kommen wir auch nicht so recht weiter.
Eckdaten:
Server 2008 R2
MS Exchange 2010
Falls ihr noch weitere Daten braucht, sagt bitte Bescheid.
Ich hoffe man kann uns helfen.
Vielen Dank und viele Grüße
Schauer
mein Chef und ich sitzen hier und kommen nicht so ganz weiter. Daher hoffen wir, dass hier ein schlauer Kopf ist, der uns erleuchtet.
Folgendes Szenario und Problem.
Wir haben 2 Exchange Datenbanken:
[PS] C:\Windows\system32>Get-Mailboxdatabase -status | ft name,databasesize,availablenewmailboxspace
Name DatabaseSize AvailableNewMailboxSpace
---- ------------ ------------------------
DB1 93 GB (99,852,943,360 bytes) 7.904 GB (8,487,010,304 bytes)
DB2 594.2 GB (637,967,335,424 bytes) 222.6 GB (239,038,398,464 bytes)Jetzt haben wir eine Auswertung der Postfachgrößen aller Datenbanken gemacht und im Access ausgerechnet, dass die tatsächliche Größe aller Postfächer, aller Datenbanken nur 226,277 GB beträgt.
Kann uns jemand erklären, wo die ~230 GB (=Summe DatabaseSize - Summe AvailableNewMailboxSpace - tatsächliche Postfachgröße) belegter Speicher sind? Wir wissen es einfach nicht.
Wir haben mal was von einem internen Index gelesen. Aber dazu kommen wir auch nicht so recht weiter.
Eckdaten:
Server 2008 R2
MS Exchange 2010
Falls ihr noch weitere Daten braucht, sagt bitte Bescheid.
Ich hoffe man kann uns helfen.
Vielen Dank und viele Grüße
Schauer
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 438956
Url: https://administrator.de/contentid/438956
Printed on: April 27, 2024 at 23:04 o'clock
8 Comments
Latest comment
kann uns jemand erklären, wo die ~230 GB (=Summe DatabaseSize - Summe AvailableNewMailboxSpace - tatsächliche Postfachgröße) belegter Speicher sind?
Stichwort Retentionhttps://docs.microsoft.com/de-de/exchange/policy-and-compliance/mrm/rete ...
https://docs.microsoft.com/de-de/exchange/recipients/user-mailboxes/dele ...
https://docs.microsoft.com/en-us/exchange/recipients/disconnected-mailbo ...
Ein anschließender Offline-Defrag der DB mit eseutil -d gibt dir dann den Rest.
Hallo Timeout.
mit diesem Befehl hatte ich 1h vorher alle gelöschten Elemente endgültig gelöscht:
Getrennte Postfächer gibt es aktuell keine.
Aber ich les erstmal komplett was da noch so alles unter den Links zu finden ist.
Die Defragmentierung ist für Samstag über den von dir genannten Befehl bereits geplant.
mit diesem Befehl hatte ich 1h vorher alle gelöschten Elemente endgültig gelöscht:
Get-Mailbox | Search-Mailbox –SearchDumpsterOnly –DeleteContentGetrennte Postfächer gibt es aktuell keine.
Aber ich les erstmal komplett was da noch so alles unter den Links zu finden ist.
Die Defragmentierung ist für Samstag über den von dir genannten Befehl bereits geplant.
Zitat von @Schauer:
Die Defragmentation ist für Samstag über den von dir genannten Befehl bereits geplant.
Gut, kleiner wird sie nämlich ohne Offline-Defrag und den o. von dir genannten Dingen nicht wirklich, Exchange ist einfach zu faul mit Online-Defrag, das kost Ihm einfach zu viel Ressourcen...Die Defragmentation ist für Samstag über den von dir genannten Befehl bereits geplant.
Hallo,
https://www.google.com/search?q=eseutil+exchange+2010
Gruß,
Peter
Zitat von @Schauer:
Kann uns jemand erklären, wo die ~230 GB (=Summe DatabaseSize - Summe AvailableNewMailboxSpace - tatsächliche Postfachgröße) belegter Speicher sind? Wir wissen es einfach nicht.
Eine Exchange Datenbank hat noch nie von alleine den nicht genutzten Platz wieder freigegeben. Es ist so per Design. Ungenutzen Datenbankplatz könnt ihr per eseutil und im Offline Modus wieder freigeben lassen. Aber bedenkt das braucht Zeit und wenn es nicht nötig ist sollte es auch nicht gemacht werden. Das kann je nach Hardware schon länger als 2 Tage dauern wo euer Exchange dann ofline ist , auch spielt die Datenmenge eine nicht unbedeutende Rolle. Eseutil gehört zum Software umfang eines Exchange und kann bei falscher Anwendung schon mal eine Datenbank schreddern. Also vorher eine Datensicherung...Kann uns jemand erklären, wo die ~230 GB (=Summe DatabaseSize - Summe AvailableNewMailboxSpace - tatsächliche Postfachgröße) belegter Speicher sind? Wir wissen es einfach nicht.
https://www.google.com/search?q=eseutil+exchange+2010
Gruß,
Peter
Hallo Peter,
dass die DB deframtentiert werden muss ist offensichtlich und wird auch diesen Samstag erledigt. Das wird bei dieser DB ungefähr 18 Stunden dauern.
Das Problem ist, dass in der DB Speicher belegt ist, der nicht zuzuordnen ist.
Am Beispiel von DB2:
Die DB2 ist gerade 594 GB groß. Ziehen wir die 222 GB AvailableMailboxSpace ab, kommen wir auf 372 GB (die größe, die sie nach der Defragmentierung haben wird). Die Summe der Postfächer in der DB2 geträgt laut Powershell Auswertung und anschließender Berechnung im Access) ~ 160GB. Ziehen wir diese dann von den 372 GB ab, kommen wir auf 232 GB. Das ist eine beachtliche Datenmenge, die ich nicht zuordnen kann.
Vielleicht habe ich mich eingangs etwas unklar ausgedrückt worum es mir genau ging. Ich hoffe, das habe ich hiermit nachgeholt und du kannst vielleicht dazu noch etwas sagen?
Grüße,
Schauer
dass die DB deframtentiert werden muss ist offensichtlich und wird auch diesen Samstag erledigt. Das wird bei dieser DB ungefähr 18 Stunden dauern.
Das Problem ist, dass in der DB Speicher belegt ist, der nicht zuzuordnen ist.
Am Beispiel von DB2:
Die DB2 ist gerade 594 GB groß. Ziehen wir die 222 GB AvailableMailboxSpace ab, kommen wir auf 372 GB (die größe, die sie nach der Defragmentierung haben wird). Die Summe der Postfächer in der DB2 geträgt laut Powershell Auswertung und anschließender Berechnung im Access) ~ 160GB. Ziehen wir diese dann von den 372 GB ab, kommen wir auf 232 GB. Das ist eine beachtliche Datenmenge, die ich nicht zuordnen kann.
Vielleicht habe ich mich eingangs etwas unklar ausgedrückt worum es mir genau ging. Ich hoffe, das habe ich hiermit nachgeholt und du kannst vielleicht dazu noch etwas sagen?
Grüße,
Schauer
Hallo,
Wer sagt das? Warum wird das gesagt? Gibt es Fehlermeldungen die darauf schliessen lassen?
Gruß,
Peter
Wer sagt das? Warum wird das gesagt? Gibt es Fehlermeldungen die darauf schliessen lassen?
Das wird bei dieser DB ungefähr 18 Stunden dauern.
Sagt wer oder was? Schätzungen?Das Problem ist, dass in der DB Speicher belegt ist, der nicht zuzuordnen ist.
Ja, das ist so per DesignDie DB2 ist gerade 594 GB groß. Ziehen wir die 222 GB AvailableMailboxSpace ab, kommen wir auf 372 GB (die größe, die sie nach der Defragmentierung haben wird). Die Summe der Postfächer in der DB2 geträgt laut Powershell Auswertung und anschließender Berechnung im Access) ~ 160GB. Ziehen wir diese dann von den 372 GB ab, kommen wir auf 232 GB. Das ist eine beachtliche Datenmenge, die ich nicht zuordnen kann.
Der Speicher wurde aber mal von der Datenbank benötigt, und eine Exchange Datenbank wird nicht Automatisch verkleinert. Ist so per Design seitdem es Exchange gibt.Vielleicht habe ich mich eingangs etwas unklar ausgedrückt worum es mir genau ging.
Wenn nur der Platzbedarf dein Sorge ist, und keine zwingernde Grund vorliegt diesen zu verkleinern, lasse es so. Ist so per Design.Gruß,
Peter
Eben, Exchange musste mal viel so viel Speicher allozieren weil es nötig war, zwischenzeitlich wurden Dinge wieder gelöscht. Exchange gibt diesen Speicher nicht wieder frei weil es denkt es könnten wieder Elemente dazu kommen und lässt die Reservierung des Speichers in der DB bestehen und nutzt diesen auch wenn neue Elemente hinzu kommen. Defragmentierung einer Datenbank kostet viel Ressourcen und Exchange hat eben bessere Dinge zu tun als sich ständig mit sich selbst zu beschäftigen . War wie schon gesagt wurde bis heute immer so.
. War wie schon gesagt wurde bis heute immer so.
Ich würde das nicht machen. Diesen Aufwand zu betreiben halte ich nicht für sinnvoll. Ich würde einen so alten Server nach MSX 2016 migrieren.
