Рекомендации по хранилищу запросовBest practices with Query Store

Применимо к:Applies to: даSQL ServerSQL Server (все поддерживаемые версии) yesSQL ServerSQL Server (all supported versions) ДаБаза данных SQL AzureAzure SQL DatabaseYesБаза данных SQL AzureAzure SQL Database ДаУправляемый экземпляр SQL AzureAzure SQL Managed InstanceYesУправляемый экземпляр SQL AzureAzure SQL Managed Instance даAzure Synapse AnalyticsAzure Synapse AnalyticsyesAzure Synapse AnalyticsAzure Synapse AnalyticsПрименимо к:Applies to: даSQL ServerSQL Server (все поддерживаемые версии) yesSQL ServerSQL Server (all supported versions) ДаБаза данных SQL AzureAzure SQL DatabaseYesБаза данных SQL AzureAzure SQL Database ДаУправляемый экземпляр SQL AzureAzure SQL Managed InstanceYesУправляемый экземпляр SQL AzureAzure SQL Managed Instance даAzure Synapse AnalyticsAzure Synapse AnalyticsyesAzure Synapse AnalyticsAzure Synapse Analytics

В этой статье приведены рекомендации по использованию хранилища запросов SQL Server с вашей рабочей нагрузкой.This article outlines the best practices for using SQL Server Query Store with your workload.

Используйте последнюю версию SQL Server Management StudioSQL Server Management StudioUse the latest SQL Server Management StudioSQL Server Management Studio

SQL Server Management StudioSQL Server Management Studio включает в себя набор пользовательских интерфейсов, предназначенных для настройки хранилища запросов и использования собранных данных о рабочей нагрузке.has a set of user interfaces designed for configuring Query Store and for consuming collected data about your workload. Скачайте последнюю версию Среда Management StudioManagement Studio здесь.Download the latest version of Среда Management StudioManagement Studio here.

Краткое описание того, как использовать хранилище запросов в сценариях устранения неполадок, см. в блогах по хранилищу запросов Azure.For a quick description on how to use Query Store in troubleshooting scenarios, see Query Store Azure blogs.

Используйте анализ производительности процессов в Базе данных SQL AzureUse Query Performance Insight in Azure SQL Database

При запуске хранилища запросов в База данных SQL AzureAzure SQL Database можно использовать анализ производительности запросов для анализа потребления ресурсов в динамике.If you run Query Store in База данных SQL AzureAzure SQL Database, you can use Query Performance Insight to analyze resource consumption over time. С помощью Среда Management StudioManagement Studio и Azure Data Studio можно получить подробные сведения о потреблении ресурсов (ЦП, памяти и подсистемы ввода-вывода) всеми вашими запросами, а анализ производительности запросов обеспечивает быстрый и эффективный способ определения их влияния на общее использование DTU для базы данных.While you can use Среда Management StudioManagement Studio and Azure Data Studio to get detailed resource consumption for all your queries, such as CPU, memory, and I/O, Query Performance Insight gives you a quick and efficient way to determine their impact on overall DTU consumption for your database. Дополнительные сведения см. в разделе Анализ производительности запросов в базе данных SQL Azure.For more information, see Azure SQL Database Query Performance Insight.

В этом разделе описываются оптимальные настройки по умолчанию, призванные обеспечить надежную работу хранилища запросов и зависимых компонентов.This section describes optimal configuration defaults that are designed to ensure reliable operation of the Query Store and dependent features. По умолчанию конфигурация оптимизирована для постоянного сбора данных, т. е. для минимальной продолжительности состояний "Отключено" и "Только для чтения".Default configuration is optimized for continuous data collection, that is minimal time spent in OFF/READ_ONLY states. Дополнительные сведения обо всех доступных параметрах хранилища запросов см. в разделе ALTER DATABASE SET Options (Transact-SQL).For more information about all available Query Store options, see ALTER DATABASE SET options (Transact-SQL).

КонфигурацияConfiguration ОписаниеDescription По умолчаниюDefault КомментарийComment
MAX_STORAGE_SIZE_MBMAX_STORAGE_SIZE_MB Предельный размер пространства данных, которое хранилище запросов использует в базе данных клиентаSpecifies the limit for the data space that Query Store can take inside the customer database 100100 Принудительно для новых баз данныхEnforced for new databases
INTERVAL_LENGTH_MINUTESINTERVAL_LENGTH_MINUTES Определяет время, в течение которого объединяются и сохраняются собранные статистические данные среды выполнения по планам запросов.Defines size of time window during which collected runtime statistics for query plans are aggregated and persisted. Для каждого активного плана запроса в течение периода, заданного в этом параметре, будет сохраняться только одна строка.Every active query plan has at most one row for a period of time defined with this configuration 6060 Принудительно для новых баз данныхEnforced for new databases
STALE_QUERY_THRESHOLD_DAYSSTALE_QUERY_THRESHOLD_DAYS Политика очистки на основе времени, которая контролирует срок хранения статистики для среды выполнения и неактивных запросов.Time-based cleanup policy that controls the retention period of persisted runtime statistics and inactive queries 3030 Принудительно для новых баз данных и баз данных с предыдущим значением по умолчанию (367)Enforced for new databases and databases with previous default (367)
SIZE_BASED_CLEANUP_MODESIZE_BASED_CLEANUP_MODE Указывает, нужно ли выполнять автоматическую очистку данных при приближении к предельному значению, установленному для размера данных хранилища запросов.Specifies whether automatic data cleanup takes place when Query Store data size approaches the limit AUTOAUTO Принудительно для всех баз данныхEnforced for all databases
QUERY_CAPTURE_MODEQUERY_CAPTURE_MODE Указывает, следует ли отслеживать все запросы или только определенное подмножество.Specifies whether all queries or only a subset of queries are tracked AUTOAUTO Принудительно для всех баз данныхEnforced for all databases
FLUSH_INTERVAL_SECONDSFLUSH_INTERVAL_SECONDS Указывает максимальный период, в течение которого статистика среды выполнения будет храниться в памяти перед записью на диск.Specifies maximum period during which captured runtime statistics are kept in memory, before flushing to disk 900900 Принудительно для новых баз данныхEnforced for new databases

Важно!

Эти значения по умолчанию будут автоматически применяться на последнем этапе активации хранилища запросов в База данных SQL AzureAzure SQL Database.These defaults are automatically applied in the final stage of Query Store activation in all База данных SQL AzureAzure SQL Database. После включения База данных SQL AzureAzure SQL Database не будет изменять значения настроек, заданные пользователями, за исключением случаев негативного влияния на основную рабочую нагрузку или на надежность работы хранилища запросов.After it's enabled, База данных SQL AzureAzure SQL Database won't change configuration values that are set by customers, unless they negatively impact primary workload or reliable operations of the Query Store.

Примечание

Хранилище запросов нельзя отключить в отдельной базе данных База данных SQL AzureAzure SQL Database и эластичном пуле.Query Store cannot be disabled in База данных SQL AzureAzure SQL Database single database and Elastic Pool. При исполнении ALTER DATABASE [database] SET QUERY_STORE = OFF будет возвращено предупреждение 'QUERY_STORE=OFF' is not supported in this version of SQL Server..Executing ALTER DATABASE [database] SET QUERY_STORE = OFF will return the warning 'QUERY_STORE=OFF' is not supported in this version of SQL Server..

