Диспетчер Хранилища Запросов в SQL Server 2024+ (он же Query Store)

Основные преимущества использования Хранилища Запросов

• встроен в SQL Server и не требует дополнительной установки

• собирает данные без существенной нагрузки на систему

При этом Хранилище Запросов не заменяет полноценную систему мониторинга, например, RedGate или SenturyOne, но дополняет ее, предоставляя данные с другого ракурса.

 

Негативные стороны:

• Слегка увеличивает использование процессора. Я бы сказал 2-5% на сильно загруженном сервере. Я бы не стал включать Хранилище Запросов если ваш сервер постоянно использует 80-90% CPU.

• Несмотря на то, что этот функционал относительно отлажен, все равно возникают странные баги, но крайне редко и в нестандартных ситуациях.
  Пример двух багов которые мы нашли:

  • Query Store существенно усугубил ситуацию с обновлением кэша WMI. Проблема появилась и пропала с обновлениями Windows 2024. Эх.. столько ресурсов было растрачено на поиск основной причины… 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-2024

 

Хотя обычно можно начать с UI. Хранилище Запросов существует в контексте базы данных (не сервера), поэтому данные можно получить даже из копии базы, востановленной на другом сервере.

 

Не могу показать скриншот с рабочей базы, но, думаю, что вот этого должно быть достаточно для понимания.

Слева вверху, список основных запросов в заданной сортировке. По умолчанию сортируется по убыванию длительностт выполнения (не по затратам CPU)

Справа вверху, список всех планов выполнения для данного запроса и примерный расклад времени выполнения в заданном периоде.

Снизу, план запроса, который выбран сейчас в диаграмме сверху справа.

При нажатии Configure появляется меню с базовыми настройками. Из него можно также понять какие параметры выполнения запросов собираются.

Я надеюсь, что этого достаточно чтобы понять основную суть инструмента.

А вот как работать с результатами уже индивидуальная история для каждого клиента.