SQL Server 2016: introdução ao 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.

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.