Partilhar via

Práticas recomendadas para monitorizar cargas de trabalho com o Repositório de Consultas

Aplica-se a: SQL Server 2016 (13.x) e versões posteriores Banco de Dados SQL do AzureInstância Gerenciada SQL do AzureAzure Synapse Analytics (somente pool SQL dedicado)banco de dados SQL no Microsoft Fabric

Este artigo descreve as práticas recomendadas para usar o Repositório de Consultas do SQL Server com sua carga de trabalho.

Usar o SQL Server Management Studio mais recente

O SQL Server Management Studio tem um conjunto de interfaces de usuário projetado para configurar o Repositório de Consultas e para consumir dados coletados sobre sua carga de trabalho. Baixe a versão mais recente do SQL Server Management Studio.

Para obter uma descrição rápida sobre como usar o Repositório de Consultas em cenários de solução de problemas, consulte Query Store Azure blogs.

Usar o Query Performance Insight no Banco de Dados SQL do Azure

Se você executar o Repositório de Consultas no Banco de Dados SQL do Azure, poderá usar do Query Performance Insight para analisar o consumo de recursos ao longo do tempo. Embora você possa usar o Management Studio e o Azure Data Studio para obter consumo de recursos detalhado para todas as suas consultas, como CPU, memória e E/S, o Query Performance Insight oferece uma maneira rápida e eficiente de determinar seu efeito no consumo geral de DTU para seu banco de dados. Para obter mais informações, consulte Azure SQL Database Query Performance Insight.

Para monitorar o desempenho no banco de dados SQL do Fabric, use o painel Desempenho do .

Usar o Repositório de Consultas com bancos de dados do Elastic Pool

Você pode usar o repositório de consultas em todos os bancos de dados sem preocupações, mesmo em pools elásticos do Banco de Dados SQL do Azure densamente povoados. Todos os problemas anteriores relacionados ao uso excessivo de recursos que poderiam ter ocorrido quando o Repositório de Consultas foi habilitado para o grande número de bancos de dados nos pools elásticos foram resolvidos.

Comece com a solução de problemas de desempenho de consulta

O fluxo de trabalho de solução de problemas com o Repositório de Consultas é simples, conforme mostrado no diagrama a seguir:

Solução de problemas do Diagrama do Repositório de Consultas: Habilitar o Repositório de Consultas, Permitir que o Repositório de Consultas colete os dados, Identifique e corrija consultas problemáticas.

Habilite o Repositório de Consultas usando o Management Studio, conforme descrito na seção anterior, ou execute a seguinte instrução Transact-SQL:

ALTER DATABASE [DatabaseOne] SET QUERY_STORE = ON;

Leva algum tempo até que o Repositório de Consultas colete o conjunto de dados que representa com precisão sua carga de trabalho. Normalmente, um dia é suficiente mesmo para cargas de trabalho muito complexas. No entanto, você pode começar a explorar os dados e identificar consultas que precisam de sua atenção imediatamente após ativar o recurso. Vá para a subpasta Repositório de Consultas no nó do banco de dados no Pesquisador de Objetos do Management Studio para abrir exibições de solução de problemas para cenários específicos.

As exibições do Repositório de Consultas do Management Studio operam com o conjunto de métricas de execução, cada uma expressa como qualquer uma das seguintes funções estatísticas:

Versão do SQL Server Métrica de execução Função estatística
SQL Server 2016 (13.x) Tempo da CPU, duração, contagem de execução, leituras lógicas, gravações lógicas, consumo de memória, leituras físicas, tempo CLR, grau de paralelismo (DOP) e contagem de linhas Média, Máximo, Mínimo, Desvio Padrão, Total
SQL Server 2017 (14.x) Tempo da CPU, Duração, Contagem de execução, Leituras lógicas, Gravações lógicas, Consumo de memória, Leituras físicas, Tempo CLR, Grau de paralelismo, Contagem de linhas, Memória de log, Memória TempDB e Tempos de espera Média, Máximo, Mínimo, Desvio Padrão, Total

A imagem a seguir mostra como localizar as vistas do Query Store.

Captura de ecrã do SSMS mostrando a localização das vistas do Repositório de Consultas.

A tabela a seguir explica quando usar cada um dos modos de exibição do Repositório de Consultas:

