Blase 15 Geschrieben 13. August 2010 Melden Geschrieben 13. August 2010 Hallo allerseits, wir haben einen 2003er SP2 Exchange Server wessen Datenbank bereits 65 GB hat. Da wir noch alte Postfächer von ehemaligen Kollgen drin hatte, haben wir diese komplett gelöscht und auch alte E-Mails aktiver Mitarbeiter ausgelagert und aus dem Postfach gelöscht. Wenn ich nun in den System Manager schaue und dort stur die einzelnen Postfächer der Größe nach addiere, erhalte ich irgendwas um die 20 GB. Aber die Gesamtgröße der Datenbank auf Dateiebene schrumpft nicht. Ich dachte, spätestens nach der Verarbeitung der Postfächer, welche bei uns immer Sontags um 3 Uhr Nachts läuft, würde die DB Größe entsprechend angepaßt werden. Dem war aber nicht so: Der Postfach-Manager von Microsoft Exchange hat die Verarbeitung der Postfächer abgeschlossen Gestartet um: 2010-08-07 00:03:50 Abgeschlossen um: 2010-08-07 00:03:51 Verarbeitete Postfächer: 0 Verschobenen Nachrichten: 0 Größe der verschobenen Nachrichten: 0,00 KB Gelöschte Nachrichten: 0 Größe der gelöschten Nachrichten: 0,00 KB Liege ich generell falsch in der Annahme, die DB müßte sich (von selbst) verkleinern, nachdem ich Postfächer komplett raus gelöscht habe?! Wie bekomme ich meine DB wieder klein? Und was hat es dann mit dieser "Verarbeitung der Postfächer" auf sich, wenn dort scheinbar gar nichts passiert? Wäre über ein wenig Hilfe hier echt dankbar! MfG Blase ps. falls es interessiert, die "priv1.stm" hat 25 GB und die "priv1.edb" hat 44 GB Zitieren
NorbertFe 2.175 Geschrieben 13. August 2010 Melden Geschrieben 13. August 2010 Die Datenbank eines Exchangeserver wird nie kleiner im laufenden Betrieb. Warum auch? Wenn du sie verkleinern willst, wirst du eine Offline Defragmentierung durchführen müssen. Bye Norbert Zitieren
NilsK 2.982 Geschrieben 13. August 2010 Melden Geschrieben 13. August 2010 Moin, ja, deine Annahmen sind falsch. Bis einschließlich Exchange 2007 gibt es einen "Single Instance Store", d.h. wenn 20 User in derselben Datenbank z.B. dasselbe 20-MB-PPT erhalten, speichert Exchange es nur einmal. Löschst du von diesen 20 nun 10 Postfächer, dann gibt es immer noch 10 Links auf das PPT. Exchange kann es also nicht löschen, und die DB bleibt gleich groß. Abgesehen davon: Selbst wenn die Inhalte aus der Datenbank verschwinden, verkleinert Exchange die Datei nicht. Es ist dann eben "Whitespace" innerhalb der Datei, den Exchange bei Bedarf wieder befüllt. Um die Datei physisch zu verkleinern, wäre eine Offline-Defrag nötig - aber das bedeutet 1. Downtime und 2. durchaus ein gewisses Risiko. Gruß, Nils Zitieren
Blase 15 Geschrieben 13. August 2010 Autor Melden Geschrieben 13. August 2010 Danke euch beiden für den Tip mit der Offline Defragmentierung und danke Dir Nils, dass Du da noch etwas ins Detail gehst. Lese ich also aus Deiner Anmerkung, dass ich besser die Finger davon lassen sollte. Ok, meine Angst war nur, dass die DB die 75GB Grenze "zeitnah" überschreiten würde und hier akut Handlungsbedarf bestünde. Wenn die DB nun bei dieser Größe quasi stehen bleibt (bis sie tatsächlich wieder komplett gefüllt ist), habe ich damit keine Probleme. Wünschenswert wäre natürlich, wenn der Platz wieder frei gegeben wird. Denn die Größe Belegt ja nicht nur HDD Platz für die DB, sondern auch für jede erstellte Sicherung. Das wäre auch der Grund @Norbert, warum eine Verkleinerung wünschenswert wäre ;) Noch ein Tip, was genau die Exchange Verarbeitung der Postfächer genau macht? Also bei mir ja scheinbar gar nichts, aber wofür ist die gut? MfG Blase Zitieren
wilgin 11 Geschrieben 13. August 2010 Melden Geschrieben 13. August 2010 Hallo Blase! Also ich kann das mit der Sicherung nicht nachvollziehen. Wenn wir Postfächer löschen oder Inhalte Archivieren wird die DB nicht kleiner, das Volumen/Zeit der Sicherung jedoch schon. Wir sichern mit Backup Exec 2010. Zur Offline Defragmentierung: Ich führe das zwei bis dreimal im Jahr mit eseutil durch, da wir alte Inhalte in PST Dateien archivieren. Mach das nun schon vier oder fünf Jahre und hatte noch nie Probleme. Ich habe auch den Eindruck das die Rechnerbelastung nach einer Defragmentierung geringer wird. Zumindest wenn ich das CPU Belasungsmonitoring ansehe. Es kann aber auch nur eine subjektive Einschätzung sein. Der Nachteil mit der Downtime ist natürlich vorhanden. Grüße! Zitieren
GuentherH 61 Geschrieben 13. August 2010 Melden Geschrieben 13. August 2010 Hi. Noch ein Tip, was genau die Exchange Verarbeitung der Postfächer genau macht? Eine Online Defragmentierung, nur dass eben wie Nils und Norbert beschrieben haben, dabei die Datenbank nicht physisch kleiner wird. LG Günther Zitieren
BrainStorm 10 Geschrieben 13. August 2010 Melden Geschrieben 13. August 2010 Hallo Blase, seit Exchange 2003 SP2 zählt der "Whitespace" auch nicht mehr zu dem 75GB Limit. Wieviel Whitespace du innerhalb einer Datenbank hast, wird nach der Online Maintanance im Application Eventlog protokolliert. Diesen kannst du von der Gesamtgröße abziehen und siehst somit wieviel Platz du effektiv noch hast. Event Type: Information Event Source: MSExchangeIS Mailbox Store Event Category: General Event ID: 1221 Date: 8/13/2010 Time: 12:27:16 AM User: N/A Computer: EXCHSRV Description: The database "Storage Group\Mailboxdatabase" has 382 megabytes of free space after online defragmentation has terminated. Zitieren
Blase 15 Geschrieben 13. August 2010 Autor Melden Geschrieben 13. August 2010 @wilgin - also ich sichere den Exchange mit NTBackup und die Größe der Sicherungsdatei hat sich nicht wesentlich verändert, obwol die Datenbank selbst ja "inhaltlich" deutlich geschrumpft ist. Ich lese mich in die offline Defragmentierung mal etwas ein - sollte ich vielleicht mal machen. @BrainStorm - laut Protokoll habe ich ca. 25 GB an freien Speicherplatz - das ist also das, was ihr "whitespace" nennt?! Wenn Du sagst, dass dieser whitespace nicht zum 75 GB Limit gezählt wird, habe ich eine Verständnis-/Logikfrage: Damit diese Regelung überhaupt nur Sinn macht, kann die Datenbank also zusätzlichen Speicher nutzen, obwohl ich noch genügen whitespace frei habe? Also anstelle den whitespace zu nutzen, wird zusätzlicher "extra" Speicherplatz genommen. Also kann es passieren, dass die Datenbank (stm/edb) weiter wächst, obwohl ich noch massig freien Platz intern habe? Aber ich muss mir dann keine Sorgen machen an das Limit zu kommen, weil der whitespace nicht angerechnet, bzw. abgezogen wird :confused: Klingt kompliziert :D Wäre doch einfacher den vorhandenen whitespace erneut zu füllen, BEVOR ich anfange, mir neuen "extra" Platz zu nehmen... MfG Blase Zitieren
BrainStorm 10 Geschrieben 13. August 2010 Melden Geschrieben 13. August 2010 Konkret bedeutet dies, dass du die DB wieder mit 25GB befüllen kannst, bevor die physische Dateigröße auf den Disks anwächst. Zitieren
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.