V tomto článku prozkoumáme konfigurace v rozsahu databáze a automatickou opravu plánu SQL Server 2017. Microsoft přidal do SQL Server 2017 nové funkce, které zlepšily výkon dotazů.
Výkon dotazů SQL Server souvisí s kvalitou a přesností plánu provádění. Když spustíme dotaz, optimalizátor dotazů analyzuje mnoho plánů provádění a poté rozhodne o optimálním plánu provádění dotazů.
Starší odhad mohutnosti: Nástroj Cardinality Estimator předpovídá, kolik řádků dotaz vrátí, a také určuje alokaci paměti dotazu.
V SQL Server 2017 je výchozí verze modelu odhadu mohutnosti 14.0, ale pokud chcete použít starší verzi 7.0 nástroje pro odhad mohutnosti, můžete to provést změnou možnosti Odhad staršího mohutnosti v Konfiguracích s rozsahem databáze silný> sekce.
Výchozí hodnota odhadu Legacy Cardinality Estimation je VYPNUTO. Pokud tedy chcete používat starší verzi, musíte ji zapnout.
Alternativně můžete tuto vlastnost změnit v T-SQL.
ALTER DATABASE SCOPED CONFIGURATION SET LEGACY_CARDINALITY_ESTIMATION =OFF|ON;
Pokud však toto nastavení povolíte, ovlivní všechny dotazy. V důsledku toho to může poškodit výkon dotazu. Abyste tomu zabránili, můžete použít nápovědu FORCE_LEGACY_CARDINALITY_ESTIMATION.
Když spustíme tento dotaz v databázi WideWorldImporters, automaticky použije novou verzi odhadu mohutnosti.
SELECT [o].[CustomerID], o.LastEditedBy , [o].[OrderDate] FROM Sales.Orders oWHERE [o].[OrderDate]>='20140101'
Když k dotazu přidáme FORCE_LEGACY_CARDINALITY_ESTIMATION, optimalizátor dotazů použije předchozí nebo nejstarší verzi odhadu mohutnosti.
MAXDOP : můžeme nastavit maximální míru paralelismu pro jednotlivou databázi. Před vytvořením této funkce jsme mohli konfigurovat pouze úroveň serveru MAXDOP.
Nápověda k dotazu MAXDOP nám umožňuje spouštět dotazy paralelně.
ALTER DATABASE SCOPED CONFIGURATION SET MAXDOP =4; GO
Sniffování parametrů: Když se doba provádění dotazu dramaticky změní a tato změna času souvisí s parametrem dotazu, nazývá se to parametrické čichání.
Nyní vytvoříme uloženou proceduru v databázi AdventureWorks. Zašleme různé parametry a porovnáme prováděcí plány.
POSTUP ZRUŠIT, POKUD EXISTUJE Get_OrdersGCREATE PROCEDURE Get_Orderes@ProductID INTASSELECT SalesOrderDetailID, OrderQtyFROM Sales.SalesOrderDetailWHERE ProductID =@ProductID;GO/*******Nepoužívejte tento skript na produkčních serverech!*******/ DBCC FREEPROCCACHE--Query MarsEXEC Get_OrderID_OrderQty @ProductID=870DBCC FREEPROCCACHE--Query VenusEXEC Get_OrderID_OrderQty @ProductID=897
Jak je znázorněno na obrázku níže, SQL Server generuje jiný plán provádění pro stejný dotaz. Plán provádění Query Mars doporučuje index. Parametr dotazu mění optimální plán provádění.
Proveďte tento dotaz a podívejte se na prováděcí plány.
DBCC FREEPROCCACHE--Query MarsEXEC Get_OrderID_OrderQty @ProductID=870--Query VenusEXEC Get_OrderID_OrderQty @ProductID=897
Plán provádění Query Venus je stejný jako plán provádění Query Mars. Toto je parametr sniffing, protože plán provádění v mezipaměti je zkompilován pro plán provádění Query Mars. Z tohoto důvodu používá Query Venus stejný plán provádění.
Nyní deaktivujeme sniffování parametrů a spustíme stejné dotazy.
ALTER DATABASE SCOPED CONFIGURATION SET PARAMETER_SNIFFING =OFF;DBCC FREEPROCCACHE--Query MarsEXEC Get_OrderID_OrderQty @ProductID=870--Query VenusEXEC Get_OrderID_OrderQty @ProductID>=897Podívejme se:
Optimalizátor dotazů SQL Server vygeneroval optimální plán provádění pro Query Venus a Query Mars. Tento přístup poskytuje dotazu optimální výkon.
Existuje několik možností, jak se tomuto problému vyhnout:
- OPTION(REKOMPILOVAT)
- MOŽNOST (OPTIMIZE FOR(@VARIABLE=UNKNOWN))
Automatická oprava plánu
SQL Server 2017 obsahuje novou funkci s názvem Automatic Plan Correction. Když spustíme dotaz, optimalizátor dotazů vytvoří plán provádění. Z některých důvodů optimalizátor dotazů zvolí nesprávné plány provádění. Některé z důvodů jsou následující:
- Dotaz, který nesplňuje kritéria výkonu
- Neaktuální statistiky
- Nevhodné indexy
Když se optimalizátor dotazů SQL Server rozhodne změnit plán provádění a tento plán provádění poškodí výkon, výkon dotazu se nazývá regrese plánu. S SQL Server 2016 přichází nová funkce. Tento nástroj pomáhá při monitorování a odstraňování problémů s výkonem dotazů a zároveň ukládá metriky výkonu a počítadla provádění dotazu.
Tyto možnosti můžeme povolit ve vlastnostech databáze.
Nyní uděláme ukázku této funkce. Nejprve vymažte mezipaměť procedur a vytvořte uloženou proceduru.
/********************************************* Tento skript nepoužívejte v produkční servery*******************************************/POUŽÍVEJTE WideWorldImportersALTER DATABASE WideWorldImporters SET QUERY_STORE =ON; ALTER DATABASE [WideWorldImporters] SET QUERY_STORE CLEAR ALLDBCC FREEPROCCACHE --Tento příkaz vymaže veškerou mezipaměť procedur na serveru SQL Server. Nezkoušejte v produkčním envoierment-- ALTER DATABASE WideWorldImporters SET AUTOMATIC_TUNING (FORCE_LAST_GOOD_PLAN =OFF); POKUD EXISTUJE Test_CoddingSight2 PŘEJDĚTE VYTVOŘIT PROC Test_CoddingSight2 @Id JAKO INT JAKO vyberte součet ([JednotkováCena]*[Quantity]) z Sales.OrderLines O VNITŘNÍ PŘIPOJENÍ k prodeji.Orders o1 ON o1.OrderID =o.ID objednávky kde o.PaID ID
V tomto kroku provedeme tento postup s různými parametry a najdeme rozdíl v čase provedení.
--Query AlphaDBCC FREEPROCCACHE EXEC Test_CoddingSight2 7GO 80DBCC FREEPROCCACHE EXEC Test_CoddingSight2 -1--Query BetaEXEC Test_CoddingSight2 7GO 80
Jak vidíte, první dotaz byl dokončen za 12 sekund, zatímco druhý byl dokončen za 33 sekund. Důvodem tohoto dramatického rozdílu je, že optimalizátor dotazů zvolil nevhodný plán provádění pro Query Beta.
Porovnejme plány provádění Query Alpha a Query Beta.
Plán provádění dotazu Alfa
Plán provádění Query Beta
Na obrázcích výše optimalizátor dotazů vytváří různé plány provádění pro stejný dotaz. Když se podíváme na Nejčastější dotazy týkající se zdrojů , můžeme vidět, že Query Beta spotřebovává více zdrojů než Query Alpha.
Níže uvedený dotaz vrátí podrobné informace o doporučeních pro ladění.
VYBERTE jméno, důvod, skóre,JSON_VALUE(podrobnosti, '$.implementationDetails.script') jako skript, podrobnosti.* Z sys.dm_db_tuning_recommendations POUŽIJTE KRÍŽEM OPENJSON(detaily, '$.planForceDetails') S (id dotazu int '$ .queryId', regressed_plan_id int '$.regressedPlanId', last_good_plan_id int '$.recommendedPlanId') jako podrobnostiWHERE JSON_VALUE(state, '$.currentValue') ='Aktivní'
Sloupec důvod ukazuje, proč musíme toto doporučení použít.
Nyní znovu spustíme Query Alpha a Query Beta s povolenou automatickou opravou plánu.
/********************************************* Tento skript nepoužívejte na produkčních serverech************************************************/ALTER DATABASE [WideWorldImporters] SET QUERY_STORE CLEAR ALLDBCC FREEPROCCACHE /************************************************** Povolit automatickou opravu plánu *****************************************/ALTER DATABASE WideWorldImporters SET AUTOMATIC_TUNING (FORCE_LAST_GOOD_PLAN =NA); --Query AlphaDBCC FREEPROCCACHE EXEC Test_CoddingSight2 7GO 80DBCC FREEPROCCACHE EXEC Test_CoddingSight2 -1--Query BetaEXEC Test_CoddingSight2 7GO 80
Po této ukázce se plán provádění Query Alpha použije na Query Beta. Časy provádění dotazu Alpha a Query Beta jsou navíc blízko sebe. Níže uvedený dotaz vrátí stav automatické opravy plánu.
VYBERTE název, důvod, skóre,JSON_VALUE(stav, '$.currentValue') jako stav,JSON_VALUE(podrobnosti, '$.implementationDetails.script') jako skript, podrobnosti.* Z sys.dm_db_tuning_recommendations VŘÍZNĚ POUŽÍT OPENJSON(podrobnosti , '$.planForceDetails') S (query_id int '$.queryId', regressed_plan_id int '$.regressedPlanId', last_good_plan_id int '$.recommendedPlanId') jako podrobnosti WHERE JSON_VALUE'(stav, 'ue$'.currentV) /před>
Některé grafické informace také najdeme v Dotazy s vynucenými plány . Tento graf definuje plány vynucených dotazů a dotaz.
Odkazy
Automatická oprava plánu v SQL Server 2017
Odhad mohutnosti