Modo de exibição do SQL Server Management Studio Cenário
Consultas regredidas Identifique consultas para as quais as métricas de execução regrediram recentemente (por exemplo, mudaram para pior).
Use essa exibição para correlacionar os problemas de desempenho observados em seu aplicativo com as consultas reais que precisam ser corrigidas ou melhoradas.
Consumo Geral de Recursos Analise o consumo total de recursos do banco de dados para qualquer uma das métricas de execução.
Use essa exibição para identificar padrões de recursos (cargas de trabalho diárias versus noturnas) e otimizar o consumo geral do seu banco de dados.
Principais consultas consumidoras de recursos Escolha uma métrica de execução de interesse e identifique as consultas que tiveram os valores mais extremos para um intervalo de tempo fornecido.
Use esta exibição para concentrar sua atenção nas consultas mais relevantes que têm o maior efeito no consumo de recursos do banco de dados.
Consultas Com Planos Forçados Lista os planos forçados anteriormente usando o Repositório de Consultas.
Use esta visualização para aceder rapidamente a todos os planos atualmente forçados.
consultas com grande variação Analise consultas com variação de alta execução em relação a qualquer uma das dimensões disponíveis, como duração, tempo de CPU, E/S e uso de memória, no intervalo de tempo desejado.
Use essa exibição para identificar consultas com desempenho amplamente variado que podem estar afetando a experiência do usuário em seus aplicativos.
Estatísticas de espera de consulta Analise as categorias de espera mais ativas em um banco de dados e quais consultas contribuem mais para a categoria de espera selecionada.
Use essa exibição para analisar estatísticas de espera e identificar consultas que possam estar afetando a experiência do usuário em seus aplicativos.

Aplica-se a: Começando com o SQL Server Management Studio v18.0 e o SQL Server 2017 (14.x).
Consultas rastreadas Acompanhe a execução das consultas mais importantes em tempo real. Normalmente, você usa esse modo de exibição quando tem consultas com planos forçados e deseja ter certeza de que o desempenho da consulta é estável.

Dica

Para obter uma descrição detalhada de como usar o Management Studio para identificar as principais consultas que consomem recursos e corrigir aquelas que regrediram devido à alteração de uma opção de plano, consulte Query Store Azure Blogs.

Quando você identifica uma consulta com desempenho abaixo do ideal, sua ação depende da natureza do problema.

  • Se a consulta foi executada com vários planos e o último plano é significativamente pior do que o plano anterior, você pode usar o mecanismo de imposição de plano para forçá-lo. O SQL Server tenta forçar o plano no otimizador. Se a imposição do plano falhar, um XEvent é acionado e o otimizador é instruído a otimizar da maneira normal.

Captura de tela do SSMS do botão de plano de força do Repositório de Consultas.

Observação

O gráfico anterior pode apresentar formas diferentes para planos de consulta específicos, com os seguintes significados para cada status possível:

Forma Significado
Círculo Consulta concluída, o que significa que a execução regular terminou com sucesso.
Quadrado Cancelada, o que significa que uma execução iniciada pelo cliente foi abortada.
Triângulo Falhou, o que significa que uma exceção anulou a execução.

Além disso, o tamanho da forma reflete a contagem de execução da consulta dentro do intervalo de tempo especificado. O tamanho aumenta com um maior número de execuções.

  • Você pode concluir que a sua consulta não tem um índice para uma execução ideal. Essas informações são exibidas no plano de execução da consulta. Crie o índice ausente e verifique o desempenho da consulta usando o Repositório de Consultas.

Captura de tela do SSMS de um plano de Repositório de Consultas, com a notificação de índice ausente realçada.

Se você executar sua carga de trabalho no Banco de Dados SQL, inscreva-se no Supervisor de Índice do Banco de Dados SQL para receber automaticamente recomendações de índice.

  • Em alguns casos, você pode impor a recompilação estatística se vir que a diferença entre o número estimado e o número real de linhas no plano de execução é significativa.
  • Reescreva consultas problemáticas, por exemplo, para tirar proveito da parametrização de consultas ou para implementar uma lógica mais otimizada.

Dica

No Banco de Dados SQL do Azure, considere o recurso de dicas do Repositório de Consultas para forçar dicas de consulta em consultas sem alterações de código. Para mais informações e exemplos, consulte sugestões do Query Store.

Verifique se o Repositório de Consultas coleta dados de consulta continuamente

