Jump to content

X2010 whitespace-DB defragmentieren


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo Exchange Freunde

 

Was macht ihr gegen Euren “Whitespace”

Was ist bei einer DAG/ CAS zu beachten?!?

Hab da ja immer eine aktive/passive DB (PAM/SAM)

kann man das iwie automatisieren, oder muss alles händisch mit cmdlets ausgeführt werden

[qoute]

DB offline- dismount,
Eseutil, defrag
DB online
[/qoute]


Bei einer Menge von 30 DB, das alles händisch umzusetzen ist inakzeptabel.

Ideen, Tipps, Tricks

Gruss

 

 

Link zu diesem Kommentar

So lange die Datensicherung nicht platzt ignoriere ich Whitespace einfach. Durch den freien Platz wächst die Datenbank erst einmal nicht weiter.

Defragmentieren hat den Nachteil, daß du die Datenbank offline nehmen musst und damit Ausfallzeiten hast.

Daher geht die "neue" Methode in die Richtung eine neue Datenbank zu erstellem, die User dahin zu verschieben und dann die alte Datenbank zu löschen.

Link zu diesem Kommentar

Moin,

 

warum willst Du was gegen den White Space machen? Exchange überschreibt den von alleine.

 

Offiziell empfiehlt Microsoft keine Offline Defragmentierung mehr, weil es einfacher und ohne Unterbrechung funktioniert, eine neue DB anzulegen und die Benutzer zu verschieben.

 

Bei einer DAG geht eine Offline-Defrag sowieso nicht, weil die Datenbanken synchron sein müssen. Wollte man das wirklich machen, würde man so vorgehen:

 - Kopie entfernen

 - Verbleibende DB offline nehmen und mit ESEUTIL behandeln (/r + /d)

 - Log-Dateien und CHK-Datei löschen

 - Datenbank wieder bereistellen

 - Neue Kopie einrichten

Link zu diesem Kommentar

Ich ergänze mal die Liste. ;)

Wollte man das wirklich machen, würde man so vorgehen:

 - Kopie entfernen

 - Verbleibende DB offline nehmen und mit ESEUTIL behandeln (/r + /d)

- Anrufe genervter ANwender annehmen die selbst zu unmöglichsten Zeiten erwarten, dass ihre Mails auf dem Ipad eintrudeln.

 - Log-Dateien und CHK-Datei löschen

 - Datenbank wieder bereistellen

 - Neue Kopie einrichten

- Vergessen zu schauen, ob das Reseeding korrekt beendet wurde, weils schon so spät ist und ja alles läuft und beim nächsten Shutdown erschrocken feststellen, dass das irgendwie doch nicht so verfügbar war, wie man dachte.

 

;)

 

Bye

Norbert

Link zu diesem Kommentar


>Get-MailboxDatabase -Status |ft name,databasesize,availablenewmailboxspace -auto

