Изследване на GUI на SQL Server 2016 Query Store

Въведение

Съхранението на заявки е нова функция, въведена в SQL Server 2016, която позволява на администраторите на бази данни да преглеждат исторически заявки и свързаните с тях планове, използвайки графичния интерфейс, наличен в SQL Server Management Studio, както и да анализират производителността на заявките, използвайки определени изгледи за динамично управление. Съхранението на заявки е опция за конфигурация с обхват на база данни и е достъпна за използване, ако нивото на съвместимост на въпросната база данни е 130.

Съхранението на заявки е подобно на такива технологии в платформата на базата данни на Oracle като автоматичното хранилище за работно натоварване (AWR). AWR улавя статистически данни за производителността в дори по-голям мащаб от Query Store и позволява на администратор на база данни да анализира исторически производителността. Такива концепции като период на задържане и ограничения за съхранение на събраните данни са налични в архитектурата на AWR, както и в хранилището на заявки. Следните ключови опции за конфигурация са налични, когато активирате Съхранение на заявки:

Режим на работа: Определя дали Query Store ще приема новозаснети данни (режим на четене и запис) или просто съхранява стари данни, налични за отчети (режим само за четене)
Интервал за изтриване на данни: Определя колко често буферите на паметта на Query Store се прехвърлят на диск. Припомнете си, че данните от хранилището на заявки се съхраняват в базата данни, където е активирано хранилището на заявки. Стойността по подразбиране е 15 минути.
Интервал за събиране на статистически данни: Определя колко често се събират статистически данни по време на изпълнение на магазина за заявки.
Максимален размер: Определя колко може да нарасне хранилището за статистика на хранилището на заявки. По подразбиране е 100 MB.
Режим за заснемане на магазина на заявки: Определя детайлността на улавянето на заявка. ВСИЧКИ, АВТОМАТИЧНО и НИЩО са наличните опции. Стойността по подразбиране е AUTO.
Режим за почистване според размера: Определя дали Query Store ще изтрие старите данни, когато се достигне максималният размер.
Праг на застояла заявка: Определя броя на дните, за които Query Store съхранява данни. Стойността по подразбиране е настроена на тридесет дни.

Фиг. 2 Опции за съхранение на заявки

Съхранението на заявки е функция с обхват на база данни, която може да бъде активирана или чрез GUI (SQL Server Management Studio) или чрез изпълнение на следната команда:

ПРОМЕНЯ БАЗА ДАННИ [WideWorldImporters] SET QUERY_STORE =ON;

Телеметрията на заявката, събрана от Query Store, се съхранява в системни таблици в базата данни, където е активирано Query Store.

Примерни заявки и отчети по подразбиране

Дотук всичко, което съм написал, е достъпно от много други източници; някои от тях могат да бъдат намерени в раздела за препратки.

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

Списък 1:Извличане на записи с помощта на специфичен филтър

използвайте WideWorldImportersgoselecta.ContactPersonID,a.OrderDate,a.DeliveryMethodID,a.Comments,b.OrderedOutersfromPurchasing.PurchaseOrders ainner join Purchasing.PurchaseOrderLines bon a.PurchaseOrderLines bon a.PurchaseOrderLines bon a.PurchaseOrderLines bon a.PurchaseOrderLines bon a.PurchaseOrderLines bon a.PurchaseOrderLines. предварително>

Списък 2:Извличане на записи с помощта на диапазон

Обърнете внимание на алтернативната версия на тези заявки, написани с главни букви:

Списък 1:Извличане на записи с помощта на специфичен филтър (Горни букви)

