Compartilhar via

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 permite 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, em que os dados são persistidos no Repositório de Consultas e ficam visíveis em todas as réplicas.

Suporte da plataforma

Atualmente, o recurso Repositório de Consultas para secundários legíveis está disponível e tem suporte em produção no SQL Server 2025 (17.x) e no Banco de Dados SQL do Azure. A partir do SQL Server 2025 (17.x) e no Banco de Dados SQL do Azure, o Repositório de Consultas para secundários legíveis é habilitado por padrão.

No SQL Server 2022 (16.x), o Repositório de Consultas para secundários legíveis permanece em versão prévia e, portanto, não tem suporte na produção e está desabilitado por padrão. Para habilitar o Repositório de Consultas para secundários legíveis somente no SQL Server 2022 (16.x), é necessário habilitar o sinalizador de rastreamento 12606 para a réplica primária e todas as réplicas secundárias legíveis. O sinalizador de rastreamento 12606 não se destina a implantações de produção baseadas no SQL Server 2022 (16.x). Para obter mais informações, consulte as notas sobre a versão do SQL Server 2022. Para o SQL Server 2025 (17.x), o recurso Repositório de Consultas em secundários legíveis está ativado por padrão.

Banco de Dados SQL do Azure, todos os bancos de dados são registrados automaticamente e habilitados para dar suporte ao Repositório de Consultas para recursos secundários legíveis, em camadas de serviço com suporte e cenários de alta disponibilidade. Atualmente, esse recurso não tem suporte na Hiperescala do Banco de Dados SQL do Azure.

Atualmente, esse recurso não tem suporte na Instância Gerenciada de SQL do Azure ou no Banco de Dados SQL no Microsoft Fabric.

Cenários de alta disponibilidade suportados

  • Antes de usar o Repositório de Consultas para secundários legíveis em uma instância do SQL Server 2025 (17.x), um grupo de disponibilidade Always On deve ser configurado.

  • 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 internas de alta disponibilidade; requer configuração de replicação geográfica para suporte secundário)
    • Premium (inclui réplicas internas de alta disponibilidade; também há suporte para replicação geográfica ativa)
    • Comercialmente crítico (inclui réplicas internas de alta disponibilidade; também há suporte para replicação geográfica ativa)

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

Se o Query Store ainda não estiver habilitado e estiver no modo READ_WRITE na réplica primária, é necessário 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 que deve ser inscrito para usar o recurso.

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

Habilitar a correção automática de 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 habilitar o Repositório de Consultas para réplicas secundárias, opcionalmente, você pode habilitar o ajuste automático para permitir que o recurso de correção automática de plano force os 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 de 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, conecte-se ao banco de dados master na réplica primary 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);

Verifique se o Repositório de Consultas está habilitado nas réplicas secundárias

Você pode validar se o Repositório de Consultas está habilitado em uma secondary réplica conectando-se ao banco de dados na réplica secundária e executar 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 da visão de catálogo sys.database_query_store_options devem indicar que o estado real do Repositório de Consultas está 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 de um banco de dados (primária) e uma ou mais réplicas somente leitura (secundárias) tratadas como uma unidade lógica. Uma função nesse contexto refere-se à função de uma réplica específica. Quando uma réplica está desempenhando o papel primário, é a réplica de leitura/gravação que pode executar tanto modificações de dados quanto atividades de leitura. Quando uma réplica é configurada para executar apenas atividades de leitura, ela está servindo em uma função secundária (secundária, secundária geográfica, secundária de alta disponibilidade geográfica). As funções podem ser alteradas por meio de eventos de failover planejados ou não planejados. Quando isso acontece, um primário pode se tornar um secundário ou vice-versa.

As funções com suporte no momento são:

  • Primária
  • Secundário
  • Secundário geográfico
  • Geo HA secundário
  • Réplica nomeada

Como funciona

Os dados armazenados sobre consultas podem ser analisados como cargas de trabalho em uma função. O Repositório de Consultas para secundários legíveis oferece a capacidade de monitorar o desempenho de qualquer carga de trabalho exclusiva 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, também parte do AG1

  • Uma réplica primária remota em outro local que faz parte de um grupo de disponibilidade separado (AG2). Em termos do SQL Server, ele também normalmente seria conhecido como um encaminhador global; no entanto, o recurso Repositório de Consultas para réplicas secundárias legíveis reconhecerá e se referirá a ele como uma Geo secondary réplica, supondo ser uma réplica secundária distribuída geograficamente.