O Repositório de Consultas pode alterar silenciosamente o modo de operação. Monitore regularmente o estado do Repositório de Consultas para garantir que o Repositório de Consultas está em funcionamento e adotar medidas para evitar falhas devido a causas evitáveis. Execute a seguinte consulta para determinar o modo de operação e exibir os parâmetros mais relevantes:

USE [QueryStoreDB];
GO

SELECT actual_state_desc, desired_state_desc, current_storage_size_mb,
    max_storage_size_mb, readonly_reason, interval_length_minutes,
    stale_query_threshold_days, size_based_cleanup_mode_desc,
    query_capture_mode_desc
FROM sys.database_query_store_options;

A diferença entre o actual_state_desc e o desired_state_desc indica que uma mudança do modo de operação ocorreu automaticamente. A alteração mais comum é que o Repositório de Consultas alterne silenciosamente para o modo somente leitura. Em circunstâncias extremamente raras, o Repositório de Consultas pode acabar no estado ERROR devido a erros internos.

Quando o estado real for somente leitura, use a coluna readonly_reason para determinar a causa raiz. Normalmente, você descobre que o Repositório de Consultas fez a transição para o modo somente leitura porque a cota de tamanho foi excedida. Nesse caso, o readonly_reason é definido como 65536. Por outros motivos, ver sys.database_query_store_options (Transact-SQL).

Considere as seguintes etapas para alternar o Repositório de Consultas para o modo de leitura-gravação e ativar a coleta de dados:

  • Aumente o tamanho máximo de armazenamento usando a opção MAX_STORAGE_SIZE_MB de ALTER DATABASE.

  • Limpe os dados do Query Store usando a seguinte instrução:

    ALTER DATABASE [QueryStoreDB] SET QUERY_STORE CLEAR;

Você pode aplicar uma ou ambas as etapas executando a seguinte instrução que altera explicitamente o modo de operação de volta para leitura-gravação:

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

Siga os seguintes passos para ser proativo:

  • Você pode evitar alterações silenciosas do modo de operação aplicando práticas recomendadas. Certifique-se de que o tamanho do Repositório de Consultas esteja sempre abaixo do valor máximo permitido para reduzir drasticamente a chance de transição para o modo somente leitura. Ative a política baseada em tamanho conforme descrito na seção Configurar o Repositório de Consultas para que o Repositório de Consultas limpe automaticamente os dados quando o tamanho se aproximar do limite.
  • Para garantir que os dados mais recentes sejam mantidos, configure a política baseada em tempo para remover informações obsoletas regularmente.
  • Por fim, considere definir Modo de Captura do Repositório de Consultas como Automático, pois ele filtra consultas que geralmente são menos relevantes para sua carga de trabalho.

Estado de ERRO

Para recuperar o Repositório de Consultas, tente definir explicitamente o modo de leitura-gravação e verifique o estado real novamente.

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE (OPERATION_MODE = READ_WRITE);
GO

SELECT actual_state_desc, desired_state_desc, current_storage_size_mb,
    max_storage_size_mb, readonly_reason, interval_length_minutes,
    stale_query_threshold_days, size_based_cleanup_mode_desc,
    query_capture_mode_desc
FROM sys.database_query_store_options;

Se o problema persistir, isso indica que a corrupção dos dados do Repositório de Consultas persiste no disco.

A partir do SQL Server 2017 (14.x), o Repositório de Consultas pode ser recuperado executando o procedimento armazenado sys.sp_query_store_consistency_check no banco de dados afetado. O Repositório de Consultas deve ser desativado antes de tentar a operação de recuperação. Aqui está uma consulta de exemplo para usar ou modificar para realizar a verificação de consistência e recuperação de QDS:

IF EXISTS (SELECT * FROM sys.database_query_store_options WHERE actual_state=3) 
BEGIN
  BEGIN TRY
    ALTER DATABASE [QDS] SET QUERY_STORE = OFF
    Exec [QDS].dbo.sp_query_store_consistency_check
    ALTER DATABASE [QDS] SET QUERY_STORE = ON
    ALTER DATABASE [QDS] SET QUERY_STORE (OPERATION_MODE = READ_WRITE)
  END TRY
 
  BEGIN CATCH 
    SELECT  
      ERROR_NUMBER() AS ErrorNumber  
      ,ERROR_SEVERITY() AS ErrorSeverity  
      ,ERROR_STATE() AS ErrorState  
      ,ERROR_PROCEDURE() AS ErrorProcedure  
      ,ERROR_LINE() AS ErrorLine  
      ,ERROR_MESSAGE() AS ErrorMessage; 
  END CATCH;   