Если вы хотите сохранить свои пользовательские настройки, используйте параметры ALTER DATABASE для хранилища запросов , чтобы восстановить предыдущее состояние конфигурации.If you want to stay with your custom settings, use ALTER DATABASE with Query Store options to revert configuration to the previous state. Изучите рекомендации по использованию хранилища запросов, чтобы научиться правильно выбирать оптимальные параметры конфигурации.Check out Best Practices with the Query Store in order to learn how to choose optimal configuration parameters.

Использование хранилища запросов с пулом эластичных баз данныхUse Query Store with Elastic Pool databases

Хранилище запросов можно без каких-либо опасений использовать во всех базах данных, даже в плотно упакованных пулах.You can use Query Store in all databases without concerns, in even densely packed pools. Все проблемы, связанные с чрезмерным использованием ресурсов, которые могли возникать, когда хранилище запросов было включено для большого количества баз данных в эластичных пулах, были устранены.All issues related to excessive resource usage that might have occurred when Query Store was enabled for the large number of databases in the elastic pools have been resolved.

Постоянная адаптация хранилища запросов к вашей рабочей нагрузкеKeep Query Store adjusted to your workload

Настраивайте хранилище запросов в соответствии с вашей рабочей нагрузкой и требованиями к устранению проблем производительности.Configure Query Store based on your workload and performance troubleshooting requirements. Параметры по умолчанию подходят для начального использования, но вам следует наблюдать за поведением хранилища запросов с течением времени и соответствующим образом настраивать его конфигурацию.The default parameters are good enough to start, but you should monitor how Query Store behaves over time and adjust its configuration accordingly.

Свойства хранилища запросовQuery Store properties

Ниже приведены рекомендации по заданию значений параметров.Here are guidelines to follow for setting parameter values:

Максимальный размер (МБ) . Задает предельный объем пространства данных, который хранилище запросов занимает в базе данных.Max Size (MB): Specifies the limit for the data space that Query Store takes inside your database. Это наиболее важный параметр, который непосредственно влияет на режим работы хранилища запросов.This is the most important setting that directly affects the operation mode of Query Store.

По мере того как хранилище запросов собирает запросы, планы выполнения и статистику, его размер в базе данных растет, пока не будет достигнут этот предельный объем.While Query Store collects queries, execution plans, and statistics, its size in the database grows until this limit is reached. Когда это происходит, хранилище запросов автоматически изменяет режим работы на "только чтение" и останавливает сбор новых данных. Это означает, что анализ производительности больше не будет точным.When that happens, Query Store automatically changes the operation mode to read-only and stops collecting new data, which means that your performance analysis is no longer accurate.

Значение по умолчанию в SQL Server 2016 (13.x);SQL Server 2016 (13.x) и SQL Server 2017 (14.x);SQL Server 2017 (14.x) — 100 МБ.The default value in SQL Server 2016 (13.x);SQL Server 2016 (13.x) and SQL Server 2017 (14.x);SQL Server 2017 (14.x) is 100 MB. Этого размера может быть недостаточно, если рабочая нагрузка создает большое количество различных запросов и планов или вы хотите хранить журнал запросов более длительный период времени.This size might not be sufficient if your workload generates a large number of different queries and plans or if you want to keep query history for a longer period of time. Начиная с версии SQL Server 2019 (15.x)SQL Server 2019 (15.x) значение по умолчанию равно 1 ГБ.Starting with SQL Server 2019 (15.x)SQL Server 2019 (15.x), the default value is 1 GB. Отслеживайте текущее использование пространства и увеличивайте максимальный размер (МБ) , чтобы предотвратить переход хранилища запросов в режим "только чтение".Keep track of current space usage and increase the Max Size (MB) value to prevent Query Store from transitioning to read-only mode.

Важно!

Ограничение Максимальный размер (МБ) не применяется строго.The Max Size (MB) limit isn't strictly enforced. Размер хранилища проверяется только в том случае, если хранилище запросов записывает данные на диск.Storage size is checked only when Query Store writes data to disk. Этот интервал задается параметром Интервал записи данных на диск (в минутах) .This interval is set by the Data Flush Interval (Minutes) option. Если хранилище запросов нарушило ограничение максимального размера между проверками размера хранилища, оно будет переведено в режим только для чтения.If Query Store has breached the maximum size limit between storage size checks, it transitions to read-only mode. Если параметр Режим очистки на основе размера включен, также активируется механизм очистки для принудительного применения ограничения максимального размера.If Size Based Cleanup Mode is enabled, the cleanup mechanism to enforce the maximum size limit is also triggered.

Используйте Среда Management StudioManagement Studio или выполните следующий скрипт, чтобы получить последние сведения о размере хранилища запросов.Use Среда Management StudioManagement Studio or execute the following script to get the latest information about Query Store size:

USE [QueryStoreDB];
GO

SELECT actual_state_desc, desired_state_desc, current_storage_size_mb,
 max_storage_size_mb, readonly_reason
FROM sys.database_query_store_options;

Следующий скрипт задает новое значение максимального размера (МБ) :The following script sets a new value for Max Size (MB):

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE (MAX_STORAGE_SIZE_MB = 1024);

Интервал записи данных на диск (в минутах) . Определяет частоту для сохранения статистики, собранной во время выполнения, на диск.Data Flush Interval (Minutes): It defines the frequency to persist collected runtime statistics to disk. Выражается в минутах в графическом пользовательском интерфейсе, и в секундах — в Transact-SQLTransact-SQL.It's expressed in minutes in the graphical user interface (GUI), but in Transact-SQLTransact-SQL it's expressed in seconds. Значение по умолчанию — 900 секунд, то есть 15 минут в графическом пользовательском интерфейсе.The default is 900 seconds, which is 15 minutes in the graphical user interface. Рассмотрите возможность увеличить значение, если рабочая нагрузка не формирует большое количество различных запросов и планов или вы можете выделить больше времени для сохранения данных до отключения базы данных.Consider using a higher value if your workload doesn't generate a large number of different queries and plans, or if you can withstand longer time to persist data before a database shutdown.

Примечание

С помощью флага трассировки 7745 можно запретить запись данных из хранилища запросов на диск в случае отработки отказа или команды завершения работы.Using trace flag 7745 prevents Query Store data from being written to disk in case of a failover or shutdown command. Дополнительные сведения см. в разделе Использование флагов трассировки на критически важных серверах.For more information, see the Use trace flags on mission-critical servers section.

Используйте SQL Server Management StudioSQL Server Management Studio или Transact-SQLTransact-SQL, чтобы задать другое значение для интервала записи данных на диск:Use SQL Server Management StudioSQL Server Management Studio or Transact-SQLTransact-SQL to set a different value for Data Flush Interval:

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE (DATA_FLUSH_INTERVAL_SECONDS = 900);

