schauer
Goto Top

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:

[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

Content-ID: 438956

Url: https://administrator.de/contentid/438956

Ausgedruckt am: 22.11.2024 um 22:11 Uhr

139374
139374 10.04.2019 aktualisiert um 16:27:56 Uhr
Goto Top
kann uns jemand erklären, wo die ~230 GB (=Summe DatabaseSize - Summe AvailableNewMailboxSpace - tatsächliche Postfachgröße) belegter Speicher sind?
Stichwort Retention
https://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.
Schauer
Schauer 10.04.2019 aktualisiert um 16:31:29 Uhr
Goto Top
Hallo Timeout.

mit diesem Befehl hatte ich 1h vorher alle gelöschten Elemente endgültig gelöscht:

Get-Mailbox | Search-Mailbox –SearchDumpsterOnly –DeleteContent

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. face-smile
139374
139374 10.04.2019 aktualisiert um 16:33:26 Uhr
Goto Top
Zitat von @Schauer:
Die Defragmentation ist für Samstag über den von dir genannten Befehl bereits geplant. face-smile
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...
Pjordorf
Pjordorf 10.04.2019 um 16:36:25 Uhr
Goto Top
Hallo,

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...
https://www.google.com/search?q=eseutil+exchange+2010

Gruß,
Peter
Schauer
Schauer 10.04.2019 um 16:42:33 Uhr
Goto Top
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
Pjordorf
Pjordorf 10.04.2019 um 16:49:28 Uhr
Goto Top
Hallo,

Zitat von @Schauer:
dass die DB deframtentiert werden muss ist offensichtlich
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 Design

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.
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
139374
139374 10.04.2019 aktualisiert um 16:59:30 Uhr
Goto Top
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 face-smile. War wie schon gesagt wurde bis heute immer so.
Ganzjahresgriller
Ganzjahresgriller 11.04.2019 um 08:04:51 Uhr
Goto Top
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.