ИЗПОЛЗВАЙТЕ WIDEWORLDIMPORTERSGOSELECTA.CONTACTPERSONID,A.ORDERDATE,A.DELIVERYMETHODID,A.COMMENTS,B.ORDEREDOUTERSFROMPURCHASING.PURCHASEORDERS AINNER ПРИСЪЕДИНЕТЕ СЕ ПРИ PURCHASING.PURCHASEORDERLINES BON A.PURCHASEORDERLINES BON A.PURCHASEORDERLINES BON A.PURCHASEORDERLINES BON A.PURCHASEORDERLINES BON A.PURCHASEORDERLINES BON A.PURCHASEORDERLINES BON A.PURCHASEORDERLINES BON A.PURCHASEORDERLINES BON A.PURCHASEORDER LINES BON A.PURCHASEORDERLIS BON A.PURCHASEORDERLIS BON A.PURCHASEORDER LINIES. предварително>

Списък 2:Извличане на записи с помощта на диапазон (главен регистър)

Използвайте widorldimportersgoselecta.contactpersonid, a.orderdate, a.deliverymethodid, a.comments, b.orderedoutersformasing.purchaseOrders ainner се присъединява към закупуване.PurchaseOrderlines bon a.purchaseord =b.purchaseorddingidydwhere a.supplierreference като 'ml%'; /предварително>

Както можете да видите, изпълнихме тези заявки няколко пъти, използвайки ключовата дума GO. По този начин имаме известно количество данни, с което да работим. Първото нещо, което трябва да сме наясно, когато използваме Query Store за анализиране на производителността, е, че има шест отчета по подразбиране, вградени в SQL Server 2016 Query Store, както е показано на Фиг. 3.

Фиг. 3 Доклади за съхранение на заявки

Имената на отчетите са описани подробно в предишните статии, както и в документацията на Microsoft. Данните, предоставени от тези отчети, се извличат от ключовите изгледи за динамично управление, изброени по-долу:

Планирайте DMV статистически данни

sys.query_store_query_text – съдържа уникални текстове на заявки, изпълнени към базата данни
sys.query_store_plan – съдържа прогнозен план за заявката със статистически данни за времето за компилиране
sys.query_context_settings – съдържа някои уникални комбинации от плана, засягащи настройките, при които се изпълняват заявките
sys.query_store_query – записи на заявки, които се проследяват и принуждават отделно в хранилището на заявки

Статистика за времето на изпълнение DMVs

sys.query_store_runtime_stats_interval – Query Store разделя времето на автоматично генерирани времеви прозорци (интервали) и съхранява обобщени статистически данни за този интервал за всеки изпълнен план
sys.query_store_runtime_stats – съдържа обобщена статистика по време на изпълнение за изпълнени планове

Много повече подробности за това как да използвате тези DMV са налични в посочената документация на Microsoft. В тази статия просто ще използваме GUI предимно.

Както можете да видите от фиг. 4, ние преглеждаме отчета за общото потребление на ресурси, докато в следващия раздел ще се стесним до заявките, които изброихме по-рано, и данните, които можем да извлечем от тези прости заявки.

Фиг. 4 Отчет за общото потребление на ресурси

Анализиране на заявки с помощта на GUI

Няколко ключови неща трябва да се считат за полезни при използване на отчетите за магазина за заявки:

Можете да конфигурирате средата, като щракнете върху бутона, маркиран на Фиг. 4. Фиг. 5 ни показва подробностите, които можем да променим, за да отговарят на нашия случай на използване:критерии за връщане на данни, период от време и набор от данни за връщане. Например, ако искам да видя ясно идентификатора на заявката, свързан със заявките, които преглеждам, бих искал да намаля набора си от данни от Топ 25 по подразбиране до Топ 10, например.
Фиг. 5 Опции за конфигуриране на отчет

Фиг. 6 Топ 25 заявки, изпълнени на 1 май 2018 г.

Фиг. 7 Топ 10 заявки, изпълнени на 1 май 2018 г.
Лентовидните диаграми показват данни предимно с времето по оста x, но можете да направите разбивка на конкретна точка от данни, за да видите данни въз основа на идентификатори на заявка. Всеки идентификатор на заявка определя конкретна заявка. Важно е да се отбележи, че заявката се идентифицира уникално чрез хеширане на текста. По този начин заявка в малкия регистър се различава от същата заявка в главния. Това трябва да е общоизвестно:ad-hoc заявките са проблем за кеша на плана и също са лоши за хранилището на заявки както по отношение на използването на пространството, така и по отношение на правилния анализ.
Фиг. 8 Заявка в листинг 1 (малки букви, заявка 42480)