Интервал сбора статистики. Определяет уровень детализации в минутах для собираемой статистики среды выполнения.Statistics Collection Interval: Defines the level of granularity for the collected runtime statistic, expressed in minutes. Значение по умолчанию — 60 минут.The default is 60 minutes. Рекомендуется использовать меньшее значение, если требуется большая степень детализации или меньшее время на обнаружение и устранение проблем.Consider using a lower value if you require finer granularity or less time to detect and mitigate issues. Помните, что это значение напрямую влияет на объем данных в хранилище запросов.Keep in mind that the value directly affects the size of Query Store data. Чтобы задать другое значение для интервала сбора статистики, используйте SQL Server Management StudioSQL Server Management Studio или Transact-SQLTransact-SQL:Use SQL Server Management StudioSQL Server Management Studio or Transact-SQLTransact-SQL to set a different value for Statistics Collection Interval:

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE (INTERVAL_LENGTH_MINUTES = 60);

Порог устаревания запросов (в днях) . Политика очистки на основе времени, которая управляет сроком хранения статистики среды выполнения и неактивных запросов, выраженная в днях.Stale Query Threshold (Days): Time-based cleanup policy that controls the retention period of persisted runtime statistics and inactive queries, expressed in days. По умолчанию для хранилища запросов настроено хранение данных в течение 30 дней, что может быть излишне долго для вашего сценария.By default, Query Store is configured to keep the data for 30 days, which might be unnecessarily long for your scenario.

Старайтесь не хранить исторические данные, которые не планируется использовать.Avoid keeping historical data that you don't plan to use. Это позволит снизить переходы в состояние только для чтения.This practice reduces changes to read-only status. Объем данных в хранилище запросов и время на обнаружение и устранение проблем будут более предсказуемыми.The size of Query Store data and the time to detect and mitigate the issue will be more predictable. Используйте Среда Management StudioManagement Studio или следующий скрипт, чтобы настроить политику очистки на основе времени:Use Среда Management StudioManagement Studio or the following script to configure time-based cleanup policy:

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE (CLEANUP_POLICY = (STALE_QUERY_THRESHOLD_DAYS = 90));

Режим очистки на основе размера. Указывает, должна ли происходить автоматическая очистка, когда объем данных в хранилище запросов достигает предельного значения.Size Based Cleanup Mode: Specifies whether automatic data cleanup takes place when Query Store data size approaches the limit. Активируйте очистку на основе размера, чтобы хранилище запросов всегда работало в режиме чтения и записи и собирало последние данные.Activate size-based cleanup to make sure that Query Store always runs in read-write mode and collects the latest data.

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE (SIZE_BASED_CLEANUP_MODE = AUTO);

Режим записи запроса хранилища. Задает политику записи запросов для хранилища запросов.Query Store Capture Mode: Specifies the query capture policy for Query Store.

  • Все: Записывает все запросы.All: Captures all queries. Этот параметр используется по умолчанию в SQL Server 2016 (13.x);SQL Server 2016 (13.x) и SQL Server 2017 (14.x);SQL Server 2017 (14.x).This option is the default in SQL Server 2016 (13.x);SQL Server 2016 (13.x) and SQL Server 2017 (14.x);SQL Server 2017 (14.x).
  • Автоматически. Редкие запросы и запросы с незначительной длительностью компиляции и выполнения игнорируются.Auto: Infrequent queries and queries with insignificant compile and execution duration are ignored. Пороговые значения для числа выполнений, длительности компиляции и времени выполнения определяются внутренним образом.Thresholds for execution count, compile, and runtime duration are internally determined. Начиная с версии SQL Server 2019 (15.x)SQL Server 2019 (15.x) это параметр по умолчанию.Starting with SQL Server 2019 (15.x)SQL Server 2019 (15.x), this is the default option.
  • Нет — Хранилище запросов прекращает запись новых запросов.None: Query Store stops capturing new queries.
  • Пользовательский. Разрешает дополнительное управление политикой сбора данных и ее тонкую настройку.Custom: Allows additional control and the capability to fine-tune the data collection policy. Новые пользовательские параметры определяют действия, которые выполняются при достижении внутреннего порогового значения времени для политики записи.The new custom settings define what happens during the internal capture policy time threshold. Это временная граница, в пределах которой происходит оценка настраиваемых условий и, если какие-либо из них соблюдаются, разрешается запись запроса в хранилище запросов.This is a time boundary during which the configurable conditions are evaluated and, if any are true, the query is eligible to be captured by Query Store.

Важно!

Курсоры, запросы в хранимых процедурах и скомпилированные в собственном коде запросы всегда записываются, если задан режим записи в хранилище запросов All, Auto или Custom.Cursors, queries inside stored procedures, and natively compiled queries are always captured when Query Store Capture Mode is set to All, Auto, or Custom. Чтобы записывать скомпилированные в собственном коде запросы, включите сбор статистики на уровне запроса с помощью хранимой процедуры sys.sp_xtp_control_query_exec_stats.To capture natively compiled queries, enable collection of per-query statistics by using sys.sp_xtp_control_query_exec_stats.

Следующий скрипт устанавливает параметр QUERY_CAPTURE_MODE в значение AUTO:The following script sets QUERY_CAPTURE_MODE to AUTO:

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE (QUERY_CAPTURE_MODE = AUTO);

ПримерыExamples

В следующем примере параметр QUERY_CAPTURE_MODE устанавливается в значение AUTO и задаются остальные рекомендованные параметры в SQL Server 2016 (13.x);SQL Server 2016 (13.x):The following example sets QUERY_CAPTURE_MODE to AUTO and sets other recommended options in SQL Server 2016 (13.x);SQL Server 2016 (13.x):

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE = ON
    (
      OPERATION_MODE = READ_WRITE,
      CLEANUP_POLICY = ( STALE_QUERY_THRESHOLD_DAYS = 90 ),
      DATA_FLUSH_INTERVAL_SECONDS = 900,
      QUERY_CAPTURE_MODE = AUTO,
      MAX_STORAGE_SIZE_MB = 1000,
      INTERVAL_LENGTH_MINUTES = 60
    );

В следующем примере параметр QUERY_CAPTURE_MODE устанавливается в значение AUTO и задаются остальные рекомендованные параметры в SQL Server 2017 (14.x);SQL Server 2017 (14.x) для включения статистики ожидания:The following example sets QUERY_CAPTURE_MODE to AUTO and sets other recommended options in SQL Server 2017 (14.x);SQL Server 2017 (14.x) to include wait statistics:

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE = ON
    (
      OPERATION_MODE = READ_WRITE,
      CLEANUP_POLICY = ( STALE_QUERY_THRESHOLD_DAYS = 90 ),
      DATA_FLUSH_INTERVAL_SECONDS = 900,
      QUERY_CAPTURE_MODE = AUTO,
      MAX_STORAGE_SIZE_MB = 1000,
      INTERVAL_LENGTH_MINUTES = 60,
      SIZE_BASED_CLEANUP_MODE = AUTO,
      MAX_PLANS_PER_QUERY = 200,
      WAIT_STATS_CAPTURE_MODE = ON
    );

