Ik geef al jaren les en schrijf over veelvoorkomende SQL Server-fouten. Ik heb er jaren geleden ook een blog over geschreven, maar naarmate de tijd vorderde, is de begeleiding een beetje veranderd. In dit artikel wordt mijn vorige artikel uitgebreid en wordt uitgelegd hoe deze van toepassing zijn op SQL Server, Azure SQL Database en Azure SQL Managed Instance.
Ik merk al jaren dat gebruikers dezelfde fouten maken. Ik noem ze fouten, maar in de meeste gevallen zijn het meer dingen die niet goed worden gedaan omdat de mensen die het milieu beheren niet beter weten. Hier zijn enkele van de meer kritieke items die iedereen die SQL Server installeert en ondersteunt moet weten:
- Back-ups
- DBCC CHECKDB
- Geheugeninstellingen
- Statistieken
- Indexonderhoud
- MAXDOP en kostendrempel voor parallellisme
- SQL Server Agent-waarschuwingen
Back-ups
Ik controleer altijd eerst de back-ups als ik naar een nieuw systeem kijk. Het is van cruciaal belang om over de juiste back-ups te beschikken om aan de hersteldoelstellingen te voldoen. Gegevensverlies kan nadelig zijn voor een organisatie. Als ik naar back-ups kijk, controleer ik het herstelmodel en de huidige geschiedenis van back-ups voor elke database. Ik vind meestal een combinatie van het volgende:
- Helemaal geen back-up - geen record van een back-up voor de database
- Ontbrekende back-ups – geen logback-ups voor een database met het volledige herstelmodel
- Geen recente back-ups – de laatste back-up was weken/maanden/jaren oud
Verkeerd geconfigureerde back-ups zijn schadelijk voor een organisatie wanneer zich een herstelsituatie voordoet. Werken met en klanten moeten vertellen dat ze gegevens zijn kwijtgeraakt, is nooit leuk of gemakkelijk. Het hebben van de juiste back-ups om aan SLA's te voldoen, zou de hoogste prioriteit van elke organisatie moeten zijn, naast het zorgen dat er kopieën van deze back-ups op een externe locatie op een secundaire locatie worden opgeslagen.
Deze situatie is van toepassing op on-premises SQL Server en IaaS. Azure SQL Database en Azure Managed Instance hebben beheerde back-ups.
DBCC CHECKDB
Databasecorruptie komt helaas voor. Zonder regelmatig te controleren op corruptie, kunnen klanten zich in een slechte positie bevinden door geen back-ups te hebben om te herstellen wanneer die corruptie de fysieke gegevens aantast. Om te controleren op corruptie, moet DBCC CHECKDB regelmatig op elke database worden uitgevoerd. Wat ik vind, lijkt erg op back-ups:
- Er zijn helemaal geen DBCC CHECKDB's uitgevoerd
- DBCC CHECKDB's worden alleen op bepaalde databases uitgevoerd
- DBCC CHECKDB's voor het laatst uitgevoerd maanden of jaren geleden
In het ergste geval is een geplande taak rapportage mislukt DBCC CHECKDBs
Het is nooit prettig om corruptie te vinden of een klant contact te laten zoeken met een corruptieprobleem wanneer de corruptie een heap of geclusterde index is en er geen back-ups zijn voordat de corruptie optreedt. In deze gevallen zijn de beschadiging de feitelijke gegevens en is het in de meeste gevallen de enige optie om het herstel te starten van vóór de beschadiging. In gevallen waar de corruptie een niet-geclusterde index is, is het herstellen van de index de oplossing.
In een paar situaties heb ik met klanten moeten werken die vervelende corruptie hebben zonder de juiste back-ups, waarbij ik de database kon scripten en alle bruikbare gegevens handmatig naar een nieuw gemaakte database kon kopiëren. Deze kostbare situaties kunnen gemakkelijk worden vermeden door DBCC CHECKDB uit te voeren en de juiste back-upretentie te hebben.
Ik adviseer klanten om DBCC CHECKDB on-premises, IaaS, Azure SQL Database en Azure SQL Managed Instance uit te voeren. Azure controleert uitstekend op fysieke corruptie; ik vind echter dat consumenten moeten controleren op logische corruptie.
Geheugeninstellingen
Bij een standaardinstallatie van Microsoft SQL Server is de minimale geheugenwaarde ingesteld op 0 en de maximale servergeheugenwaarde ingesteld op 2147483647 MB, oftewel 2 Petabytes. Vóór SQL Server 2012 gold de maximale servergeheugenwaarde alleen voor de bufferpool, dus klanten moesten de hoeveelheid geheugen beperken die de bufferpool kon gebruiken om geheugen voor het besturingssysteem en andere processen te besparen. SQL Server 2012 heeft een herschrijving van geheugenbeheer geïntroduceerd, zodat de maximale servergeheugenwaarde van toepassing is op alle geheugentoewijzingen van SQL Server.
Het is ten zeerste aan te raden om een maximale waarde in te stellen voor uw SQL Server-instantie. Jonathan Kehayias heeft een blogpost geschreven Hoeveel geheugen heeft mijn SQL Server eigenlijk nodig, met een formule die helpt bij het bepalen van de basislijn voor de maximale geheugenwaarde. In het geval van een gedeelde SQL Server raad ik mijn klanten aan om de minimumwaarde in te stellen op 30% van het geheugen op de server.
In situaties met meerdere instanties of waar de server wordt gebruikt voor SQL Server, SSIS, SSAS of SSRS, moet u evalueren hoeveel geheugen die andere systemen nodig hebben en de maximale servergeheugenwaarde verlagen om voldoende geheugen voor het besturingssysteem en de andere mogelijk te maken diensten.
Dit probleem is geldig voor on-premises, IaaS en gedeeltelijk voor door Azure SQL beheerd exemplaar. Beheerde instantie stelt een maximale servergeheugenwaarde in op basis van de geïmplementeerde laag, maar toen ik testte om de grootte van de omgeving te wijzigen, werd de maximale geheugenwaarde niet dynamisch gewijzigd. In die situatie moet u de waarde handmatig bijwerken. Dit probleem is niet van toepassing op Azure SQL Database.
Statistieken
De query-optimizer gebruikt statistieken om uitvoeringsplannen op te stellen. Dit betekent dat SQL Server statistieken nodig heeft om up-to-date te zijn, zodat de query-optimizer een betere kans heeft om een goed uitvoeringsplan te bouwen. Statistieken worden standaard bijgewerkt nadat 20% +500 gegevensrijen zijn gewijzigd. Op grotere tafels kan dat lang duren. Vanaf compatibiliteitsniveau 130 is de drempel voor het bijwerken van statistieken voor grote tabellen verlaagd. Voor SQL Server 2008R – 2014 kunt u deze drempel verlagen met traceringsvlag 2371.
Ik merk regelmatig dat klanten de statistieken niet handmatig bijwerken en zelfs met de lagere drempel heb ik gemerkt dat handmatig bijwerken een omgeving stabieler maakt.
Ik raad klanten aan een script van een derde partij te gebruiken om statistieken bij te werken. Ola Hallengren heeft een veelgebruikte onderhoudsoplossing voor SQL Server gepubliceerd. Onderdeel van dat proces is zijn Index Optimize-procedure, die aanvullende parameters kan gebruiken om statistieken bij te werken.
@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
Ik heb geconstateerd dat klanten die producten of scripts van derden gebruiken om indexonderhoud uit te voeren op basis van het fragmentatieniveau van de index, niet overwegen dat reorganisaties de statistieken niet bijwerken zoals bij rebuilds. Veel van deze applicaties van derden hebben opties voor het bijwerken van statistieken, net als Ola's Index Optimize-procedure, je hoeft het alleen maar aan te zetten.
Het bijwerken van statistieken is van toepassing op on-premises, IaaS, Azure SQL Database en Azure SQL Managed Instance.
Indexonderhoud
Het is nog steeds belangrijk om indexonderhoud uit te voeren door fragmentatie uit uw indexen te verwijderen. Sommige verouderde documentatie van Microsoft stelt dat indexfragmentatie een negatief effect kan hebben van 13-460%, afhankelijk van de grootte van de omgeving en het niveau van fragmentatie. Hoewel hardware zoals intelligente SAN's, Solid State Disk en andere ontwikkelingen hebben geholpen om de zaken te versnellen, kan verspilde ruimte in de index zich vertalen in verspilde ruimte in de bufferpool en meer I/O verspillen.
Fragmentatie vindt plaats door middel van reguliere bewerkingen zoals invoegingen, updates en verwijderingen. Om dit te verhelpen, is een goed indexonderhoud van het opnieuw opbouwen of reorganiseren van uw indexen nodig. Ik wend me opnieuw tot Ola Hallengren voor zijn Index Optimize-script. Het script van Ola biedt de mogelijkheid om te specificeren om opnieuw te bouwen of te reorganiseren op basis van het niveau van fragmentatie en minimale pagina's. Veel tools van derden bieden dezelfde logica. Onderhoudsplannen voor SQL Server-databases voorafgaand aan SQL Server 2016 mogen alleen alle indexen opnieuw opbouwen of reorganiseren. Vanaf SQL Server 2016 kunt u nu vergelijkbare logica opgeven op basis van fragmentatieniveaus. Vergeet die statistieken echter niet als u slimme logica gebruikt op basis van fragmentatieniveaus.
Ik hou van Ola's script en tools van derden die inloggen op een tabel. Ik kan dan de tabel doorzoeken om te zien of ik index-hotspots heb waar fragmentatie constant op een hoog niveau voorkomt en problemen oplossen waarom fragmentatie zo vaak voorkomt en kan er iets worden gedaan.
Er zijn uitzonderingen op elke regel of best practice. Sommige patronen van gegevenstoegang leiden tot constante fragmentatie. De kosten van het voortdurend opnieuw opbouwen/reorganiseren van die tabellen zijn misschien niet de moeite waard en kunnen worden uitgesloten van onderhoud. Die situaties moeten van geval tot geval worden beoordeeld.
Dit geldt voor on-premises, IaaS, Azure SQL Database en Azure SQL Managed Instance.
MAXDOP
Ik vind dat de maximale mate van parallellisme en de kostendrempel voor parallellisme meestal op de standaardwaarden op de clientservers worden gelaten. Voor MAXDOP is de standaardwaarde nul, wat betekent dat een 'onbeperkt' aantal CPU's kan worden gebruikt om een parallel gebied van een query uit te voeren. Technisch gezien maximaal 64 processors, tenzij je een traceringsvlag inschakelt om meer te gebruiken.
Tien jaar geleden, toen processors een lager aantal cores hadden, was deze waarde acceptabel. Tegenwoordig, met een hoge kerndichtheid en servers met meerdere sockets, is een onbeperkt aantal CPU's voor parallellisme niet zo goed. Microsoft heeft richtlijnen gegeven over welke waarden moeten worden gebruikt voor MAXDOP.
Als u SQL Server 2008 – SQL Server 2014 gebruikt, moet u voor één NUMA-knooppunt met minder dan 8 logische processors MAXDOP op of onder het aantal logische processors houden. Als u meer dan 8 logische processors hebt, houdt u MAXDOP op 8. Als u meerdere NUMA-knooppunten hebt met minder dan 8 logische processors per NUMA-knooppunt, houdt u MAXDOP op of onder het aantal logische processors per NUMA-knooppunt. Groter dan 8, houd MAXDOP op 8.
SQL Server 2016 introduceerde soft-NUMA-knooppunten. Als de database-engine tijdens het opstarten van de service meer dan 8 fysieke kernen per NUMA-knooppunt of socket detecteert, worden automatisch soft-NUMA-knooppunten gemaakt. De engine zorgt voor het plaatsen van logische processors van dezelfde fysieke kern in verschillende soft-NUMA-knooppunten. Om die reden hebben we iets andere richtlijnen voor MAXDOP voor SQL Server 2016 en later.
Als u SQL Server 2016 en hoger gebruikt, moet u voor één NUMA-knooppunt met minder dan 16 logische processors MAXDOP op of onder het aantal logische processors houden. Als u meer dan 16 logische processors hebt, houdt u MAXDOP op 16. Als u meerdere NUMA-knooppunten hebt met minder dan 16 logische processors per NUMA-knooppunt, houdt u MAXDOP op of onder het aantal logische processors per NUMA-knooppunt. Groter dan 16, houd MAXDOP op de helft van het aantal logische processors per NUMA-knooppunt met een MAX-waarde van 16.
Als je meestal gevirtualiseerd bent op machines met 8 of minder logische processors met een standaard MAXDOP, zit je waarschijnlijk goed. Als je grote fysieke hardware met standaardinstellingen hebt, moet je kijken naar het optimaliseren van MAXDOP.
Alle bovenstaande cijfers zijn richtlijnen, geen harde waarheden. Uw werkbelasting varieert en er moet rekening mee worden gehouden wanneer u bepaalt welke waarde het meest optimaal is voor uw werkbelasting.
Het configureren van MAXDOP is van toepassing op on-premises, IaaS en Azure SQL Managed Instance. Er is echter een database-scoped configuratie die kan worden toegepast per database vanaf SQL Server 2016, en dit geldt voor Azure SQL Database.
Kostendrempel voor parallellisme
De kostendrempel voor parallellisme heeft een standaardwaarde van 5. De geschiedenis van dit aantal gaat terug tot de begindagen van SQL Server en het werkstation waarop de werkbelastingstest werd uitgevoerd. Met moderne hardware is de kostenraming van 5 achterhaald. Testen hebben aangetoond dat het verhogen van het aantal van 5 naar een hogere waarde ervoor zorgt dat kortere query's geen parallel plan hebben. Ik heb de neiging om aan te bevelen deze waarde naar een hoger getal te verhogen na het onderzoeken van de plancache. In veel gevallen begin ik met een waarde van 25 en controleer dan verder en pas vanaf daar aan, indien nodig. Voor meer informatie over het afstemmen van de kostendrempel voor parallellisme, schreef Jonathan Kehayias:Afstemming van 'kostendrempel voor parallellisme' uit de Plan Cache.
Dit geldt voor on-premises, IaaS en Azure SQL Managed Instance.
SQL Server Agent-waarschuwingen
Iedereen zou SQL Agent-waarschuwingen moeten gebruiken, tenzij ze een toepassingsbewaking van derden hebben voor dezelfde foutcondities. Het configureren van waarschuwingen is eenvoudig en gratis, en als u ze configureert, krijgt u kritieke informatie wanneer uw servers problemen hebben.
Ik schreef een artikel met de titel SQL Server Agent Alerts, met stapsgewijze instructies voor het maken van waarschuwingen voor ernst 19-25 fouten en fout 825. Het inschakelen van deze waarschuwingen is eenvoudig:schakel databasemail in, maak een e-mailoperator en maak vervolgens de waarschuwingen. Dit kan worden bereikt met behulp van de GUI of met T-SQL. Ik moedig iedereen aan om dit proces te scripten met T-SQL en het onderdeel te maken van je standaard serverbuild.
Dit geldt voor on-premises, IaaS en Azure SQL Managed Instance.
Samenvatting
Zoals u kunt zien, zijn er veel instellingen die moeten worden gewijzigd ten opzichte van de standaardinstellingen na het installeren van SQL Server. Dit is geen uitgebreide lijst; het dekt echter wel veel van de meer kritieke en prestatie-beïnvloedende problemen die ik tegenkom, en die ik onder mijn categorie "SQL Server-ongevallen" heb gegooid.