Основные преимущества использования Хранилища Запросов
-
встроен в SQL Server и не требует дополнительной установки
-
собирает данные без существенной нагрузки на систему
При этом Хранилище Запросов не заменяет полноценную систему мониторинга, например, RedGate или SenturyOne, но дополняет ее, предоставляя данные с другого ракурса.
Негативные стороны:
-
Слегка увеличивает использование процессора. Я бы сказал 2-5% на сильно загруженном сервере. Я бы не стал включать Хранилище Запросов если ваш сервер постоянно использует 80-90% CPU.
-
Несмотря на то, что этот функционал относительно отлажен, все равно возникают странные баги, но крайне редко и в нестандартных ситуациях.
Пример двух багов которые мы нашли:-
Query Store существенно усугубил ситуацию с обновлением кэша WMI. Проблема появилась и пропала с обновлениями Windows 2016. Эх.. столько ресурсов было растрачено на поиск основной причины… https://dba.stackexchange.com/questions/214818/why-select-query-is-waiting-on-hadr-sync-commit
-
Только пару дней назад процесс на основном сервере упал с дампом из-за бага в коде SQL Server. Переписка с MS уже в процессе, может и исправят.
-
Где Хранилище Запросов может быть полезно
Хранилище Запросов может быть использовано во многих ситуациях для отслеживания нагрузки на базы данных и идентификации регрессии. Некоторые сценарии:
-
Для идентификации и исправления запросов с деградировавшим планом выполнения
-
Идентификации основных запросов, потребляющих ресурсы сервера.
-
Обеспечения стабильности сервера после обновления на новую версию SQL Server
-
Идентификации и исправления ad-hoc запросов (в основном запросы, которые выполняют бизнес пользователи)
Как включить Хранилище Запросов
Активируется Query Store в свойствах базы данных (или через TSQL, конечно).
Основные параметры, на которые стоит обратить внимание:
-
Operation Mode: Read Write - SQL будет собирать и сохранять данные
-
Statistics Collection Interval - зависит от того насколько гранулярно нужны данные. Для критичных серверов и достаточным количеством свободных ресурсов я обычно ставлю 5 минут.
-
Query Store Capture Mode - лучше не ставить All, а поменять на Auto - в этом случае SQL сохранит только значимые запросы и большая часть мелких нечастых запросов будет отсеяна.
-
Stale Query Threshold (Days) - 30 дней мне кажется мало, обычно увеличиваю до года.
Работа с собранными данными.
Для просмотра данных можно воспользоваться TSQL запросами. Примеры приведены здесь - https://docs.microsoft.com/en-us/sql/relational-databases/performance/monitoring-performance-by-using-the-query-store?view=sql-server-2017
Хотя обычно можно начать с UI. Хранилище Запросов существует в контексте базы данных (не сервера), поэтому данные можно получить даже из копии базы, востановленной на другом сервере.
Не могу показать скриншот с рабочей базы, но, думаю, что вот этого должно быть достаточно для понимания.
Слева вверху, список основных запросов в заданной сортировке. По умолчанию сортируется по убыванию длительностт выполнения (не по затратам CPU)
Справа вверху, список всех планов выполнения для данного запроса и примерный расклад времени выполнения в заданном периоде.
Снизу, план запроса, который выбран сейчас в диаграмме сверху справа.
При нажатии Configure появляется меню с базовыми настройками. Из него можно также понять какие параметры выполнения запросов собираются.
Я надеюсь, что этого достаточно чтобы понять основную суть инструмента.
А вот как работать с результатами уже индивидуальная история для каждого клиента.
