SQL Server-databaseomfangede konfigurationer og automatisk plankorrektion

I denne artikel vil vi undersøge Database Scoped Configurations og SQL Server 2017 Automatic Plan Correction. Microsoft tilføjede nye funktioner til SQL Server 2017, der forbedrede forespørgselsydeevnen.

SQL Server-forespørgselsydeevne er relateret til kvalitet og nøjagtighed af eksekveringsplanen. Når vi kører en forespørgsel, analyserer forespørgselsoptimeringsværktøjet en masse eksekveringsplaner og beslutter derefter den optimale forespørgselsudførelsesplan.

Ældre kardinalitetsvurdering: Cardinality Estimator forudsiger, hvor mange rækker forespørgslen vil returnere, samt bestemmer hukommelsesallokeringen for forespørgslen.

I SQL Server 2017 er standardversionen af ​​Cardinality Estimator Model Version 14.0, men hvis du vil bruge den ældre version 7.0 af Cardinality Estimator, kan du gøre dette ved at ændre indstillingen Legacy Cardinality Estimation i Database Scoped Configurations stærk> afsnit.

Standardværdien for Legacy Cardinality Estimation er FRA. Så hvis du vil bruge den ældre version, skal du slå den til ON.

Alternativt kan du ændre denne egenskab i T-SQL.

ALTER DATABASE SCOPED CONFIGURATION SET LEGACY_CARDINALITY_ESTIMATION =FRA|TIL;

Men hvis du aktiverer denne indstilling, vil det påvirke alle forespørgsler. Som følge heraf kan dette skade forespørgselsydeevnen. For at forhindre dette kan du bruge FORCE_LEGACY_CARDINALITY_ESTIMATION tippet.

Når vi kører denne forespørgsel i WideWorldImporters-databasen, vil den automatisk bruge en ny version af kardinalitetsestimatet.

VÆLG [o].[CustomerID], o.LastEditedBy , [o].[OrderDate] FRA Sales.Orders oWHERE [o].[OrderDate]>='20140101'

Når vi tilføjer FORCE_LEGACY_CARDINALITY_ESTIMATION til forespørgslen, vil forespørgselsoptimeringsværktøjet bruge den tidligere eller ældste version af kardinalitetsestimatet.

MAXDOP : vi kan indstille den maksimale grad af parallelitet for en individuel database. Før denne funktion var blevet oprettet, kunne vi kun konfigurere MAXDOP-serverniveauet.

MAXDOP-forespørgselstip giver os mulighed for at køre forespørgsler parallelt.

ÆNDR DATABASE OMFANG KONFIGURATIONSSÆT MAXDOP =4; GÅ

Parametersniffing: Når en forespørgselsudførelsestid ændrer sig dramatisk, og denne tidsændring er relateret til forespørgselsparameteren, kaldes det en parametersniffing.

Nu vil vi oprette en lagret procedure på AdventureWorks-databasen. Vi sender forskellige parametre og sammenligner udførelsesplaner.

DROP PROCEDURE HVIS FINDER Get_OrdersGOCREATE PROCEDURE Get_Orderes@ProductID INTASSELECT SalesOrderDetailID, OrderQtyFROM Sales.SalesOrderDetailWHERE ProductID =@ProductID;GO/*******Brug ikke dette script i produktionsservere!*******/ DBCC FREEPROCCACHE--Forespørgsel MarsEXEC Get_OrderID_OrderQty @ProductID=870DBCC FREEPROCCACHE--Forespørgsel VenusEXEC Get_OrderID_OrderQty @ProductID=897

Som vist på billedet nedenfor, genererer SQL Server en anden eksekveringsplan for den samme forespørgsel. Query Mars-udførelsesplanen anbefaler et indeks. Forespørgselsparameteren ændrer den optimale udførelsesplan.

Udfør denne forespørgsel og se på udførelsesplanerne.

DBCC FREEPROCCACHE--Forespørgsel MarsEXEC Get_OrderID_OrderQty @ProductID=870--Forespørgsel VenusEXEC Get_OrderID_OrderQty @ProductID=897

Query Venus-udførelsesplanen er den samme som Query Mars-udførelsesplanen. Dette er parameteren sniffning, fordi den cachelagrede eksekveringsplan er kompileret til Query Mars eksekveringsplanen. Af denne grund bruger Query Venus den samme eksekveringsplan.

Nu vil vi deaktivere parametersniffing og køre de samme forespørgsler.

ÆNDR DATABASE OMFANG KONFIGURATIONSSÆT PARAMETER_SNIFFING =OFF;DBCC FREEPROCCACHE--Forespørg MarsEXEC Get_OrderID_OrderQty @ProductID=870--Forespørg VenusEXEC Get_OrderID_OrderQty @ProductID=897

Lad os undersøge:

SQL Server Query Optimizer genererede den optimale udførelsesplan for Query Venus og Query Mars. Denne tilgang giver den optimale ydeevne til forespørgslen.

Der er nogle muligheder for at undgå dette problem:

• MULIGHED (GENKOMPILER)
• MULIGHED (OPTIMER FOR(@VARIABLE=UKENDT))

Automatisk plankorrektion

SQL Server 2017 indeholder en ny funktion kaldet Automatic Plan Correction. Når vi udfører en forespørgsel, opretter forespørgselsoptimeringsværktøjet en eksekveringsplan. Af nogle grunde vælger forespørgselsoptimeringsværktøjet forkerte eksekveringsplaner. Nogle af årsagerne er som følger:

