DBA'er spiller en afgørende rolle i en organisation. Som administratorer af data er de ansvarlige for at styre alle aspekter af databasens ydeevne, herunder høj tilgængelighed, hurtig forespørgselsbehandlingstid og risikobegrænsning og gendannelse af katastrofer. Derudover er DBA'er ansvarlige for forretningsmålet om at vedligeholde organisationens databaser med øje for ROI og omkostningsbesparelser.
Med alle de forskellige hatte, de bærer, skal DBA'er arbejde effektivt, og effektiv tidsstyring er deres bedste ven. Den bedste måde at opnå effektivitet på er først at fokusere på de nøgleaktiviteter, der vil hjælpe med at holde databaserne til at fungere optimalt.
Her er fire databaseovervågningsaktiviteter, der bør toppe enhver DBA's "must-know"-liste.
Hvordan (og hvorfor) justeres standardindstillingerne i SQL Server
Mange DBA'er kører SQL Server som de er, lige ud af boksen. Standardkonfigurationerne er dog ikke altid det bedste valg ud fra et sikkerheds- eller ydeevnesynspunkt. Hver organisations databaser er forskellige og opfylder forskellige forretningsbehov, så det giver kun mening, at ikke alle databaser er konfigureret på samme måde.
Afhængigt af dine specifikke databasebehov og -præferencer er der flere standard-SQL Server-indstillinger, du måske vil ændre:
- Fyldfaktor:Hvis du opbygger et indeks uden at angive fyldfaktorværdien, er standardværdien 0. Det betyder, at siden fyldes helt op, og eventuelle indsættelser, sletninger eller opdateringer kan forårsage for store sideopdelinger og fragmentering.
Der er ingen universelt "korrekt" fyldfaktorværdi, men 80-90 er normalt et sikkert valg. Dette værdiinterval tillader 80-90 procent af siden at fylde, hvilket efterlader 10-20 procent frit.
- Omkostningstærskel for parallelitet:Omkostningstærsklen for parallelitet er den værdi, ved hvilken SQL Server-motoren begynder at køre parallelle planer for dine forespørgsler. Standardværdien er fem sekunder, men denne værdi er ret lav og kan skabe en masse unødvendigt komplekse forespørgsler, som vil påvirke ydeevnen negativt.
Start med en indstilling på 20 sekunder, og juster efter behov baseret på CXPACKET-venter og CPU-brug.
- Databasefil autogrow:Autogrowth er en proces, der opstår, når SQL Server-motoren øger størrelsen af en databasefil, når den er tør for plads. Hvor meget filen vokser, er som standard sat til 1 MB for datafiler og 10 procent for transaktionslogfiler.
Hver database vil vokse med forskellige hastigheder, så estimer, hvor meget du tror, databasen vil vokse, og indstil værdien i overensstemmelse hermed.
- Databasegendannelsesmodel:Standardgendannelsesmodellen er FULD ud af æsken, men det er ikke effektivt for alle databaser.
Skift indstillingen til SIMPLE for databaser, der ikke er missionskritiske, og lad kun indstillingen stå på FULD for højrisikoproduktionsdatabaser. - Maksimal serverhukommelse:Standardværdien er 2 TB, hvilket betyder, at SQL Server allokerer al hukommelse fra operativsystemet. Dette efterlader ikke nogen hukommelse til OS at bruge.
Juster indstillingen for at maksimere mængden af tilgængelig hukommelse til SQL Server-processen, men lad OS'et bruge lidt om nødvendigt. - Maksimal grad af parallelisme (MAXDOP):MAXDOP styrer, hvor mange processorer der bruges til at udføre en forespørgsel i en parallel plan. Standarden er 0, hvilket betyder, at SQL Server kan bestemme, hvor mange processorer den kan bruge. Hvis du lader prisen på tærskelværdien for parallelitet være standardværdien på 5, kan du ende med at bruge alle CPU'er for hver forespørgsel.
Den ideelle MAXDOP-indstilling vil variere baseret på dit specifikke system, men Microsoft tilbyder nogle forslag her. - Sikkerhedskopieringskomprimering:Standardindstillingen for denne funktion er FRA. Sikkerhedskopieringskomprimering fremskynder dog sikkerhedskopiering af databasen og skaber mindre størrelse af backupfiler, så du vil måske slå den TIL.
Et sidste tip til justering af SQL Server-indstillinger fra standardværdierne:Test altid systemet grundigt efter at have ændret eventuelle indstillinger for at sikre, at der ikke er kommet problemer ved et uheld.
Sådan fjerner du flaskehalse i SQL Server
SQL Server-flaskehalse er en almindelig kilde til ydelsesproblemer, herunder SQL Server-hogging af processoren, lange forespørgselsudførelsestider, overdreven I/O og ekstrem aktivitet på diskene.
Der er mange ikke-flaskehalsårsager til, at din database kan opleve disse ydeevneproblemer, men hvis problemet stammer fra SQL Server-flaskehalse, er der tre hovedområder, der sandsynligvis vil blive påvirket:hukommelse, I/O og CPU.
Hukommelsesflaskehalse skyldes utilstrækkelige hukommelsesressourcer eller SQL Server-aktiviteter, der bruger for meget tilgængelig hukommelse. Hold øje med længere udførelsestider for forespørgsler, overdreven I/O, meddelelser, der mangler hukommelse i applikationsloggen, og hyppige systemnedbrud.
I/O-flaskehalse opstår, når der ikke er nok lagerplads til rådighed til at understøtte almindelige databaseoperationer såsom tempDB. Hold øje med lange svartider, langsommere programmer og hyppige timeouts for opgaver.
CPU-flaskehalse er forårsaget af utilstrækkelige hardwareressourcer. Hold øje med din databaseovervågning for logdata, der viser, at SQL Server bruger for meget CPU.
Sådan forhindrer du vækst af tempDB
TempDB er et midlertidigt arbejdsområde i SQL Server-instanser, der bruges til at oprette og holde mellemliggende og midlertidige objekter. TempDB er en af de mest aktive ressourcer i et SQL Server-miljø, så det er vigtigt at overvåge og kontrollere overdreven tempDB-vækst.
TempDB bruges ofte i en instans, fordi den bruges til at gemme brugerobjekter, interne objekter og versionslagre. Overdreven vækst af tempDB kan forårsage ydeevneproblemer, så det er vigtigt at spore store forespørgsler, midlertidige tabeller og tabelvariabler, der bruger en stor mængde tempDB diskplads.
For at optimere tempDB størrelse og vækst anbefaler Microsoft følgende bedste praksis:
- Indstil gendannelsesmodellen for tempDB til SIMPLE
- Tillad tempDB-filer at vokse automatisk efter behov
- Indstil filvækststigningen til en rimelig størrelse for at undgå, at tempDB-databasefilerne vokser med en for lille værdi
- Tildel plads på forhånd til alle tempDB-filer ved at indstille filstørrelsen til en værdi, der er stor nok til at rumme den typiske arbejdsbyrde i miljøet
- Gør hver datafil til samme størrelse
Du kan justere størrelsen og vækstparametrene for tempDB-datafilerne ved hjælp af SQL Server Management Studio.
Sådan beregnes de samlede ejeromkostninger
Selvom du måske ikke bruger et væld af tid på at tænke på din virksomheds budget, skal du tro, at CFO'en gør det. Når det er tid til at bede om ny teknologi til overvågning af ydeevne, er det smart at komme forberedt med hårde data til at sikkerhedskopiere din anmodning.
En af de mest indflydelsesrige data, du kan præsentere, er de potentielle samlede ejeromkostninger (TCO) for den nye teknologi kontra din nuværende løsning. Ud over direkte omkostninger skal du sørge for at overveje indirekte omkostninger såsom infrastruktur og ressourceomkostninger såsom vedligeholdelse.
Reduktion af TCO er et fælles mål for DBA'er, der overvejer at erstatte deres nuværende værktøj til overvågning af databaseydelse, så der er flere faktorer at overveje. Som nævnt ovenfor er det vigtigt at se på ikke kun direkte omkostninger såsom indkøbsprisen, men også indirekte omkostninger såsom lager og ressourceomkostninger såsom uddannelse.
For at bestemme TCO for det nye værktøj skal du tilslutte dine detaljer til en TCO-beregner og se, hvad omkostningsbesparelserne er, hvis nogen.