Repositório de Consultas para secundários legíveis

Aplica-se a: SQL Server 2025 (17.x) Azure SQL Database

O Repositório de Consultas para secundários legíveis habilita insights do Repositório de Consultas para cargas de trabalho executadas em réplicas secundárias. Quando habilitadas, as réplicas secundárias transmitem informações de execução de consulta (como estatísticas de tempo de execução e espera) para a réplica primária, onde os dados são mantidos no Repositório de Consultas e tornados visíveis em todas as réplicas.

Suporte da plataforma

Atualmente, a funcionalidade Query Store para secundários legíveis está disponível e suportada em produção no SQL Server 2025 (17.x) e na Azure SQL Database. A partir do SQL Server 2025 (17.x), e no Azure SQL Database, o Query Store para secundários legíveis está ativado por defeito.

No SQL Server 2022 (16.x), a Loja de Consultas para secundários legíveis permanece em pré-visualização, e por isso não é suportada em produção, estando desativada por defeito. Para ativar a Loja de Consultas para secundários legíveis apenas no SQL Server 2022 (16.x), é necessário ativar uma flag de rastreamento 12606 nas réplicas primárias e em todas as réplicas secundárias legíveis. Trace flag 12606 não se destina a implementações de produção baseadas no SQL Server 2022 (16.x). Para obter mais informações, consulte Notas de versão do SQL Server 2022. No SQL Server 2025 (17.x), a funcionalidade Query Store em secundários legíveis está ativada por defeito.

Azure SQL Database, todas as bases de dados são automaticamente inscritas e ativadas para suportar a funcionalidade Query Store para secundários legíveis, em níveis de serviço suportados e em cenários de alta disponibilidade. Atualmente, esta funcionalidade não é suportada no Azure SQL Database Hyperscale.

Atualmente, esta funcionalidade não é suportada no Azure SQL Managed Instance nem na base de dados SQL no Microsoft Fabric.

Cenários de alta disponibilidade suportados

Antes de usar o Query Store para secundários legíveis numa instância SQL Server 2025 (17.x), deve ser configurado um grupo de disponibilidade Always On .
Para o Banco de Dados SQL do Azure, o Repositório de Consultas para secundários legíveis dá suporte às seguintes camadas de serviço:
- Uso geral com replicação geográfica ativa (sem réplicas de alta disponibilidade integradas; requer configuração de replicação geográfica para suporte secundário)
- Premium (inclui réplicas de alta disponibilidade integradas; replicação geográfica ativa também suportada)
- Essencial para os negócios (inclui réplicas integradas de alta disponibilidade; replicação geográfica ativa também suportada)

Habilitar o Repositório de Consultas para secundários legíveis

Se o Repositório de Consultas ainda não estiver habilitado e no READ_WRITE modo na réplica primária, você deverá habilitá-lo antes de continuar. Execute o seguinte script para cada banco de dados desejado na réplica primária:

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

Para habilitar o Repositório de Consultas em todos os secundários legíveis, conecte-se à réplica primária e execute o script a seguir para cada banco de dados a ser listado para usar o recurso.

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

Ativar o ajuste automático do plano para réplicas secundárias

Aplica-se a: SQL Server 2022 (16.x) e versões posteriores, Banco de Dados SQL do Azure.

Depois de ativar o Repositório de Consultas para réplicas secundárias, poderá, caso assim deseje, ativar o ajuste automático para permitir ao recurso de correção automática de planos forçar planos em réplicas secundárias. Isso permite que o otimizador de consulta identifique e corrija automaticamente problemas de desempenho de consulta causados por regressões do plano de execução em réplicas secundárias.

Para habilitar a correção automática de plano para réplicas secundárias, conecte-se à réplica primária e execute o seguinte script para cada banco de dados desejado:

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

Desabilitar o Repositório de Consultas para réplicas secundárias

Para desabilitar o recurso Repositório de Consultas para réplicas secundárias em todas as réplicas secundárias, conecte-se ao master banco de dados na primary réplica e execute o seguinte script para cada banco de dados desejado:

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

Validar que o Armazenamento de Consultas está habilitado nas réplicas secundárias

Pode validar que o Query Store está ativado numa secondary réplica ligando-se à base de dados na réplica secundária e executando a seguinte instrução T-SQL:

SELECT desired_state_desc,
       actual_state_desc,
       readonly_reason
FROM sys.database_query_store_options;