В следующем примере параметр QUERY_CAPTURE_MODE устанавливается в значение AUTO и задаются остальные рекомендованные параметры в SQL Server 2019 (15.x)SQL Server 2019 (15.x), а также при необходимости устанавливается политика записи CUSTOM с параметрами по умолчанию вместо нового режима записи AUTO по умолчанию:The following example sets QUERY_CAPTURE_MODE to AUTO and sets other recommended options in SQL Server 2019 (15.x)SQL Server 2019 (15.x), and optionally sets the CUSTOM capture policy with its defaults, instead of the new default AUTO capture mode:

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE = ON
    (
      OPERATION_MODE = READ_WRITE,
      CLEANUP_POLICY = ( STALE_QUERY_THRESHOLD_DAYS = 90 ),
      DATA_FLUSH_INTERVAL_SECONDS = 900,
      MAX_STORAGE_SIZE_MB = 1000,
      INTERVAL_LENGTH_MINUTES = 60,
      SIZE_BASED_CLEANUP_MODE = AUTO,
      MAX_PLANS_PER_QUERY = 200,
      WAIT_STATS_CAPTURE_MODE = ON,
      QUERY_CAPTURE_MODE = CUSTOM,
      QUERY_CAPTURE_POLICY = (
        STALE_CAPTURE_POLICY_THRESHOLD = 24 HOURS,
        EXECUTION_COUNT = 30,
        TOTAL_COMPILE_CPU_TIME_MS = 1000,
        TOTAL_EXECUTION_CPU_TIME_MS = 100
      )
    );

Как приступить к устранению проблем производительности запросовStart with query performance troubleshooting

Как показано на приведенной ниже схеме, рабочий процесс устранения неполадок в хранилище запросов довольно простой.The troubleshooting workflow with Query Store is simple, as shown in the following diagram:

Устранение неполадок хранилища запросовQuery Store troubleshooting

Включите хранилище запросов с помощью Среда Management StudioManagement Studio, как описано в предыдущем разделе, или выполните следующую инструкцию Transact-SQLTransact-SQL:Enable Query Store by using Среда Management StudioManagement Studio, as described in the previous section, or execute the following Transact-SQLTransact-SQL statement:

ALTER DATABASE [DatabaseOne] SET QUERY_STORE = ON;

Сбор хранилищем запросов набора данных, который точно представляет рабочую нагрузку, может занять некоторое время.It takes some time until Query Store collects the data set that accurately represents your workload. Обычно одного дня достаточно даже для очень сложных рабочих нагрузок.Usually, one day is enough even for very complex workloads. Однако вы можете приступить к исследованию данных и выявлению запросов, требующих вашего внимания, сразу после включения этой функции.However, you can start exploring the data and identify queries that need your attention immediately after you enable the feature. Перейдите во вложенную папку Query Store в узле базы данных в обозревателе объектов Среда Management StudioManagement Studio, чтобы открыть представления по устранению неполадок для конкретных сценариев.Go to the Query Store subfolder under the database node in Object Explorer of Среда Management StudioManagement Studio to open troubleshooting views for specific scenarios.

Представления хранилища запросовСреда Management StudioManagement Studio работают с набором метрик выполнения, каждая из которых выражается в виде какой-либо из следующих статистических функций.Среда Management StudioManagement Studio Query Store views operate with the set of execution metrics, each expressed as any of the following statistic functions:

SQL ServerSQL Server versionversion Метрика выполненияExecution metric Статистическая функцияStatistic function
SQL Server 2016 (13.x);SQL Server 2016 (13.x) CPU time (время ЦП), Duration (длительность), Execution count (число выполнений), Logical reads (число логических операций чтения), Logical writes (число логических операций записи), Memory consumption (потребление памяти), Physical reads (число физических операций чтения), CLR time (время среды CLR), Degree of parallelism (DOP) (степень параллелизма) и Row count (число строк)CPU time, Duration, Execution count, Logical reads, Logical writes, Memory consumption, Physical reads, CLR time, Degree of parallelism (DOP), and Row count Average (среднее), Maximum (максимум), Minimum (минимум), Standard Deviation (стандартное отклонение), Total (всего)Average, Maximum, Minimum, Standard Deviation, Total
SQL Server 2017 (14.x);SQL Server 2017 (14.x) CPU time (время ЦП), Duration (длительность), Execution count (число выполнений), Logical reads (число логических операций чтения), Logical writes (число логических операций записи), Memory consumption (потребление памяти), Physical reads (число физических операций чтения), CLR time (время среды CLR), Degree of parallelism (DOP) (степень параллелизма), Row count (число строк), Log memory (память, занимаемая журналом), TempDB memory (память, занимаемая базой данных TempDB) и Wait times (время ожидания)CPU time, Duration, Execution count, Logical reads, Logical writes, Memory consumption, Physical reads, CLR time, Degree of parallelism, Row count, Log memory, TempDB memory, and Wait times Average (среднее), Maximum (максимум), Minimum (минимум), Standard Deviation (стандартное отклонение), Total (всего)Average, Maximum, Minimum, Standard Deviation, Total

На следующем рисунке показано, как найти представления хранилища запросов.The following graphic shows how to locate Query Store views:

Представления хранилища запросовQuery Store views

В следующей таблице поясняется, когда следует использовать каждое из представлений хранилища запросов.The following table explains when to use each of the Query Store views:

Представление SQL Server Management StudioSQL Server Management Studio view СценарийScenario
Регрессированные запросыRegressed Queries Выявите запросы, метрики выполнения для которых недавно регрессировали (т. е. стали хуже).Pinpoint queries for which execution metrics have recently regressed (for example, changed to worse).
Используйте это представление для сопоставления наблюдаемых проблем производительности в приложении с фактическими запросами, которые необходимо улучшить или исправить.Use this view to correlate observed performance problems in your application with the actual queries that need to be fixed or improved.
Общее потребление ресурсовOverall Resource Consumption Анализируйте общее потребление ресурсов базы данных для любой из метрик выполнения.Analyze the total resource consumption for the database for any of the execution metrics.
Используйте это представление для определения шаблонов ресурсов (дневная и ночная рабочие нагрузки) и оптимизации общего потребления для базы данных.Use this view to identify resource patterns (daily vs. nightly workloads) and optimize overall consumption for your database.
Основные запросы, потребляющие ресурсыTop Resource Consuming Queries Выберите интересующую метрику выполнения и определите запросы, которые имели максимальные значения в указанном промежутке времени.Choose an execution metric of interest, and identify queries that had the most extreme values for a provided time interval.
Используйте это представление, чтобы сосредоточиться на наиболее важных запросах, которые оказывают самое большое воздействие на потребление ресурсов базы данных.Use this view to focus your attention on the most relevant queries that have the biggest impact to database resource consumption.
Запросы с принудительными планамиQueries With Forced Plans Здесь приводятся планы, которые были принудительно выполнены ранее с помощью Query Store.Lists previously forced plans using Query Store.
В этом представлении можно быстро получить доступ ко всем текущим принудительным планам.Use this view to quickly access all currently forced plans.
Запросы с высокой вариативностьюQueries With High Variation Анализ запросов с высокой вариативностью выполнения с учетом всех доступных параметров, таких как длительность, время ЦП, ввод-вывод данных и использование памяти, в соответствующем временном интервале.Analyze queries with high-execution variation as it relates to any of the available dimensions, such as Duration, CPU time, IO, and Memory usage, in the desired time interval.
Используйте это представление для выявления запросов с сильно варьируемой производительностью, которые могут влиять на работу пользователей в приложениях.Use this view to identify queries with widely variant performance that can be affecting user experience across your applications.
Статистика ожидания запросовQuery Wait Statistics Анализируйте категории ожидания, наиболее активные в базе данных, и определите, какие запросы вносят наибольший вклад в выбранную категорию ожидания.Analyze wait categories that are most active in a database and which queries contribute most to the selected wait category.
Используйте это представление, чтобы проанализировать статистику ожидания и определить запросы, которые могут влиять на работу пользователей в приложениях.Use this view to analyze wait statistics and identify queries that might be affecting user experience across your applications.

