Хранилище запросов для доступных для чтения вторичных файлов

Область применения: SQL Server 2022 (16.x) и более поздних версий

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

Функция первоначально появилась в SQL Server 2022 (16.x), однако по умолчанию она была отключена и требуется флаг трассировки для включения. Это было связано с тем, что эта функция была и остается в состоянии предварительной версии для SQL Server 2022 (16.x).

Начиная с предварительной версии SQL Server 2025 (17.x), хранилище запросов для доступных для чтения вторичных файлов по умолчанию включено.

Это важно

В SQL Server 2022 (16.x) Хранилище запросов для доступных для чтения вторичных реплик является предварительной функцией и требует применения флага трассировки 12606 как к первичной реплике, так и ко всем вторичным репликам, доступным для чтения. Он не предназначен для рабочих развертываний, основанных на SQL Server 2022 (16.x). Дополнительные сведения см. в заметках о выпуске SQL Server 2022.

Для предварительной версии SQL Server 2025 (17.x) функция включена по умолчанию и флаг трассировки 12606 не требуется. Включение этого флага трассировки приводит к отключению функции.

Включение хранилища запросов для доступных для чтения вторичных файлов

Прежде чем использовать хранилище запросов для доступных для чтения вторичных файлов в экземпляре предварительной версии SQL Server 2025 (17.x), необходимо настроить группу доступности AlwaysOn .

Если хранилище запросов еще не включено в режиме READ_WRITE на основной реплике, сначала его необходимо включить, прежде чем продолжить. Выполните следующий скрипт для каждой требуемой базы данных на первичной реплике:

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

Чтобы включить хранилище запросов во всех доступных для чтения вторичных файлов, подключитесь к первичной реплике и выполните следующий скрипт для каждой базы данных, которая должна быть включена для использования этой функции.

ALTER DATABASE [Database_Name]
    FOR SECONDARY
    SET QUERY_STORE = ON
    (OPERATION_MODE = READ_WRITE);

Включите автоматическую коррекцию планов для вторичных реплик

После включения хранилища запросов для вторичных реплик можно, при желании, включить автоматическую настройку, чтобы функция автоматического исправления планов могла принудительно применять планы на вторичных репликах. Это позволяет оптимизатору запросов автоматически выявлять и устранять проблемы с производительностью запросов, вызванные регрессией плана выполнения на вторичных репликах.

Чтобы включить автоматическое исправление плана для вторичных реплик, подключитесь к первичной реплике и выполните следующий скрипт для каждой требуемой базы данных:

ALTER DATABASE [Database_Name]
FOR SECONDARY
SET AUTOMATIC_TUNING (FORCE_LAST_GOOD_PLAN = ON);

Отключение хранилища запросов для вторичных реплик баз данных

Чтобы отключить функцию хранилища запросов для вторичных реплик во всех вторичных репликах, подключитесь к master базе данных на реплике primary и выполните следующий скрипт для каждой требуемой базы данных:

ALTER DATABASE [Database_Name]
    FOR SECONDARY
    SET QUERY_STORE = ON
    (OPERATION_MODE = READ_ONLY);

Проверите, что хранилище запросов включено на вторичных репликах

Вы можете проверить, включено ли хранилище запросов на реплике, подключившись к базе данных на вторичной реплике secondary и выполните следующую инструкцию T-SQL:

SELECT desired_state_desc,
       actual_state_desc,
       readonly_reason
FROM sys.database_query_store_options;

Результаты запроса представления каталога sys.database_query_store_options должны указывать на то, что фактическое состояние хранилища запросов — READ_CAPTURE_SECONDARY, с readonly_reason8.

`desired_state_desc`	`actual_state_desc`	`readonly_reason`
`READ_CAPTURE_SECONDARY`	`READ_CAPTURE_SECONDARY`	`8`

Замечания

Терминология

Набор реплик определяется как реплика чтения и записи базы данных (первичная) и одна или несколько реплик только для чтения (вторичная), которые рассматриваются как логическая единица. В данном контексте роль относится к функции конкретной реплики. Когда реплика выполняет основную роль, это реплика чтения и записи, которая может производить как изменения данных, так и действия чтения. Если реплика настроена только для чтения, она обслуживается в вторичной роли (вторичная, геоторичная, геоторичная, геодоступная вторичная). Роли могут изменяться путем запланированных или незапланированных событий переключения на резерв; когда это происходит, основной компонент может стать вторичным, или наоборот.

В настоящее время поддерживаются роли:

Primary
Secondary
Гео вторичное
Вторичная географическая отказоустойчивость
Именованная реплика

Принцип работы

Данные, связанные с запросами, можно анализировать как нагрузки по ролям. Хранилище запросов для читаемых вторичных реплик позволяет отслеживать производительность любой уникальной рабочей нагрузки, доступной только для чтения, которая может выполняться на вторичных копиях. Данные агрегируются на уровне роли. Например, конфигурация распределенных групп доступности SQL Server может состоять из следующих элементов:

Одна первичная реплика, часть группы доступности 1 (AG1)
Две локальные вторичные реплики также являются частью AG1
Одна удаленная первичная реплика в другом расположении, которая входит в отдельную группу доступности (AG2). В терминах SQL Server это также обычно называют глобальным пересылателем, однако хранилище запросов для вторичных реплик, доступных для чтения, будет распознавать и называть ее Geo secondary репликой, предполагая, что это географически распределенная вторичная реплика.