• En forespørgsel, der ikke opfylder ydeevnekriterierne
• Forældede statistikker
• Uegnede indekser

Når SQL Server-forespørgselsoptimeringsværktøjet beslutter at ændre eksekveringsplanen, og denne eksekveringsplan skader ydeevnen, kaldes forespørgselsydeevnen planregression. En ny funktion kommer med SQL Server 2016. Dette værktøj hjælper med at overvåge og fejlfinde forespørgselsydeevne og gemmer samtidig ydeevnemålinger og tællere for forespørgselsudførelsen.

Vi kan aktivere disse muligheder under databaseegenskaber.

Nu skal vi lave en demo af denne funktion. Først og fremmest skal du rydde procedurecachen og oprette en lagret procedure.

/****************************************Brug ikke dette script i produktionsservere*******************************************/BRUG WideWorldImportersALTER DATABASE WideWorldImporters SET QUERY_STORE =TIL; ALTER DATABASE [WideWorldImporters] SET QUERY_STORE RYD ALLDBCC FREEPROCCACHE --Denne kommando vil rydde al procedurecache i SQL Server. Forsøg ikke i produktionen envoierment-- ALTER DATABASE WideWorldImporters SET AUTOMATIC_TUNING (FORCE_LAST_GOOD_PLAN =OFF); DROP PROCEDURE HVIS EKSISTERER Test_CoddingSight2 GÅ OPRET PROC Test_CoddingSight2 @Id AS INT AS vælg sum([Enhedspris]*[Antal]) fra Sales.Ordrelinjer O INNER JOIN salg.Ordrer o1 PÅ o1.OrdreID =o.OrdreID hvor o.Pakke Id

På dette trin vil vi udføre denne procedure med forskellige parametre og finde udførelsestidsforskellen.

--Forespørgsel AlphaDBCC FREEPROCCACHE EXEC Test_CoddingSight2 7GO 80DBCC FREEPROCCACHE EXEC Test_CoddingSight2 -1--Query BetaEXEC Test_CoddingSight2 7GO 80

Som du kan se, blev den første forespørgsel gennemført på 12 sek., mens den anden blev udført på 33 sek. Årsagen til denne dramatiske forskel er, at forespørgselsoptimeringsværktøjet vælger en uegnet eksekveringsplan for forespørgsel beta.

Lad os sammenligne udførelsesplanerne for Query Alpha og Query Beta.

Udførelsesplan for Query Alpha

Eksekveringsplan for Query Beta

På billederne ovenfor opretter forespørgselsoptimeringsværktøjet forskellige eksekveringsplaner for den samme forespørgsel. Når vi ser på Top ressourceforbrugende forespørgsler , kan vi se, at Query Beta bruger flere ressourcer end Query Alpha.

Nedenstående forespørgsel vil returnere detaljerede oplysninger om indstillingsanbefalingerne.

VÆLG navn, årsag, score,JSON_VALUE(detaljer, '$.implementationDetails.script') som script, detaljer.* FRA sys.dm_db_tuning_recommendations KRYDS ANVEND OPENJSON(detaljer, '$.planForceDetails') MED ( query_id int '$ .queryId', regressed_plan_id int '$.regressedPlanId', last_good_plan_id int '$.recommendedPlanId') as detailsWHERE JSON_VALUE(state, '$.currentValue') ='Aktiv'

Årsagskolonnen viser, hvorfor vi er nødt til at anvende denne anbefaling.

Nu vil vi køre Query Alpha og Query Beta igen med den automatiske plankorrektion aktiveret.

/****************************************Brug ikke dette script i produktionsservere*******************************************/ALTER DATABASE [WideWorldImporters] SÆT QUERY_STORE RYD ALLDBCC FREEPROCCACHE /*********************************************Aktivér automatisk plankorrektion *****************************************/ALTER DATABASE WideWorldImporters SET AUTOMATIC_TUNING (FORCE_LAST_GOOD_PLAN =PÅ); --Forespørgsel AlphaDBCC FREEPROCCACHE EXEC Test_CoddingSight2 7GO 80DBCC FREEPROCCACHE EXEC Test_CoddingSight2 -1--Query BetaEXEC Test_CoddingSight2 7GO 80

Efter denne demo anvendes Query Alpha-udførelsesplanen på Query Beta. Derudover er udførelsestiderne for Query Alpha og Query Beta tæt på hinanden. Nedenstående forespørgsel returnerer status for automatisk plankorrektion.

VÆLG navn, årsag, score,JSON_VALUE(stat, '$.currentValue') som status,JSON_VALUE(detaljer, '$.implementationDetails.script') som script, detaljer.* FRA sys.dm_db_tuning_recommendations KRYDS ANVEND OPENJSON(detaljer , '$.planForceDetails') MED ( query_id int '$.queryId', regressed_plan_id int '$.regressedPlanId', last_good_plan_id int '$.recommendedPlanId') som detaljerWHERE JSON_VALUE(state, '$.currentVerifying') 

 
 

 Vi kan også finde nogle grafiske oplysninger i Forespørgsler med tvungne planer . Denne graf definerer de tvungne forespørgselsplaner og forespørgsel.
 

 
 

 Referencer 
 

 Automatisk plankorrektion i SQL Server 2017
 

 Kardinalitetsvurdering