Конфигурации с обхват на базата данни на SQL Server и автоматична корекция на план

В тази статия ще разгледаме конфигурациите с обхват на базата данни и автоматичната корекция на плана на SQL Server 2017. Microsoft добави нови функции към SQL Server 2017, които подобриха производителността на заявката.

Производителността на заявката на SQL Server е свързана с качеството и точността на плана за изпълнение. Когато изпълняваме заявка, оптимизаторът на заявки анализира много планове за изпълнение и след това взема решение за оптималния план за изпълнение на заявка.

Оценка на наследената кардиналност: Инструментът за оценка на кардиналитета прогнозира колко реда ще върне заявката, както и определя разпределението на паметта на заявката.

В SQL Server 2017 версията на модела за оценка на мощността по подразбиране е 14.0, но ако искате да използвате по-старата версия 7.0 на Cardinality Estimator, можете да направите това, като промените опцията Legacy Cardinality Estimation в Конфигурации с обхват на базата данни раздел.

Стойността по подразбиране на оценката на наследената кардиналност е ИЗКЛ. Следователно, ако искате да използвате по-старата версия, трябва да я превключите на ВКЛ.

Като алтернатива можете да промените това свойство в T-SQL.

ПРОМЕНЯ КОНФИГУРАЦИЯ ЗА ОБХВАТ НА БАЗА ДАННИ LEGACY_CARDINALITY_ESTIMATION =ИЗКЛ.|ВКЛ.;

Ако обаче активирате тази настройка, тя ще засегне всички заявки. В резултат на това това може да повреди производителността на заявката. За да предотвратите това, можете да използвате съвета FORCE_LEGACY_CARDINALITY_ESTIMATION.

Когато изпълним тази заявка в базата данни WideWorldImporters, тя автоматично ще използва нова версия на оценката за мощността.

ИЗБЕРЕТЕ [o].[CustomerID], o.LastEditedBy , [o].[OrderDate] FROM Sales.Orders OWHERE [o].[OrderDate]>='20140101'

Когато добавим FORCE_LEGACY_CARDINALITY_ESTIMATION към заявката, оптимизаторът на заявки ще използва предишната или най-старата версия на оценката за мощността.

MAXDOP : можем да зададем максимална степен на паралелизъм за отделна база данни. Преди да бъде създадена тази функция, можехме да конфигурираме само нивото на сървъра MAXDOP.

Подсказката за заявка MAXDOP ни позволява да изпълняваме заявки паралелно.

ПРОМЕНЯ КОНФИГУРАЦИЯ ЗА ОБХВАТ НА БАЗА ДАННИ MAXDOP =4; ОТПРАВИ

Подушване на параметри: Когато времето за изпълнение на заявката се промени драстично и тази промяна на времето е свързана с параметъра на заявката, това се нарича подслушване на параметър.

Сега ще създадем съхранена процедура в базата данни на AdventureWorks. Ще изпратим различни параметри и ще сравним планове за изпълнение.

ОТПУСКАНЕ ПРОЦЕДУРА, АКО СЪЩЕСТВУВА Get_OrdersGOCREATE PROCEDURE Get_Orderes@ProductID INTASSELECT SalesOrderDetailID, OrderQtyFROM Sales.SalesOrderDetailWHERE ProductID =@ProductID;GO/******* Не използвайте този скрипт в производствени сървъри!*******/ DBCC FREEPROCCACHE--Запитване на MarsEXEC Get_OrderID_OrderQty @ProductID=870DBCC FREEPROCCACHE--Заявка за VenusEXEC Get_OrderID_OrderQty @ProductID=897

Както е показано на изображението по-долу, SQL Server генерира различен план за изпълнение за същата заявка. Планът за изпълнение на Query Mars препоръчва индекс. Параметърът на заявката променя оптималния план за изпълнение.

Изпълнете тази заявка и вижте плановете за изпълнение.

DBCC FREEPROCCACHE--Запитване на MarsEXEC Get_OrderID_OrderQty @ProductID=870--Заявка за VenusEXEC Get_OrderID_OrderQty @ProductID=897

Планът за изпълнение на Query Venus е същият като плана за изпълнение на Query Mars. Това е подслушването на параметъра, защото кешираният план за изпълнение се компилира за плана за изпълнение на Query Mars. Поради тази причина Query Venus използва същия план за изпълнение.

Сега ще деактивираме подслушването на параметри и ще изпълним същите заявки.

ПРОМЕНЯ КОНФИГУРАЦИЯ ЗА ОБХВАТ НА БАЗА ДАННИ PARAMETER_SNIFFING =OFF;DBCC FREEPROCCACHE--Заявка MarsEXEC Get_OrderID_OrderQty @ProductID=870--Query VenusEXEC Get_OrderID_OrderQty @Product=87
Нека да разгледаме:

Оптимизаторът на заявки на SQL Server генерира оптималния план за изпълнение за Query Venus и Query Mars. Този подход осигурява оптимална производителност на заявката.

Има някои опции за избягване на този проблем:

ОПЦИЯ(ПРЕКОМПИЛИРАНЕ)

ОПЦИЯ (ОПТИМИЗИРАНЕ ЗА(@VARIABLE=UNKNOWN))

Автоматична корекция на план

