DBA spelar en viktig roll inom en organisation. Som väktare av data är de ansvariga för att hantera alla aspekter av databasprestanda, inklusive hög tillgänglighet, snabb frågebehandlingstid och riskreducering och katastrofåterställning. Dessutom är DBA:er ansvariga för affärsmålet att underhålla organisationens databaser med sikte på ROI och kostnadsbesparingar.
Med alla de olika hattarna de bär måste DBA:er arbeta effektivt, och effektiv tidshantering är deras bästa vän. Det bästa sättet att uppnå effektivitet är att först fokusera på de nyckelaktiviteter som kommer att hjälpa databaserna att fungera optimalt.
Här är fyra databasövervakningsaktiviteter som bör toppa alla DBA:s "måste-veta"-lista.
Hur (och varför) justera standardinställningarna i SQL Server
Många DBA:er kör SQL Server som de är, direkt ur lådan. Men standardkonfigurationerna är inte alltid det bästa valet ur säkerhets- eller prestandasynpunkt. Varje organisations databaser är olika och uppfyller olika affärsbehov, så det är bara logiskt att inte alla databaser är konfigurerade på samma sätt.
Beroende på dina specifika databasbehov och preferenser finns det flera standardinställningar för SQL Server som du kanske vill ändra:
- Fyllningsfaktor:Om du bygger ett index utan att ange fyllningsfaktorvärdet är standardvärdet 0. Det betyder att sidan kommer att fyllas till kapaciteten, och eventuella infogningar, borttagningar eller uppdateringar kan orsaka överdrivna siddelningar och fragmentering.
Det finns inget universellt "korrekt" fyllfaktorvärde, men 80-90 är normalt ett säkert val. Detta värdeintervall tillåter 80-90 procent av sidan att fyllas, vilket lämnar 10-20 procent ledigt.
- Kostnadströskel för parallellism:Kostnadströskeln för parallellitet är det värde vid vilket SQL Server-motorn börjar köra parallella planer för dina frågor. Standardvärdet är fem sekunder, men detta värde är ganska lågt och kan skapa många onödigt komplexa frågor, vilket kommer att påverka prestandan negativt.
Börja med en inställning på 20 sekunder och justera efter behov baserat på CXPACKET-väntningar och CPU-användning.
- Databasfil autogrow:Autogrowth är en process som inträffar när SQL Server-motorn ökar storleken på en databasfil när det är ont om utrymme. Hur mycket filen växer är som standard inställt på 1 MB för datafiler och 10 procent för transaktionsloggfiler.
Varje databas kommer att växa i olika takt, så uppskatta hur mycket du tror att databasen kommer att växa och ställ in värdet därefter.
- Databasåterställningsmodell:Standardåterställningsmodellen är FULL ur kartongen, men det är inte effektivt för alla databaser.
Ändra inställningen till SIMPLE för databaser som inte är verksamhetskritiska och lämna inställningen på FULL endast för högriskproduktionsdatabaser. - Max serverminne:Standardvärdet är 2 TB, vilket innebär att SQL Server allokerar allt minne från operativsystemet. Detta lämnar inget minne för operativsystemet att använda.
Justera inställningen för att maximera mängden tillgängligt minne för SQL Server-processen, men lämna lite för operativsystemet att använda om det behövs. - Max grad av parallellism (MAXDOP):MAXDOP styr hur många processorer som används för exekvering av en fråga i en parallell plan. Standard är 0, vilket innebär att SQL Server får bestämma hur många processorer den kan använda. Om du lämnar kostnaden för tröskelvärdet för parallellitet på standardvärdet 5, kan du sluta använda alla CPU:er för varje fråga.
Den idealiska MAXDOP-inställningen kommer att variera beroende på ditt specifika system, men Microsoft ger några förslag här. - Säkerhetskopieringskomprimering:Standardinställningen för den här funktionen är AV. Säkerhetskopieringskomprimering påskyndar dock databassäkerhetskopieringen och skapar mindre storlek på säkerhetskopieringsfilerna, så du kanske vill slå PÅ den.
Ett sista tips för att justera SQL Server-inställningarna från standardvärdena:Testa alltid systemet noggrant efter att ha ändrat några inställningar för att säkerställa att inga problem uppstod av misstag.
Hur man eliminerar SQL Server-flaskhalsar
SQL Server-flaskhalsar är en vanlig källa till prestandaproblem, inklusive SQL Server-problem med processorn, långa frågekörningstider, överdriven I/O och extrem aktivitet på diskarna.
Det finns många skäl som inte är flaskhalsar till att din databas kan uppleva dessa prestandaproblem, men om problemet beror på SQL Server-flaskhalsar finns det tre huvudområden som sannolikt kommer att påverkas:minne, I/O och CPU.
Minnesflaskhalsar beror på otillräckliga minnesresurser eller SQL Server-aktiviteter som använder för mycket tillgängligt minne. Håll utkik efter längre körningstider för frågor, överdriven I/O, meddelanden om att minnet är slut i programloggen och frekventa systemkrascher.
I/O-flaskhalsar uppstår när det inte finns tillräckligt med lagringsutrymme för att stödja vanliga databasoperationer som tempDB. Håll utkik efter långa svarstider, programfördröjningar och frekventa timeouts för uppgifter.
CPU-flaskhalsar orsakas av otillräckliga hårdvaruresurser. Håll utkik i din databasövervakning efter loggdata som visar att SQL Server använder för mycket CPU.
Hur man förhindrar tillväxt av tempDB
TempDB är en tillfällig arbetsyta i SQL Server-instanser som används för att skapa och hålla mellanliggande och temporära objekt. TempDB är en av de mest aktiva resurserna i en SQL Server-miljö, så det är viktigt att övervaka och kontrollera överdriven tempDB-tillväxt.
TempDB används ofta inom en instans eftersom den används för att lagra användarobjekt, interna objekt och versionslagrar. Överdriven tillväxt av tempDB kan orsaka prestandaproblem, så det är viktigt att spåra stora frågor, temporära tabeller och tabellvariabler som använder en stor mängd tempDB-diskutrymme.
För att optimera tempDB storlek och tillväxt rekommenderar Microsoft följande bästa praxis:
- Ställ in återställningsmodellen för tempDB till SIMPLE
- Tillåt tempDB-filer att växa automatiskt efter behov
- Ställ in filtillväxtökningen till en rimlig storlek för att undvika att tempDB-databasfilerna växer med ett för litet värde
- Förtilldela utrymme för alla tempDB-filer genom att ställa in filstorleken till ett värde som är tillräckligt stort för att rymma den typiska arbetsbelastningen i miljön
- Gör varje datafil till samma storlek
Du kan justera storleken och tillväxtparametrarna för tempDB-datafilerna med SQL Server Management Studio.
Hur man beräknar den totala ägandekostnaden
Även om du kanske inte spenderar massor av tid på att tänka på ditt företags budget, bör du tro att CFO gör det. När det är dags att be om ny prestandaövervakningsteknik är det smart att komma förberedd med hårda data för att säkerhetskopiera din begäran.
En av de mest inflytelserika databitarna du kan presentera är den potentiella totala ägandekostnaden (TCO) för den nya tekniken kontra din nuvarande lösning. Utöver direkta kostnader, se till att ta hänsyn till indirekta kostnader som infrastruktur och resurskostnader som underhåll.
Att minska TCO är ett vanligt mål för DBA:er som funderar på att ersätta sina nuvarande databasprestandaövervakningsverktyg, så det finns flera faktorer att ta hänsyn till. Som nämnts ovan är det viktigt att inte bara titta på direkta kostnader som inköpspriset utan även indirekta kostnader som lagring och resurskostnader som utbildning.
För att fastställa TCO för det nya verktyget, koppla in dina detaljer till en TCO-kalkylator och se vad kostnadsbesparingarna är, om några.