Fala, pessoal!
Continuando a série sobre o Query Store, hoje vou dar algumas dicas pra você, que deseja habilitar o Query Store em produção.
Caso não tenha lido os artigos anteriores:
- Query Store – Parte 01
- Query Store – Parte 02: você está utilizando o Query Store do SQL Server em produção?
- Query Store – Parte 03: Lock grande ao tentar limpar o Query Store
Quando habilitamos o Query Store, ele vem com essas configurações por default:
Falaremos um pouco sobre essas quatro opções de retenção do Query Store destacadas acima.
Max Size(MB)
Essa opção não tem a ver com impacto de performance do Query Store, mas sim com o volume de dados que você vai armazenar.
Na minha experiência de uso, 100 MB não dura muita coisa.
Normalmente utilizo 1 ou 2 GB nessa configuração para conseguir ter mais informações no Query Store.
A Erin Stellato cita em um de seus artigos que já viu um Query Store de produção com 50 GB de informações.
Conseguimos monitorar o espaço utilizado pelo Query Store com a Query abaixo:
SELECT actual_state_desc, desired_state_desc, current_storage_size_mb,
max_storage_size_mb, readonly_reason
FROM sys.database_query_store_options;Depois vou fazer um artigo com um alerta para monitorar esse tamanho e enviar um e-mail.
No Azure SQL Database atual, o default para uma base Basic é de 10 MB; para uma base Standard é de 100 MB e para uma base Premium é de 1 GB.
Query Store Capture Mode
Essa é a opção mais importante para se configurar, caso você tenha medo do Query Store impactar a performance do seu ambiente.
Se ela estiver configurada como ALL, o Query Store vai armazenar todas as queries que são executadas.
Em um ambiente grande ou com muita query Ad Hoc, o número de queries e planos que o Query Store vai armazenar será muito grande, e isso pode gerar uma sobrecarga maior do que o comum no ambiente.
Mudando essa configuração para AUTO, o Query Store vai ignorar queries mais simples que não precisaríamos monitorar.
Quando utilizamos o modo AUTO, as regras exatas que definem se um plano vai ser gravado ou não pelo Query Store não são documentadas. Dessa forma, a Microsoft pode alterar essa regra quando quiser.
Contudo, já consegui pegar em teste (dica de um MVP da Rússia) e mostrarei para vocês em um próximo artigo que falaremos somente sobre esse modo de captura.
Opinião pessoal:
Essa opção deveria vir como default, configurada como AUTO e, se eu quisesse logar todas as execuções de queries, incluindo as mais simples, eu colocaria como ALL. A configuração default devia ser a menos impactante possível.
No Azure SQL Database atual (primeiro quadrimestre de 2019), o default já está vindo como AUTO.
Size Based Cleanup Mode
Essa opção vem por default como AUTO e devemos manter assim.
Com essa configuração o Query Store vai limpar automaticamente seus dados mais antigos e menos custosos quando chegar a 90% de consumo de espaço.
Vale alguns testes no futuro para explorar detalhes sobre como funciona essa opção. Existem alguns XEvents que nos mostram alguns detalhes de como isso funciona.
Stale Query Threshold (Days)
Essa configuração determina quantos dias você vai manter os dados no Query Store. O default é de 30 dias de armazenamento.
Minha sugestão é: se você não for ficar olhando e comparando 30 dias de informações do Query Store, reduza esse valor para uma ou duas semanas.
Em ambientes com um número grande de queries, muitas vezes nem conseguimos ver as informações do Query.
Neste caso, terá que pegar as informações para analisar via Query. Veremos mais detalhes sobre como fazer isso em outros artigos.
Reduzindo o volume de informações armazenadas pode ajudar na velocidade para visualizar esses dados.
No Azure SQL Database atual (primeiro bimestre de 2019), o default também é de 30 dias, exceto em uma database Basic, que vem configurada como sete dias.
Data Flush Interval (Minutes)
Para reduzir o impacto de implantação, os dados do Query Store são armazenados em memória e, posteriormente, é realizado um flush assíncrono para persistir os dados no disco.
Esse flush ocorre a cada 15 minutos por default. Essa configuração eu não altero.
Com ele você pode perder até 15 minutos de informações do Query Store em caso de problema, mas para quem vive hoje do Plan Cache que não tem dado persistido, estamos no lucro com o Query Store.
Statistics Collection Interval
O padrão desse cara é de uma hora e não costumo alterar.
Essa configuração diz que o Query Store agrupará as informações de estatísticas a cada uma hora para cada plano e vai somar o consumo de CPU, disco, memória e etc.
Com esse agrupamento, a quantidade de dados persistida no Query Store é reduzida. Você pode mudar o padrão de 60 minutos para 1, 5, 10, 15, 30, 60 ou 1440 minutos.
Reduzindo, terá informações mais granulares. Contudo, se reduzir esse tempo para 30 minutos, vai armazenar o dobro de espaço que utilizaria com a configuração de 60 minutos, pois a cada 30 minutos um registro será gerado para cada plano na view sys.query_store_runtime_stats.
Repare no exemplo abaixo, onde temos informações do plano 44 armazenadas duas vezes na view sys.query_store_runtime_stats, uma vez para o intervalo das 18h00 às 19h00 e a outra para o intervalo das 19h00 às 20h00.
Mudando para 30 minutos, se essa query for executada o tempo todo, teríamos quatro linhas ao invés de duas linhas nessa view.
O Query Store já vem habilitado por default no Azure SQL Database e está ligado hoje para milhares de databases.
Logo, a Microsoft está assumindo que essa feature é muito válida, e que ela ajuda muito mais do que impacta os ambientes com algum overhead, concordam?
Segue abaixo as configurações default do Query Store para uma base Basic no Azure SQL Database:
Além das configurações de retenção do Query Store, seguem outras melhores práticas ao habilitá-lo:
Utilize a versão mais recente do Management Studio
Com uma versão antiga o SSMS pode não visualizar todos os gráficos que foram desenvolvidos para a utilização do Query Store, então instale a mais recente.
Atualize o seu SQL Server para a última versão
Conforme mostrei neste artigo, já tivemos alguns problemas identificados e corrigidos para o Query Store:
Logo, se habilitar o Query Store em uma versão do SQL que ainda tem bug, estará correndo um risco maior de ser impactado ao habilitar a feature.
Trace Flags 7745 e 7752
Se o seu banco é critico e o Query Store vai armazenar muita informação, vale a pena habilitar os dois Trace Flags abaixo.
Esses dois Trace Flags são suportados pela Microsoft conforme pode ser verificado neste link.
O que eles fazem?
Trace Flag 7745
Query Store por default faz um flush de informações da memória para o disco a cada 15 minutos. Caso você inicie uma operação de shutdown no SQL Server, por default ele vai esperar o Query Store salvar as informações de memória no disco antes de realizar o Shutdown – isso pode atrasar o shutdown dependendo do ambiente.
Imagine um failover do AlwaysOn ter que esperar o Query Store salvar as informações no disco?
- Me ajuda aí, SQL Server, não ligo de perder 15 minutos de informações do Query Store – pode jogar fora essa informação!
Habilitando o Trace Flag 7745, pulamos essa etapa de salvar os dados em disco antes de um Shutdown.
Trace Flag 7752
Esse Trace Flag faz o trabalho inverso do outro. Quando o SQL Server inicia, ele carrega algumas informações internas do Query Store na memória. Em alguns casos isso pode demorar um pouco e as queries não conseguem ser executadas até a finalização desse processo.
Para que o Query Store faça essa subida de informações para a memória de forma assíncrona, sem impactar na execução das queries, temos que habilitar o Trace Flag 7752.
Nesse tempo, o Query Store fica em Read Only, mas para mim isso não tem problema. Posso deixar de ter informações no Query Store – o importante é impactar o mínimo possível o ambiente.
Espero que agora, com essas informações, você possa habilitar o Query Store com mais segurança e impactando menos o ambiente.
É isso ai, pessoal! Até o próximo artigo da série sobre o Query Store.
Referências
De 0 a 10, o quanto você recomendaria este artigo para um amigo?