Query Store para réplicas secundárias legíveis (visualização prévia)

Aplica-se a: SQL Server 2022 (16.x) e versões posteriores Base de Dados SQL do AzureAzure SQL Managed Instance

A Query Store para réplicas secundárias legíveis permite insights da Query Store para cargas de trabalho que correm em réplicas secundárias. Quando ativadas, as réplicas secundárias transmitem informações de execução da consulta (como estatísticas de tempo de execução e espera) para a réplica primária, onde os dados são mantidos na Query Store e tornados visíveis em todas as réplicas.

Disponibilidade

Query Store para réplicas secundárias legíveis está disponível a partir do SQL Server 2025 (17.x), assim como Base de Dados SQL do Azure e Azure SQL Managed Instance com a política de atualização Always-up-to-date. Para o SQL Server 2022 (16.x), a Query Store para réplicas secundárias legíveis requer ativar a bandeira de rastreio 12606 para usar a funcionalidade. Para versões anteriores do SQL Server e do Azure SQL Managed Instance com outras políticas de atualização, a Query Store para réplicas secundárias legíveis não está disponível.

A tabela seguinte resume a disponibilidade e o estado ativado do Query store para secundários legíveis.

¹ O armazenamento de consultas para secundários legíveis não está atualmente disponível do nível de serviço Hyperscale do Base de Dados SQL do Azure.
² O Query Store para secundários de leitura mantém-se em pré-visualização para o SQL Server 2022 (16.x), sendo por isso não suportado em produção e desativado por padrão. Para ativar o Query Store apenas para secundários legíveis no SQL Server 2022 (16.x), é necessário ativar o sinalizador de rastreio 12606 na réplica primária e em todas as réplicas secundárias legíveis. A marca de traço 12606 não é destinada a implementações de produção baseadas no SQL Server 2022 (16.x). Para mais informações, consulte as Notas de versão do SQL Server 2022.

Cenários de alta disponibilidade suportados

• Antes de usar o Query Store para réplicas secundárias legíveis numa instância do SQL Server 2025 (17.x), deve ser configurado um Always On availability group.

• Para Base de Dados SQL do Azure, a Query Store para réplicas secundárias legíveis suporta os seguintes níveis de serviço:

  • Uso geral com geo-replicação ativa ou configuração de grupo de failover (sem réplicas de alta disponibilidade incorporadas; requer geo-replicação ou configuração de grupo de failover para suporte secundário)
  • Premium (inclui réplicas de alta disponibilidade incorporadas; também suporta grupos de replicação geográfica ativa ou de failover)
  • Crítico para o negócio (inclui réplicas de alta disponibilidade incorporadas; grupos de geo-replicação ativa ou failover também suportados)

• Para Azure SQL Managed Instance com a política Always-up-to-date, Query Store para réplicas secundárias legíveis suporta os seguintes níveis de serviço:

  • Uso geral com um grupo de failover (sem réplicas de alta disponibilidade incorporadas; requer uma configuração de grupo de failover para suporte secundário)
  • Crítico para o negócio (inclui réplicas integradas de alta disponibilidade)

Ativar a Query Store para réplicas secundárias legíveis

Se Query Store ainda não estiver ativado e estiver em modo READ_WRITE na réplica principal, deve ativá-lo antes de avançar. 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 ativar a Query Store em todas as réplicas secundárias legíveis, ligue-se à réplica primária e execute o seguinte script para cada base de dados que deve ser recrutada para usar a funcionalidade.

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, Base de Dados SQL do Azure.

Depois de ativar o Query Store para réplicas secundárias, pode opcionalmente ativar o ajuste automático para permitir que a funcionalidade de correção automática de planos force 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);

Desativar a Query Store para réplicas secundárias

Para desativar a funcionalidade Query Store para réplicas secundárias em todas as réplicas secundárias, ligue-se à base de dados master na réplica primary e execute o seguinte script para cada base de dados desejada:

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

O Validate Query Store está ativado em réplicas secundárias