Os resultados da consulta à exibição de catálogo sys.database_query_store_options devem indicar que o estado real do Repositório de Consultas é READ_CAPTURE_SECONDARY com um readonly_reason de 8.

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

Observações

Terminologia

Um conjunto de réplicas é definido como uma réplica de leitura/gravação (primária) de um banco de dados e uma ou mais réplicas somente leitura (secundárias) tratadas como uma unidade lógica. Uma função neste contexto refere-se ao papel de uma réplica específica. Quando uma réplica está servindo na função principal, é a réplica de leitura/gravação que pode executar modificações de dados e atividade de leitura. Quando uma réplica é configurada para realizar apenas atividade de leitura, ela está servindo numa função secundária (secundária, geo secundária, geo ha secundária). As funções podem mudar por meio de eventos de "failover" planeados ou não planeados; nesses casos, um primário pode tornar-se secundário ou vice-versa.

As funções atualmente suportadas são:

Primary
Secundária
Geo secundário
Geo HA secundário
Réplica nomeada

Como funciona

Os dados armazenados sobre consultas podem ser analisados como cargas de trabalho com base na função. O Query Store para secundários legíveis oferece a capacidade de monitorizar o desempenho de qualquer carga de trabalho única e somente leitura que possa estar sendo executada em réplicas secundárias. Os dados são agregados no nível da função. Por exemplo, uma configuração de grupos de disponibilidade distribuída do SQL Server pode consistir em:

Uma réplica primária, parte do Grupo de Disponibilidade 1 (AG1)
Duas réplicas secundárias locais, que também fazem parte do AG1
Uma réplica primária remota em outro local que faz parte de um grupo de disponibilidade separado (AG2). No contexto do SQL Server, ele também seria comumente referido como um global forwarder; no entanto, a funcionalidade Query Store para secundários legíveis irá reconhecer e referir-se a ele como uma Geo secondary réplica, assumindo que seja uma réplica secundária distribuída geograficamente.

Se o AG1 e o AG2 sejam configurados para permitir ligações de leitura quando uma carga de trabalho de leitura for executada em qualquer uma das réplicas secundárias do AG1, as estatísticas de execução do Repositório de Consultas serão enviadas para a réplica primária do AG1 e agregadas e persistidas como dados que foram gerados a partir da função secondary antes que esses dados sejam remetidos a todas as réplicas secundárias, incluindo o encaminhador global no AG2. Quando uma carga de trabalho separada é executada no primário do AG2, o forwarder global, os seus dados são enviados de volta para a réplica primária do AG1 e são persistidos como dados que foram gerados pela função Geo secondary.

De uma perspetiva de observabilidade, a vista de catálogo do sistema sys.query_store_runtime_stats foi expandida para ajudar a identificar o papel de onde as estatísticas de execução se originaram. Há uma relação entre esse modo de exibição e o sys.query_store_replicas modo de exibição do catálogo do sistema, que pode fornecer um nome mais amigável da função. No SQL Server, a replica_name coluna é NULL. No entanto, a replica_name coluna é preenchida para o nível de serviço Hyperscale se houver uma réplica nomeada presente e estiver a ser usada para cargas de trabalho apenas de leitura.

Um exemplo de uma consulta T-SQL que poderia ser usada para fornecer uma análise global das 50 principais consultas nas últimas 8 horas, que consumiram recursos de CPU de todas as réplicas, seria:

-- 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;

Os relatórios do Repositório de Consultas no SQL Server Management Studio (SSMS) 21 e versões posteriores fornecem um menu suspenso de Réplica, que oferece uma maneira de exibir dados do Repositório de Consultas em vários conjuntos ou funções de réplica. Além disso, dentro da vista do explorador de objetos, o nó da Loja de Consultas reflete o estado atual da Loja de Consultas (ou seja, READ_CAPTURE_SECONDARY) se estiver ligado a uma réplica secundária legível.

Query Store para telemetria secundária legível no Azure SQL Database

se aplica ao: Banco de Dados SQL do Azure

Ao transmitir estatísticas de tempo de execução do Repositório de Consultas por meio das configurações de diagnóstico do Azure, duas colunas são incluídas para ajudar a identificar a origem da réplica dos dados de telemetria:

is_primary_b: Um valor booleano que indica se os dados se originaram da réplica primária (true) ou de uma réplica secundária (false)
replica_group_id: Um inteiro que corresponde à função de réplica

