Hvor meget tid bruger du på at fejlfinde problemer med ydeevnen som databaseadministrator eller -udvikler? Har du nogensinde sporet det? Som den gennemsnitlige samlede procentdel af din dag, ser det måske ikke ud som meget tid, men når problemet er alvorligt, kan du bruge timer på at spore det ned og arbejde dig igennem en analyse af årsagen. Nogle gange forsvinder problemet, og du kender ikke den sande oprindelse. Og endnu værre? Når du skal kæmpe mod disse problemer midt om natten eller i weekenden. Ikke alene forsøger du at løse et problem, men du mister også din personlige fritid. Hvordan afhjælper vi det? Hvordan tager vi vores tid og kræfter ud af ligningen og fikser ydeevnen på samme tid?
Funktionen Automatic Tuning i SQL Server 2017 Enterprise Edition og Azure SQL Database er det første skridt i at reducere den tid, dataprofessionelle bruger på at fejlfinde og løse ydeevneproblemer. Funktionen inkluderer automatisk plankorrektion og automatisk indeksstyring (kun tilgængelig i Azure SQL Database), som er aktiveret uafhængigt. I dette indlæg vil jeg fokusere på funktionen Automatisk plankorrektion. Med Automatic Plan Correction, hvis SQL Server opdager, at en forespørgsel er gået betydeligt tilbage, vil den tvinge den sidst kendte gode plan for forespørgslen til at stabilisere ydeevnen. I det væsentlige, i stedet for at du, DBA eller udvikler, bliver ringet op i weekenden om systemydelse, vil SQL Server løse det for dig. Det lyder for nemt, ikke? Lad os tage et kig.
Under dynen
For det første er det vigtigt at forstå, at automatisk plankorrektion bruger Query Store, så det skal være aktiveret for databasen. For det andet er automatisk plankorrektion simpelthen automatisk plantving. Mens Query Store er en markedsført som flight-recorder til din database, der sporer forespørgselstekst, planer, runtime-statistikker og ventestatistikker, giver den dig også mulighed for at gennemtvinge en plan for en forespørgsel for at tillade en ensartet ydeevne. Automatisk plankorrektion er planforcering uden din indgriben.
Aktivering af automatisk plankorrektion
Som nævnt skal Query Store først aktiveres for brugerdatabasen. Dette kan gøres i SSMS, med T-SQL og med REST API til Azure SQL DB. Bemærk, at Query Store er aktiveret som standard for databaser i Azure og har været det siden 2016 Q4.
Aktivering af Query Store via SSMS
USE [master]; GO ALTER DATABASE [WideWorldImporters] SET QUERY_STORE = ON; GO ALTER DATABASE [WideWorldImporters] SET QUERY_STORE (OPERATION_MODE = READ_WRITE); GO
Aktivering af Query Store ved hjælp af T-SQL
Ovenstående kode er standard T-SQL fra SSMS, hvis du scripter den ud. I Azure SQL Database kører du ikke USE-sætningen. Hvis du vil ændre nogen af standardindstillingerne, bedes du læse mit indlæg i Query Store Settings om, hvad disse muligheder er, og overvejelser om alternative værdier.
Når Query Store er aktiveret, kan du bruge Azure Portal, T-SQL eller EST API til at aktivere automatisk plankorrektion i Azure SQL Database ((og C# og PowerShell er under arbejde). Det kan kun aktiveres med T-SQL i SQL Server 2017.
Aktivering af automatisk plankorrektion i Azure Portal
ALTER DATABASE [WideWorldImporters] SET AUTOMATIC_TUNING ( FORCE_LAST_GOOD_PLAN = ON ); GO
Aktivering af automatisk plankorrektion i T-SQL
Bemærk, at automatisk plankorrektion vil blive aktiveret som standard for nye databaser i Azure i den nærmeste fremtid. Fra januar 2018 aktiveres Automatisk tuning for Azure SQL-databaser, der ikke allerede havde det aktiveret, med meddelelser sendt til administratorer, så indstillingen kan deaktiveres, hvis det ønskes.
Sådan fungerer det
Med automatisk plankorrektion aktiveret overvåger SQL Server forespørgselsydeevne ved hjælp af Query Store-data. Det ser ud til en væsentlig ændring* i CPU** ydeevne med et 48-timers vindue***. Læg mærke til stjernerne i den sætning... de er med vilje:
- *Tærsklen for, hvad der udgør en væsentlig ændring, er ikke dokumenteret, fordi Microsoft forbeholder sig retten til at ændre den.
- **Metricen, der bruges til at bestemme ændringen i ydeevne (CPU), er ikke dokumenteret, fordi Microsoft forbeholder sig retten til at ændre den. Det betyder, at Microsoft kunne overveje yderligere dimensioner for at se på ydeevnen, hvis det ville være bedre/præstere bedre end CPU alene.
- ***Den tidsperiode, hvori forespørgselsydeevnedataene sammenlignes, er ikke dokumenteret af samme årsag, Microsoft forbeholder sig retten til at ændre den.
- Bemærk:Selvom de førnævnte elementer ikke var dokumenterede, bekræftede jeg med de relevante personer hos Microsoft, at disse oplysninger kunne deles med at bryde enhver NDA. Det er ekstremt vigtigt at forstå, at værdierne ikke er faste og kan ændre sig med forventning om, at de ville ændre sig for at forbedre funktionens pålidelighed.
Manglen på dokumentation og muligheden for ændringer i tærskelværdien kan være frustrerende for nogle individer, men her er det, der er virkelig vigtigt at huske:
Microsoft fanger dagligt terabyte af operationelle telemetridata fra SQL Azure-databaser, og disse data er afgørende for de automatiske funktioner, der udvikles. Disse data inkluderer ting som query_id, query_plan_id og query_hash, og Microsoft fanger IKKE query_text eller query_plan (de ser ikke på dine faktiske data). Microsoft arkiverer ikke blot den operationelle telemetri eller bruger den til fejlfinding, de miner disse data og bruger dem til at udvikle algoritmer og modeller, der giver SQL Server mulighed for at træffe uafhængige, intelligente beslutninger.
SQL Server kan drage fordel af overfloden af data i Query Store, der beskriver ydelsen af forespørgsler, og automatisk plankorrektion starter med at sammenligne den nuværende ydeevne for en forespørgsel med tidligere ydeevne for at afgøre, om der er en regression i ydeevnen. Er ydeevnen faldet eller blevet dårligere, og er det i så fald væsentligt?
Hvis der har været en regression i forespørgselsydelsen, så vil SQL Server fremtvinge den sidst kendte gode plan for den forespørgsel, som naturligvis trækkes fra Query Store. Men det stopper ikke der. SQL Server fortsætter derefter med at overvåge ydeevnen - stadig ved hjælp af Query Store - for at bekræfte, at den tvungne plan stadig er en god plan for den forespørgsel, hvilket betyder, at forespørgslen med den tvungne plan yder bedre end den regresserede version. Hvis forespørgslen ikke fungerer bedre, vil den ophæve planen. En plan kan også være un-forced, hvis der er en rekompilering, eller hvis forcering mislykkes.
Denne cyklus fortsætter; hvis en forespørgsel har en tvungen plan, og den plan ikke er tvunget af en af de førnævnte årsager, kan den samme plan tvinges igen senere, eller der kan være en anden plan tvunget til den forespørgsel på et senere tidspunkt. Dette er en kontinuerlig proces, der finder sted, så længe du har muligheden for automatisk plankorrektion aktiveret for databasen. Nu, det interessante er, at du kan se på den samme information, som denne funktion fanger og bruge den til at forcere planer manuelt. Det vil sige, i SQL Server 2017 Enterprise Edition og i Azure SQL Database, bliver disse data indsamlet i sys.dm_db_tuning_recommendations DMV, selv når funktionen Automatic Plan Correction ikke er aktiveret, så du kan undersøge disse data og følge dens anbefalinger for at fremtvinge planer for specifikke forespørgsler på egen hånd. Bemærk, at hvis du tvinger en plan ved hjælp af anbefalinger fra sys.dm_db_tuning_recommendations, vil den aldrig automatisk blive ophævet. Yderligere, hvis du har automatisk plankorrektion aktiveret, og du manuelt gennemtvinger en plan, vil den aldrig automatisk blive ophævet. Kun planer, der er tvunget med funktionen Automatisk plankorrektion, vil automatisk blive ophævet.
Skal jeg virkelig lade SQL Server have kontrol?
Hvis du er skeptisk og spekulerer på, om du virkelig kan stole på, at SQL Server træffer en plan-tvingende beslutning, er her, hvad jeg vil opfordre dig til at huske:
- Denne funktion er udviklet med en svimlende mængde data, der er opsamlet fra næsten to millioner Azure SQL-databaser. Det er en ny funktion i SQL Server 2017, men den blev global tilgængelig i 2016 i Azure, så denne funktion har virkelig været tilgængelig i godt et år, og den er blevet forfinet.
- Ingeniørerne har foretaget ændringer i algoritmen over tid, da de har fanget flere data. Den finder måske ikke hver regression, der opstår – fordi en regression måske ikke er alvorlig nok, men jeg vil vædde på, at mange af jer hellere vil have denne funktionskraft sjældnere end for ofte.
- Oven i købet, hvis en plan tvinges, men ender med at forårsage et problem, er SQL Servers evne til at komme sig fra det og annullere planen ekstremt pålidelig og sker meget hurtigt.
Oversigt
Du er måske ikke tryg ved tanken om, at SQL Server løser ydeevneproblemer for dig. Men er det ubehag, fordi du tror, det vil tage en dårlig beslutning? Eller er du bekymret for, at automatisering overtager dit job? Ret direkte spørgsmål, jeg ved det. Hvis det er førstnævnte, så er min anbefaling at se på dataene, der er opsamlet i sys.dm_db_tuning_recommendations (uden at aktivere Automatic Plan Correction) og se, hvad SQL Server ønsker at gøre. Stemmer det med, hvad du ville gøre? Finder den regressioner, som du måske går glip af? Hvis du ikke vil aktivere funktionen, fordi du er bange for, at du pludselig ikke har nok at lave, opfordrer jeg dig til at læse Conor Cunninghams seneste indlæg, How cloud speed helps SQL Server DBAs. Microsoft forsøger ikke at kode dig ud af et job. De forsøger simpelthen at håndtere den lavthængende frugt, så du kan fokusere på vigtigere opgaver.