END

Para o SQL Server 2016 (13.x), você precisa limpar os dados do Repositório de Consultas, conforme mostrado.

Se a recuperação não tiver sido bem-sucedida, você pode tentar limpar o Repositório de Consultas antes de definir o modo de leitura-gravação.

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE CLEAR;
GO

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE (OPERATION_MODE = READ_WRITE);
GO

SELECT actual_state_desc, desired_state_desc, current_storage_size_mb,
    max_storage_size_mb, readonly_reason, interval_length_minutes,
    stale_query_threshold_days, size_based_cleanup_mode_desc,
    query_capture_mode_desc
FROM sys.database_query_store_options;

Evite usar consultas não parametrizadas

Usar consultas não parametrizadas quando isso não é necessário não é uma prática recomendada. Um exemplo é o caso da análise ad hoc. Os planos armazenados em cache não podem ser reutilizados, o que força o Otimizador de Consultas a compilar consultas para cada texto de consulta exclusivo. Para obter mais informações, consulte Diretrizes para o uso de parametrização forçada.

Além disso, o Repositório de Consultas pode exceder rapidamente a cota de tamanho devido a um número potencialmente grande de textos de consulta diferentes e, consequentemente, um grande número de planos de execução diferentes com forma semelhante. Como resultado, o desempenho da sua carga de trabalho está abaixo do ideal, e o Repositório de Consultas pode alternar para o modo somente leitura ou excluir constantemente os dados para tentar acompanhar as consultas recebidas.

Considere as seguintes opções:

  • Parametrizar consultas quando aplicável. Por exemplo, encapsular consultas dentro de um procedimento armazenado ou sp_executesql. Para obter mais informações, consulte Parâmetros e reutilização do plano de execução.
  • Utilize a opção otimizar para cargas de trabalho ad hoc se a sua carga de trabalho contém muitos lotes ad hoc de utilização única com planos de consulta diferentes.
    • Compare o número de valores de query_hash distintos com o número total de entradas em sys.query_store_query. Se a proporção estiver próxima de 1, sua carga de trabalho ad hoc gerará consultas diferentes.
  • Aplique de parametrização forçada para o banco de dados ou para um subconjunto de consultas se o número de planos de consulta diferentes não for grande.
    • Use um guia de plano de para forçar a parametrização apenas para a consulta selecionada.
    • Configure a parametrização obrigatória usando o comando parameterization database option, se houver um pequeno número de planos de consulta diferentes na sua carga de trabalho. Um exemplo é quando a razão entre a contagem de hashes de consulta distintos e o número total de entradas em sys.query_store_query é muito menor que 1.
  • Defina QUERY_CAPTURE_MODE como AUTO para filtrar automaticamente consultas ad hoc com pequeno consumo de recursos.

Dica

Ao usar uma solução de Object-Relational Mapping (ORM), como o Entity Framework (EF), consultas de aplicativos como árvores de consulta LINQ manuais ou certas consultas SQL brutas podem não ser parametrizadas, o que afeta a reutilização do plano e a capacidade de rastrear consultas no Repositório de Consultas. Para obter mais informações, consulte Cache e parametrização de consultas EF e Consultas SQL Brutas do EF.

Localizar consultas não parametrizadas no Repositório de Consultas

Você pode encontrar o número de planos armazenados no Repositório de Consultas usando a consulta abaixo, usando DMVs do Repositório de Consultas, no SQL Server, na Instância Gerenciada SQL do Azure ou no Banco de Dados SQL do Azure:

SELECT count(Pl.plan_id) AS plan_count, Qry.query_hash, Txt.query_text_id, Txt.query_sql_text
FROM sys.query_store_plan AS Pl
INNER JOIN sys.query_store_query AS Qry
    ON Pl.query_id = Qry.query_id
INNER JOIN sys.query_store_query_text AS Txt
    ON Qry.query_text_id = Txt.query_text_id
GROUP BY Qry.query_hash, Txt.query_text_id, Txt.query_sql_text
ORDER BY plan_count desc;

