I tidigare versioner av Exchange har vi under ett "servicefönster" varje natt kört en sk. online-defragmentering av databaserna i syfte att optimera hur block i databasen lagras, framförallt med hänsyn till lagrings kapacitet. Databasfilen har inte krympt, men den har rapporterat hur mycket ledigt utrymme som finns i databasen genom ett event id som heter 1221. Detta kan vara en intressant siffra att övervaka eftersom den visar om vår databas växer (om det är lite eller knappt ngt freespace), eller om den är onödigt stor och vi skulle må bra av att minska filen för att ex. snabba upp backup/restore tider. Förr i tiden brukade man råda bot på för stora databaser med mycket freespace genom att köra en offline-defragmentering (eseutil /d), men problemet är att den tar väldigt mycket tid, och eftersom själva defragmenteringen skapar en ny databasfil, med en ny signatur så måste man se till att man både innan och direkt efter tar en backup, då de loggar som genereras efter defragmenteringen inte kommer passa ihop med en äldre version av databasen. Ett bättre sätt att komma undan omständiga defragmenteringar är att skapa en ny databas, flytta över alla mailboxar, och därefter skrota den första.
I Exchange 2010 har man istället för att köra online defragmenteringen under ett par timmar på natten gjort om just den processen till en lågt prioriterad process som går kontinuerligt i bakgrunden. Om du nu vill se hur mycket ledigt utrymme din databas innehåller skriver du istället:
get-mailboxdatabase -status | select name, availablenewmailboxspace
Offlinedefragmentering för att krympa en fil fungera dock precis som förr. Det är bara det att det inte är värt att köra det...
I Exchange 2010 har man istället för att köra online defragmenteringen under ett par timmar på natten gjort om just den processen till en lågt prioriterad process som går kontinuerligt i bakgrunden. Om du nu vill se hur mycket ledigt utrymme din databas innehåller skriver du istället:
get-mailboxdatabase -status | select name, availablenewmailboxspace
Offlinedefragmentering för att krympa en fil fungera dock precis som förr. Det är bara det att det inte är värt att köra det...
Inga kommentarer:
Skicka en kommentar