I den här artikeln kommer vi att undersöka Database Scoped Configurations och SQL Server 2017 Automatic Plan Correction. Microsoft lade till nya funktioner i SQL Server 2017 som förbättrade frågeprestanda.
SQL Server-frågeprestanda är relaterad till kvalitet och noggrannhet hos exekveringsplanen. När vi kör en fråga analyserar frågeoptimeraren många exekveringsplaner och beslutar sedan om den optimala frågeexekveringsplanen.
Uppskattning av äldre kardinalitet: Cardinality Estimator förutsäger hur många rader frågan kommer att returnera, samt bestämmer minnesallokeringen för frågan.
I SQL Server 2017 är standardversionen av Cardinality Estimation Model Version 14.0, men om du vill använda den äldre versionen 7.0 av Cardinality Estimator kan du göra detta genom att ändra alternativet Legacy Cardinality Estimation i Databas Scoped Configurations stark> avsnitt.
Standardvärdet för den äldre kardinalitetsuppskattningen är AV. Så om du vill använda den äldre versionen måste du sätta den på PÅ.
Alternativt kan du ändra den här egenskapen i T-SQL.
ÄNDRA DATABAS OMFATTAD KONFIGURATIONSSÄTT LEGACY_CARDINALITY_ESTIMATION =AV|PÅ;
Men om du aktiverar den här inställningen kommer det att påverka alla frågor. Som ett resultat kan detta skada frågeprestandan. För att förhindra detta kan du använda tipset FORCE_LEGACY_CARDINALITY_ESTIMATION.
När vi kör den här frågan i WideWorldImporters-databasen kommer den automatiskt att använda en ny version av kardinalitetsuppskattningen.
VÄLJ [o].[CustomerID], o.LastEditedBy , [o].[OrderDate] FROM Sales.Orders oWHERE [o].[OrderDate]>='20140101'
När vi lägger till FORCE_LEGACY_CARDINALITY_ESTIMATION i frågan kommer frågeoptimeraren att använda den tidigare eller äldsta versionen av kardinalitetsuppskattningen.
MAXDOP : vi kan ställa in den maximala graden av parallellitet för en enskild databas. Innan den här funktionen hade skapats kunde vi bara konfigurera MAXDOP-servernivån.
MAXDOP-frågetipset låter oss köra frågor parallellt.
ÄNDRA DATABAS OMFATTAD KONFIGURATIONSSÄTT MAXDOP =4; GÅ
Parametersniffning: När en frågekörningstid ändras dramatiskt och denna tidsförändring är relaterad till frågeparametern, kallas det parametersniffning.
Nu kommer vi att skapa en lagrad procedur på AdventureWorks-databasen. Vi kommer att skicka olika parametrar och jämföra genomförandeplaner.
DROPP PROCEDUR OM FINNS Get_OrdersGOCREATE PROCEDURE Get_Orderes@ProductID INTASSELECT SalesOrderDetailID, OrderQtyFROM Sales.SalesOrderDetailWHERE ProductID =@ProductID;GO/*******Använd inte detta skript i produktionsservrar!*******/ DBCC FREEPROCCACHE--Fråga MarsEXEC Get_OrderID_OrderQty @ProductID=870DBCC FREEPROCCACHE--Fråga VenusEXEC Get_OrderID_OrderQty @ProductID=897
Som visas i bilden nedan genererar SQL Server en annan exekveringsplan för samma fråga. Query Mars exekveringsplan rekommenderar ett index. Frågeparametern ändrar den optimala exekveringsplanen.
Kör den här frågan och titta på exekveringsplanerna.
DBCC FREEPROCCACHE--Fråga MarsEXEC Get_OrderID_OrderQty @ProductID=870--Fråga VenusEXEC Get_OrderID_OrderQty @ProductID=897
Query Venus exekveringsplan är densamma som Query Mars exekveringsplan. Detta är parametern sniffning eftersom den cachade exekveringsplanen kompileras för Query Mars exekveringsplan. Av denna anledning använder Query Venus samma exekveringsplan.
Nu kommer vi att inaktivera parametersniffning och köra samma frågor.
ÄNDRA DATABAS OMFATTAD KONFIGURATIONSSÄTT PARAMETER_SNIFFING =AV;DBCC FREEPROCCACHE--Fråga MarsEXEC Get_OrderID_OrderQty @ProductID=870--Fråga VenusEXEC Get_OrderID_OrderQty @ProductID=897
Låt oss undersöka:
SQL Server Query Optimizer genererade den optimala exekveringsplanen för Query Venus och Query Mars. Detta tillvägagångssätt ger den optimala prestandan för frågan.
Det finns några alternativ för att undvika det här problemet:
- ALTERNATIV(OMKOMPILERA)
- ALTERNATIV (OPTIMERA FÖR(@VARIABLE=OKÄNT))
Automatisk plankorrigering
SQL Server 2017 innehåller en ny funktion som heter Automatic Plan Correction. När vi kör en fråga skapar frågeoptimeraren en exekveringsplan. Av vissa skäl väljer frågeoptimeraren felaktiga exekveringsplaner. Några av anledningarna är följande:
- En fråga som inte uppfyller resultatkriterierna
- Inaktuell statistik
- Olämpliga index
När SQL Server-frågeoptimeraren bestämmer sig för att ändra exekveringsplanen och denna exekveringsplan skadar prestandan, kallas frågeprestandan planregression. En ny funktion kommer med SQL Server 2016. Det här verktyget hjälper till att övervaka och felsöka frågeprestanda och samtidigt lagra prestandamått och räknare för frågekörningen.
Vi kan aktivera dessa alternativ under databasegenskaper.
Nu ska vi göra en demo av denna funktion. Rensa först och främst procedurcachen och skapa en lagrad procedur.
/****************************************Använd inte det här skriptet i produktionsservrar*******************************************/ANVÄND WideWorldImportersALTER DATABASE WideWorldImporters SET QUERY_STORE =PÅ; ALTER DATABASE [WideWorldImporters] SET QUERY_STORE RENSA ALLDBCC FREEPROCCACHE --Detta kommando rensar all procedurcache i SQL Server. Försök inte i produktionsangivelse-- ALTER DATABASE WideWorldImporters SET AUTOMATIC_TUNING (FORCE_LAST_GOOD_PLAN =OFF); SLÄPP PROCEDUR OM FINNS Test_CoddingSight2 GÅ SKAPA PROC Test_CoddingSight2 @Id AS INT AS välj summa([Enhetspris]*[Quantity]) från Sales.OrderLines O INNER JOIN sales.Orders o1 ON o1.OrderID =o.OrderType där o.ID ID
I det här steget kommer vi att köra denna procedur med olika parametrar och hitta skillnaden i körtid.
--Fråga AlphaDBCC FREEPROCCACHE EXEC Test_CoddingSight2 7GO 80DBCC FREEPROCCACHE EXEC Test_CoddingSight2 -1--Query BetaEXEC Test_CoddingSight2 7GO 80
Som du kan se slutfördes den första frågan på 12 sek, medan den andra gjordes på 33 sek. Anledningen till denna dramatiska skillnad är att frågeoptimeraren väljer en olämplig exekveringsplan för Query Beta.
Låt oss jämföra exekveringsplanerna för Query Alpha och Query Beta.
Exekveringsplan för Query Alpha
Utförandeplan för Query Beta
I bilderna ovan skapar frågeoptimeraren olika exekveringsplaner för samma fråga. När vi tittar på Bästa resurser som konsumerar frågor , kan vi se att Query Beta förbrukar mer resurser än Query Alpha.
Frågan nedan kommer att returnera detaljerad information om inställningsrekommendationerna.
VÄLJ namn, anledning, poäng, JSON_VALUE(detaljer, '$.implementationDetails.script') som skript, detaljer.* FRÅN sys.dm_db_tuning_recommendations KRYSS ANVÄND 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'
Anledningskolumnen visar varför vi måste tillämpa denna rekommendation.
Nu kommer vi att köra Query Alpha och Query Beta igen med den automatiska plankorrigeringen aktiverad.
/****************************************Använd inte det här skriptet i produktionsservrar*******************************************/ALTER DATABASE [WideWorldImporters] STÄLL IN QUERY_STORE RENSA ALLDBCC FREEPROCCACHE /*********************************************Aktivera automatisk plankorrigering *****************************************/ALTER DATABASE WideWorldImporters SET AUTOMATIC_TUNING (FORCE_LAST_GOOD_PLAN =PÅ); --Query AlphaDBCC FREEPROCCACHE EXEC Test_CoddingSight2 7GO 80DBCC FREEPROCCACHE EXEC Test_CoddingSight2 -1--Query BetaEXEC Test_CoddingSight2 7GO 80
Efter denna demo tillämpas Query Alpha-exekveringsplanen på Query Beta. Dessutom är körtiderna för Query Alpha och Query Beta nära varandra. Frågan nedan returnerar status för automatisk plankorrigering.
VÄLJ namn, anledning, poäng, JSON_VALUE(tillstånd, '$.currentValue') som status,JSON_VALUE(detaljer, '$.implementationDetails.script') som skript, detaljer.* FRÅN sys.dm_db_tuning_recommendations CROSS APPLY OPENJSON(detaljer , '$.planForceDetails') WITH ( query_id int '$.queryId', regressed_plan_id int '$.regressedPlanId', last_good_plan_id int '$.recommendedPlanId') som detaljerWHERE JSON_VALUE(state, '$.currentValifying') /pre>
Vi kan också hitta en del grafisk information i Frågor med tvångsplaner . Det här diagrammet definierar de påtvingade frågeplanerna och frågan.
Referenser
Automatisk plankorrigering i SQL Server 2017
Kardinalitetsuppskattning