Se o AG1 e o AG2 estiverem configurados para permitir conexões somente leitura, quando uma carga de trabalho somente leitura for executada em qualquer uma das réplicas secundárias do AG1, as estatísticas de execução do Armazenamento de Consultas serão enviadas para a réplica primária do AG1, onde são agregadas e mantidas 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 principal do AG2, o fowarder global, seus dados são enviados de volta para a réplica primária do AG1 e mantidos como dados gerados a partir da Geo secondary função.

Do ponto de vista da observabilidade, a exibição do catálogo do sistema sys.query_store_runtime_stats é estendida para ajudar a identificar a função da qual as estatísticas de execução se originaram. Há uma relação entre essa visão e a vista de catálogo de sistema sys.query_store_replicas, que pode fornecer um nome mais amigável para o papel. No SQL Server, a replica_name coluna é NULL. No entanto, a coluna replica_name é preenchida para a camada de serviço de Hyperscale se houver uma réplica nomeada e estiver sendo usada para cargas de trabalho somente leitura.

Um exemplo de uma consulta T-SQL que pode ser usada para fornecer uma análise geral 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 uma lista suspensa Replica, que fornece uma maneira de exibir dados do Repositório de Consultas em vários conjuntos de funções de réplica. Além disso, dentro da exibição do Explorador de Objetos, o nó Query Store reflete o estado atual do Query Store (ou seja, READ_CAPTURE_SECONDARY) se conectado a uma réplica secundária com capacidade de leitura.

Repositório de Consultas para telemetria de secundários legíveis no Banco de Dados SQL do Azure

aplica-se a: Banco de Dados SQL do Azure

Ao transmitir estatísticas de runtime 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 fonte de réplica dos dados de telemetria:

  • is_primary_b: um valor booliano 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 entre conjuntos de réplicas. Ao definir as configurações de diagnóstico para transmitir as estatísticas de tempo de execução do Query Store para o Log Analytics, Hubs de Eventos ou Armazenamento do Azure, verifique se suas consultas e dashboards consideram essas colunas para segmentar os dados corretamente por função de réplica. Para obter mais informações sobre como definir as configurações de diagnóstico e as métricas disponíveis, consulte as configurações de diagnóstico no Azure Monitor.

Importante

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

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

O canal usado por 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 sincronizam 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 de dados e a preparação para failover.

Quando o Repositório de Consultas para secundários legíveis é habilitado, ele não cria um ponto de extremidade de rede separado. Em vez disso, 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 Hiperescala), a Instância Gerenciada de SQL do Azure e o SQL Server, utiliza a camada de transporte Always On de alta disponibilidade e recuperação de desastres (HADR).

  • Para o Azure SQL Database Hyperscale, uma camada de transporte diferente chamada camada de transporte de E/S de Blob Remoto é utilizada. A camada de transporte de I/O de Blob Remoto é o canal de comunicação entre os nós computacionais e o Serviço de Log/Servidores de Página. A camada de transporte de E/S de Blob Remoto fornece um canal criptografado confiável para mover registros de log 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) junto com o tráfego normal de registro de log, usando a mesma sessão criptografada. O recurso tem suas próprias filas de captura de dados e recebimento, que podem ser visualizadas consultando a sys.database_query_store_internal_state perspectiva de exibição de qualquer réplica:

SELECT pending_message_count,
       messaging_memory_used_mb
FROM sys.database_query_store_internal_state;

Os dados dos 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 recompactaçã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 diretrizes sobre como gerenciar políticas de captura e tamanho do Repositório de Consultas, consulte Manter os dados mais relevantes no Repositório de Consultas.

Visibilidade de consulta/ID do plano negativa

IDs negativas indicam espaços reservados temporários na memória para consultas/planos de execução em secundários antes da persistência no primário.

Antes que os dados do Repositório de Consultas sejam mantidos no primário a partir de réplicas secundárias legíveis, as consultas e os planos podem receber identificadores temporários dentro da representação local na memória do Repositório de Consultas – o MEMORYCLERK_QUERYDISKSTORE_HASHMAP. As IDs de consulta e de plano podem aparecer como números negativos e são marcadores 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 configurados para o modo de captura. Se uma política de captura personalizada estiver em vigor, você poderá examinar 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 de tempo de execução/espera e o plano podem ser persistidos e as IDs temporárias locais são substituídas por IDs positivas. Isso também permite que você use a capacidade de forçar ou sugerir planos.

Conteúdo relacionado

  • Last updated on