Hoeveel tijd besteedt u als databasebeheerder of -ontwikkelaar aan het oplossen van prestatieproblemen? Heb je het ooit gevolgd? Als het gemiddelde totale percentage van uw dag, lijkt het misschien niet veel tijd, maar als het probleem ernstig is, kunt u uren besteden aan het opsporen en analyseren van de oorzaak. Soms verdwijnt het probleem en weet je de ware oorsprong niet. En nog erger? Wanneer u midden in de nacht of in het weekend met deze problemen moet worstelen. Je worstelt niet alleen om een probleem op te lossen, maar je verliest ook je persoonlijke vrije tijd. Hoe verlichten we dat? Hoe halen we onze tijd en moeite uit de vergelijking en verbeteren we tegelijkertijd de prestaties?
De functie Automatic Tuning in SQL Server 2017 Enterprise Edition en Azure SQL Database is de eerste stap in het verminderen van de tijd die dataprofessionals besteden aan het oplossen van problemen en het oplossen van prestatieproblemen. De functie omvat automatische plancorrectie en automatisch indexbeheer (alleen beschikbaar in Azure SQL Database), die afzonderlijk worden ingeschakeld. In dit bericht wil ik me concentreren op de functie Automatische plancorrectie. Als SQL Server met automatische plancorrectie constateert dat een query aanzienlijk achteruit is gegaan, wordt het laatst bekende goede plan voor de query geforceerd om de prestaties te stabiliseren. In wezen, in plaats van dat u, de DBA of ontwikkelaar, in het weekend wordt gebeld over systeemprestaties, zal SQL Server het voor u aanpakken. Klinkt te makkelijk, toch? Laten we eens kijken.
Onder de dekens
Ten eerste is het essentieel om te begrijpen dat Automatische plancorrectie gebruikmaakt van Query Store, dus het moet zijn ingeschakeld voor de database. Ten tweede is automatische plancorrectie gewoon automatische planforcering. Hoewel Query Store op de markt wordt gebracht als vluchtrecorder voor uw database die querytekst, plannen, runtime-statistieken en wachtstatistieken bijhoudt, kunt u ook een plan voor een query forceren om consistente prestaties mogelijk te maken. Automatische plancorrectie is plannen forceren zonder uw tussenkomst.
Automatische plancorrectie inschakelen
Zoals vermeld, moet Query Store eerst worden ingeschakeld voor de gebruikersdatabase. Dit kan in SSMS, met T-SQL en met REST API voor Azure SQL DB. Merk op dat Query Store standaard is ingeschakeld voor databases in Azure en sinds 2016 Q4.
Query Store inschakelen via SSMS
USE [master]; GO ALTER DATABASE [WideWorldImporters] SET QUERY_STORE = ON; GO ALTER DATABASE [WideWorldImporters] SET QUERY_STORE (OPERATION_MODE = READ_WRITE); GO
Query Store inschakelen met T-SQL
De bovenstaande code is de standaard T-SQL van SSMS als u deze uitschrijft. In Azure SQL Database voert u de USE-instructie niet uit. Als je een van de standaardopties wilt wijzigen, lees dan mijn bericht over Query Store-instellingen over wat die opties zijn en overwegingen voor alternatieve waarden.
Zodra Query Store is ingeschakeld, kunt u de Azure Portal, T-SQL of EST API gebruiken om automatische plancorrectie in Azure SQL Database in te schakelen ((en C# en PowerShell zijn in de maak). Het kan alleen worden ingeschakeld met T-SQL in SQL Server 2017.
Automatische plancorrectie inschakelen in Azure Portal
ALTER DATABASE [WideWorldImporters] SET AUTOMATIC_TUNING ( FORCE_LAST_GOOD_PLAN = ON ); GO
Automatische plancorrectie inschakelen in de T-SQL
Houd er rekening mee dat automatische plancorrectie in de nabije toekomst standaard wordt ingeschakeld voor nieuwe data bases in Azure. Vanaf januari 2018 wordt automatisch afstemmen ingeschakeld voor Azure SQL-databases waarvoor dit nog niet was ingeschakeld, met meldingen die naar beheerders worden gestuurd, zodat de optie desgewenst kan worden uitgeschakeld.
Hoe het werkt
Als Automatische plancorrectie is ingeschakeld, bewaakt SQL Server de queryprestaties met behulp van Query Store-gegevens. Het zoekt naar een significante verandering* in CPU**-prestaties met een 48-uurs venster***. Let op de sterretjes in die zin... die zijn expres:
- *De drempel voor wat een significante wijziging is, is niet gedocumenteerd omdat Microsoft zich het recht voorbehoudt om deze te wijzigen.
- **De statistiek die wordt gebruikt om de prestatiewijziging (CPU) te bepalen, is niet gedocumenteerd omdat Microsoft zich het recht voorbehoudt om deze te wijzigen. Dit betekent dat Microsoft extra dimensies zou kunnen overwegen om naar prestaties te kijken als dat beter zou zijn / beter zou presteren dan alleen de CPU.
- ***De periode waarin de prestatiegegevens van de query worden vergeleken, is om dezelfde reden niet gedocumenteerd. Microsoft behoudt zich het recht voor deze te wijzigen.
- Opmerking:hoewel de bovengenoemde items niet zijn gedocumenteerd, heb ik met de juiste personen bij Microsoft bevestigd dat deze informatie kan worden gedeeld met het breken van een NDA. Het is uiterst belangrijk om te begrijpen dat de waarden niet vastliggen en kunnen veranderen, met de verwachting dat ze zouden veranderen om de betrouwbaarheid van de functie te verbeteren.
Het gebrek aan documentatie en de mogelijkheid van wijzigingen in de drempelwaarde kan voor sommige mensen frustrerend zijn, maar dit is wat echt belangrijk is om te onthouden:
Microsoft legt dagelijks terabytes aan operationele telemetriegegevens vast uit SQL Azure-databases en die gegevens zijn essentieel voor de automatische functies die worden ontwikkeld. Deze gegevens omvatten zaken als query_id, query_plan_id en query_hash, en Microsoft legt GEEN query_text of query_plan vast (ze kijken niet naar uw werkelijke gegevens). Microsoft archiveert niet alleen die operationele telemetrie of gebruikt het voor het oplossen van problemen, ze ontginnen die gegevens en gebruiken het om algoritmen en modellen te ontwikkelen waarmee SQL Server onafhankelijke, intelligente beslissingen kan nemen.
SQL Server kan profiteren van de overvloed aan gegevens in Query Store waarin de prestaties van query's worden beschreven, en automatische plancorrectie begint met het vergelijken van de huidige prestaties voor een query met eerdere prestaties om te bepalen of er sprake is van een achteruitgang in de prestaties. Zijn de prestaties gedaald of verslechterd, en zo ja, is dit aanzienlijk?
Als er een achteruitgang is opgetreden in de queryprestaties, dwingt SQL Server het laatst bekende goede plan voor die query af, dat natuurlijk uit de Query Store wordt gehaald. Maar daar stopt het niet. SQL Server blijft vervolgens de prestaties monitoren - nog steeds met behulp van Query Store - om te bevestigen dat het geforceerde plan nog steeds een goed plan is voor die query, wat betekent dat de query met het geforceerde plan beter presteert dan de regressieversie. Als die zoekopdracht niet beter presteert, wordt het plan ongedaan gemaakt. Een plan kan ook niet-geforceerd worden als er een hercompilatie is, of als het forceren mislukt.
Deze cyclus gaat door; als een query een geforceerd plan heeft en dat plan om een van de bovengenoemde redenen niet-geforceerd is, kan datzelfde plan later opnieuw worden geforceerd, of er kan op een later tijdstip een ander plan voor die query worden geforceerd. Dit is een continu proces dat plaatsvindt zolang u de optie Automatische plancorrectie voor de database hebt ingeschakeld. Wat nu interessant is, is dat u dezelfde informatie kunt bekijken die deze functie vastlegt en deze handmatig kunt forceren. Dat wil zeggen, in SQL Server 2017 Enterprise Edition en in Azure SQL Database worden deze gegevens verzameld in de DMV sys.dm_db_tuning_recommendations, zelfs als de functie Automatische plancorrectie niet is ingeschakeld, zodat u die gegevens kunt onderzoeken en de aanbevelingen kunt volgen om plannen af te dwingen voor specifieke vragen op uw eigen. Merk op dat als je een plan forceert met behulp van aanbevelingen van sys.dm_db_tuning_recommendations, het nooit automatisch ongedaan gemaakt zal worden. Verder, als u Automatische plancorrectie hebt ingeschakeld en u handmatig een plan forceert, wordt het nooit automatisch ongedaan gemaakt. Alleen plannen die zijn afgedwongen met de functie Automatische plancorrectie, worden automatisch ongedaan gemaakt.
Ga ik SQL Server echt de controle geven?
Als je sceptisch bent en je afvraagt of je SQL Server echt kunt vertrouwen om een besluit te nemen dat het plan afdwingt, dan raad ik je aan om dit te onthouden:
- Deze functie is ontwikkeld met een duizelingwekkende hoeveelheid gegevens die zijn vastgelegd uit bijna twee miljoen Azure SQL-databases. Het is een nieuwe functie in SQL Server 2017, maar werd in 2016 wereldwijd beschikbaar in Azure, dus deze functie is echt al meer dan een jaar beschikbaar en is verfijnd.
- De technici hebben in de loop van de tijd wijzigingen aangebracht in het algoritme, omdat ze meer gegevens hebben verzameld. Het vindt misschien niet elke regressie die optreedt - omdat een regressie misschien niet ernstig genoeg is, maar ik durf te wedden dat velen van jullie liever deze functiekracht minder vaak dan te vaak hebben.
- Bovendien, als een plan wordt geforceerd maar uiteindelijk een probleem veroorzaakt, is het vermogen van SQL Server om hiervan te herstellen en het plan ongedaan te maken uiterst betrouwbaar en gebeurt het zeer snel.
Samenvatting
U voelt zich misschien niet op uw gemak bij het idee dat SQL Server prestatieproblemen voor u oplost. Maar is dat ongemak omdat je denkt dat het een slechte beslissing zal zijn? Of maakt u zich zorgen dat automatisering uw werk overneemt? Vrij directe vraag, ik weet het. Als het de eerste is, dan is mijn aanbeveling om te kijken naar de gegevens die zijn vastgelegd in sys.dm_db_tuning_recommendations (zonder automatische plancorrectie in te schakelen) en te kijken wat SQL Server zou willen doen. Komt het overeen met wat jij zou doen? Vindt het regressies die u misschien mist? Als je de functie niet wilt inschakelen omdat je bang bent dat je plotseling niet genoeg te doen hebt, raad ik je aan om het recente bericht van Conor Cunningham te lezen:Hoe cloudsnelheid SQL Server DBA's helpt. Microsoft probeert u niet uit een baan te coderen. Ze proberen gewoon het laaghangende fruit aan te pakken, zodat jij je kunt concentreren op belangrijkere taken.