Область применения: начиная с SQL Server Management StudioSQL Server Management Studio версии 18.0 и SQL Server 2017 (14.x);SQL Server 2017 (14.x).Applies to: Starting with SQL Server Management StudioSQL Server Management Studio v18.0 and SQL Server 2017 (14.x);SQL Server 2017 (14.x).
Отслеживаемые запросыTracked Queries Отслеживайте выполнение наиболее важных запросов в реальном времени.Track the execution of the most important queries in real time. Как правило, эти представления используются, когда имеются запросы с принудительными планами и требуется убедиться в стабильной производительности запросов.Typically, you use this view when you have queries with forced plans and you want to make sure that query performance is stable.

Совет

Подробное описание того, как использовать Среда Management StudioManagement Studio для выявления запросов с самым большим потреблением ресурсов и исправления тех, чьи метрики ухудшились из-за изменения плана, см. в блогах по хранилищу запросов Azure.For a detailed description of how to use Среда Management StudioManagement Studio to identify the top resource-consuming queries and fix those that regressed due to the change of a plan choice, see Query Store Azure Blogs.

При указании запроса с недостаточной производительностью необходимые действия будут зависеть от характера проблемы.When you identify a query with suboptimal performance, your action depends on the nature of the problem.

  • Если запрос выполнялся с несколькими планами и последний план оказался значительно хуже предыдущего, можно применить механизм принудительного использования плана.If the query was executed with multiple plans and the last plan is significantly worse than the previous plan, you can use the plan forcing mechanism to force it. SQL ServerSQL Server попытается принудительно применить план в оптимизаторе.tries to force the plan in the optimizer. Если это не удастся сделать, будет порождено событие XEvent и оптимизация будет выполнена как обычно.If plan forcing fails, an XEvent is fired and the optimizer is instructed to optimize in the normal way.

    План принудительного использования хранилища запросовQuery Store force plan

    Примечание

    На представленном выше графике могут отображаться различные фигуры, каждая из которых соответствует определенному состоянию.The previous graphic might feature different shapes for specific query plans, with the following meanings for each possible status:

    ФигурнаяShape ЗначениеMeaning
    CircleCircle Запрос выполнен, то есть обычное выполнение успешно завершено.Query completed, which means that a regular execution successfully finished.
    SquareSquare Запрос отменен, то есть клиент прервал выполнение.Cancelled, which means that a client-initiated aborted execution.
    TriangleTriangle Сбой, то есть выполнение прервано с исключением.Failed, which means that an exception aborted execution.

    Кроме того, размер фигуры отражает количество выполнений запроса за указанный интервал времени.Also, the size of the shape reflects the query execution count within the specified time interval. Чем больше это количество, тем больше размер фигуры.The size increases with a higher number of executions.

  • Вы можете решить, что в запросе отсутствует индекс для оптимального выполнения.You might conclude that your query is missing an index for optimal execution. Эта информация будет отображена в плане выполнения запроса.This information is surfaced within the query execution plan. Создайте отсутствующий индекс и проверьте производительность запросов с помощью хранилища запросов.Create the missing index, and check the query performance by usingQuery Store.

    План отображения хранилища запросовQuery Store show plan

При выполнении рабочей нагрузки в База данных SQLSQL Databaseподпишитесь на помощник по построению индексов База данных SQLSQL Database , чтобы автоматически получать рекомендации по индексам.If you run your workload on База данных SQLSQL Database, sign up for База данных SQLSQL Database Index Advisor to automatically receive index recommendations.

  • В некоторых случаях можно принудительно выполнить перекомпиляцию статистики, если вы видите, что разница между предполагаемым и фактическим числом строк в плане выполнения является существенной.In some cases, you might enforce statistic recompilation if you see that the difference between the estimated and the actual number of rows in the execution plan is significant.
  • Повторно создайте проблемные запросы, например чтобы воспользоваться преимуществами параметризации запросов или для реализации более оптимальной логики.Rewrite problematic queries, for example, to take advantage of query parameterization or to implement more optimal logic.

Проверка непрерывности сбора данных по запросам хранилищем запросовVerify that Query Store collects query data continuously

Хранилище запросов может без предупреждения изменять режим работы.Query Store can silently change the operation mode. Постоянно наблюдайте за состоянием хранилища запросов, чтобы знать, что оно работает, и предпринимать действия для исключения сбоев по предотвращаемым причинам.Regularly monitor the state of Query Store to ensure that Query Store is operating, and to take action to avoid failures due to preventable causes. Выполните следующий запрос, чтобы определить режим работы и просмотреть наиболее актуальные параметры.Execute the following query to determine the operation mode and view the most relevant parameters:

USE [QueryStoreDB];
GO

SELECT actual_state_desc, desired_state_desc, current_storage_size_mb,
    max_storage_size_mb, readonly_reason, interval_length_minutes,
    stale_query_threshold_days, size_based_cleanup_mode_desc,
    query_capture_mode_desc
FROM sys.database_query_store_options;

Разница между actual_state_desc и desired_state_desc показывает, что произошло автоматическое изменение режима работы.The difference between the actual_state_desc and desired_state_desc indicates that a change of the operation mode occurred automatically. Самое частое изменение — автоматическое переключение хранилища запросов в режим "только чтение".The most common change is for Query Store to silently switch to read-only mode. В исключительно редких случаях хранилище запросов может оказаться в состоянии ошибки из-за внутренних ошибок.In extremely rare circumstances, Query Store can end up in the ERROR state because of internal errors.

Если фактическое состояние является режимом только чтения, используйте столбец readonly_reason для определения основной причины.When the actual state is read-only, use the readonly_reason column to determine the root cause. Скорее всего, вы обнаружите, что хранилище запросов перешло в режим "только чтение" из-за превышения квоты на размер.Typically, you find that Query Store transitioned to read-only mode because the size quota was exceeded. В этом случае в столбце readonly_reason будет значение 65536.In that case, the readonly_reason is set to 65536. Другие причины см. в разделе sys.database_query_store_options (Transact-SQL).For other reasons, see sys.database_query_store_options (Transact-SQL).

Рассмотрите следующие действия, чтобы переключить хранилище запросов в режим чтения и записи и активировать сбор данных.Consider the following steps to switch Query Store to read-write mode and activate data collection:

  • Увеличение максимального размера хранилища с помощью параметра MAX_STORAGE_SIZE_MB инструкции ALTER DATABASE.Increase the maximum storage size by using the MAX_STORAGE_SIZE_MB option of ALTER DATABASE.

  • Очистка данных в хранилище запросов с помощью следующей инструкции.Clean up Query Store data by using the following statement:

    ALTER DATABASE [QueryStoreDB] SET QUERY_STORE CLEAR;
    