Pode validar que Query Store está ativado numa réplica secondary 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 à vista de catálogo sys.database_query_store_options devem indicar que o estado real do Query Store é READ_CAPTURE_SECONDARY com um readonly_reason de 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 réplicas secundárias leituráveis permite-lhe monitorizar o desempenho de qualquer carga de trabalho única e apenas de leitura que possa estar a ser executada em réplicas secundárias. Os dados são agregados no nível da função. Por exemplo, uma configuração SQL Server grupos de disponibilidade distribuídos 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). Em termos de SQL Server, também seria comumente referida como um reencaminhador global, no entanto, a funcionalidade Query Store para réplicas secundárias legíveis irá reconhecê-la e referir-se-á como uma réplica Geo secondary, assumindo que é uma réplica secundária geograficamente distribuída.

Se o AG1 e o AG2 estiverem configurados para permitir ligações de leitura quando uma carga de trabalho de leitura é executada contra qualquer uma das réplicas secundárias do AG1, as estatísticas de execução do Query Store são enviadas para a réplica primária do AG1 e agregadas e persistidas como dados gerados a partir da função secondary antes de serem enviados de volta para 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. Em SQL Server, a coluna replica_name é 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 Query Store em SQL Server Management Studio (SSMS) 21 e versões posteriores fornecem uma lista suspensa Replica, que permite visualizar dados Query Store entre vários conjuntos/funções de réplica. Além disso, dentro da vista Object explorer, o nó Query Store reflete o estado atual do Query Store (ou seja, READ_CAPTURE) se estiver ligado a uma réplica secundária legível.

Query Store para telemetria de réplicas secundárias legíveis no Base de Dados SQL do Azure

Aplica-se a: Base de Dados SQL do Azure

Ao transmitir estatísticas de tempo de execução do Query Store runtime através das definições de diagnóstico da Azure, são incluídas duas colunas para ajudar a identificar a réplica de origem 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 configurar definições de diagnóstico para transmitir estatísticas de tempo de execução da Query Store para Log Analytics, Event Hubs ou Armazenamento do Azure, certifique-se de que as suas consultas e dashboards têm em conta estas colunas para segmentar corretamente os dados por função réplica. Para mais informações sobre como configurar definições de diagnóstico e métricas disponíveis, consulte Definições de diagnóstico em Azure Monitor.

Considerações de desempenho para o Query Store em réplicas secundárias 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 Query Store para réplicas secundárias legíveis está ativado, não cria um endpoint de rede separado. Em vez disso, ele estabelece um novo caminho de comunicação lógica sobre a camada de transporte existente:

• Para Base de Dados SQL do Azure (não-Hyperscale), Azure SQL Managed Instance e SQL Server, isto utiliza a camada de transporte Always On de alta disponibilidade e recuperação de desastres (HADR).

• Para o Base de Dados SQL do Azure 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.

Este caminho multiplexa os dados de execução da Query Store (texto da consulta, planos, estatísticas de execução/espera) juntamente com o tráfego normal de registos de log, usando a mesma sessão encriptada. 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 das réplicas secundárias são mantidos nas mesmas tabelas Query Store na primária, 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 ad hoc de captura de consultas que se aplicam à Query Store no primário também se aplicam a réplicas secundárias. Para mais informações e orientações sobre a gestão de políticas de tamanho e captura de Query Store, consulte Manter os dados mais relevantes em Query Store.

Visibilidade do ID da consulta negativa/ID do plano

IDs negativos indicam marcadores temporários em memória para consultas e planos nas réplicas secundárias antes de serem persistidos na réplica principal.

Antes de os dados do Query Store serem persistidos no primário a partir das réplicas secundárias legíveis, as consultas e os planos podem receber identificadores temporários dentro da representação local em memória do Query Store - o MEMORYCLERK_QUERYDISKSTORE_HASHMAP. Os IDs da consulta e do plano podem aparecer como números negativos e servem como marcadores de posição até que a réplica primária atribua um identificador autoritativo, o que acontece depois que o Query Store determina que uma consulta cumpre os requisitos configurados do modo de captura. 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.

Conteúdo relacionado

• ALTER DATABASE SET OPTIONS (Transact-SQL)
• sys.query_store_replicas
• sys.query_store_plan_forcing_locations (Transact-SQL)
• sys.sp_query_store_force_plan (Transact-SQL)
• Query Store dicas
• Query Store Cenários de Utilização
• sys.database_query_store_options (Transact-SQL)
• Melhores práticas para monitorizar cargas de trabalho com Query Store
• Melhores práticas para gerir o Query Store
• afina a performance com o Query Store