2010-08-19

Är du en ofrivillig MS SQL Databasadministratör? (del1)

Tyvärr är det nog så att många människor blir mer eller mindre tvingade att bli MS SQL DBA... Vad jag menar? Jo att man får en uppgift av chefen eller liknande och skall sköta en server eller ett system och där ingår en Microsoft SQL databas...

Denna post är den första delen i en serie. Här är samtliga delar i denna serie:
del 1 - Data och Logfils hantering
del 2 - Index, statistics
del 3 - Korrupt data
del 4 - Backupper
del 5- Sammanfattning

Det finns massor med enormt skickliga DBAer ute på företagen, men alla företag har inte tillgång till en dedicerad MS SQL DBA. På många ställen är det så att samma person som sköter IT även har helt andra arbetsuppgifter...
Så vad kan man göra för att få en hyffsad nivå på "sin" miljö?
Det finns så klart MASSOR med bra saker som man kan göra, men som oftast blir det en fråga om vad som är "tillräckligt bra".

Jag tänkte skriva ned några av mina tankar kring detta.
Observera att det inte finns någon inbördes ordning bland dessa tankar utan alla sakerna är sådant som man bör fundera på....



Data och Logfils hantering
Huvudpunkter:
- placering av filer på diskarna
- Hur är Auto-growth konfigurerat
- Auto-shrink skall inte vara påslaget och inga jobb med shrink skall finnas i nån maintenance plan.

Många säger att man skall ha en disk på servern för Operativsystemet, en för Databaserna, en för Transaktionsloggarna och en för Tempdatabasen. Detta är helt klart ett bra förslag och man bör försöka styra mot det, speciellt om man har en lite tyngre SQL-server som får ta mycket last. Dock skall sägas att det går utmärkt att lägga alla dessa saker på samma disk om man vill det. Det fungerar.
En fördel att lägga skilja på dessa olika filer är att man kan slippa en del fragmentering av filerna. Fragmenterade filer kan ge en stor påverkan på prestanda, speciellt om det är stora datamängder som skall scannas igenom och/eller om det är transaktionsloggar som växer i väldigt små steg. Dessutom genom att använda olika fysiska diskar så får man bättre prestanda (ju fler diskar ger normalt bättre prestanda). Tänk dock på hur RAID-kort och bakplan i servern är konfigurerade så att man sprider lasten på bästa möjliga sätt.

Det bästa sättet när det gäller "sizing" av databaser och transaktionsloggar är att se till att filerna är tillräckligt stora från början. Att expandera en fil är en mycket I/O intensiv procedur och helst vill man undvika att detta utförs under normal arbetstid (eller när användare/system jobbar mot SQL-servern). Exempelvis, om du vet att databasen behöver 10GB nu och de närmaste 6 månaderna så kommer den att växa med 10GB till så är det helt klart rekommenderat att sätta databasen som 20GB redan från början.
När det gäller transaktionsloggar så är det klart klurigare. Kimberly Tripp har skrivit en bra artikel om detta ("8 Steps to Better Transaction Log Throughput"). Man måste väga in storleken på den största transaktionen, hur lång tid är det mellan backupper osv.
Att lämna en databas med Auto-grow både på databaser och transaktionsloggar är helt klart en bra ide. Då kan SQL själv se till att utöka filerna om det behövs och man slipper få ett system som stannar. För att minska fragmentering av filer och minimera stora spikar på disk I/O under utökning av filerna så rekommenderar åtminstone jag att man sätter stoleken på både transaktionslogg och databas så att de är tillräckligt stora så att de normalt inte skall behöva växa per automatik... Sedan kan man med jämna mellanrum dubbelkolla att det finns ledigt utrymme och om det behövs utöka manuellt. Skillnaden här är att man väljer när man vill få den extra disk I/O och kan då lägga det en tid när användarna påverkas som minst.

När vi ändå talar om fragmentering... Auto-Shrink skall ALDRIG aktiveras på en databas eller transaktionslogg!!!!!
Jag kan inte nog betona detta. Det finns inga som helst skäl att krympa en databas eller transaktionslogg per automatik. Om de skall krympas så gör man det manuellt och under kontrollerade former. Det enda som händer är att databaserna och transaktionsloggarna blir fragmenterade så det står härliga till och sedan får man skit av användarna för att servern är långsam eftersom att den måste utöka databasen och transaktionsloggen hela tiden (och då stannar normalt alla förfrågningar mot databasen under tiden...)
Jag har fått kommentaren: "Men min databas har ju tomt utrymme helt i onödan. Det vet jag för att med jämna mellanrum så krymper mitt shrink-jobb databasen!"
Jo, visst.. Fast om det händer med jämna mellanrum så betyder det att databasen och/eller transaktionsloggen har växt, och detta i sin tur betyder att de behövde detta extra utrymme och om detta händer med jämna mellanrum så betyder det att filerna behöver vara i den större storleken (beror oftast på att det finns nått veckojobb som körs eller liknande). Så egentligen sparar man inget diskutrymme, det utrymmet behövs ju nästa gång som databasen skall köra samma jobb... Så låt databasen och transaktionsloggen ha den mängd disk de behöver!!
Det är mycket fetstil och understrykningar här, men det beror på att jag ser detta alldeles för ofta....

Ahh, en sak som slog mig nu när jag sparade denna artikel... En orsak till varför man inte vill göra databasfilen så stor innan det behövs är ibland för att "Då blir backuppen så stor". Nä, det stämmer inte. Backuppen innehåller bara den data som ligger i själva databasen. Testa själv om du inte tror mig....
- Gör en manuell backup på en databas.  (högerklicka på databasen i SQL server Manager och välj "Backup..")
- Gå in i utforskaren och kolla hur stor databas-filen är.
- Högerklicka på databasen igen i SQL Server Manager och välj Properties. Under Files ändra så att databasen blir rejält mycket större och klicka på OK.
- Kolla i utforskaren så att filen har växt
- Gör en till backup fast till ett annat filnamn.
... Nå? :)
(fast gör inte detta på en produktionsdatabas... Man kan ju råka göra fel och ha sönder nått och det är onödigt om det är produktion.)

3 kommentarer:

  1. Ooh , letade xenapp / xenserver material för jag hade för mig sett dina "posters" tidigare. Men så stöter jag på serien om den ofrivilliga MS SQL dba'n , lysande precis vad jag behövde. TACK för allt material !!

    SvaraRadera
  2. *rodnar*
    Tack för den mycket trevliga feedbacken.
    Hjälp mig att sprida informationen så blir jag enormt tacksam. :)
    //Björne

    SvaraRadera
  3. Helt suverän serie, man tackar :) mvh Fredrik

    SvaraRadera

Related Posts Plugin for WordPress, Blogger...