Essas colunas são essenciais para desambiguar métricas e dados de desempenho ao analisar cargas de trabalho em conjuntos de réplicas. Ao definir configurações de diagnóstico para transmitir estatísticas de tempo de execução do Repositório de Consultas para o Log Analytics, Hubs de Eventos ou Armazenamento do Azure, certifique-se de que suas consultas e painéis contabilizem essas colunas para segmentar adequadamente os dados por função de réplica. Para obter mais informações sobre como definir configurações de diagnóstico e métricas disponíveis, consulte Configurações de diagnóstico no Azure Monitor.

Importante

O Query Performance Insight para Azure SQL Database (QPI)does not suporta atualmente este replica_group_id conceito. Os dados exibidos no painel agrupam todos os dados de estatísticas de execução e espera de todas as réplicas.

Considerações de desempenho para o Repositório de Consultas para secundários legíveis

O canal usado pelas réplicas secundárias para enviar informações de consulta de volta para a réplica primária é o mesmo canal usado para manter as réplicas secundárias atualizadas. O que significa channel aqui?

Em uma configuração de grupo de disponibilidade (HADR), as réplicas são sincronizadas entre si usando uma camada de transporte dedicada que carrega blocos de log, confirmações e mensagens de status entre as réplicas primária e secundária. Isso garante a consistência dos dados e a prontidão para failover.

Quando o Repositório de Consultas para secundários legíveis está habilitado, ele não cria um ponto de extremidade de rede separado. Em vez disso, ele estabelece um novo caminho de comunicação lógica sobre a camada de transporte existente:

Para o Banco de Dados SQL do Azure (não Hyperscale), a Instância Gerenciada SQL do Azure e o SQL Server, isso usa a camada de transporte Always On de alta disponibilidade e recuperação de desastres (HADR).
Para Azure SQL Database Hyperscale, é utilizada uma camada de transporte diferente chamada camada de transporte Remote Blob I/O. A camada de transporte de E/S Blob Remoto é o canal de comunicação entre os nós de computação e os Serviços de Registo/Servidores de Páginas. A camada de transporte Remote Blob I/O fornece um canal fiável e encriptado para mover registos de registo e páginas de dados.

Esse caminho multiplexa os dados de execução do Repositório de Consultas (texto de consulta, planos, estatísticas de tempo de execução/espera) juntamente com o tráfego normal de registro de log, usando a mesma sessão criptografada. O recurso tem suas próprias filas de captura e recebimento, que podem ser visualizadas consultando a sys.database_query_store_internal_state exibição da perspetiva de qualquer réplica:

SELECT pending_message_count,
       messaging_memory_used_mb
FROM sys.database_query_store_internal_state;

Os dados de secundários são mantidos nas mesmas tabelas do Repositório de Consultas no primário, o que pode aumentar os requisitos de armazenamento. Sob carga pesada, você pode observar latência ou contrapressão no canal de transporte. As mesmas limitações de captura de consultas ad hoc que se aplicam ao Query Store no primário também se aplicam aos secundários. Para obter mais informações e orientações sobre como gerenciar o tamanho do Repositório de Consultas e as políticas de captura, consulte Manter os dados mais relevantes no Repositório de Consultas.

Visibilidade do ID da consulta negativa/ID do plano

IDs negativos indicam espaços reservados temporários na memória para consultas/planos em instâncias secundárias antes de serem persistidos na instância primária.

Antes que os dados do Repositório de Consultas sejam transferidos para o primário a partir de réplicas secundárias legíveis, consultas e planos podem receber identificadores temporários na representação na memória local do Repositório de Consultas - o MEMORYCLERK_QUERYDISKSTORE_HASHMAP. As IDs de consulta e plano podem aparecer como números negativos e são espaços reservados até que a réplica primária atribua um identificador autoritativo, o que ocorre depois que o Repositório de Consultas determina que uma consulta atende aos requisitos do modo de captura configurado. Se uma política de captura personalizada estiver em vigor, você poderá revisar os requisitos que devem ser atendidos consultando a exibição do catálogo do sys.database_query_store_options sistema.

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;

Depois que uma consulta é designada como capturada, suas estatísticas e plano de tempo de execução/espera podem ser persistidos, e as IDs temporárias locais são substituídas por IDs positivas. Isso também lhe permite usar recursos de forçamento ou sugestão de planos.

Comentários

Esta página foi útil?

Last updated on 2025-11-20