Бенджамин Неварез е независим консултант със седалище в Лос Анджелис, Калифорния, който е специализиран в настройката и оптимизацията на заявки на SQL Server. Той е автор на „SQL Server 2014 Query Tuning &Optimization“ и „Inside the SQL Server Query Optimizer“ и съавтор на „SQL Server 2012 Internals“. С повече от 20 години опит в релационни бази данни, Бенджамин е бил и лектор на много конференции на SQL Server, включително PASS Summit, SQL Server Connections и SQLBits. Блогът на Бенджамин може да бъде намерен на адрес http://www.benjaminnevarez.com и той може да бъде достигнат и по имейл на admin на benjaminnevarez dot com и в Twitter на @BenjaminNevarez.
Откривали ли сте някога регресия на плана след надстройка на SQL Server и сте искали да знаете какъв беше предишният план за изпълнение? Имали ли сте някога проблем с производителността на заявката поради факта, че заявка неочаквано е получила нов план за изпълнение? На последната PASS среща на върха Конър Кънингам разкри нова функция на SQL Server, която може да бъде полезна при решаването на проблеми с производителността, свързани с тези и други промени в плановете за изпълнение.
Тази функция, наречена Query Store, може да ви помогне при проблеми с производителността, свързани с промени в плана, и скоро ще бъде налична в SQL Azure и по-късно в следващата версия на SQL Server. Въпреки че се очаква да бъде наличен в Enterprise Edition на SQL Server, все още не е известно дали ще бъде наличен в Standard или други издания. За да разберете предимствата на магазина за заявки, позволете ми да говоря накратко за процеса на отстраняване на неизправности със заявките.
Защо заявката е бавна?
След като откриете, че проблемът с производителността е защото заявката е бавна, следващата стъпка е да разберете защо. Очевидно не всеки проблем е свързан с промени в плана. Може да има множество причини, поради които заявка, която се представя добре, внезапно се забави. Понякога това може да е свързано с блокиране или проблем с други системни ресурси. Нещо друго може да се е променило, но предизвикателството може да е да разберете какво. Много пъти нямаме базови данни за използването на системни ресурси, статистика за изпълнение на заявки или история на производителността. И обикновено нямаме представа какъв е бил старият план. Възможно е някаква промяна, например данни, схема или параметри на заявка, да накара процесора на заявки да създаде нов план.
Промени в плана
На сесията Конор използва инструмента Picasso Database Query Optimizer Visualizer, въпреки че не го спомена по име, за да покаже защо плановете в същата заявка са се променили и обясни факта, че различни планове могат да бъдат избрани за една и съща заявка въз основа на селективността на техните предикати. Той дори спомена, че екипът за оптимизиране на заявки използва този инструмент, който е разработен от Индийския научен институт. Пример за визуализацията (щракнете за уголемяване):
Picasso Database Query Optimizer Visualizer
Всеки цвят в диаграмата е различен план и всеки план се избира въз основа на селективността на предикатите. Важен факт е, че когато границата е пресечена в графиката и е избран различен план, в повечето случаи цената и производителността на двата плана трябва да са сходни, тъй като селективността или приблизителният брой редове се променят само леко. Това може да се случи например, когато към таблица се добави нов ред, който отговаря на изискванията за използвания предикат. Въпреки това, в някои случаи, най-вече поради ограничения в разходния модел на оптимизатора на заявки, при който не е в състояние да моделира нещо правилно, новият план може да има голяма разлика в производителността в сравнение с предишния, създавайки проблем за вашето приложение. Между другото, плановете, показани на диаграмата, са окончателният план, избран от оптимизатора на заявки, не бъркайте това с многото алтернативи, които оптимизаторът трябва да вземе предвид, за да избере само една.
Важен факт, според мен, който Conor не обхвана директно, беше промяната на плановете поради регресия след промени в кумулативни актуализации (CU), сервизни пакети или надстройки на версии. Основен проблем, който идва на ум при промените в оптимизатора на заявки, е регресията на плана. Страхът от регресия на плана се счита за най-голямата пречка пред подобренията на оптимизатора на заявки. Регресиите са проблеми, въведени след прилагане на корекция към оптимизатора на заявки и понякога наричани класическото „две или повече грешки правят правилно“. Това може да се случи, когато, например, две лоши оценки, едната надценява стойност, а втората я подценява, се компенсират взаимно, за щастие давайки добра оценка. Коригирането само на една от тези стойности вече може да доведе до лоша оценка, която може да повлияе негативно на избора на избор на план, причинявайки регресия.
Какво прави хранилището на заявки?
Conor спомена, че Query Store работи и може да помогне със следното:
- Съхранява историята на плановете за заявки в системата;
- Уловете ефективността на всеки план за заявка във времето;
- Определете заявки, които „наскоро са станали по-бавни“;
- Позволява ви бързо да налагате планове; и,
- Уверете се, че това работи при рестартиране на сървъра, надстройки и повторно компилиране на заявки.
Така че тази функция не само съхранява плановете и свързаната информация за ефективността на заявката, но също така може да ви помогне лесно да наложите стар план за заявка, което в много случаи може да реши проблем с производителността.
Как да използвате хранилището на заявки
Трябва да активирате хранилището на заявки, като използвате ALTER DATABASE CURRENT SET QUERY_STORE = ON; изявление. Опитах го в текущия си абонамент за SQL Azure, но изявлението върна грешка, тъй като изглежда, че функцията все още не е налична. Свързах се с Conor и той ми каза, че функцията ще бъде налична скоро.
След като хранилището на заявки е активирано, то ще започне да събира плановете и данните за ефективността на заявките и можете да анализирате тези данни, като разгледате таблиците на хранилището на заявки. В момента мога да видя тези таблици в SQL Azure, но тъй като не успях да активирам хранилището на заявки, каталозите не върнаха никакви данни.
Можете да анализирате събраната информация или проактивно, за да разберете промените в производителността на заявката във вашето приложение, или със задна дата, в случай че имате проблем с производителността. След като идентифицирате проблема, можете да използвате традиционни техники за настройка на заявки, за да се опитате да отстраните проблема, или можете да използвате sp_query_store_force_plan съхранена процедура за форсиране на предишен план. Планът трябва да бъде заловен в хранилището на заявки, за да бъде принуден, което очевидно означава, че е валиден план (поне когато е бил събран; повече за това по-късно) и е генериран от оптимизатора на заявки преди това. За да наложите план, имате нужда от plan_id , наличен в sys.query_store_plan каталог. След като погледнете различните съхранени показатели, които са много подобни на това, което се съхранява например в sys.dm_exec_query_stats , можете да вземете решение да оптимизирате за конкретен показател, като CPU, I/O и т.н. След това можете просто да използвате изявление като това:
EXEC sys.sp_query_store_force_plan @query_id = 1, @plan_id = 1;
Това казва на SQL Server да принуди план 1 към заявка 1. Технически бихте могли да направите същото, като използвате ръководство за план, но би било по-сложно и на първо място ще трябва ръчно да събирате и намирате необходимия план.
Как работи хранилището на заявки?
Всъщност форсирането на план използва ръководства за план във фонов режим. Конър спомена, че „когато компилирате заявка, ние имплицитно добавяме намек за USE PLAN с фрагмента от XML плана, свързан с това изявление.“ Така че вече не е необходимо да използвате ръководство за планове. Също така имайте предвид, че, както при използването на ръководство за план, не е гарантирано, че имате точно принудителния план, но поне нещо подобно на него. За напомняне как работят ръководствата за план, разгледайте тази статия. Освен това трябва да сте наясно, че има някои случаи, в които принудителното прилагане на план не работи, типичен пример е, когато схемата се е променила, т.е. ако съхранен план използва индекс, но индексът вече не съществува. В този случай SQL Server не може да форсира плана, ще извърши нормална оптимизация и ще запише факта, че операцията принудително изпълнение на плана е неуспешна в sys.query_store_plan каталог.
Архитектура
Всеки път, когато SQL Server компилира или изпълнява заявка, съобщение се изпраща до хранилището на заявки. Това е показано по-нататък.
Общ преглед на работния процес в магазина за заявки
Информацията за компилиране и изпълнение се съхранява първо в паметта и след това се записва на диск, в зависимост от конфигурацията на хранилището на заявки (данните се обобщават според INTERVAL_LENGTH_MINUTES параметър, който по подразбиране е един час и се прехвърля на диск според DATA_FLUSH_INTERVAL_SECONDS параметър). Данните също могат да бъдат изхвърлени на диск, ако има натиск върху паметта в системата. Във всеки случай ще имате достъп до всички данни, както в паметта, така и в диска, когато стартирате sys.query_store_runtime_stats каталог.
Каталози
Събраните данни се съхраняват на диск и се съхраняват в потребителската база данни, където е активирано хранилището на заявки (и настройките се съхраняват в sys.database_query_store_options . Каталозите на Query Store са:
sys.query_store_query_text | Текстова информация за заявка |
sys.query_store_query | Текст на заявката плюс използвания план, засягащ SET опции |
sys.query_store_plan | Планове за изпълнение, включително история |
sys.query_store_runtime_stats | Статистика по време на изпълнение на заявка |
sys.query_store_runtime_stats_interval | Начален и краен час за интервали |
sys.query_context_settings | Информация за настройките на контекста на заявка |
Изгледи в магазина за заявки
Статистиката по време на изпълнение улавя цял набор от показатели, включително средната, последната, мин., максималната и стандартното отклонение. Ето пълния набор от колони за sys.query_store_runtime_stats :
runtime_stats_id | plan_id | runtime_stats_interval_id | ||
execution_type | execution_type_desc | first_execution_time | last_execution_time | count_executions |
avg_duration | last_duration | min_duration | max_duration | stdev_duration |
avg_cpu_time | last_cpu_time | min_cpu_time | max_cpu_time | stdev_cpu_time |
avg_logical_io_reads | last_logical_io_reads | min_logical_io_reads | max_logical_io_reads | stdev_logical_io_reads |
avg_logical_io_writes | last_logical_io_writes | min_logical_io_writes | max_logical_io_writes | stdev_logical_io_writes |
avg_physical_io_reads | last_physical_io_reads | min_physical_io_reads | max_physical_io_reads | stdev_physical_io_reads |
avg_clr_time | last_clr_time | min_clr_time | max_clr_time | stdev_clr_time |
avg_dop | last_dop | min_dop | max_dop | stdev_dop |
avg_query_max_used_memory | last_query_max_used_memory | min_query_max_used_memory | max_query_max_used_memory | stdev_query_max_used_memory |
avg_rowcount | last_rowcount | min_rowcount | max_rowcount | stdev_rowcount |
Колони в sys.query_store_runtime_stats
Тези данни се улавят само когато изпълнението на заявката приключи. Съхранението на заявки също взема предвид SET на заявката опции, които могат да повлияят на избора на план за изпълнение, тъй като влияят на неща като резултатите от оценката на константни изрази по време на процеса на оптимизация. Разгледах тази тема в предишна публикация.
Заключение
Това определено ще бъде страхотна функция и нещо, което бих искал да опитам възможно най-скоро (между другото, демонстрацията на Conor показва „SQL Server 15 CTP1“, но тези битове не са публично достъпни). Съхранението на заявки може да бъде полезно за надстройки, които могат да бъдат версия на CU, сервизен пакет или SQL Server, тъй като можете да анализирате информацията, събрана от хранилището на заявки преди и след това, за да видите дали някоя заявка е регресирала. (И ако функцията е налична в по-ниски издания, можете дори да направите това в сценарий за надграждане на SKU.) Познаването на това може да ви помогне да предприемете някои конкретни действия в зависимост от проблема и едно от тези решения може да бъде да наложите предишния план както беше обяснено по-горе.