Можно применить одно или оба этих действия, выполнив следующую инструкцию, которая явно изменяет режим работы обратно на режим чтения и записи:You can apply one or both of these steps by executing the following statement that explicitly changes the operation mode back to read-write:

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE (OPERATION_MODE = READ_WRITE);

Выполните следующие упреждающие действия.Take the following steps to be proactive:

  • Вы можете предотвратить автоматические изменения режима работы, применяя рекомендации.You can prevent silent changes of operation mode by applying best practices. Если размер хранилища запросов всегда будет меньше максимально допустимого значения, это существенно уменьшит вероятность перехода в режим "только чтение".Ensure that Query Store size is always below the maximally allowed value to dramatically reduce a chance of transitioning to read-only mode. Активируйте политику на основе размера, как описано в разделе Настройка хранилища запросов, чтобы хранилище запросов автоматически очищало данные при достижении предельного размера.Activate size-based policy as described in the Configure Query Store section so that Query Store automatically cleans data when the size approaches the limit.
  • Чтобы обеспечить сохранение последних данных, настройте политику на основе времени для регулярного удаления устаревшей информации.To make sure that most recent data is retained, configure time-based policy to remove stale information regularly.
  • Наконец, следует рассмотреть возможность установки автоматического режима записи запросов, так как в нем отфильтровываются запросы, которые обычно меньше всего соответствуют вашей рабочей нагрузке.Finally, consider setting Query Store Capture Mode to Auto because it filters out queries that are usually less relevant for your workload.

Состояние ошибкиERROR state

Чтобы восстановить хранилище запросов, попробуйте явно установить режим чтения и записи и проверьте фактическое состояние еще раз.To recover Query Store, try explicitly setting the read-write mode and check the actual state again.

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE (OPERATION_MODE = READ_WRITE);
GO

SELECT actual_state_desc, desired_state_desc, current_storage_size_mb,
    max_storage_size_mb, readonly_reason, interval_length_minutes,
    stale_query_threshold_days, size_based_cleanup_mode_desc,
    query_capture_mode_desc
FROM sys.database_query_store_options;

Если проблема сохраняется, это означает повреждение данных в хранилище запросов, сохраненных на диске.If the problem persists, it indicates that corruption of Query Store data is persisted on the disk.

В версии SQL Server 2017 (14.x);SQL Server 2017 (14.x) и выше хранилище запросов можно восстановить, выполнив хранимую процедуру sp_query_store_consistency_check в соответствующей базе данных.Starting with SQL Server 2017 (14.x);SQL Server 2017 (14.x), Query Store can be recovered by executing the sp_query_store_consistency_check stored procedure within the affected database. Прежде чем пытаться выполнять операцию восстановления, необходимо отключить хранилище запросов.Query Store must be disabled before you attempt the recovery operation. В версии SQL Server 2016 (13.x);SQL Server 2016 (13.x) необходимо очистить данные в хранилище запросов, как показано ниже.For SQL Server 2016 (13.x);SQL Server 2016 (13.x), you need to clear the data from Query Store as shown.

Если восстановление выполнить не удалось, можно попробовать очистить хранилище запросов перед включением режима чтения и записи.If the recovery was unsuccessful, you can try clearing Query Store before you set the read-write mode.

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE CLEAR;
GO

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE (OPERATION_MODE = READ_WRITE);
GO

SELECT actual_state_desc, desired_state_desc, current_storage_size_mb,
    max_storage_size_mb, readonly_reason, interval_length_minutes,
    stale_query_threshold_days, size_based_cleanup_mode_desc,
    query_capture_mode_desc
FROM sys.database_query_store_options;

Установка оптимального режима записи для хранилища запросовSet the optimal Query Store Capture Mode

Наиболее важные данные следует хранить в хранилище запросов.Keep the most relevant data in Query Store. В приведенной ниже таблице описаны типичные сценарии для каждого режима записи в хранилище запросов.The following table describes typical scenarios for each Query Store Capture Mode:

Режим записи хранилища запросовQuery Store Capture Mode СценарийScenario
всеAll Тщательно анализируйте рабочую нагрузку на основе форм всех запросов и частоты их выполнения, а также других статистических данных.Analyze your workload thoroughly in terms of all queries' shapes and their execution frequencies and other statistics.

Выявление новых запросов в рабочей нагрузке.Identify new queries in your workload.

Обнаруживайте, используются ли динамические запросы для определения возможностей для пользовательской или автоматической параметризации.Detect if ad-hoc queries are used to identify opportunities for user or auto parameterization.

Примечание. Это режим записи по умолчанию в версиях SQL Server 2016 (13.x);SQL Server 2016 (13.x) и SQL Server 2017 (14.x);SQL Server 2017 (14.x).Note: This is the default capture mode in SQL Server 2016 (13.x);SQL Server 2016 (13.x) and SQL Server 2017 (14.x);SQL Server 2017 (14.x).
АвтоматическиAuto Сосредоточьте внимание на важных и действенных запросах.Focus your attention on relevant and actionable queries. Примерами могут служить запросы, которые выполняются регулярно или потребляют ресурсы в значительных объемах.An example is those queries that execute regularly or that have significant resource consumption.

Примечание. Начиная с версии SQL Server 2019 (15.x)SQL Server 2019 (15.x) это режим записи по умолчанию.Note: Starting with SQL Server 2019 (15.x)SQL Server 2019 (15.x), this is the default capture mode.
NoneNone Вы уже записали набор запросов, который хотите отслеживать в среде выполнения, и хотите исключить отвлекающие факторы, которые могут быть внесены другими запросами.You've already captured the query set that you want to monitor in runtime and you want to eliminate the distractions that other queries might introduce.

Значение None подходит для тестовых сред и сред тестирования производительности.None is suitable for testing and benchmarking environments.

Кроме того, значение None подходит для поставщиков программного обеспечения, поставляющих конфигурацию хранилища запросов, настроенную для наблюдения за рабочей нагрузкой приложений.None is also appropriate for software vendors who ship Query Store configuration configured to monitor their application workload.

Значение None следует использовать с осторожностью, поскольку можно упустить возможность отслеживания и оптимизации важных новых запросов.None should be used with caution because you might miss the opportunity to track and optimize important new queries. Старайтесь не использовать None, если этого не требуется в конкретном сценарии.Avoid using None unless you have a specific scenario that requires it.
CustomCustom В версии SQL Server 2019 (15.x)SQL Server 2019 (15.x) реализован режим Custom с использованием команды ALTER DATABASE SET QUERY_STORE.SQL Server 2019 (15.x)SQL Server 2019 (15.x) introduces a Custom capture mode under the ALTER DATABASE SET QUERY_STORE command. Если этот параметр включен, для нового параметра политики записи хранилища запросов доступны дополнительные конфигурации хранилища запросов, что позволяет тонко настраивать сбор данных на конкретном сервере.When enabled, additional Query Store configurations are available under a new Query Store capture policy setting to fine-tune data collection in a specific server.