Фиг. 9 Заявка в листинг 3 (Горни букви, заявка 42490)
Третото важно наблюдение е фактът, че когато точка от данни е маркирана в зелено, подробният план за изпълнение, показан в долния панел, се отнася до тази точка от данни. На фиг. 7 тази точка от данни се отнася до идентификатор на заявка 42481, която изпълнихме по-рано (пълната заявка е показана в листинг 2). Задържането на мишката върху тази точка от данни показва заявката, нейния идентификатор и броя на плановете, свързани с тази заявка (вж. Фиг. 8).
Фиг. 10 Запитване 42481 Подробности

Нашата заявка беше изпълнена 1391 пъти, тъй като е точно уловена от Query Store и показана в оста y (брой на изпълнение) на лентата на фиг. 10. Отчетът се изтегляше, докато пакетът все още се изпълняваше. По този начин нямаме пълния брой (1500), който ни информира, че има улавяне на данни в реално време всеки път, когато се изпълнява заявка. От дясната страна също виждаме плана, който се използва за тези множество изпълнения (План 675). Можем да проверим това с помощта на заявката в листинг 5.

Обява 5

ИЗПОЛЗВАЙТЕ WideWorldImportersGOSELECT Txt.query_text_id, Txt.query_sql_text, Pl.plan_id, Qry.*FROM sys.query_store_plan КАТО PlJOIN sys.query_store_query КАТО Qry ON Pl.query_id =Qry.query_id =Qry.xquery_text_Qry. .query_text_idwhere Qry.query_id=42481;

Фиг. 11 ID на заявка и ID на план от DMV

Малко настройка

Нека да разгледаме друга заявка.

Когато изпълним заявката в листинг 6 и разгледаме подробностите от магазина на заявки, подробностите за плана за изпълнение разкриват, че се нуждаем от индекс, за да постигнем 51% подобрение.

Списък 6:Неоптимална заявка

ИЗБЕРЕТЕ TOP (1000) [OrderLineID] ,[OrderID] ,[StockItemID] ,[Description] ,[PackageTypeID] ,[Quantity] ,[UnitPrice] ,[TaxRate] ,[PickedQuantityComplete],[Layst]PihenEdit ] ,[LastEditedWhen] ОТ [WideWorldImporters].[Sales].[OrderLines] където unitPrice> 1000 GO 2000

Фиг. 12 Подробности за неоптимална заявка

Фиг. 13 Неоптимален план за изпълнение на заявка

След като създадем препоръчания индекс, използвайки израза в листинг 7, караме оптимизатора на заявки да генерира нов план за изпълнение. В този случай се очаква новият план за изпълнение да подобри производителността. Въпреки това, има случаи, в които определени промени могат да доведат до влошаване на производителността, като например значителни промени в обема на данни, които ефективно обезсилват статистическите данни или намаляват броя на индексите и т.н. Казва се, че такива заявки са регресирали в производителността и могат да бъдат проверени с помощта на отчета за регресирани заявки в хранилището на заявки.

Списък 7:Създаване на индекс

ИЗПОЛЗВАЙТЕ [WideWorldImporters]GOCREATE NONCLUSTERED INDEX [Custom_IX_UnitPrice]ВЪВ [Продажби].[OrderLines] ([UnitPrice])ВКЛЮЧВАТЕ([OrderLineID],[OrderID],[StockItemID],[StockItemID],[Package[Que],[Package,Tpe] ],[TaxRate],[PickedQuantity],[PickingCompletedWhen],[LastEditedBy],[LastEditedWhen])GO

Фиг. 14 Оптимизирана заявка (Промяна в плана за изпълнение)

Фиг. 15 Оптимизирана заявка (два плана)

Фиг. 16 Оптимизирана заявка (Принудителен план)

