Benjamin Nevarez é um consultor independente com sede em Los Angeles, Califórnia, especializado em ajuste e otimização de consultas do SQL Server. Ele é o autor de “SQL Server 2014 Query Tuning &Optimization” e “Inside the SQL Server Query Optimizer” e coautor de “SQL Server 2012 Internals”. Com mais de 20 anos de experiência em bancos de dados relacionais, Benjamin também foi palestrante em muitas conferências do SQL Server, incluindo o PASS Summit, SQL Server Connections e SQLBits. O blog de Benjamin pode ser encontrado em http://www.benjaminnevarez.com e ele também pode ser contatado por e-mail em admin em benjaminnevarez ponto com e no twitter em @BenjaminNevarez.
Você já encontrou uma regressão de plano após uma atualização do SQL Server e queria saber qual era o plano de execução anterior? Você já teve um problema de desempenho de consulta devido ao fato de que uma consulta inesperadamente recebeu um novo plano de execução? No último PASS Summit, Conor Cunningham descobriu um novo recurso do SQL Server, que pode ser útil para resolver problemas de desempenho relacionados a essas e outras mudanças nos planos de execução.
Esse recurso, chamado de Repositório de Consultas, pode ajudá-lo com problemas de desempenho relacionados a alterações de plano e estará disponível em breve no SQL Azure e posteriormente na próxima versão do SQL Server. Embora seja esperado que esteja disponível na Enterprise Edition do SQL Server, ainda não se sabe se estará disponível na Standard ou em qualquer outra edição. Para entender os benefícios do Repositório de Consultas, deixe-me falar brevemente sobre o processo de solução de problemas de consulta.
Por que uma consulta é lenta?
Depois de detectar que um problema de desempenho ocorre porque uma consulta está lenta, a próxima etapa é descobrir o motivo. Obviamente, nem todo problema está relacionado a mudanças de planos. Pode haver vários motivos pelos quais uma consulta com bom desempenho fica repentinamente lenta. Às vezes, isso pode estar relacionado ao bloqueio ou a um problema com outros recursos do sistema. Algo mais pode ter mudado, mas o desafio pode ser descobrir o quê. Muitas vezes não temos uma linha de base sobre o uso de recursos do sistema, estatísticas de execução de consultas ou histórico de desempenho. E geralmente não temos ideia de qual era o plano antigo. Pode ser que alguma mudança, por exemplo, dados, esquema ou parâmetros de consulta, tenha feito o processador de consulta produzir um novo plano.
Mudanças do plano
Na sessão, Conor usou a ferramenta Picasso Database Query Optimizer Visualizer, embora sem mencioná-la pelo nome, para mostrar por que os planos na mesma consulta mudaram e explicou o fato de que planos diferentes podem ser selecionados para a mesma consulta com base em a seletividade de seus predicados. Ele ainda mencionou que a equipe do otimizador de consultas usa essa ferramenta, que foi desenvolvida pelo Indian Institute of Science. Um exemplo da visualização (clique para ampliar):
Picasso Database Query Optimizer Visualizer Cada cor no diagrama é um plano diferente e cada plano é selecionado com base na seletividade dos predicados. Um fato importante é que quando um limite é cruzado no gráfico e um plano diferente é selecionado, na maioria das vezes o custo e o desempenho de ambos os planos devem ser semelhantes, pois a seletividade ou número estimado de linhas mudou apenas ligeiramente. Isso pode acontecer, por exemplo, quando uma nova linha é adicionada a uma tabela que se qualifica para o predicado usado. No entanto, em alguns casos, principalmente devido a limitações no modelo de custo do otimizador de consultas em que não é possível modelar algo corretamente, o novo plano pode ter uma grande diferença de desempenho em relação ao anterior, gerando um problema para sua aplicação. A propósito, os planos mostrados no diagrama são o plano final selecionado pelo otimizador de consultas, não confunda isso com as muitas alternativas que o otimizador deve considerar para selecionar apenas uma.
Um fato importante, na minha opinião, que Conor não abordou diretamente, foi a mudança de planos devido a regressões após alterações em atualizações cumulativas (CUs), service packs ou atualizações de versão. Uma grande preocupação que vem à mente com as alterações dentro do otimizador de consulta são as regressões de plano. O medo de regressões de planos tem sido considerado o maior obstáculo para melhorias no otimizador de consultas. Regressões são problemas introduzidos após uma correção ter sido aplicada ao otimizador de consulta e, às vezes, referidas como o clássico “dois ou mais erros fazem um acerto”. Isso pode acontecer quando, por exemplo, duas estimativas ruins, uma superestimando um valor e a segunda subestimando-o, se anulam, felizmente dando uma boa estimativa. A correção de apenas um desses valores pode agora levar a uma má estimativa que pode impactar negativamente na escolha da seleção do plano, causando uma regressão.
O que o repositório de consultas faz?
Conor mencionou que o Query Store funciona e pode ajudar com o seguinte:
- Armazenar o histórico dos planos de consulta no sistema;
- Capture o desempenho de cada plano de consulta ao longo do tempo;
- Identifique as consultas que "ficaram mais lentas recentemente";
- Permitir que você force planos rapidamente; e,
- Certifique-se de que isso funcione nas reinicializações, atualizações e recompilações de consultas do servidor.
Portanto, esse recurso não apenas armazena os planos e as informações de desempenho de consulta relacionadas, mas também pode ajudá-lo a forçar facilmente um plano de consulta antigo, que em muitos casos pode resolver um problema de desempenho.
Como usar o repositório de consultas
Você precisa habilitar o Query Store usando o
ALTER DATABASE CURRENT SET QUERY_STORE = ON; demonstração. Eu tentei na minha assinatura atual do SQL Azure, mas a instrução retornou um erro, pois parece que o recurso ainda não está disponível. Entrei em contato com Conor e ele me disse que o recurso estará disponível em breve. Depois que o Repositório de Consultas estiver habilitado, ele começará a coletar os planos e os dados de desempenho da consulta e você poderá analisar esses dados examinando as tabelas do Repositório de Consultas. Atualmente, posso ver essas tabelas no SQL Azure, mas, como não consegui habilitar o Query Store, os catálogos não retornaram dados.
Você pode analisar as informações coletadas de forma proativa para entender as alterações de desempenho da consulta em seu aplicativo ou retroativamente, caso tenha um problema de desempenho. Depois de identificar o problema, você pode usar as técnicas tradicionais de ajuste de consulta para tentar corrigir o problema ou pode usar o
sp_query_store_force_plan procedimento armazenado para forçar um plano anterior. O plano precisa ser capturado no Repositório de consultas para ser forçado, o que obviamente significa que é um plano válido (pelo menos quando foi coletado; falaremos mais sobre isso depois) e foi gerado pelo otimizador de consultas antes. Para forçar um plano, você precisa do plan_id , disponível no sys.query_store_plan Catálogo. Depois de observar as diferentes métricas armazenadas, que são muito semelhantes ao que está armazenado, por exemplo, em sys.dm_exec_query_stats , você pode tomar a decisão de otimizar para uma métrica específica, como CPU, E/S etc. Em seguida, basta usar uma instrução como esta:EXEC sys.sp_query_store_force_plan @query_id = 1, @plan_id = 1;
Isso está dizendo ao SQL Server para forçar o plano 1 na consulta 1. Tecnicamente, você poderia fazer a mesma coisa usando um guia de plano, mas seria mais complicado e você teria que coletar e encontrar manualmente o plano necessário em primeiro lugar.
Como funciona o repositório de consultas?
Na verdade, forçar um plano usa guias de plano em segundo plano. Conor mencionou que “quando você compila uma consulta, adicionamos implicitamente uma dica USE PLAN com o fragmento do plano XML associado a essa instrução”. Assim, você não precisa mais usar um guia de plano. Lembre-se também de que, assim como usar um guia de planos, não é garantido ter exatamente o plano obrigatório, mas pelo menos algo semelhante a ele. Para um lembrete de como os guias de plano funcionam, dê uma olhada neste artigo. Além disso, você deve estar ciente de que existem alguns casos em que forçar um plano não funciona, um exemplo típico é quando o esquema foi alterado, ou seja, se um plano armazenado usa um índice, mas o índice não existe mais. Nesse caso, o SQL Server não pode forçar o plano, realizará uma otimização normal e registrará o fato de que a operação de forçar o plano falhou no
sys.query_store_plan Catálogo. Arquitetura
Sempre que o SQL Server compila ou executa uma consulta, uma mensagem é enviada ao Repositório de Consultas. Isso é mostrado a seguir.
Visão geral do fluxo de trabalho do repositório de consultas As informações de compilação e execução são mantidas primeiro na memória e depois salvas em disco, dependendo da configuração do Query Store (os dados são agregados de acordo com o
INTERVAL_LENGTH_MINUTES parâmetro, cujo padrão é uma hora e liberado para o disco de acordo com o DATA_FLUSH_INTERVAL_SECONDS parâmetro). Os dados também podem ser liberados para o disco se houver pressão de memória no sistema. Em qualquer caso, você poderá acessar todos os dados, tanto na memória quanto no disco, ao executar o sys.query_store_runtime_stats Catálogo. Catálogos
Os dados coletados são mantidos no disco e armazenados no banco de dados do usuário onde o Repositório de Consultas está habilitado (e as configurações são armazenadas em
sys.database_query_store_options . Os catálogos do Repositório de Consultas são:sys.query_store_query_text | Informações de texto de consulta |
sys.query_store_query | Texto da consulta mais o plano usado que afeta as opções SET |
sys.query_store_plan | Planos de execução, incluindo histórico |
sys.query_store_runtime_stats | Estatísticas de tempo de execução da consulta |
sys.query_store_runtime_stats_interval | Horário de início e término dos intervalos |
sys.query_context_settings | Informações de configurações de contexto de consulta |
Visualizações do repositório de consultas
As estatísticas de tempo de execução capturam uma grande quantidade de métricas, incluindo a média, o último, o mínimo, o máximo e o desvio padrão. Aqui está o conjunto completo de colunas para
sys.query_store_runtime_stats :runtime_stats_id | plan_id | runtime_stats_interval_id | ||
execution_type | execution_type_desc | first_execution_time | last_execution_time | count_executions |
avg_duration | last_duration | min_duration | max_duration | stdev_duration |
avg_cpu_time | last_cpu_time | min_cpu_time | max_cpu_time | stdev_cpu_time |
avg_logical_io_reads | last_logical_io_reads | min_logical_io_reads | max_logical_io_reads | stdev_logical_io_reads |
avg_logical_io_writes | last_logical_io_writes | min_logical_io_writes | max_logical_io_writes | stdev_logical_io_writes |
avg_physical_io_reads | last_physical_io_reads | min_physical_io_reads | max_physical_io_reads | stdev_physical_io_reads |
avg_clr_time | last_clr_time | min_clr_time | max_clr_time | stdev_clr_time |
avg_dop | last_dop | min_dop | max_dop | stdev_dop |
avg_query_max_used_memory | last_query_max_used_memory | min_query_max_used_memory | max_query_max_used_memory | stdev_query_max_used_memory |
avg_rowcount | last_rowcount | min_rowcount | max_rowcount | stdev_rowcount |
Colunas em sys.query_store_runtime_stats
Esses dados são capturados apenas quando a execução da consulta termina. O Query Store também considera o
SET da consulta opções, que podem afetar a escolha de um plano de execução, pois afetam coisas como os resultados da avaliação de expressões constantes durante o processo de otimização. Eu abordo este tópico em um post anterior. Conclusão
Este será definitivamente um ótimo recurso e algo que eu gostaria de experimentar o mais rápido possível (a propósito, a demonstração de Conor mostra “SQL Server 15 CTP1”, mas esses bits não estão disponíveis publicamente). O Repositório de Consultas pode ser útil para atualizações que podem ser uma versão CU, service pack ou SQL Server, pois você pode analisar as informações coletadas pelo Repositório de Consultas antes e depois para ver se alguma consulta regrediu. (E se o recurso estiver disponível em edições anteriores, você pode até fazer isso em um cenário de atualização de SKU.) Saber disso pode ajudá-lo a tomar algumas medidas específicas dependendo do problema, e uma dessas soluções pode ser forçar o plano anterior como explicado antes.