O exemplo a seguir cria uma sessão de Eventos Estendidos para capturar o evento query_store_db_diagnostics, que pode ser útil no diagnóstico do consumo de recursos de consulta. No SQL Server, essa sessão de evento estendida cria um arquivo de evento na pasta Log do SQL Server por padrão. Por exemplo, em uma instalação padrão do SQL Server 2019 (15.x) no Windows, o arquivo de evento (arquivo .xel) deve ser criado na pasta C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\Log. Para a Instância Gerida SQL do Azure, especifique uma localização do Azure Blob Storage em vez disso. Para obter mais informações, consulte XEvent event_file for Azure SQL Managed Instance. O evento 'qds.query_store_db_diagnostics' não está disponível para o Banco de Dados SQL do Azure.

CREATE EVENT SESSION [QueryStore_Troubleshoot] ON SERVER 
ADD EVENT qds.query_store_db_diagnostics(
      ACTION(sqlos.system_thread_id,sqlos.task_address,sqlos.task_time,sqlserver.database_id,sqlserver.database_name))
ADD TARGET package0.event_file(SET filename=N'QueryStore',max_file_size=(100))
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF);

Com estes dados, podes encontrar a contagem de planos no Query Store, bem como muitas outras estatísticas. Procure as colunas plan_count, query_count, max_stmt_hash_map_size_kbe max_size_mb nos dados do evento para entender a quantidade de memória usada e o número de planos que são rastreados pelo Query Store. Se a contagem de planos for maior do que o normal, isso pode indicar um aumento nas consultas não parametrizadas. Use a consulta DMVs do Repositório de Consultas abaixo para revisar as consultas parametrizadas e as consultas não parametrizadas no Repositório de Consultas.

Para consultas parametrizadas:

SELECT qsq.query_id, qsqt.query_sql_text
FROM sys.query_store_query AS qsq 
INNER JOIN sys.query_store_query_text AS qsqt
ON qsq.query_text_id= qsqt.query_text_id 
WHERE qsq.query_parameterization_type<>0 or qsqt.query_sql_text like '%@%';

Para consultas não parametrizadas:

SELECT qsq.query_id, qsqt.query_sql_text
FROM sys.query_store_query AS qsq 
INNER JOIN sys.query_store_query_text AS qsqt
ON qsq.query_text_id= qsqt.query_text_id 
WHERE query_parameterization_type=0;

Evite um padrão DROP e CREATE para conter objetos

O Repositório de Consultas associa a entrada de consulta a um objeto que o contém, como procedimento guardado, função e trigger. Quando você recria um objeto que contém, uma nova entrada de consulta é gerada para o mesmo texto de consulta. Isso impede que se acompanhem as estatísticas de desempenho dessa consulta ao longo do tempo e se utilize um mecanismo de forçamento do plano. Para evitar essa situação, use o processo ALTER <object> para alterar uma definição de objeto contendo sempre que possível.

Verifique regularmente o estado dos planos forçados

O forçamento de planos é um mecanismo conveniente para otimizar o desempenho das consultas críticas e torná-las mais previsíveis. Tal como acontece com dicas de planos e guias de planos, forçar um plano não é uma garantia de que ele será usado em execuções futuras. Normalmente, quando o esquema do banco de dados é alterado de forma a que os objetos referenciados pelo plano de execução sejam modificados ou eliminados, o forçamento do plano começa a falhar. Nesse caso, o SQL Server recorre à recompilação de consulta enquanto o motivo real da falha forçada é apresentado no sys.query_store_plan. A consulta a seguir retorna informações sobre planos forçados:

USE [QueryStoreDB];
GO

SELECT p.plan_id, p.query_id, q.object_id as containing_object_id,
    force_failure_count, last_force_failure_reason_desc
FROM sys.query_store_plan AS p
JOIN sys.query_store_query AS q on p.query_id = q.query_id
WHERE is_forced_plan = 1;

Para obter uma lista completa dos motivos, consulte sys.query_store_plan. Você também pode usar o XEvent query_store_plan_forcing_failed para rastrear e solucionar problemas de imposição de plano.

Dica

No Banco de Dados SQL do Azure, considere o recurso dicas do Repositório de Consultas para forçar dicas de consulta em consultas sem alterações de código. Para obter mais informações e exemplos, consulte dicas do Repositório de Consultas.

Evite renomear bancos de dados em consultas com planos forçados

Os planos de execução fazem referência a objetos usando nomes de três partes, como database.schema.object.

