117471
Sep 11, 2017
1327
5
0
SBS2011 - Datenbankentlastung durch Verschieben der Postfächer in eine neue Datenbank
Hallo,
ich betreue einen "historisch gewachsenen" SBS2011, auf dem die Exchange-Datenbank auf nunmehr 65GB angelaufen ist.
Aktuell bin ich dabei, mehrere GB in PST-Dateien zu exportieren.
Ich gehe mal davon aus, dass ich danach entsprechend viel "White Space" in der Datenbank habe und spiele mit dem Gedanken, diesen einzudampfen.
Ist das klug, oder sollte man hier eher auf "magische Selbstheilungskräfte" vertrauen?
Ich würde die Datenbank ungerne längere Zeit offline schalten. Ich habe mir deshalb überlegt, eine neue Datenbank zu gründen und alle Postfächer per Verschiebungsanforderung in die neue Datenbank zu schubsen.
Kann ich damit die gewünschte Defragmentierung erreichen?
Muss ich das Offline-Adressbuch gesondert betrachten?
Kann ich das Ziel, den Speicherverbrauch der Datenbank zu reduzieren, auf diesen Weg erreichen?
Gruß,
Jörg
ich betreue einen "historisch gewachsenen" SBS2011, auf dem die Exchange-Datenbank auf nunmehr 65GB angelaufen ist.
Aktuell bin ich dabei, mehrere GB in PST-Dateien zu exportieren.
Ich gehe mal davon aus, dass ich danach entsprechend viel "White Space" in der Datenbank habe und spiele mit dem Gedanken, diesen einzudampfen.
Ist das klug, oder sollte man hier eher auf "magische Selbstheilungskräfte" vertrauen?
Ich würde die Datenbank ungerne längere Zeit offline schalten. Ich habe mir deshalb überlegt, eine neue Datenbank zu gründen und alle Postfächer per Verschiebungsanforderung in die neue Datenbank zu schubsen.
Kann ich damit die gewünschte Defragmentierung erreichen?
Muss ich das Offline-Adressbuch gesondert betrachten?
Kann ich das Ziel, den Speicherverbrauch der Datenbank zu reduzieren, auf diesen Weg erreichen?
Gruß,
Jörg
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: 348746
Url: https://administrator.de/contentid/348746
Printed on: April 19, 2024 at 01:04 o'clock
5 Comments
Latest comment
Zitat von @117471:
Ich gehe mal davon aus, dass ich danach entsprechend viel "White Space" in der Datenbank habe und spiele mit dem Gedanken, diesen einzudampfen.
Ist das klug, oder sollte man hier eher auf "magische Selbstheilungskräfte" vertrauen?
Ich gehe mal davon aus, dass ich danach entsprechend viel "White Space" in der Datenbank habe und spiele mit dem Gedanken, diesen einzudampfen.
Ist das klug, oder sollte man hier eher auf "magische Selbstheilungskräfte" vertrauen?
Er sollte das automatisch tun.
Ich würde die Datenbank ungerne längere Zeit offline schalten. Ich habe mir deshalb überlegt, eine neue Datenbank zu gründen und alle Postfächer per Verschiebungsanforderung in die neue Datenbank zu schubsen.
Was spricht dagegen? Nur weil Du den Informationsspeicherdienst offline schaltest, ist Dein Server immernoch empfangsbereit. Der SMTP-Dienst kann einige Zeit cachen und spült dann Emails in die DB.
Kann ich damit die gewünschte Defragmentierung erreichen?
Die Offline-Defragmentierung macht nichts anderes, als das, was Du oben beschrieben hast. Sie fertigt eine neue DB, spült alles relevante da rein und schmeißt die alte dann weg.
Muss ich das Offline-Adressbuch gesondert betrachten?
Wenn Du es händisch machst, ja.
Machst Du ne Offline-Defrag, nein.
Kann ich das Ziel, den Speicherverbrauch der Datenbank zu reduzieren, auf diesen Weg erreichen?
Du musst erstmal 110% mehr Speicher bereithalten, damit eine saubere Kopie der DB erstellt wird.
Eine Datenbank wächst für gewöhnlich. Wenn Du regelmäßig Sicherungen fährst, lassen Sie die Transaction-Logs recht klein halten.
Dass sie auf Dauer größer wird, kannst Du nicht vermeiden.
Hallo,
danke für deine Unterstützung!
Das ich nicht nachvollziehen kann, wie lange das dauert. Ich möchte die Gesamtausfallzeit so kurz wie möglich halten.
Falls ich die Datenbank offline nehme, würde ich sogar soweit gehen, zusätzlich den POP3-Connector vom SBS zu deaktivieren.
Die Datenbank wurde seinerzeit per SBS-Konsole auf D:\ ausgelagert, dort sind knapp 200 von 280GB frei.
Perspektivisch kommt der Server auf den Schrott. Die Domäne wird gelöscht. Die Migration wird dahingehend ablaufen, dass ich sämtliche Postfächer via PowerShell in PST-Dateien exportiere und dann erst entschieden wird, ob die Inhalte ins DMS oder auf den neuen Exchanger kommen.
D.h., ich arbeite jetzt quasi "vorweg" um bei der endgültigen Leerung des alten Exchange weniger Kopieraufwand zu haben.
Würde sich das zusammendampfen der Datenbank überhaupt positiv auf den Speicherverbrauch auswirken? Min und Max Cachesize habe ich per ADSI-Edit auf 2GB gesetzt, aktuell schluckt der aber immer noch 10 bis 15GB RAM.
Gruß,
Jörg
danke für deine Unterstützung!
Was spricht dagegen?
Das ich nicht nachvollziehen kann, wie lange das dauert. Ich möchte die Gesamtausfallzeit so kurz wie möglich halten.
Der SMTP-Dienst kann einige Zeit cachen und spült dann Emails in die DB.
Falls ich die Datenbank offline nehme, würde ich sogar soweit gehen, zusätzlich den POP3-Connector vom SBS zu deaktivieren.
Du musst erstmal 110% mehr Speicher bereithalten, damit eine saubere Kopie der DB erstellt wird.
Die Datenbank wurde seinerzeit per SBS-Konsole auf D:\ ausgelagert, dort sind knapp 200 von 280GB frei.
Dass sie auf Dauer größer wird, kannst Du nicht vermeiden.
Perspektivisch kommt der Server auf den Schrott. Die Domäne wird gelöscht. Die Migration wird dahingehend ablaufen, dass ich sämtliche Postfächer via PowerShell in PST-Dateien exportiere und dann erst entschieden wird, ob die Inhalte ins DMS oder auf den neuen Exchanger kommen.
D.h., ich arbeite jetzt quasi "vorweg" um bei der endgültigen Leerung des alten Exchange weniger Kopieraufwand zu haben.
Würde sich das zusammendampfen der Datenbank überhaupt positiv auf den Speicherverbrauch auswirken? Min und Max Cachesize habe ich per ADSI-Edit auf 2GB gesetzt, aktuell schluckt der aber immer noch 10 bis 15GB RAM.
Gruß,
Jörg
Moin,
. Wenn Dich da was stört ... mal über ein Archiv nachdenken.
LG, Thomas
auf dem die Exchange-Datenbank auf nunmehr 65GB angelaufen ist
da ist noch etwas Luft bis zu den maximal möglichen 2 TB . Wenn Dich da was stört ... mal über ein Archiv nachdenken.LG, Thomas
Hallo,
Ich beobachte, dass der store.exe knapp 28GB von den 32GB RAM nimmt. Hinzu kommen dann natürlich noch die ganzen Datenbanken (SBSMonitoring, WSUS, Sharepoint usw. usf.).
Sprich: Das Ding steht.
Ich habe die Cachesize reduziert. Auf meinem Testsystem zeigt das Erfolg, auf dem Server des Kunden nicht. Wobei ich sagen muss, dass dort Einzelpostfächer mit > 10GB an Daten liegen - was ich vorsichtig gesagt etwas "unüblich" finde.
Gruß,
Jörg
da ist noch etwas Luft bis zu den maximal möglichen 2 TB . Wenn Dich da was stört ... mal über ein Archiv nachdenken.
. Wenn Dich da was stört ... mal über ein Archiv nachdenken.Ich beobachte, dass der store.exe knapp 28GB von den 32GB RAM nimmt. Hinzu kommen dann natürlich noch die ganzen Datenbanken (SBSMonitoring, WSUS, Sharepoint usw. usf.).
Sprich: Das Ding steht.
Ich habe die Cachesize reduziert. Auf meinem Testsystem zeigt das Erfolg, auf dem Server des Kunden nicht. Wobei ich sagen muss, dass dort Einzelpostfächer mit > 10GB an Daten liegen - was ich vorsichtig gesagt etwas "unüblich" finde.
Gruß,
Jörg
Zitat von @117471:
Hallo,
danke für deine Unterstützung!
Hallo,
danke für deine Unterstützung!
Ich helfe gerne.
Perspektivisch kommt der Server auf den Schrott. Die Domäne wird gelöscht. Die Migration wird dahingehend ablaufen, dass ich sämtliche Postfächer via PowerShell in PST-Dateien exportiere und dann erst entschieden wird, ob die Inhalte ins DMS oder auf den neuen Exchanger kommen.
Die PST-Migration hat den hübschen Vorteil, dass Du in der neuen Domäne nicht die Reste des alten Exchange drin hast. Insofern yep! Das ist ein Plan.
D.h., ich arbeite jetzt quasi "vorweg" um bei der endgültigen Leerung des alten Exchange weniger Kopieraufwand zu haben.
Die Datenbank wird anfangs auf jeden Fall wieder flotter.
Würde sich das zusammendampfen der Datenbank überhaupt positiv auf den Speicherverbrauch auswirken? Min und Max Cachesize habe ich per ADSI-Edit auf 2GB gesetzt, aktuell schluckt der aber immer noch 10 bis 15GB RAM.
Jein. Dieser Prozess nimmt, was er bekommen kann. Ich fahre meinen Exchange mit knapp 40 Postfächern mit 8 GB RAM. Läuft rund. Ist ein EX2010 auf letztem Updatestand. Der SQL_Server ist auch so ein Schlingel. Frisst was er bekommt und sagt nicht mal danke. Es macht eigentlich nichts, wenn er RAM frisst. Das ist ein normales Verhalten.
Gruß,
Jörg
Gruß,
Andreas