Если AG1 и AG2 настроены для разрешения подключений только для чтения, и рабочая нагрузка только для чтения выполняется на любой из вторичных реплик AG1, статистика выполнения хранилища запросов отправляется в основную реплику AG1, агрегируется и сохраняется в виде данных, сгенерированных из роли secondary, прежде чем эти данные отправляются обратно во все вторичные реплики, включая глобальный пересылщик в AG2. Когда отдельная рабочая нагрузка выполняется в отношении AG2, глобальный пересылатель, данные отправляются обратно в основную реплику AG1 и сохраняются в качестве данных, созданных из Geo secondary роли.

С точки зрения наблюдаемости представление системного каталога sys.query_store_runtime_stats расширено, чтобы определить роль, из которой возникла статистика выполнения. Существует связь между этим представлением и представлением системного каталога sys.query_store_replicas, которое может предоставить более удобочитаемое имя роли. В SQL Server столбец replica_name есть NULL. Однако столбец replica_name заполняется для уровня служб гипермасштабирования, если существует именованная реплика, и она используется для рабочих нагрузок только для чтения.

Пример запроса t-sql, который можно использовать для предоставления общего анализа топ-50 запросов за последние 8 часов, которые использовали ресурсы ЦП со всех реплик будет:

-- Top 50 queries by CPU across all replicas in the last 8 hours
DECLARE @hours AS INT = 8;

SELECT TOP 50 qsq.query_id,
              qsp.plan_id,
              CASE qrs.replica_group_id WHEN 1 THEN 'PRIMARY' WHEN 2 THEN 'SECONDARY' WHEN 3 THEN 'GEO SECONDARY' WHEN 4 THEN 'GEO HA SECONDARY' ELSE CONCAT('NAMED REPLICA_', qrs.replica_group_id) END AS replica_type,
              qsq.query_hash,
              qsp.query_plan_hash,
              SUM(qrs.count_executions) AS sum_executions,
              SUM(qrs.count_executions * qrs.avg_logical_io_reads) AS total_logical_reads,
              SUM(qrs.count_executions * qrs.avg_cpu_time / 1000.0) AS total_cpu_ms,
              AVG(qrs.avg_logical_io_reads) AS avg_logical_io_reads,
              AVG(qrs.avg_cpu_time / 1000.0) AS avg_cpu_ms,
              ROUND(TRY_CAST (SUM(qrs.avg_duration * qrs.count_executions) AS FLOAT) / NULLIF (SUM(qrs.count_executions), 0) * 0.001, 2) AS avg_duration_ms,
              COUNT(DISTINCT qsp.plan_id) AS number_of_distinct_plans,
              qsqt.query_sql_text
FROM sys.query_store_runtime_stats_interval AS qsrsi
     INNER JOIN sys.query_store_runtime_stats AS qrs
         ON qrs.runtime_stats_interval_id = qsrsi.runtime_stats_interval_id
     INNER JOIN sys.query_store_plan AS qsp
         ON qsp.plan_id = qrs.plan_id
     INNER JOIN sys.query_store_query AS qsq
         ON qsq.query_id = qsp.query_id
     INNER JOIN sys.query_store_query_text AS qsqt
         ON qsq.query_text_id = qsqt.query_text_id
WHERE qsrsi.start_time >= DATEADD(HOUR, -@hours, GETUTCDATE())
GROUP BY qsq.query_id, qsq.query_hash, qsp.query_plan_hash, qsp.plan_id, qrs.replica_group_id, qsqt.query_sql_text
ORDER BY SUM(qrs.count_executions * qrs.avg_cpu_time / 1000.0) DESC, AVG(qrs.avg_cpu_time / 1000.0) DESC;

Отчеты хранилища запросов в SQL Server Management Studio (SSMS) 21 и более поздних версиях предоставляют раскрывающийся список реплик , который предоставляет способ просмотра данных хранилища запросов в различных наборах или ролях реплик. Кроме того, в представлении обозревателя объектов узел хранилища запросов отражает текущее состояние хранилища запросов (то есть READ_CAPTURE) при подключении к доступной для чтения вторичной реплике.

Видимость идентификатора или идентификатора плана отрицательного запроса

Отрицательные идентификаторы указывают временные заполнители в памяти для запросов или планов на вторичных системах перед сохранением на основном сервере.

Прежде чем данные Query Store сохраняются на главном узле из доступных для чтения вторичных реплик, запросы и планы могут получить временные идентификаторы в локальной памяти представления Query Store — MEMORYCLERK_QUERYDISKSTORE_HASHMAP. Идентификаторы запросов и планов могут отображаться как отрицательные числа и являются заполнителями, пока первичная реплика не назначает достоверный идентификатор, который возникает после того, как хранилище запросов определяет, что запрос соответствует требованиям настроенного режима захвата. Если политика захвата данных настроена, вы можете проверить требования, которые необходимо выполнить, запросив представление системного sys.database_query_store_options каталога.

SELECT query_capture_mode_desc,
       capture_policy_execution_count,
       capture_policy_total_compile_cpu_time_ms,
       capture_policy_total_execution_cpu_time_ms
FROM sys.database_query_store_options;

После того как запрос определяется как зафиксированный, его статистика выполнения и ожидания, а также план могут сохраняться, и локальные временные идентификаторы заменяются положительными идентификаторами. Это также позволяет использовать возможности принудительного или указания плана.

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2025-11-08