Håll din SQL Serverdatabas defragmenterad med Diskeeper
Förord
Alla SQL Server databaser upplever någon gång under tidens gång en ”intern” fragmentering av sina data. Det kan ske då man tar bort records från databassidorna och lämnar kvar det utrymme som recorden tog upp. Med tiden så återanvänds i och för sig utrymmet, men allteftersom det gör det så sker en fysisk fragmentering av datasidorna. Det kan leda till en massa onödig I/O, speciellt i tabellsökningar där datasidorna scannas en efter en.
Innehåll
Håll din SQL Server databas defragmenterad med Diskeeper
av Howard Butler Sr., systemingenjör
och Michael Materie, systemingenjör MSCE, CCNA, A+, I-Net+
I SQL Server finns det ett antal metoder du kan ta till för att defragmentera en intern fragmentering. En av dessa metoder är genom att använda kommandot DBCC REINDEX som bygger upp både Clustrade och icke-Clustrade Index. När Indexet väl är återuppbyggt, så är datasidorna nu logiskt kontinuerliga och disk I/O har förminskats.
Tyvärr så är den ”interna” fragmenteringen bara en del av hela fragmenteringsproblemet. När kommandot DBCC REINDEX körs så händer ingenting med den ”externa” fragmenteringen, vilket är refererat som fragmenteringen av de fysiska filerna på din Servers hårddisk. Det kan skapa lika mycket – om inte mer – onödig I/O aktivitet, som den interna fragmenteringen. Som du kanske förstår, så skadar den onödiga I/O aktiviteten SQL Serverns prestanda.
SQL Serverns databaser byggs upp av en mängd större databas- och loggfiler, som är lokaliserade med samma diskutrymme där de skapades. Om det finns tillräckligt med fortlöpande lediga utrymmen på disken när originalfilerna skapas, så bör det inte ske någon fragmentering. Men om alla tillgängliga lediga utrymmen inte är kontinuerliga, så kommer dessa originaldatabasfiler och loggfiler att bli fragmenterade.
Även om originaldatabasen och loggfilerna inte blev fragmenterade då de skapades, så lär de garanterat bli det allteftersom databasen växer. Låt säga att du t ex sätter databasens storlek till 100 MB och loggfilerna till 10 MB, samt konfigurerar filerna till att växa automatiskt. Om databasen då skulle växa till 5 GB och loggfilerna till 100 MB så kan den externa fragmenteringen bli enorm. Det finns risk för extern fragmentering varje gång som databasen och loggfilerna växer.
För att defragmentera en extern fragmentering så måste man använda verktyg från operativsystemet, och inte från SQL Servern. Ett av de populäraste verktygen till att defragmentera SQL Serverns databasfiler är ett verktyg från
När man kör ett externt fragmenteringsverktyg, såsom Diskeeper, så återstruktureras inte det interna innehållet i filen, så som DBCC REINDEX gör. Efter att Diskeeper har defragmenterat en fil så kommer filen att likna originalet, fast hopsamlat. Så alla hål som finns i databasen kommer fortfarande att finnas där, vilket gör att du då och då måste bygga om dina Index för att även kämpa mot den interna fragmenteringen.
Diskeeper tar hand om två typer av extern fragmentering; filfragmentering och fragmentering av ledigt utrymme. Filfragmenteringen innefattar de filer på hårddisken som inte är hela, utan ligger utspritt över hårddisken. Och med fragmentering av det lediga utrymmet menas att det lediga utrymmet ligger utspritt över hårddisken, istället för att vara ett enda stort ledigt utrymme. Filfragmenteringen skapar problem då man vill accessa data från filerna på hårddisken, och fragmenteringen av det lediga utrymmet skapar problem då man vill skapa en ny fil, eller då man utökar en existerande fil.
Så när man kör Diskeeper, så defragmenteras databaser och loggfiler från att vara utspritt på hårddisken, till att vara en enda kontinuerlig fysisk fil. Dessutom så defragmenterar Diskeeper till extra utrymme efter den fysiska filen, så när databasen eller loggilerna expanderar så gör dem det med lite, eller ingen, fragmentering. Men så kan det inte fortsätta i all evighet. Någon gång kommer fragmenteringen återigen att bli ett problem, och databaserna och loggfilerna behöver defragmenteras igen. Det idealiska skulle vara att defragmentera filerna regelbundet, för att förhindra onödig fragmentering.
Nu kommer något som du förmodligen inte har tänkt på förut. Vilken effekt har en fysisk filfragmenteringen på att du bygger om dina Index? Med andra ord, om du inte skulle utföra en fysisk defragmentering, men istället utför en intern defragmentering, finns det några nackdelar med det?
Ja, det finns det. Det tar mycket längre tid (och mer I/O) för SQL Server att bygga om Index på fragmenterade fysiska filer, än vad det gör på kontinuerliga fysiska filer. Det innebär att innan du påbörjar en intern defragmenteringsprocess, så bör du ha klarat av den fysiska defragmenteringsprocessen först. På så sätt kan du reducera den tid det tar att bygga om dina Index, samtidigt som du reducerar den I/O last som krävs från Servern under ombyggnadsprocessen av Indexen.
Medan den fysiska fragmenteringen av SQL Serverns databaser och loggfiler kan ha en negativ effekt på SQL Serverns prestanda, så får du inte glömma bort att det finns fler filer som SQL Servern kommer åt. Det kan t ex vara SQL Serverns exekveringsbara filer, eller om du använder Full-Text Indexing så kan det vara Indexfiler för Full-Text. Så du får inte bara defragmentera databaser och loggfiler, utan alla filer som ligger på din SQL Server.
Som du vet så låser SQL Server de filer som används. Det gäller även SQL Serverns databas- och loggfiler, samt vissa andra SQL Server filer. På grund av det så måste vissa SQL Server tjänster (mssqlserver och sqlserveragent) stängas av innan du kan defragmentera SQL Serverns fysiska filer. Jag vet vad du tänker då; ”Jag kan inte göra det, min databas måste vara igång 24 timmar om dygnet!”. Om så är fallet att det inte finns något sorts undantag, så går det helt enkelt inte att defragmentera dina fysiska filer på SQL Servern. Men kom då ihåg att om du inte gör det, så kommer din SQL Servers prestanda att avta allteftersom tiden går. Diskeeper kan dock fortfarande köras och defragmentera de filer som den kommer åt, medan den låter bli filer som är låsta av SQL Server Services.
Som tur är så har de flesta SQL Servrarna schemalagda overksamma tider (down time), och det är under dessa som du måste planera in din defragmentering av SQL Serverns filer. Trots att det inte är den bästa lösningen för fragmenterade filer, så är det alternativet det enda fram till den dagen då Microsoft har skrivit om ett operativsystem som även låter dig göra en fysisk defragmentering av filer som används.
Så hur får du reda på om en fysisk fil på din SQL Server är fragmenterad? Det är lätt. Som en del av Diskeeperns funktionalitet, så kan du köra en fragmenteringsanalys för att få reda på just hur fragmenterade dina SQL Server filer egentligen är. Det kan till och med köras medan SQL Server är igång, så du behöver inte stänga ner dina Servrar för att få reda på det.
Du bör planera in en regelbunden kontroll av fragmenteringen på din SQL Servers filer för att se hur hög fragmenteringsnivån är. Skulle du då finna att fragmenteringen är enorm, så bör du därefter schemalägga en inaktiv period på Servern, så att Diskeeper kan gå in och defragmentera filerna. Det är svårt att rekommendera ett specifikt schema för det här, då varje databas är olika och en fragmentering kan inträffa vid olika tillfällen och på olika nivåer.
Så det är ganska lätt att se till att ett defragmenteringsverktyg som Diskeeper tar hand om de externa diskfragmenteringarna, medan ett SQL Server verktyg, såsom DBCC REINDEX, tar hand om de interna diskfragmenteringarna i SQL Server. Tillsammans arbetar de som ett team, för att försäkra dig om att dina SQL Servrars prestanda är optimala.
Om du känner minsta lilla uns av tvivel, så kan du enkelt installera Diskeeper, och sedan låta dess analyseringar visa dig exakt hur många individuella bitar dina filer egentligen är uppdelade i. Jag är säker på att du kommer bli överraskad. Jag har fått rapporter från siter där deras databasfiler varit uppdelade i 287 000 bitar!! OUCH!
0 Kommentarer