SQL Server 2016: introdução ao Query Store
Este artigo apresenta um dos novos recursos do SQL Server 2016, o Query Store. Para isso, ele discute um exemplo de uma consulta que apresenta queda de desempenho e sua análise através do Query Store.
Caso já tenha administrado uma ou mais instâncias SQL Server, certamente já deve ter passado pelo seguinte cenário: você chega segunda-feira ao escritório e seu telefone toca. Do outro lado da linha alguém avisa que uma funcionalidade do sistema está lenta e que você precisa analisar. A partir disso, você isola o procedimento chamado pela interface, olha para um enorme plano de execução e começa a se questionar: alguma coisa mudou nesse plano? Se sim, o que? Qual era o tempo médio de execução, consumo de I/O e tempo de CPU?
A menos que o administrador de banco de dados tenha um mecanismo de monitoramento muito detalhado (e igualmente pesado) ou um registro histórico desse procedimento, talvez por ele já ter causado problema no passado, o mais comum é que não se encontre evidências de alterações no plano de execução, menos ainda o que foi alterado. Assim, resta somente tentar identificar possíveis causas da lentidão, analisar e otimizar o plano de execução, considerando elementos como mudanças de estatísticas, otimização do procedimento para parâmetros diferentes do usual, entre outros. Definitivamente, um problema sem resposta simples.
Para auxiliar o administrador de banco de dados a trabalhar com casos de regressão de desempenho de consultas no SQL Server, a Microsoft implementou no produto a funcionalidade Query Store, solução que armazena registros com métricas de desempenho das consultas ao longo do tempo, oferecendo também mecanismos de análise. Esse será o foco deste artigo.
Query store
Em fevereiro de 2011, MVPs de SQL Server do mundo inteiro estavam no campus da Microsoft, em Seattle, participando de um evento onde todo o conteúdo estava sob NDA (Non-Disclosure Agreement ou acordo de não divulgação, em Português). Nesse evento, em uma das palestras ouvimos Conor Cunningham (ver BOX 1) falar sobre algumas ideias para o futuro do SQL Server, e entre os tópicos listados foi citado um item muito interessante: a possibilidade de haver no produto um armazenamento de planos de execução junto com estatísticas sobre o tempo de execução, uso de CPU, I/O e memória para que fosse possível fornecer informações históricas de desempenho sobre consultas e procedimentos.
Na época não era possível saber se já havia algo em desenvolvimento ou se era apenas uma ideia, mas anos depois estamos vendo aparecer no produto o fruto desse trabalho: o Query Store. Segundo o time de desenvolvimento do produto, não foi uma tarefa fácil colocar esse recurso no roadmap do SQL Server, pois como acontece para todo software em desenvolvimento, cada funcionalidade deve ser justificada e conseguir o investimento necessário antes de ter a chance de ser desenvolvida.
BOX 1. Conor Cunningham
É uma figura muito importante para o SQL Server (ver seção Links). Com mais de 17 anos na Microsoft, ele já atuou como arquiteto do Query Processor (que inclui o otimizador de consultas) e hoje é Principal Architect do SQL Server e Azure SQL Database, apoiando as equipes de desenvolvimento nas decisões arquiteturais do produto. Como ele mesmo diz, qualquer problema com o SQL Server é culpa dele. Sendo assim, ele tem a chance de trabalhar com os casos mais complexos, seja de clientes ou do próprio time do produto.
Deixando de lado um pouco da perspectiva histórica e partindo para os detalhes técnicos, é importante definirmos o que é o Query Store, recurso que pode ser traduzido como armazém de consultas. O Query Store é um mecanismo que registra em memória informações sobre a execução de diferentes instruções (consultas ou procedimentos) e, posteriormente, persiste esses dados em disco, evitando, assim, que eles sejam perdidos no caso de algum problema abrupto com o servidor. Os dados armazenados no repositório do Query Store, juntamente com as métricas de desempenho, são agregados em intervalos específicos de tempo (por exemplo, de hora em hora), o que permite que sejam observadas mudanças de comportamento de uma consulta ao longo de dias, semanas ou meses.
Visão arquitetural
Antes de mostrarmos esse recurso em funcionamento, conheceremos um pouco de sua arquitetura. O Query Store pode ser habilitado separadamente por banco de dados e, a partir daí o SQL Server passará a armazenar em tabelas específicas o histórico de execução/planos das instruções SQL executadas mantendo, dentro do mesmo banco, todos os dados capturados."
[...] continue lendo...Artigos relacionados
-
Artigo
-
Artigo
-
Artigo
-
Artigo
-
Artigo