Новые пользовательские параметры определяют действия, которые выполняются при достижении внутреннего порогового значения времени для политики записи.The new custom settings define what happens during the internal capture policy time threshold. Это временная граница, в пределах которой происходит оценка настраиваемых условий и, если какие-либо из них соблюдаются, разрешается запись запроса в хранилище запросов.This is a time boundary during which the configurable conditions are evaluated and, if any are true, the query is eligible to be captured by Query Store. Дополнительные сведения см. в разделе Параметры ALTER DATABASE SET (Transact-SQL).For more information, see ALTER DATABASE SET Options (Transact-SQL).

Примечание

Курсоры, запросы в хранимых процедурах и скомпилированные в собственном коде запросы всегда записываются, если задан режим записи в хранилище запросов All, Auto или Custom.Cursors, queries inside stored procedures, and natively compiled queries are always captured when Query Store Capture Mode is set to All, Auto, or Custom. Чтобы записывать скомпилированные в собственном коде запросы, включите сбор статистики на уровне запроса с помощью хранимой процедуры sys.sp_xtp_control_query_exec_stats.To capture natively compiled queries, enable collection of per-query statistics by using sys.sp_xtp_control_query_exec_stats.

Храните наиболее важные данные в хранилище запросовKeep the most relevant data in Query Store

Настройте хранилище запросов таким образом, чтобы в нем содержались только нужные данные, и оно будет выполняться непрерывно, предоставляя прекрасные возможности для устранения неполадок с минимальным воздействием на обычную рабочую нагрузку.Configure Query Store to contain only the relevant data so that it runs continuously and provides a great troubleshooting experience with a minimal impact on your regular workload. В следующей таблице приведены рекомендации.The following table provides best practices:

РекомендацииBest practice ПараметрSetting
Ограничение сохраненных исторических данных.Limit retained historical data. Настройте политику на основе времени для активации автоматической очистки.Configure time-based policy to activate autocleanup.
Отфильтровывайте несущественные запросы.Filter out nonrelevant queries. Настройте автоматический режим записи хранилища запросов.Configure Query Store Capture Mode to Auto.
Удаляйте менее важные запросы по достижении максимального размера.Delete less relevant queries when the maximum size is reached. Активируйте политику очистки на основе размера.Activate size-based cleanup policy.

Старайтесь не использовать запросы без параметровAvoid using non-parameterized queries

Использовать запросы без параметров не рекомендуется за исключением случаев, когда этого никак нельзя избежать.Using non-parameterized queries when that isn't necessary isn't a best practice. Примером такой ситуации может служить динамический анализ.An example is in the case of ad-hoc analysis. Кэшированные планы не могут использоваться повторно, что заставляет оптимизатор запросов компилировать запросы для каждого уникального текста запроса.Cached plans can't be reused, which forces Query Optimizer to compile queries for every unique query text. См. рекомендации по использованию принудительной параметризации.For more information, see Guidelines for using forced parameterization.

Кроме того, хранилище запросов может быстро превысить квоту на размер из-за потенциально большого количества разных текстов запросов и, следовательно, большого количества разных планов выполнения с аналогичной формой.Also, Query Store can rapidly exceed the size quota because of a potentially large number of different query texts and consequently a large number of different execution plans with similar shape. В результате производительность рабочей нагрузки может стать неудовлетворительной и хранилище запросов может перейти в режим "только чтение" или постоянно удалять данные в попытке справиться с входящими запросами.As a result, performance of your workload is suboptimal, and Query Store might switch to read-only mode or constantly delete data to try to keep up with the incoming queries.

Следуйте приведенным ниже рекомендациям.Consider the following options:

  • Параметризуйте запросы везде, где это возможно.Parameterize queries where applicable. Например, заключайте запросы в хранимую процедуру или sp_executesql.For example, wrap queries inside a stored procedure or sp_executesql. См. дополнительные сведения о параметрах и повторном использовании планов выполнения.For more information, see Parameters and execution plan reuse.
  • Используйте параметр Оптимизировать для нерегламентированной рабочей нагрузки, если рабочая нагрузка содержит много нерегламентированных пакетов для однократного использования с разными планами запроса.Use the optimize for ad hoc workloads option if your workload contains many single-use ad-hoc batches with different query plans.
    • Сравните число уникальных значений query_hash с общим числом записей в sys.query_store_query.Compare the number of distinct query_hash values with the total number of entries in sys.query_store_query. Если их соотношение близко к 1, ваша нерегламентированная рабочая нагрузка создает разные запросы.If the ratio is close to 1, your ad-hoc workload generates different queries.
  • Применяйте принудительную параметризацию для базы данных или подмножества запросов, если количество разных планов запроса невелико.Apply forced parameterization for the database or for a subset of queries if the number of different query plans isn't large.
    • Используйте структуру плана, чтобы применить принудительную параметризацию только в выбранном запросе.Use a plan guide to force parameterization only for the selected query.
    • Настройте принудительную параметризацию с помощью параметра базы данных Параметризация, если в рабочей нагрузке существует небольшое число разных планов запроса.Configure forced parameterization by using the parameterization database option command, if there are a small number of different query plans in your workload. Примером является ситуация, когда отношение числа разных query_hash к общему числу записей в sys.query_store_query намного меньше чем 1.An example is when the ratio between the count of distinct query_hash and the total number of entries in sys.query_store_query is much less than 1.
  • Установите параметр QUERY_CAPTURE_MODE в значение AUTO, чтобы динамические запросы с небольшим потреблением ресурсов отфильтровывались автоматически.Set QUERY_CAPTURE_MODE to AUTO to automatically filter out ad-hoc queries with small resource consumption.

Старайтесь не использовать шаблоны DROP и CREATE для содержащих объектовAvoid a DROP and CREATE pattern for containing objects

Хранилище запросов связывает запись запроса с содержащим объектом, например хранимой процедурой, функцией или триггером.Query Store associates query entry with a containing object, such as stored procedure, function, and trigger. При повторном создании содержащего объекта создается новая запись запроса для того же текста запроса.When you re-create a containing object, a new query entry is generated for the same query text. Это препятствует отслеживанию статистики производительности для этого запроса с течением времени и использованию механизма принудительного применения планов.This prevents you from tracking performance statistics for that query over time and using a plan forcing mechanism. Чтобы избежать такой ситуации, используйте процесс ALTER <object> для изменения определения содержащего объекта везде, где это возможно.To avoid this situation, use the ALTER <object> process to change a containing object definition whenever it's possible.

Регулярно проверяйте состояние принудительных плановCheck the status of forced plans regularly

Форсирование плана — это удобный механизм, позволяющий исправлять производительность важных запросов и делать их более предсказуемыми.Plan forcing is a convenient mechanism to fix performance for the critical queries and make them more predictable. Как и в случае указаний планов и структур планов, не гарантируется, что это будет использовано в будущих выполнениях.As with plan hints and plan guides, forcing a plan isn't a guarantee that it will be used in future executions. Обычно, когда схема базы данных изменяется так, что объекты, упоминаемые в плане выполнения, изменяются или удаляются, принудительное выполнение плана начинает завершаться сбоем.Typically, when database schema changes in a way that objects referenced by the execution plan are altered or dropped, plan forcing starts failing. В этом случае SQL ServerSQL Server возвращается к перекомпиляции запроса, а фактическая причина сбоя принудительного выполнения отображается в sys.query_store_plan.In that case, SQL ServerSQL Server falls back to query recompilation while the actual forcing failure reason is surfaced in sys.query_store_plan. Следующий запрос возвращает информацию о принудительно выполненных планах.The following query returns information about forced plans:

USE [QueryStoreDB];
GO

SELECT p.plan_id, p.query_id, q.object_id as containing_object_id,
    force_failure_count, last_force_failure_reason_desc
FROM sys.query_store_plan AS p
JOIN sys.query_store_query AS q on p.query_id = q.query_id
WHERE is_forced_plan = 1;

Полный список причин см. в статье sys.query_store_plan.For a full list of reasons, see sys.query_store_plan. Кроме того, можно использовать XEvent query_store_plan_forcing_failed для отслеживания и устранения неполадок с принудительным выполнением планов.You can also use the query_store_plan_forcing_failed XEvent to track and troubleshoot plan forcing failures.

Избегайте переименования баз данных для запросов с принудительными планамиAvoid renaming databases for queries with forced plans

Планы выполнения ссылаются на объекты по трехкомпонентным именам, например database.schema.object.Execution plans reference objects by using three-part names like database.schema.object.

При переименовании базы данных происходит сбой принудительного выполнения планов, что приводит к повторной компиляции при выполнении всех последующих запросов.If you rename a database, plan forcing fails, which causes recompilation in all subsequent query executions.

Использование хранилища запросов на критически важных серверахUsing Query Store in mission-critical servers

Глобальные флаги трассировки 7745 и 7752 можно использовать для повышения уровня доступности баз данных с помощью хранилища запросов.The global trace flags 7745 and 7752 can be used to improve availability of databases by using Query Store. Дополнительные сведения см. в статье о флагах трассировки.For more information, see Trace flags.

  • Флаг трассировки 7745 препятствует поведению по умолчанию, при котором хранилище запросов записывает данные на диск до того, как SQL ServerSQL Server сможет завершить работу.Trace flag 7745 prevents the default behavior where Query Store writes data to disk before SQL ServerSQL Server can be shut down. Это означает, что будут потеряны все собранные данные хранилища запросов, которые еще не сохранены на диске, за период времени, определенный в DATA_FLUSH_INTERVAL_SECONDS.This means that Query Store data that has been collected but not yet persisted to disk will be lost, up to the time window defined with DATA_FLUSH_INTERVAL_SECONDS.
  • Флаг трассировки 7752 включает асинхронную загрузку для хранилища запросов.Trace flag 7752 enables asynchronous load of Query Store. Это позволяет восстановить базу данных и выполнять запросы раньше, чем будет полностью восстановлено хранилище запросов.This allows a database to become online and queries to be executed before Query Store has been fully recovered. По умолчанию загрузка хранилища запросов выполняется в синхронном режиме.The default behavior is to do a synchronous load of Query Store. Этот вариант не позволяет выполнять запросы до полного восстановления хранилища запросов, но зато предотвращает потерю запросов при сборе данных.The default behavior prevents queries from executing before Query Store has been recovered but also prevents any queries from being missed in the data collection.

Примечание

Начиная с версии SQL Server 2019 (15.x)SQL Server 2019 (15.x) это поведение управляется подсистемой и флаг трассировки 7752 не оказывает влияния.Starting with SQL Server 2019 (15.x)SQL Server 2019 (15.x), this behavior is controlled by the engine, and trace flag 7752 has no effect.

Важно!

Если вы используете хранилище запросов для JIT-анализа рабочих нагрузок в SQL Server 2016 (13.x);SQL Server 2016 (13.x), запланируйте установку улучшений масштабируемости производительности в накопительном обновлении 2 (CU2) SQL Server 2016 (13.x);SQL Server 2016 (13.x) SP2 (статья базы знаний 4340759) как можно скорее.If you're using Query Store for just-in-time workload insights in SQL Server 2016 (13.x);SQL Server 2016 (13.x), plan to install the performance scalability improvements in SQL Server 2016 (13.x);SQL Server 2016 (13.x) SP2 CU2 (KB 4340759) as soon as possible. Без этих улучшений, если база данных испытывает значительные рабочие нагрузки, может возникнуть конкуренция циклической блокировки и производительность сервера может снизиться.Without these improvements, when the database is under heavy workloads, spinlock contention may occur and server performance may become slow. В частности, вы можете столкнуться с интенсивной конкуренцией циклической блокировки QUERY_STORE_ASYNC_PERSIST или циклической блокировки SPL_QUERY_STORE_STATS_COOKIE_CACHE.In particular, you may see heavy contention on the QUERY_STORE_ASYNC_PERSIST spinlock or SPL_QUERY_STORE_STATS_COOKIE_CACHE spinlock. После применения этого улучшения хранилище запросов больше не будет вызывать конфликты циклической блокировки.After this improvement is applied, Query Store will no longer cause spinlock contention.

Важно!

Если вы используете хранилище запросов для JIT-анализа рабочих нагрузок в SQL ServerSQL Server (SQL Server 2016 (13.x);SQL Server 2016 (13.x) через SQL Server 2017 (14.x);SQL Server 2017 (14.x)), запланируйте установку улучшений масштабируемости производительности в SQL Server 2016 (13.x);SQL Server 2016 (13.x) с пакетом обновления 2 (SP2) и накопительным обновлением 15 (CU15), SQL Server 2017 (14.x);SQL Server 2017 (14.x) с накопительным обновлением 22 (CU22) и SQL Server 2019 (15.x)SQL Server 2019 (15.x) с накопительным обновлением 8 (CU8) как можно скорее.If you're using Query Store for just-in-time workload insights in SQL ServerSQL Server (SQL Server 2016 (13.x);SQL Server 2016 (13.x) through SQL Server 2017 (14.x);SQL Server 2017 (14.x)), plan to install the performance scalability improvement in SQL Server 2016 (13.x);SQL Server 2016 (13.x) SP2 CU15, SQL Server 2017 (14.x);SQL Server 2017 (14.x) CU22, and SQL Server 2019 (15.x)SQL Server 2019 (15.x) CU8 as soon as possible. Без этого улучшения, если база данных испытывает значительные нерегламентированные рабочие нагрузки, хранилище запросов может потреблять большой объем памяти, а производительность сервера может снизиться.Without this improvement, when the database is under heavy ad-hoc workloads, the Query Store may use a large amount of memory and server performance may become slow. После применения этого улучшения хранилище запросов накладывает внутренние ограничения на объем памяти, которую могут использовать различные компоненты, и может автоматически изменить режим работы на "только для чтения" до тех пор, пока в Компонент Database EngineDatabase Engineне будет возвращен достаточный объем памяти.After this improvement is applied, Query Store imposes internal limits to the amount of memory its various components can use, and can automatically change the operation mode to read-only until enough memory has been returned to the Компонент Database EngineDatabase Engine. Обратите внимание, что ограничения внутренней памяти хранилища запросов не документированы, так как они могут быть изменены.Note that Query Store internal memory limits are not documented because they are subject to change.

См. также разделSee also