{"id":12,"date":"2009-05-06T11:40:09","date_gmt":"2009-05-06T09:40:09","guid":{"rendered":"http:\/\/langlitz-consulting.de\/blog\/?p=12"},"modified":"2015-04-27T13:18:35","modified_gmt":"2015-04-27T11:18:35","slug":"exchange-datenbanken-grosenverwaltung","status":"publish","type":"post","link":"https:\/\/www.langlitz-it.de\/?p=12","title":{"rendered":"Exchange Datenbanken &#8211; Gr\u00f6\u00dfenverwaltung"},"content":{"rendered":"<p><strong>Datenbankgr\u00f6\u00dfen <\/strong><\/p>\n<p>Ein gro\u00dfes Problem bei Exchange stellt die Datenbankgr\u00f6\u00dfe dar. Microsoft gibt sich da etwas schwammig, was die Empfehlungen betrifft. Meiner Erfahrung nach kann ich sagen, dass Datenbanken bis max. 200 GB noch OK und zu handlen sind.<br \/>\nWenn wir nun eine Corporate DB haben, auf der sich alle Postf\u00e4cher eines Unternehmens befinden und eine \u00d6ffentliche Ordner DB, am besten noch auf einem Server. Beide bis 50 GB gro\u00df, dann brauchen Sie hier nicht weiterzulesen und sollten die Finger von \u201eVerkleinerungsmassnahmen\u201c lassen.<br \/>\nWenn wir aber z.B. von einer Enterprise Umgebung mit vier Mailstore Servern reden, auf denen mehrere DBs liegen\u00a0und diese auch in Bereiche von 200 GB und mehr kommen, kann sich eine Verkleinerung anbieten.<br \/>\nAm empfehlenswertesten ist nat\u00fcrlich, bei einer gro\u00dfen DB alle Postf\u00e4cher auf eine neue DB zu verschieben, die \u201ealte\u201c danach l\u00f6schen und neu anzulegen. Damit ist die DB Datei leer und kann neu gef\u00fcllt werden.<\/p>\n<p><strong>Offline Defrag<\/strong><\/p>\n<p>Es gibt nat\u00fcrlich auch noch die M\u00f6glichkeit der Offline Defragmentierung.<br \/>\nBei Exchange Versionen vor 2003 habe ich auch lieber die Finger davon gelassen, weil das Offline Defrag damals mehr Offline als Defrag war. Es ist h\u00e4ufig vorgekommen, dass DBs nach dieser Maintenance nicht mehr online kamen\u2026<br \/>\nMeine Erfahrungen ab Exchange 2007 sind da eher positiv. Gerade bei Unternehmen, bei denen im Postfachbereich eine relativ hohe Fluktuation herrscht, kann sich diese Vorgehen rechnen.<\/p>\n<p><strong>Wie wird das am besten gemacht?<\/strong><\/p>\n<p>Nehmen wir mal an, ich habe eine DB Datei, die 150 GB gro\u00df ist (von alleine wird sie nie kleiner). Liegt Diese edb Datei auf einer LUN mit 160 GB, sollte der Admin aktiv werden. Die gro\u00dfe Frage ist aber, was kann ich eigentlich durch das Offline Defrag erreichen. Im Anwendungseventlog wird bei der n\u00e4chtlichen Online Defragmentierung ein Eintrag erstellt, der mir den Wert des freien Bereiches einer DB angibt:<\/p>\n<p><a href=\"http:\/\/blog.langlitz-it.de\/wp-content\/uploads\/2009\/05\/unbenannt.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-13\" src=\"http:\/\/blog.langlitz-it.de\/wp-content\/uploads\/2009\/05\/unbenannt.jpg\" alt=\"Screenshot\" width=\"403\" height=\"446\" srcset=\"https:\/\/www.langlitz-it.de\/wp-content\/uploads\/2009\/05\/unbenannt.jpg 403w, https:\/\/www.langlitz-it.de\/wp-content\/uploads\/2009\/05\/unbenannt-271x300.jpg 271w\" sizes=\"(max-width: 403px) 100vw, 403px\" \/><\/a><\/p>\n<p>Bei dieser DB kann durch ein Offline Defrag also ein Platz von ca. 47 GB eingespart werden. Microsoft gibt an, dass die endg\u00fcltige Gr\u00f6\u00dfe der neuen edb Datei sich folgenderma\u00dfen errechnet:<\/p>\n<p>Alte DB \u2013 Wert aus dem 1221 Event * 110 % = neue DB<br \/>\nDas w\u00e4re in unserem Fall 150 GB \u2013 47,020 GB *110 % = 113,278 GB<\/p>\n<p>Allerdings werden Sie feststellen, dass das nur ein ungef\u00e4hrer Wert ist.<\/p>\n<p><strong>Vorgehensweise<\/strong><\/p>\n<p>Sie sollten nat\u00fcrlich f\u00fcr diesen Vorgang (je nach Rechnerleistung, IO, usw.) einige Stunden einplanen. Genau l\u00e4sst sich das leider nie voraussagen. Sie sollten aber f\u00fcr die 113 GB ca. 3-6 Stunden rechnen. Also sind wir bei einer n\u00e4chtlichen Aktion. Des Weiteren ben\u00f6tigen Sie entsprechenden Speicherplatz f\u00fcr die neue DB und am sinnvollsten auch noch f\u00fcr eine offline Kopie der produktiven DB.<br \/>\nAls erstes nehmen sie die DB offline. Es bleibt Ihn frei, dies \u00fcber die Management Konsole oder die Shell zu machen. Ich arbeite lieber \u00fcber die Shell. Da werden auch noch mehr Optionen angeboten und f\u00fcr die Defragmentierung brauche ich die Shell ohnehin.<\/p>\n<p>Dismount-Database \u2013identity \u201eServer\\Storage Group\\Mailstore\u201d<\/p>\n<p>Ist die DB dismounted, erstellen sie sinnvollerweise eine Offline Kopie, bevor Sie der produktiven DB ans Eingemachte gehen.<br \/>\nDanach k\u00f6nnen Sie mit dem Befehl:<\/p>\n<p>Eseutil \/d Databasepath\\database.edb<\/p>\n<p>Damit wird eine Offline Defragmentierung durchgef\u00fchrt und eine neue Defragmentierte DB im aktuellen Verzeichnis angelegt.<br \/>\nNach einiger Geduld und einigen Stunden Verarbeitung erhalten sie die neue DB, die Sie dann wieder mounten k\u00f6nnen.<\/p>\n<p>Mount-Database \u2013identity \u201eServer\\Storage Group\\Mailstore\u201d<\/p>\n<p>Sollte es Ihnen nicht gelingen, die DB zu mounten, haben Sie ja nun immer noch die Offline Sicherungskopie der DB, die sich im Ursprungszustand befindet und auf jeden Fall noch zu mounten sein sollte. Ich kann aber guten Gewissens sagen, dass ich dies bei Exchange 2007 bisher noch nicht erlebt habe.<br \/>\nIch empfehle Ihnen aber dieses Vorgehen zu erst auf einem entsprechenden Testsystem auszuf\u00fchren, bevor Sie das auf einem Produktivsystem machen.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Datenbankgr\u00f6\u00dfen Ein gro\u00dfes Problem bei Exchange stellt die Datenbankgr\u00f6\u00dfe dar. Microsoft gibt sich da etwas schwammig, was die Empfehlungen betrifft. Meiner Erfahrung nach kann ich sagen, dass Datenbanken bis max. 200 GB noch OK und zu handlen sind. Wenn wir &hellip; <a href=\"https:\/\/www.langlitz-it.de\/?p=12\">Continue reading <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[36,37,38,30,12,14],"_links":{"self":[{"href":"https:\/\/www.langlitz-it.de\/index.php?rest_route=\/wp\/v2\/posts\/12"}],"collection":[{"href":"https:\/\/www.langlitz-it.de\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.langlitz-it.de\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.langlitz-it.de\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.langlitz-it.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=12"}],"version-history":[{"count":23,"href":"https:\/\/www.langlitz-it.de\/index.php?rest_route=\/wp\/v2\/posts\/12\/revisions"}],"predecessor-version":[{"id":1088,"href":"https:\/\/www.langlitz-it.de\/index.php?rest_route=\/wp\/v2\/posts\/12\/revisions\/1088"}],"wp:attachment":[{"href":"https:\/\/www.langlitz-it.de\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=12"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.langlitz-it.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=12"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.langlitz-it.de\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=12"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}