Se você renomear um banco de dados, o esforço de planejamento falhará, o que causará a recompilação em todas as execuções de consulta subsequentes.

Usar o Repositório de Consultas em servidores de missão crítica

Os sinalizadores de rastreamento global 7745 e 7752 podem ser usados para melhorar a disponibilidade de bancos de dados usando o Repositório de Consultas. Para obter mais informações, consulte sinalizadores de rastreamento.

  • O sinalizador de rastreamento 7745 impede o comportamento padrão em que o Repositório de Consultas grava dados no disco antes que o SQL Server possa ser desligado. Isso significa que os dados do Repositório de Consultas que foram coletados, mas ainda não persistiram no disco, serão perdidos, até a janela de tempo definida com DATA_FLUSH_INTERVAL_SECONDS.
  • O sinalizador de rastreamento 7752 permite o carregamento assíncrono do Repositório de Consultas. Isso permite que um banco de dados fique online e que as consultas sejam executadas antes que o Repositório de Consultas tenha sido totalmente recuperado. O comportamento padrão é fazer uma carga síncrona do Repositório de Consultas. O comportamento padrão impede que as consultas sejam executadas antes que o Repositório de Consultas tenha sido recuperado, mas também impede que quaisquer consultas sejam perdidas na coleta de dados.

Observação

A partir do SQL Server 2019 (15.x), esse comportamento é controlado pelo mecanismo e o sinalizador de rastreamento 7752 não tem efeito.

Importante

Se você estiver usando o Repositório de Consultas para informações de carga de trabalho just-in-time no SQL Server 2016 (13.x), planeje instalar as melhorias de escalabilidade de desempenho no SQL Server 2016 (13.x) SP2 CU2 (KB 4340759) o mais rápido possível. Sem essas melhorias, quando o banco de dados está sob cargas de trabalho pesadas, a contenção de spinlock pode ocorrer e o desempenho do servidor pode ficar lento. Em particular, poderá observar uma contenção intensa no spinlock QUERY_STORE_ASYNC_PERSIST ou SPL_QUERY_STORE_STATS_COOKIE_CACHE. Depois de aplicada esta melhoria, o Repositório de Consultas não causará mais contenção de spinlock.

Importante

Se você estiver usando o Repositório de Consultas para obter informações sobre a carga de trabalho just-in-time no SQL Server (SQL Server 2016 (13.x) a SQL Server 2017 (14.x)), planeje instalar a melhoria da escalabilidade de desempenho no SQL Server 2016 (13.x) SP2 CU15, SQL Server 2017 (14.x) CU23 e SQL Server 2019 (15.x) CU9 o mais rápido possível. Sem essa melhoria, quando o banco de dados está sob cargas de trabalho ad hoc pesadas, o Repositório de Consultas pode usar uma grande quantidade de memória e o desempenho do servidor pode ficar lento. Depois que essa melhoria é aplicada, o Repositório de Consultas impõe limites internos à quantidade de memória que seus vários componentes podem usar e pode alterar automaticamente o modo de operação para somente leitura até que memória suficiente tenha sido retornada ao Mecanismo de Banco de Dados. Os limites de memória interna do Repositório de Consultas não estão documentados porque estão sujeitos a alterações.

Usar o Repositório de Consultas na replicação geográfica ativa do Banco de Dados SQL do Azure

O Repositório de Consultas em uma réplica geográfica ativa secundária do Banco de Dados SQL do Azure será uma cópia somente leitura da atividade na réplica primária.

Evite camadas incompatíveis com a replicação geográfica do Banco de Dados SQL do Azure. Um banco de dados secundário deve ter o mesmo tamanho de computação do banco de dados primário e estar na mesma camada de serviço do banco de dados primário. Procure o tipo de espera HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO no sys.dm_db_wait_stats, que indica a limitação da taxa de log de transações na réplica primária devido ao atraso secundário.

Para obter mais informações sobre como estimar e configurar o tamanho do banco de dados SQL secundário do Azure de replicação geográfica ativa, consulte Configurando o banco de dados secundário.

Mantenha o Repositório de Consultas ajustado à sua carga de trabalho

As práticas recomendadas e recomendações para configurar e gerenciar o Repositório de Consultas foram expandidas neste artigo: Práticas recomendadas para gerenciar o Repositório de Consultas.

Conteúdo relacionado