Jeg har undervist og skrevet om almindelige SQL Server-fejl i mange år. Jeg skrev også en blog om det for mange år siden, men som tiden er gået, har vejledningen ændret sig lidt. Denne artikel vil udvide min tidligere artikel og påpege, hvordan disse gælder for SQL Server, Azure SQL Database og Azure SQL Managed Instance.
I mange år har jeg oplevet, at brugere begår de samme fejl. Jeg kalder dem fejl, men i de fleste tilfælde er det mere bare ting, der ikke bliver gjort ordentligt, fordi de mennesker, der styrer miljøet, ikke ved bedre. Her er nogle af de mere kritiske elementer, som enhver, der installerer og understøtter SQL Server, bør vide om:
- Sikkerhedskopier
- DBCC CHECKDB
- Hukommelsesindstillinger
- Statistik
- Indeksvedligeholdelse
- MAXDOP og omkostningstærskel for parallelitet
- SQL Server Agent-advarsler
Sikkerhedskopier
Jeg tjekker altid backups først, når jeg ser på et nyt system. Det er afgørende at have ordentlige sikkerhedskopier for at opfylde gendannelsesmålene. Tab af data kan være skadeligt for en organisation. Når jeg ser på sikkerhedskopier, tjekker jeg efter gendannelsesmodel og den aktuelle historik for sikkerhedskopier for hver database. Jeg finder normalt en kombination af følgende:
- Ingen sikkerhedskopiering overhovedet – ingen registrering af sikkerhedskopiering til databasen
- Manglende sikkerhedskopier – ingen log backups for en database, der bruger den fulde gendannelsesmodel
- Ingen nylige sikkerhedskopier – sidste backup var uger/måneder/år gammel
Fejlkonfigurerede sikkerhedskopier er skadelige for en organisation, når en genoprettelsessituation opstår. At arbejde med og skulle fortælle kunderne, at de har mistet data, er aldrig sjovt eller nemt. At have ordentlige sikkerhedskopier for at opfylde SLA'er bør være enhver organisations topprioritet ud over at sikre, at der er kopier af disse sikkerhedskopier gemt på en sekundær placering uden for stedet.
Denne situation gælder for lokale SQL Server og IaaS. Azure SQL Database og Azure Managed Instance har administrerede sikkerhedskopier.
DBCC CHECKDB
Databasekorruption sker desværre. Uden regelmæssigt at tjekke for korruption kan kunderne befinde sig et dårligt sted ved ikke at have sikkerhedskopier for at gendanne, når den korruption påvirker de fysiske data. For at kontrollere for korruption skal DBCC CHECKDB køres mod hver database regelmæssigt. Det, jeg finder, minder meget om sikkerhedskopier:
- Der blev ikke udført nogen DBCC CHECKDB overhovedet
- DBCC CHECKDB'er udføres kun på udvalgte databaser
- DBCC CHECKDB'er blev sidst udført for måneder eller år siden
Værste tilfælde er et planlagt job, der rapporterer mislykkede DBCC CHECKDB'er
Det er aldrig behageligt at finde korruption eller at få en kunde til at nå ud med et korruptionsproblem, når korruptionen er en bunke eller et klynget indeks, og der ikke er sikkerhedskopier før korruptionen opstår. I disse tilfælde er korruptionen de faktiske data, og at starte gendannelsen fra før korruptionen er i de fleste tilfælde den eneste mulighed. I tilfælde, hvor korruptionen er et ikke-klynget indeks, er genopbygning af indekset løsningen.
I nogle få situationer har jeg været nødt til at arbejde med kunder, der har grim korruption uden ordentlige backups, hvor jeg har været i stand til at scripte databasen ud og manuelt kopiere alle brugbare data ind i en nyoprettet database. Disse kostbare situationer kan nemt undgås ved at køre DBCC CHECKDB og have korrekt backup-retention.
Jeg råder kunder til at køre DBCC CHECKDB on-premises, IaaS, Azure SQL Database og Azure SQL Managed Instance. Azure gør et godt stykke arbejde med at tjekke for fysisk korruption; Jeg føler dog, at forbrugerne skal tjekke for logisk korruption.
Hukommelsesindstillinger
En standardinstallation af Microsoft SQL Server har den mindste hukommelsesværdi sat til 0 og den maksimale serverhukommelsesværdi sat til 2147483647 MB, hvilket er 2 Petabytes. Før SQL Server 2012 gjaldt den maksimale serverhukommelsesværdi kun for bufferpuljen, så kunderne skulle begrænse mængden af hukommelse, bufferpuljen kunne bruge til at gemme hukommelse til operativsystemet og andre processer. SQL Server 2012 introducerede en hukommelseshåndteringsomskrivning, så den maksimale serverhukommelsesværdi gælder for alle SQL Server-hukommelsestildelinger.
Det er stærkt tilrådeligt at indstille en maksimal værdi for din SQL Server-instans. Jonathan Kehayias har skrevet et blogindlæg Hvor meget hukommelse har min SQL Server egentlig brug for, med en formel, der hjælper med at etablere basislinjen for den maksimale hukommelsesværdi. I tilfælde af en delt SQL Server anbefaler jeg mine klienter at indstille minimumsværdien til 30 % af hukommelsen på serveren.
I situationer med flere forekomster, eller hvor serveren bruges til SQL Server, SSIS, SSAS eller SSRS, skal du vurdere, hvor meget hukommelse de andre systemer har brug for og reducere den maksimale serverhukommelsesværdi for at tillade tilstrækkelig hukommelse til OS og den anden tjenester.
Dette problem er gyldigt for on-premises, IaaS og delvist for Azure SQL Managed Instance. Managed Instance angiver en maksimal serverhukommelsesværdi baseret på det implementerede niveau, men da jeg testede at ændre størrelsen på miljøet, blev den maksimale hukommelsesværdi ikke ændret dynamisk. I den situation skal du manuelt opdatere værdien. Dette problem gælder ikke for Azure SQL Database.
Statistik
Forespørgselsoptimeringsværktøjet bruger statistik til at opbygge eksekveringsplaner. Dette betyder, at SQL Server har brug for statistik for at være opdateret, så forespørgselsoptimeringsværktøjet har en bedre chance for at opbygge en god eksekveringsplan. Som standard opdateres statistikker efter 20 % +500 rækker med data er blevet ændret. Det kan tage lang tid på større borde. Fra og med kompatibilitetsniveau 130 er tærsklen for statistikopdateringer for store tabeller blevet sænket. For SQL Server 2008R – 2014 kan du sænke denne tærskel ved at bruge sporingsflag 2371.
Jeg oplever jævnligt, at kunder ikke manuelt opdaterer statistik, og selv med den lavere tærskel har jeg fundet ud af, at manuel opdatering gør et miljø mere stabilt.
Jeg anbefaler, at kunder bruger et tredjepartsscript til at opdatere statistik. Ola Hallengren har udgivet en meget brugt vedligeholdelsesløsning til SQL Server. En del af denne proces er hans Index Optimize-procedure, som kan tage yderligere parametre for at opdatere statistik.
@UpdateStatistics
ALL = update index and column statistics
INDEX = update index statistics
COLUMNS = update column statistics
NULL = Do not perform statistics maintenance (this is the default)
@OnlyModifiedStatistics
Y = Update statistics only if rows have been modified since most recent stats update
N = Update statistics regardless of whether any rows have been modified
Jeg har fundet ud af, at kunder, der bruger tredjepartsprodukter eller scripts til at udføre indeksvedligeholdelse baseret på indeksets fragmenteringsniveau, ikke overvejer, at omorganiseringer ikke opdaterer statistikker, som ombygninger gør. Mange af disse tredjepartsapplikationer har muligheder for at opdatere statistik ligesom Olas indeksoptimeringsprocedure, du skal bare slå den til.
Opdatering af statistik gælder for on-premises, IaaS, Azure SQL Database og Azure SQL Managed Instance.
Indeksvedligeholdelse
Det er stadig vigtigt at udføre indeksvedligeholdelse ved at fjerne fragmentering fra dine indekser. Noget tilbagetrukket dokumentation fra Microsoft anførte, at indeksfragmentering kan have en negativ indvirkning fra 13-460 % afhængigt af størrelsen af miljøet og fragmenteringsniveauet. Mens hardware såsom intelligente SAN'er, Solid State Disk og andre fremskridt har hjulpet med at fremskynde tingene, kan spildplads i indeks oversættes til spildplads i bufferpuljen samt spild mere I/O.
Fragmentering sker gennem regelmæssige operationer såsom indsættelser, opdateringer og sletninger. For at afhjælpe dette, er det nødvendigt med korrekt indeksvedligeholdelse af genopbygning eller omorganisering af dine indekser. Jeg vender mig igen til Ola Hallengren for hans Index Optimize-manuskript. Olas script giver mulighed for at specificere at genopbygge eller omorganisere baseret på niveauet af fragmentering og minimumssider. Mange tredjepartsværktøjer tilbyder den samme logik. SQL Server-databasevedligeholdelsesplaner før SQL Server 2016 tillod kun at genopbygge eller omorganisere alle indekser. Fra og med SQL Server 2016 kan du nu angive lignende logik baseret på fragmenteringsniveauer. Glem dog ikke disse statistikker, hvis du bruger smart logik baseret på fragmenteringsniveauer.
Jeg kan godt lide Olas script og tredjepartsværktøjer, der logger på en tabel. Jeg kan derefter forespørge i tabellen for at se, om jeg har nogle indeks-hot spots, hvor der konstant forekommer fragmentering på høje niveauer, og fejlfinde, hvorfor fragmentering er så udbredt, og hvad som helst kan gøres.
Der er undtagelser fra enhver regel eller bedste praksis. Nogle mønstre for dataadgang fører til konstant fragmentering. Omkostningerne ved konstant at genopbygge/omorganisere disse borde er måske ikke det værd og kan udelukkes fra vedligeholdelse. Disse situationer bør vurderes fra sag til sag.
Dette gælder for on-premises, IaaS, Azure SQL Database og Azure SQL Managed Instance.
MAXDOP
Jeg oplever, at den maksimale grad af parallelitet og omkostningstærskel for parallelitet typisk efterlades ved standardværdierne på klientserverne. For MAXDOP er standardværdien nul, hvilket betyder, at et "ubegrænset" antal CPU'er kan bruges til at udføre en parallel region af en forespørgsel. Teknisk set op til 64 processorer, medmindre du aktiverer et sporingsflag for at bruge flere.
For et årti siden, da processorer havde lavere kerneantal, var denne værdi acceptabel. I dag, med høj kernedensitet og multi-socket-servere, er et ubegrænset antal CPU'er til parallelitet ikke så godt. Microsoft har givet vejledning om, hvilke værdier der skal bruges til MAXDOP.
Hvis du er på SQL Server 2008 – SQL Server 2014, for en enkelt NUMA-node med mindre end 8 logiske processorer, skal du holde MAXDOP på eller under antallet af logiske processorer. Hvis du har mere end 8 logiske processorer, behold MAXDOP på 8. Hvis du har flere NUMA-noder med mindre end 8 logiske processorer pr. NUMA-knude, skal du holde MAXDOP på eller under antallet af logiske processorer pr. NUMA-knude. Større end 8, hold MAXDOP på 8.
SQL Server 2016 introducerede soft-NUMA noder. Hvis databasemotoren under servicestart registrerer mere end 8 fysiske kerner pr. NUMA-knude eller -sokkel, oprettes soft-NUMA-noder automatisk. Motoren sørger for at placere logiske processorer fra den samme fysiske kerne i forskellige soft-NUMA noder. Af den grund har vi lidt anderledes vejledning til MAXDOP til SQL Server 2016 og fremefter.
Hvis du er på SQL Server 2016 og nyere, for en enkelt NUMA-node med mindre end 16 logiske processorer, skal du holde MAXDOP på eller under antallet af logiske processorer. Hvis du har mere end 16 logiske processorer, skal du beholde MAXDOP på 16. Hvis du har flere NUMA-noder med mindre end 16 logiske processorer pr. NUMA-knude, skal du holde MAXDOP på eller under antallet af logiske processorer pr. NUMA-knude. Større end 16, hold MAXDOP på halvdelen af antallet af logiske processorer pr. NUMA-node med en MAX-værdi på 16.
Hvis du for det meste er virtualiseret på maskiner med 8 eller færre logiske processorer med en standard MAXDOP, er du sandsynligvis i OK. Hvis du har stor fysisk hardware med standardindstillinger, så bør du se på at optimere MAXDOP.
Alle ovenstående tal er retningslinjer, ikke hårde sandheder. Dine arbejdsbelastninger varierer, og du bør tage hensyn til, hvilken værdi der er mest optimal for din arbejdsbyrde.
Konfiguration af MAXDOP gælder for on-premises, IaaS og Azure SQL Managed Instance. Der er dog en databaseomfattet konfiguration, der kan anvendes pr. database, startende med SQL Server 2016, og dette gælder for Azure SQL Database.
Omkostningstærskel for parallelisme
Omkostningstærskel for parallelisme har en standardværdi på 5. Historien om dette tal går tilbage til de tidlige dage af SQL Server og den arbejdsstation, som test af arbejdsbelastning blev udført på. Med moderne hardware er omkostningsestimatet på 5 forældet. Test har vist, at en forøgelse af tallet fra 5 til en højere værdi vil forhindre, at kortvarende forespørgsler har en parallel plan. Jeg plejer at anbefale at øge denne værdi til et højere tal efter at have undersøgt Plan-cachen. I mange tilfælde ender jeg med at starte med en værdi på 25 og derefter overvåge videre og justere derfra, hvis det er nødvendigt. For mere information om justering af omkostningstærskel for parallelisme, skrev Jonathan Kehayias:Tuning 'cost threshold for parallelism' fra Plan Cache.
Dette gælder for on-premises, IaaS og Azure SQL Managed Instance.
SQL Server Agent Alerts
Alle bør udnytte SQL Agent-advarsler, medmindre de har en tredjepartsapplikation, der overvåger de samme fejltilstande. Konfiguration af alarmer er nemt og gratis, og at have dem konfigureret vil give dig kritisk information, når dine servere har problemer.
Jeg skrev en artikel med titlen SQL Server Agent Alerts, der giver trin-for-trin instruktioner om, hvordan man opretter advarsler for alvorlighedsgrad 19-25 fejl og fejl 825. Det er nemt at aktivere disse advarsler:aktiver databasemail, opret en mailoperatør og opret derefter alarmer. Dette kan opnås ved hjælp af GUI eller med T-SQL. Jeg opfordrer alle til at scripte denne proces ved hjælp af T-SQL og gøre den til en del af din standard server build.
Dette gælder for on-premises, IaaS og Azure SQL Managed Instance.
Oversigt
Som du kan se, er der mange indstillinger, der bør ændres fra standardindstillingerne efter installation af SQL Server. Dette er ikke en udtømmende liste; den dækker dog mange af de mere kritiske og præstationspåvirkende problemer, jeg finder, og som jeg er havnet under kategorien "SQL Server-uheld".