Name          DatabaseSize                     AvailableNewMailboxSpace
----          ------------                     ------------------------
TB000815-DB02 4.383 GB (4,706,074,624 bytes)   577.7 MB (605,716,480 bytes)
TB000815-DB01 43.01 GB (46,179,352,576 bytes)  2.551 GB (2,739,404,800 bytes)
TB000815-DB03 143.3 GB (153,823,543,296 bytes) 20.88 MB (21,889,024 bytes)
TB000815-DB04 117.4 GB (126,039,949,312 bytes) 77.53 MB (81,297,408 bytes)
TB000815-DB11 116 GB (124,563,554,304 bytes)   1.487 GB (1,596,293,120 bytes)
TB000815-DB12 95.38 GB (102,417,104,896 bytes) 69.13 MB (72,482,816 bytes)
TB000815-DB13 142.5 GB (153,017,712,640 bytes) 563.9 MB (591,298,560 bytes)
TB000815-DB14 89.76 GB (96,377,307,136 bytes)  470.1 MB (492,961,792 bytes)
TB000815-DB15 167.3 GB (179,594,919,936 bytes) 51.05 GB (54,818,963,456 bytes)
TB000815-DB21 92.51 GB (99,330,621,440 bytes)  1.641 GB (1,761,509,376 bytes)
TB000815-DB22 70.51 GB (75,708,301,312 bytes)  2.814 GB (3,021,045,760 bytes)
TB000815-DB23 8.383 GB (9,001,041,920 bytes)   2.644 GB (2,839,183,360 bytes)
TB000815-DB24 25.38 GB (27,254,652,928 bytes)  407.6 MB (427,425,792 bytes)
TB000815-DB25 88.26 GB (94,767,218,688 bytes)  293.8 MB (308,117,504 bytes)
TB000815-DB05 65.38 GB (70,206,423,040 bytes)  16.74 GB (17,974,558,720 bytes)
TB000815-DB06 102.3 GB (109,799,604,224 bytes) 4.1 GB (4,401,856,512 bytes)
TB000815-DB07 120.6 GB (129,529,610,240 bytes) 139.5 MB (146,276,352 bytes)
TB000815-DB08 122.3 GB (131,274,440,704 bytes) 105.8 MB (110,952,448 bytes)
TB000815-DB09 105.3 GB (113,020,305,408 bytes) 11.49 GB (12,339,347,456 bytes)
TB000815-DB10 102.3 GB (109,799,604,224 bytes) 69.41 MB (72,777,728 bytes)
TB000815-DB17 112.5 GB (120,805,982,208 bytes) 2.203 GB (2,365,259,776 bytes)
TB000815-DB19 156.5 GB (168,050,622,464 bytes) 9.235 GB (9,915,924,480 bytes)
TB000815-DB26 13.51 GB (14,503,968,768 bytes)  65.66 MB (68,845,568 bytes)
TB000815-DB27 41.38 GB (44,434,522,112 bytes)  122 MB (127,926,272 bytes)
TB000815-DB28 42.76 GB (45,910,917,120 bytes)  1.591 GB (1,708,523,520 bytes)
TB000815-DB29 16.13 GB (17,322,541,056 bytes)  281.4 MB (295,108,608 bytes)
TB000815-DB30 49.26 GB (52,890,763,264 bytes)  3.473 GB (3,728,834,560 bytes)
TB000815-DB20 86.51 GB (92,888,170,496 bytes)  88.44 MB (92,733,440 bytes)
TB000815-DB16 87.51 GB (93,961,912,320 bytes)  102.7 MB (107,642,880 bytes)
TB000815-DB18 20.51 GB (22,020,161,536 bytes)  270.6 MB (283,738,112 bytes)

weil, wie ich finde, wir, mit unter ein bisschen zuviel White/Recylable Space haben

Link zu diesem Kommentar

Die mit "MB" sind Peanuts. Die mit "GB" sind vermutlich entstanden, weil viele Postfächer verschoben oder gelöscht wurde.

 

Aber was stört Dich wirklich daran? Sind die Platten voll? Schafft das Backup die Daten nicht mehr? Anleitungen findest Du oben, offizielle (Neue DB und Mailbox Move) und inoffizielles (DAG auflösen).

 

Ganz ehrlich: In meinem Umgebungen schaue ich mir die Zahl nicht mal an. Da ist nur die Gesamtgröße der DB wichtig, was da drin liegt, interessiert mich als Admin erstmal nicht,

 

Wenn ich auf Deine Tabelle schaue, würde mich vorallem die Fragmentierung stören. Eine DB hat 4,3 GB, eine andere 156 GB. Aber das kann natürlich gute Gründe haben.

Link zu diesem Kommentar

ja die Platten auf einem Mountpoint wird langsam knapp.
das mit der Verteilung finde ich auch suboptimal, ist so auch nicht gewollt.
Habe nachwievor das Problem, dass alle DB "IsExcludedFromProvisioning $true" bis auf die DB09

wg der MB verteilung sollte man das von "hand" gerade ziehen, anschliessend das exclude aufheben und nur auf die DB setzen, welche "viele" Mailboxen haben

oder was würdet ihr uns raten?

bearbeitet von karlldall
Link zu diesem Kommentar

Zur Verteilung der MB lautet die Antwort: Das kommt darauf an. ;)

 

Es gibt zu viele Faktoren, die das beeinflussen können.

 

Ich persönlich bevorzuge eine gleichmäßige Auslastung, aber nicht nach der Anzahl der Mailboxen, sondern nach der Summe der Größe.

 

Es kann aber auch die Recovery-Strategie wichtig sein, Admin-Delegierung, örtliche Gründe, Festplatten, usw. usf.

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...