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

Применимо к:База данных SQL Azure 2025 (17.x)

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

Поддержка платформы

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

В SQL Server 2022 (16.x) хранилище запросов для доступных для чтения вторичных файлов остается в предварительной версии и поэтому не поддерживается в рабочей среде и по умолчанию отключено. Чтобы включить хранилище запросов только для доступных для чтения вторичных файлов в SQL Server 2022 (16.x), необходимо включить флаг трассировки 12606 для основной и всех доступных для чтения вторичных реплик. Флаг трассировки 12606 не предназначен для рабочих развертываний, основанных на SQL Server 2022 (16.x). Дополнительные сведения см. в заметках о выпуске SQL Server 2022. Для SQL Server 2025 (17.x) хранилище запросов для доступных для чтения вторичных файлов по умолчанию включено .

База данных SQL Azure автоматически регистрируется и включается для поддержки хранилища запросов для доступных для чтения вторичных файлов в поддерживаемых уровнях служб и сценариях высокой доступности. В настоящее время эта функция не поддерживается в гипермасштабировании базы данных SQL Azure.

В настоящее время эта функция не поддерживается в Управляемом экземпляре SQL Azure или базе данных SQL в Microsoft Fabric.

Поддерживаемые сценарии высокой доступности

Прежде чем использовать хранилище запросов для доступных для чтения вторичных файлов в экземпляре SQL Server 2025 (17.x), необходимо настроить группу доступности AlwaysOn .
Для базы данных SQL Azure хранилище запросов для доступных для чтения вторичных файлов поддерживает следующие уровни служб:
- Общая цель с активной георепликацией (без встроенных реплик высокой доступности; требуется конфигурация георепликации для поддержки вторичных)
- Premium (включает встроенные реплики высокой доступности; также поддерживается активная георепликация)
- Критически важный для бизнеса (включает встроенные реплики высокой доступности; активная георепликация также поддерживается)

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

Если хранилище запросов еще не включено в режиме 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);

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

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

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

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

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_SECONDARY) при подключении к читаемой вторичной реплике.

Хранилище запросов для доступных для чтения данных телеметрии в Базе данных SQL Azure

применимо к: База данных SQL Azure

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

is_primary_b: Логическое значение, указывающее, получены ли данные из первичной реплики (true) или вторичной реплики (false)
replica_group_id: целое число, соответствующее роли реплики

Эти столбцы важны для уточнения метрик и данных производительности при анализе нагрузок в наборах реплик. При настройке параметров диагностики для потоковой передачи статистики времени выполнения хранилища запросов в Log Analytics, Центры событий или хранилище Azure убедитесь, что ваши запросы и панели мониторинга учитывают эти столбцы, чтобы правильно сегментировать данные по роли реплики. Дополнительные сведения о настройке параметров диагностики и доступных метрик см. в разделе "Параметры диагностики" в Azure Monitor.

Это важно

Аналитика производительности запросов для базы данных SQL Azure (QPI)does not в настоящее время поддерживает концепцию replica_group_id . Данные, отображаемые на панели управления, будут агрегировать все данные статистики среды выполнения и ожидания из всех реплик.

Рекомендации по производительности хранилища запросов для доступных для чтения вторичных файлов

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

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

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

Для базы данных Azure SQL (не гипермасштабируемая), управляемого экземпляра Azure SQL и SQL Server используется транспортный уровень высокой доступности и аварийного восстановления (HADR) Always On.
Для базы данных Azure SQL в режиме Hyperscale используется другой транспортный уровень, называемый уровнем транспорта Remote Blob I/O. Транспортный уровень удалённого ввода-вывода Blob — это канал связи между вычислительными узлами и серверами службы журналов и страниц. Транспортный уровень удаленного ввода-вывода большого двоичного объекта предоставляет надежный зашифрованный канал для перемещения записей журналов и страниц данных.

Этот путь мультиплексирует данные о выполнении хранилища запросов (текст запроса, планы, статистика времени выполнения и ожидания) вместе с обычным трафиком записи журнала, используя тот же зашифрованный сеанс. Функция имеет собственные очереди записи и получения, которые можно просматривать, запрашивая sys.database_query_store_internal_state представление с точки зрения любой реплики:

SELECT pending_message_count,
       messaging_memory_used_mb
FROM sys.database_query_store_internal_state;

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

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

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

Прежде чем данные 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-20