SQL Server 2017 включва нова функция, наречена автоматична корекция на плана. Когато изпълняваме заявка, оптимизаторът на заявки създава план за изпълнение. По някои причини оптимизаторът на заявки избира грешни планове за изпълнение. Някои от причините са следните:

Заявка, която не отговаря на критериите за ефективност

Неактуална статистика

Неподходящи индекси

Когато оптимизаторът на заявки на SQL Server реши да промени плана за изпълнение и този план за изпълнение уврежда производителността, производителността на заявката се нарича регресия на плана. Нова функция идва с SQL Server 2016. Този инструмент помага при наблюдение и отстраняване на неизправности на производителността на заявката и в същото време съхранява показатели за ефективност и броячи на изпълнението на заявката.

Можем да активираме тези опции в свойствата на базата данни.

Сега ще направим демонстрация на тази функция. Първо, изчистете кеша на процедурите и създайте съхранена процедура.

/********************************************* Не използвайте този скрипт в производствени сървъри**********************************************/ИЗПОЛЗВАЙТЕ WideWorldImportersALTER DATABASE WideWorldImporters SET QUERY_STORE =ВКЛЮЧЕНО; ALTER DATABASE [WideWorldImporters] SET QUERY_STORE CLEAR ALLDBCC FREEPROCCACHE --Тази команда ще изчисти целия кеш на процедурите в SQL Server. Не се опитвайте в производството на изпращане-- ПРОМЕНИ БАЗА ДАННИ WideWorldImporters SET AUTOMATIC_TUNING (FORCE_LAST_GOOD_PLAN =OFF); ПРОЦЕДУРА ОТПУСКАНЕ, АКО СЪЩЕСТВУВА Test_CoddingSight2 GO CREATE PROC Test_CoddingSight2 @Id AS INT AS изберете sum([UnitPrice]*[Quantity]) от Sales.OrderLines O INNER JOIN sales.Orders o1 ON o1.OrderID =opeID =o.OrderID =o. ID

На тази стъпка ще изпълним тази процедура с различни параметри и ще намерим разликата във времето на изпълнение.

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

Както можете да видите, първата заявка е изпълнена за 12 секунди, а втората е направена за 33 секунди. Причината за тази драматична разлика е, че оптимизаторът на заявки избира неподходящ план за изпълнение за Query Beta.

Нека сравним плановете за изпълнение на Query Alpha и Query Beta.

План за изпълнение на заявка Alpha

План за изпълнение на Query Beta

В изображенията по-горе оптимизаторът на заявки създава различни планове за изпълнение за една и съща заявка. Когато разгледаме Най-използващите ресурси заявки , можем да видим, че Query Beta консумира повече ресурси от Query Alpha.

Заявката по-долу ще върне подробна информация за препоръките за настройка.

ИЗБЕРЕТЕ име, причина, резултат,JSON_VALUE(подробности, '$.implementationDetails.script') като скрипт, подробности.* ОТ sys.dm_db_tuning_recommendations КРЪСТ ПРИЛОЖИ OPENJSON(подробности, '$.planForceDetails') С ( query'$id в .queryId', regressed_plan_id int '$.regressedPlanId', last_good_plan_id int '$.recommendedPlanId') като подробностиWHERE JSON_VALUE(state, '$.currentValue') ='Активен'

Колоната за причина показва защо трябва да приложим тази препоръка.

Сега ще стартираме повторно Query Alpha и Query Beta с активирана автоматична корекция на плана.

/********************************************* Не използвайте този скрипт в производствени сървъри**********************************************/ALTER DATABASE [WideWorldImporters] SET QUERY_STORE CLEAR ALLDBCC FREEPROCCACHE /**************************************** Активиране на автоматичната корекция на плана *****************************************/ ПРОМЕНИ БАЗА ДАННИ WideWorldImporters НАСТРОЙТЕ AUTOMATIC_TUNING (FORCE_LAST_GOOD_PLAN =НА); --Query AlphaDBCC FREEPROCCACHE EXEC Test_CoddingSight2 7GO 80DBCC FREEPROCCACHE EXEC Test_CoddingSight2 -1--Query BetaEXEC Test_CoddingSight2 7GO 80

След тази демонстрация планът за изпълнение на Query Alpha се прилага към Query Beta. Освен това времената за изпълнение на заявка Alpha и Query Beta са близки едно до друго. Заявката по-долу ще върне състоянието на автоматичната корекция на плана.

ИЗБЕРЕТЕ име, причина, резултат,JSON_VALUE(state, '$.currentValue') като състояние,JSON_VALUE(подробности, '$.implementationDetails.script') като скрипт, подробности.* ОТ sys.dm_db_tuning_recommendations КРЪСТ ПРИЛОЖИ OPENJSON(подробности , '$.planForceDetails') WITH ( query_id int '$.queryId', regressed_plan_id int '$.regressedPlanId', last_good_plan_id int '$.recommendedPlanId') като подробностиWHERE JSON_VALUE.(state, '$erifying, 'lu'$erifying' /предварително>

Също така можем да намерим графична информация в Запитвания с принудителни планове . Тази графика дефинира плановете за принудително запитване и заявката.

Препратки

Автоматична корекция на плана в SQL Server 2017

Оценка на кардиналност