2010 SP2 UR2 - Whitespace manuell durch Offline Defrag freigeben?

[oh2204 10]

Hallo,

 

wie im Titel angegeben nutze ich einen Exchange 2010 SP2 mit UR2. Nachdem ich eine Software zur E-Mail Archivierung eingesetzt habe (welche auch funktioniert), habe ich knapp 200GB Whitespace in meiner Public Folder Datenbank und würde den Whitespace gern freigeben und die Datenbank dadurch verkleinern.

 

Ist das gegenwärtig immer noch nur durch eseutil /d xxx.edb lösbar?

 

 

VG!

[GuentherH 61]

Ist das gegenwärtig immer noch nur durch eseutil /d xxx.edb lösbar?

 

Jein. Wird bei Exchange 2010 eigentlich nicht mehr empfohlen.

 

Siehe dazu - Database Maintenance in Exchange 2010 - Exchange Team Blog - Site Home - TechNet Blogs

 

Und dann bei "How can I reclaim the whitespace?"

 

LG Günther

[oh2204 10]

Hi Günther,

 

ok die Empfehlung von Microsoft ist, eine neue DB zu erstellen und die Mailboxen da hin zu verschieben. Mit einer MBDB ist das ja auch kein Problem, aber ich habe hier eine Public Folder DB, wie macht man es in diesem Fall?

 

Danke für die Hilfe!

[RobertWi 81]

Moin,

 

bei einer PFDB gibt es nur eseutil - oder abwarten.

 

Es ist zwar nicht mehr empfohlen, das hat aber praktische Gründe. Supportet ist eseutil /d weiterhin.

[oh2204 10]

Hi Robert,

 

wie lange muss man da abwarten? :-) Die Archivsoftware läuft ja nun schon knapp eine Woche.

Mir geht es ja nur darum, die DB zu verkleinern um das Backup zu verkürzen und zu verkleinern. Die Mailbox DB habe ich da noch nicht eingerechnet, aber ich rechne mit ca. 400GB Einsparung (MBDB und PFDB).

[RobertWi 81]

Wie lange man abwarten muss, hast Du in den Eigenschaften der Datenbank eingestellt (Reiter Grenzwerte), im Standard sind es 14 Tage.

 

Vorher hilft auch kein eseutil /d, denn dann ist es noch gar kein Whitespace. WS wird es erst, wenn die Aufbewahrungszeit abgelaufen ist.

[oh2204 10]

Ja, standardmäßig sind es 14 Tage.

Und nach Ablauf der 14 Tage, verkleinert sich auch die DB entsprechend? Um die Sache zu beschleunigen könnte ich die Aufbewahrungszeit auch auf 7 Tage setzen richtig?

[RobertWi 81]

Nein, die DB verkleinert sich nie von alleine (Programmfehler ausgenommen).

 

Nach der eingestellten Zeit (engli. Retention Period) werden gelöschte Elemente zu Whitespace. Whitespace wird dann entweder überschrieben oder durch eine Offline-Defragmentierung entfernt.

 

Du würdest also erleben, dass Deine Datenbank einfach nicht mehr größer wird (bzw. nicht so viel wächst, wie reingeht), weil der Whitespace überschrieben wird. Aber kleiner wird sie von alleine nicht.

 

Den verfügbaren freien Speicher kannst Du Dir übrigens so anschauen (nur ab 2010):

Get-MailboxDatabase -Status | fl Name,AvailableNewMailboxSpace

Get-PublicFolderDatabase -Status | fl Name,AvailableNewMailboxSpace

 

Und dann kannst Du entscheiden, ob es sich lohnt, die Datenbank bei der Größe für mehrere Stunden außer Betrieb zu nehmen und offline zu defragmentieren.

[oh2204 10]

Mit diesem Befehl habe ich ja herausgefunden, dass der AvailableNewMailboxSpace knapp 200GB beträgt.

Also ich denke eine Offline Defragmentierung macht bei dem Whitespace schon Sinn. Was meinst du?

[GuentherH 61]

Also ich denke eine Offline Defragmentierung macht bei dem Whitespace schon Sinn

 

Wenn durch eine regelmäßig Archivierung die Datenbank nicht mehr anwächst, dann ja. Wenn die Archivierung in der Größenordnung nur eine einmalige Aktion war, und der freie Platz in der Datenbank wieder genützt wird, dann bringt es nicht viel.

Gibt es Problem mit der Festplattenkapazität oder eventuell mit der Zeitdauer des Backup. Dann wäre dies eventuell auch ein Grund die Datenbank physisch zu verkleinern.

 

LG Günther

[RobertWi 81]

Sehe ich wie Günther.

 

Es ist supported und machbar, bedeutet nur einen "Ausfall" für die Anwender (daher die Empfehlung einer neuen DB und des Verschiebens der PF, was im Hintergrund stattfindet).

 

Aber bringen würde es in Deinem Fall sicher was.

[oh2204 10]

Die Archivierung läuft nun täglich, sodass die DBs nicht mehr weiter anwachsen.

Der Ausfall wäre ja kalkulierbar, indem es am Wochenende läuft. Damit würde ich klarkommen.

 

Es gibt mehrere Gründe für die Verkleinerung: Platzprobleme, Backupzeiten und Reduzierung des Backups.

 

 

Danke für eure Hilfe.