Jag har undervisat och skrivit om vanliga SQL Server-misstag i många år. Jag skrev en blogg om det för flera år sedan, men allt eftersom tiden har gått har vägledningen ändrats lite. Den här artikeln kommer att utöka min tidigare artikel och påpeka hur dessa gäller för SQL Server, Azure SQL Database och Azure SQL Managed Instance.
I många år har jag märkt att användare gör samma misstag. Jag kallar dem misstag, men i de flesta fall är det mer bara saker som inte görs ordentligt eftersom människorna som hanterar miljön inte vet bättre. Här är några av de mer kritiska objekten som alla som installerar och stödjer SQL Server bör känna till:
- Säkerhetskopieringar
- DBCC CHECKDB
- Minnesinställningar
- Statistik
- Indexunderhåll
- MAXDOP och kostnadströskel för parallellism
- SQL Server Agent-varningar
Säkerhetskopiering
Jag kontrollerar alltid säkerhetskopior först när jag tittar på ett nytt system. Att ha ordentliga säkerhetskopior för att uppfylla återställningsmålen är avgörande. Dataförlust kan vara skadligt för en organisation. När jag tittar på säkerhetskopior, kollar jag efter återställningsmodell och den aktuella historiken för säkerhetskopior för varje databas. Jag brukar hitta en kombination av följande:
- Ingen säkerhetskopia alls – ingen registrering av någon säkerhetskopia för databasen
- Säkerhetskopiering saknas – inga loggsäkerhetskopior för en databas som använder den fullständiga återställningsmodellen
- Inga nya säkerhetskopior – senaste säkerhetskopian var veckor/månader/år gammal
Felkonfigurerade säkerhetskopior är skadliga för en organisation när en återställningssituation uppstår. Att arbeta med och behöva berätta för kunder att de har förlorat data är aldrig roligt eller lätt. Att ha korrekta säkerhetskopior för att uppfylla SLA:er bör vara alla organisationers högsta prioritet förutom att se till att det finns kopior av dessa säkerhetskopior lagrade på en sekundär plats utanför platsen.
Denna situation gäller lokal SQL Server och IaaS. Azure SQL Database och Azure Managed Instance har hanterade säkerhetskopior.
DBCC CHECKDB
Databaskorruption inträffar tyvärr. Utan att regelbundet kontrollera efter korruption kan kunder hamna på en dålig plats genom att inte ha säkerhetskopior för att återställa när den korruptionen påverkar den fysiska datan. För att kontrollera om det finns korruption bör DBCC CHECKDB köras mot varje databas regelbundet. Vad jag tycker är väldigt likt säkerhetskopior:
- Inga DBCC CHECKDBs utfördes alls
- DBCC CHECKDB utförs endast på utvalda databaser
- DBCC CHECKDB utfördes senast för månader eller år sedan
Det värsta fallet är ett schemalagt jobb som rapporterar misslyckade DBCC CHECKDBs
Det är aldrig trevligt att hitta korruption eller att få en kund att nå ut med ett korruptionsproblem när korruptionen är en hög eller ett klusterindex och det inte finns några säkerhetskopior innan korruptionen inträffade. I dessa fall är korruptionen den faktiska informationen och att starta återställningen från innan korruptionen är i de flesta fall det enda alternativet. I de fall där korruptionen är ett icke-klustrat index, är återuppbyggnad av indexet lösningen.
I några situationer har jag varit tvungen att arbeta med kunder som har otäck korruption utan ordentliga säkerhetskopior där jag har kunnat skriva ut databasen och manuellt kopiera all användbar data till en nyskapad databas. Dessa kostsamma situationer kan enkelt undvikas genom att köra DBCC CHECKDB och ha korrekt säkerhetskopiering.
Jag råder kunder att köra DBCC CHECKDB lokalt, IaaS, Azure SQL Database och Azure SQL Managed Instance. Azure gör ett bra jobb med att leta efter fysisk korruption; Men jag känner att konsumenterna måste leta efter logisk korruption.
Minnesinställningar
En standardinstallation av Microsoft SQL Server har minsta minnesvärde inställt på 0 och maximalt serverminne inställt på 2147483647 MB, vilket är 2 Petabyte. Före SQL Server 2012 gällde det maximala serverminnesvärdet endast för buffertpoolen, så kunder behövde begränsa mängden minne som buffertpoolen kunde använda för att spara minne för operativsystemet och andra processer. SQL Server 2012 introducerade en omskrivning av minneshanteraren så att det maximala serverminnesvärdet gäller för alla SQL Server-minnestilldelningar.
Det är starkt tillrådligt att ställa in ett maximalt värde för din SQL Server-instans. Jonathan Kehayias har skrivit ett blogginlägg Hur mycket minne behöver min SQL Server faktiskt, med en formel som hjälper till att fastställa baslinjen för det maximala minnesvärdet. I fall av en delad SQL-server rekommenderar jag mina klienter att ställa in minimivärdet till 30 % av minnet på servern.
I situationer med flera instanser eller där servern används för SQL Server, SSIS, SSAS eller SSRS, måste du utvärdera hur mycket minne de andra systemen behöver och minska det maximala serverminnesvärdet för att tillåta tillräckligt med minne för operativsystemet och det andra tjänster.
Det här problemet är giltigt för lokalt, IaaS och delvis för Azure SQL Managed Instance. Managed Instance anger ett maximalt serverminnesvärde baserat på den distribuerade nivån, men när jag testade att ändra storlek på miljön ändrades inte det maximala minnesvärdet dynamiskt. I den situationen skulle du behöva uppdatera värdet manuellt. Det här problemet gäller inte Azure SQL Database.
Statistik
Frågeoptimeraren använder statistik för att bygga utförandeplaner. Detta innebär att SQL Server behöver statistik för att vara uppdaterad så att frågeoptimeraren har en bättre chans att bygga en bra exekveringsplan. Som standard uppdateras statistiken efter att 20 % +500 rader med data har ändrats. Det kan ta lång tid på större bord. Från och med kompatibilitetsnivå 130 har tröskeln för statistikuppdateringar för stora tabeller sänkts. För SQL Server 2008R – 2014 kan du sänka denna tröskel med hjälp av spårningsflagga 2371.
Jag upptäcker regelbundet att kunder inte uppdaterar statistik manuellt och även med den lägre tröskeln har jag upptäckt att manuell uppdatering gör en miljö mer stabil.
Jag rekommenderar att kunder använder ett tredjepartsskript för att uppdatera statistik. Ola Hallengren har publicerat en mycket använd underhållslösning för SQL Server. En del av den processen är hans Index Optimize-procedur, som kan ta ytterligare parametrar för att uppdatera 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
Jag har upptäckt att kunder som använder tredjepartsprodukter eller skript för att utföra indexunderhåll baserat på indexets fragmenteringsnivå inte anser att omorganisationer inte uppdaterar statistik som ombyggnader gör. Många av dessa tredjepartsprogram har alternativ för att uppdatera statistik precis som Olas Index Optimize-procedur, du behöver bara aktivera den.
Uppdatering av statistik gäller lokalt, IaaS, Azure SQL Database och Azure SQL Managed Instance.
Indexunderhåll
Att utföra indexunderhåll genom att ta bort fragmentering från dina index är fortfarande viktigt. En del pensionerad dokumentation från Microsoft angav att indexfragmentering kan ha en negativ inverkan från 13-460 % beroende på storleken på miljön och graden av fragmentering. Medan hårdvara som intelligenta SAN, Solid State Disk och andra framsteg har hjälpt till att påskynda saker och ting, kan slöseri med utrymme i index översättas till slöseri med utrymme i buffertpoolen samt slösa mer I/O.
Fragmentering sker genom regelbundna operationer såsom infogar, uppdateringar och borttagningar. För att åtgärda detta krävs korrekt indexunderhåll för att bygga om eller omorganisera dina index. Jag vänder mig återigen till Ola Hallengren, för hans Index Optimize-manus. Olas skript ger möjligheten att specificera att bygga om eller omorganisera baserat på nivån av fragmentering och minsta antal sidor. Många tredjepartsverktyg erbjuder samma logik. SQL Server-databasunderhållsplaner före SQL Server 2016 tillåts endast bygga om eller omorganisera alla index. Från och med SQL Server 2016 kan du nu ange liknande logik baserat på fragmenteringsnivåer. Glöm dock inte den statistiken om du använder smart logik baserad på fragmenteringsnivåer.
Jag gillar Olas skript och tredjepartsverktyg som loggar till en tabell. Jag kan sedan fråga tabellen för att se om jag har några hotspots för index där fragmentering ständigt förekommer på höga nivåer och felsöka varför fragmentering är så utbredd och kan någonting göras.
Det finns undantag från varje regel eller bästa praxis. Vissa mönster för dataåtkomst leder till konstant fragmentering. Kostnaden för att ständigt bygga om/organisera dessa tabeller kanske inte är värt det och kan uteslutas från underhåll. Dessa situationer bör utvärderas från fall till fall.
Detta gäller lokalt, IaaS, Azure SQL Database och Azure SQL Managed Instance.
MAXDOP
Jag tycker att maximal grad av parallellitet och kostnadströskel för parallellitet vanligtvis lämnas vid standardvärdena på klientservrarna. För MAXDOP är standardvärdet noll, vilket betyder att ett "obegränsat" antal processorer kan användas för att exekvera en parallell region av en fråga. Tekniskt upp till 64 processorer om du inte aktiverar en spårningsflagga för att använda fler.
För ett decennium sedan, när processorer hade lägre antal kärnor, var detta värde acceptabelt. Idag, med hög kärndensitet och multi-socket-servrar, är ett obegränsat antal processorer för parallellism inte så bra. Microsoft har gett vägledning om vilka värden som ska användas för MAXDOP.
Om du använder SQL Server 2008 – SQL Server 2014, för en enda NUMA-nod med mindre än 8 logiska processorer, håll MAXDOP vid eller under antalet logiska processorer. Om du har fler än 8 logiska processorer, håll MAXDOP vid 8. Om du har flera NUMA-noder med mindre än 8 logiska processorer per NUMA-nod, håll MAXDOP vid eller under antalet logiska processorer per NUMA-nod. Större än 8, håll MAXDOP på 8.
SQL Server 2016 introducerade soft-NUMA-noder. Under servicestart, om databasmotorn upptäcker mer än 8 fysiska kärnor per NUMA-nod eller socket, skapas mjuk-NUMA-noder automatiskt. Motorn tar hand om att placera logiska processorer från samma fysiska kärna i olika mjuk-NUMA-noder. Av den anledningen har vi lite annorlunda vägledning för MAXDOP för SQL Server 2016 och framåt.
Om du använder SQL Server 2016 och senare, för en enda NUMA-nod med mindre än 16 logiska processorer, håll MAXDOP vid eller under antalet logiska processorer. Om du har fler än 16 logiska processorer, håll MAXDOP vid 16. Om du har flera NUMA-noder med färre än 16 logiska processorer per NUMA-nod, håll MAXDOP vid eller under antalet logiska processorer per NUMA-nod. Större än 16, håll MAXDOP på hälften av antalet logiska processorer per NUMA-nod med ett MAX-värde på 16.
Om du mestadels är virtualiserad på maskiner med 8 eller färre logiska processorer med en standard MAXDOP, är du förmodligen okej. Om du har stor fysisk hårdvara med standardvärden bör du titta på att optimera MAXDOP.
Alla siffror ovan är riktlinjer, inte hårda sanningar. Dina arbetsbelastningar varierar och hänsyn bör tas när du avgör vilket värde som är mest optimalt för din arbetsbelastning.
Konfigurering av MAXDOP gäller lokalt, IaaS och Azure SQL Managed Instance. Det finns dock en databas-omfattad konfiguration som kan tillämpas per databas från och med SQL Server 2016, och detta gäller för Azure SQL Database.
Kostnadströskel för parallellism
Kostnadströskeln för parallellism har ett standardvärde på 5. Historiken för detta nummer går tillbaka till de tidiga dagarna av SQL Server och arbetsstationen som arbetsbelastningstestning utfördes på. Med modern hårdvara är kostnadsuppskattningen på 5 föråldrad. Tester har visat att en ökning av antalet från 5 till ett högre värde kommer att förhindra att kortare sökningar har en parallell plan. Jag brukar rekommendera att öka detta värde till ett högre antal efter att ha undersökt Plan Cache. I många fall slutar jag med att börja med ett värde på 25 och sedan övervaka vidare och justera därifrån, om det behövs. För mer information om justering av kostnadströskel för parallellism, skrev Jonathan Kehayias:Tuning 'kostnadströskel för parallellism' från Plan Cache.
Detta gäller lokalt, IaaS och Azure SQL Managed Instance.
SQL Server Agent Alerts
Alla borde utnyttja SQL Agent-varningar om de inte har en tredjepartsapplikation som övervakar samma feltillstånd. Att konfigurera varningar är enkelt och gratis, och att ha dem konfigurerade ger dig viktig information när dina servrar har problem.
Jag skrev en artikel med titeln SQL Server Agent Alerts, som ger steg-för-steg-instruktioner om hur man skapar varningar för allvarlighetsgrad 19-25-fel och fel 825. Det är enkelt att aktivera dessa varningar:aktivera databaspost, skapa en e-postoperatör och skapa sedan varningar. Detta kan göras med hjälp av GUI eller med T-SQL. Jag uppmuntrar alla att skriva ut den här processen med T-SQL och göra den till en del av din standardserverbyggnad.
Detta gäller lokalt, IaaS och Azure SQL Managed Instance.
Sammanfattning
Som du kan se finns det många inställningar som bör ändras från standardinställningarna efter installation av SQL Server. Detta är inte en heltäckande lista; den täcker dock många av de mer kritiska och prestandapåverkande problem som jag hittar, och som jag har hamnat under kategorin "SQL Server-missöden".