karlldall 0 Geschrieben 24. September 2013 Melden Teilen Geschrieben 24. September 2013 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, defragDB online[/qoute] Bei einer Menge von 30 DB, das alles händisch umzusetzen ist inakzeptabel. Ideen, Tipps, TricksGruss Zitieren Link zu diesem Kommentar
tesso 373 Geschrieben 24. September 2013 Melden Teilen Geschrieben 24. September 2013 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. Zitieren Link zu diesem Kommentar
RobertWi 81 Geschrieben 24. September 2013 Melden Teilen Geschrieben 24. September 2013 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 Zitieren Link zu diesem Kommentar
NorbertFe 2.016 Geschrieben 24. September 2013 Melden Teilen Geschrieben 24. September 2013 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 Zitieren Link zu diesem Kommentar
karlldall 0 Geschrieben 25. September 2013 Autor Melden Teilen Geschrieben 25. September 2013 >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 Zitieren Link zu diesem Kommentar
RobertWi 81 Geschrieben 25. September 2013 Melden Teilen Geschrieben 25. September 2013 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. Zitieren Link zu diesem Kommentar
karlldall 0 Geschrieben 25. September 2013 Autor Melden Teilen Geschrieben 25. September 2013 (bearbeitet) 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 25. September 2013 von karlldall Zitieren Link zu diesem Kommentar
RobertWi 81 Geschrieben 25. September 2013 Melden Teilen Geschrieben 25. September 2013 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. Zitieren Link zu diesem Kommentar
karlldall 0 Geschrieben 25. September 2013 Autor Melden Teilen Geschrieben 25. September 2013 Die Umgebung ist „natürlich“ gewachsen. Was hätte ich für eine Option einen Ausgleich herzustellen? Soll heißendafür zu sorgen, dass die DB Size gleichmäßiger verteilt ist Zitieren Link zu diesem Kommentar
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.