Когато има множество планове за заявка, както е показано на фиг. 14 и фиг. 16, можем да кажем на оптимизатора винаги да използва план, който избираме, като щракнете върху бутона Force Plan. Това беше малко досадна задача в предишните версии на SQL Server.

Както можете да видите от Фиг. 17, Query Store ни позволява да сравним различните планове, свързани със заявка, използвайки редица показатели.

Фиг. 17 Сравняване на планове за изпълнение

Отново можем да използваме заявката в листинг 8, за да проверим плановете, свързани с този идентификатор на заявка, използвайки DMV. (Вижте Фиг. 11)

Списък 8:Планове, свързани със заявка 42497

ИЗПОЛЗВАЙТЕ WideWorldImportersGOSELECT Txt.query_text_id, Txt.query_sql_text, Pl.plan_id, Qry.*FROM sys.query_store_plan КАТО PlJOIN sys.query_store_query КАТО Qry ON Pl.query_id =Qry.query_id =Qry.xquery_text_Qry. .query_text_idwhere Qry.query_id=42497;

Изследване на вариации

Друг полезен отчет, който ни предлага Query Store, е заявките с висока вариация. Този отчет ни показва колко далеч са желаните показатели за конкретна заявка за даден период. Това е много полезно за исторически анализ на изпълнението. Използвайки изразите в листинг 9, ние генерираме данни, които могат да дадат картина на това как биха изглеждали вариантите. Стъпките в процедурата просто създават малка таблица и след това вмъкват записи, използвайки различни размери на партиди.

Списък 9:Планове, свързани със заявка 42497

използвайте WideWorldImportersgo-- Създайте Tablecreate tableone(ID int identity(1000,1),FirstName varchar(30),LastName varchar(30),CountryCode char(2),HireDate datetime2 default getdate());-- Вмъкнете записи в партиди с различни размери вмъкнете в стойности на таблицата ('Kenneth','Igiri','NG',getdate());GO 10000вмъкнете в стойностите на tableone ('Kwame','Boateng','GH', getdate());GO 10вмъкнете в стойностите на таблицата ('Philip','Onu','NG',getdate());GO 100000вмъкнете в стойностите на tableone ('Kwesi','Armah','GH', getdate());GO 100

Магазинът на заявки ни показва подробности като минималните и максималните стойности на тези показатели за конкретни интервали на изпълнение на заявката, която ни интересува. В този пример откриваме, че това е просто резултат от броя на партидите на изпълнение (обърнете внимание, че параметрите всъщност се използват за изпълнение на оператора INSERT). В производството други фактори биха могли да бъдат отговорни за подобни вариации.

Фиг. 18 Вариации в продължителността

Фиг. 19 Вариации в логическите записи

Фиг. 20 Вариации във физическите показания

Заключение

В тази статия прегледахме GUI средата на SQL Server 2016 Query Store и няколко неща, които можем да изведем относно производителността на нашия екземпляр (по отношение на SQL), използвайки Query Store. В интернет има няколко статии, които показват още по-напреднали случаи на употреба и много по-задълбочено обяснение на вътрешните елементи. Тази статия трябва да е от полза за администраторите на база данни от средно ниво, които искат да получат начален старт в използването на Query Store за оценка/настройка на производителността.

Препратки

Най-добра практика с магазина за заявки
Кристиман, Л. (2016) Съхранение на заявки – настройки и ограничения
Наблюдение на производителността чрез използване на хранилището на заявки
Заявка за изгледи на каталог на магазин
Запитване на съхраняваните процедури
Съхранение на заявки – как работи и как да го използвате
Сценарии за използване на магазин за заявки
Van de Lar, E. (2016) SQL Server 2016 Query Store:Принудителни планове за изпълнение с помощта на хранилището на заявки

Полезен инструмент:

dbForge Query Builder за SQL Server – позволява на потребителите да създават бързо и лесно сложни SQL заявки чрез интуитивен визуален интерфейс без ръчно писане на код.