Correção automática de plano no SQL Server

Quanto tempo você gasta solucionando problemas de desempenho como Administrador ou Desenvolvedor de Banco de Dados? Você já o rastreou? Como a porcentagem total média do seu dia, pode não parecer muito tempo, mas quando o problema é sério, você pode passar horas rastreando-o e trabalhando na análise da causa raiz. Às vezes o problema desaparece e você não sabe a verdadeira origem. E ainda pior? Quando você tem que lutar contra esses problemas no meio da noite ou no fim de semana. Você não está apenas lutando para resolver um problema, mas está perdendo seu tempo livre pessoal. Como aliviamos isso? Como tiramos nosso tempo e esforço da equação e corrigimos o desempenho ao mesmo tempo?

O recurso Ajuste Automático no SQL Server 2017 Enterprise Edition e no Banco de Dados SQL do Azure é a primeira etapa para reduzir o tempo que os profissionais de dados gastam para solucionar problemas de desempenho. O recurso inclui Correção Automática de Plano e Gerenciamento Automático de Índice (disponível apenas no Banco de Dados SQL do Azure), que são habilitados independentemente. Neste post, quero focar no recurso de correção automática de plano. Com a correção automática de plano, se o SQL Server descobrir que uma consulta regrediu significativamente, ele forçará o último bom plano conhecido para a consulta a estabilizar o desempenho. Essencialmente, em vez de você, o DBA ou Desenvolvedor, ser chamado no fim de semana sobre o desempenho do sistema, o SQL Server resolverá isso para você. Parece fácil demais, certo? Vamos dar uma olhada.

Sob as Coberturas

Primeiro, é essencial entender que a Correção Automática de Planos usa o Query Store, portanto, deve ser habilitada para o banco de dados. Em segundo lugar, a correção automática do plano é simplesmente a imposição automática do plano. Embora o Query Store seja comercializado como gravador de voo para seu banco de dados que rastreia texto de consulta, planos, estatísticas de tempo de execução e estatísticas de espera, ele também permite que você force um plano para uma consulta para permitir um desempenho consistente. A Correção Automática de Plano é forçar o plano sem a sua intervenção.

Ativando a correção automática do plano

Conforme mencionado, o Repositório de Consultas deve primeiro ser habilitado para o banco de dados do usuário. Isso pode ser feito no SSMS, com T-SQL e com a API REST para Azure SQL DB. Observe que o Repositório de Consultas está habilitado por padrão para bancos de dados no Azure e está desde o quarto trimestre de 2016.

Ativando o Query Store por meio do SSMS

USE [master];
GO
ALTER DATABASE [WideWorldImporters] 
	SET QUERY_STORE = ON;
GO
ALTER DATABASE [WideWorldImporters] 
	SET QUERY_STORE (OPERATION_MODE = READ_WRITE);
GO

Habilitando o Query Store usando T-SQL

O código acima é o T-SQL padrão do SSMS se você fizer o script dele. No Banco de Dados SQL do Azure, você não executa a instrução USE. Se você quiser alterar qualquer uma das opções padrão, leia minha postagem Configurações do repositório de consultas sobre quais são essas opções e considerações para valores alternativos.

Depois que o Repositório de Consultas estiver habilitado, você poderá usar o Portal do Azure, T-SQL ou API EST para habilitar a Correção Automática de Plano no Banco de Dados SQL do Azure ((e C# e PowerShell estão em andamento). Só pode ser habilitado com T-SQL no SQL Server 2017.

Habilitando a correção automática de plano no Portal do Azure

ALTER DATABASE [WideWorldImporters] 
	SET AUTOMATIC_TUNING (
		FORCE_LAST_GOOD_PLAN = ON
	);
GO

Habilitando a correção automática de plano no T-SQL

Observe que a correção automática de plano será habilitada por padrão para novos bancos de dados no Azure em um futuro próximo. A partir de janeiro de 2018, o Ajuste Automático está sendo habilitado para Bancos de Dados SQL do Azure que ainda não o tinham habilitado, com notificações enviadas aos administradores para que a opção possa ser desabilitada, se desejado.

Como funciona

Com a Correção Automática de Plano habilitada, o SQL Server monitora o desempenho da consulta usando os dados do Repositório de Consultas. Ele procura uma mudança significativa* no desempenho da CPU** com uma janela de 48 horas***. Observe os asteriscos nessa frase ... eles são de propósito:

*O limite para o que constitui uma alteração significativa não está documentado porque a Microsoft se reserva o direito de alterá-lo.
**A métrica usada para determinar a alteração no desempenho (CPU) não está documentada porque a Microsoft se reserva o direito de alterá-la. Ou seja, a Microsoft poderia considerar dimensões adicionais para analisar o desempenho se isso fosse melhor/desempenho melhor do que apenas a CPU.
***O período de tempo em que os dados de desempenho da consulta são comparados não documentado pelo mesmo motivo, a Microsoft reserva-se o direito de alterá-lo.
Observação:embora os itens mencionados não estejam documentados, confirmei com os indivíduos apropriados da Microsoft que essas informações podem ser compartilhadas com a quebra de qualquer NDA. É extremamente importante entender que os valores não são fixos e podem mudar, com a expectativa de que eles mudem para melhorar a confiabilidade do recurso.

A falta de documentação e a possibilidade de alterações no limite podem ser frustrantes para alguns indivíduos, mas aqui está o que é realmente importante lembrar:

A Microsoft captura diariamente terabytes de dados de telemetria operacional dos Bancos de Dados SQL Azure, e esses dados são essenciais para os recursos automáticos que estão sendo desenvolvidos. Esses dados incluem coisas como query_id, query_plan_id e query_hash, e a Microsoft NÃO captura query_text ou query_plan (eles não estão analisando seus dados reais). A Microsoft não está simplesmente arquivando essa telemetria operacional ou usando-a para solucionar problemas, ela está extraindo esses dados e usando-os para desenvolver algoritmos e modelos para permitir que o SQL Server tome decisões inteligentes e independentes.

O SQL Server pode aproveitar a infinidade de dados no Repositório de Consultas que detalham o desempenho das consultas, e a correção automática do plano começa com a comparação do desempenho atual de uma consulta com o desempenho anterior para determinar se há uma regressão no desempenho. O desempenho caiu ou piorou e, em caso afirmativo, é uma quantidade significativa?

Se houver uma regressão no desempenho da consulta, o SQL Server forçará o último bom plano conhecido para essa consulta, que obviamente é extraído do Query Store. Mas não para por aí. O SQL Server continua monitorando o desempenho – ainda usando o Query Store – para confirmar se o plano forçado ainda é um bom plano para essa consulta, o que significa que a consulta com o plano forçado tem um desempenho melhor do que a versão regredida. Se essa consulta não tiver um desempenho melhor, ela desforçará o plano. Um plano também pode não ser forçado se houver uma recompilação ou se o forçamento falhar.

Este ciclo continua; se uma consulta tiver um plano forçado e esse plano não for forçado por um dos motivos mencionados acima, esse mesmo plano poderá ser forçado novamente mais tarde ou poderá haver outro plano forçado para essa consulta posteriormente. Este é um processo contínuo que ocorre desde que você tenha a opção Correção Automática de Plano habilitada para o banco de dados. Agora, o interessante é que você pode olhar para as mesmas informações que esse recurso captura e usá-lo forçar planos manualmente. Ou seja, no SQL Server 2017 Enterprise Edition e no Banco de Dados SQL do Azure, esses dados estão sendo coletados no DMV sys.dm_db_tuning_recommendations mesmo quando o recurso de correção automática de plano não está habilitado, para que você possa examinar esses dados e seguir suas recomendações para forçar planos para consultas específicas por conta própria. Observe que, se você forçar um plano usando recomendações de sys.dm_db_tuning_recommendations, ele nunca será desforçado automaticamente. Além disso, se você tiver a Correção Automática de Plano habilitada e forçar manualmente um plano, ele nunca será desforçado automaticamente. Apenas os planos que são forçados com o recurso Correção Automática de Planos não serão forçados automaticamente.

Eu realmente vou deixar o SQL Server ter controle?

Se você está cético e se perguntando se pode realmente confiar no SQL Server para tomar uma decisão de forçar um plano, aqui está o que eu o encorajo a lembrar:

Esse recurso foi desenvolvido com uma quantidade impressionante de dados capturados de quase dois milhões de Bancos de Dados SQL do Azure. É um novo recurso no SQL Server 2017, mas chegou à disponibilidade global em 2016 no Azure, portanto, esse recurso está realmente disponível há mais de um ano e foi refinado.
Os engenheiros fizeram alterações no algoritmo ao longo do tempo, pois capturaram mais dados. Ele pode não encontrar todas as regressões que ocorrem – porque uma regressão pode não ser grave o suficiente, mas eu aposto que muitos de vocês preferem ter essa força de recurso com menos frequência do que com muita frequência.
Além disso, se um plano for forçado, mas acabar causando um problema, a capacidade do SQL Server de se recuperar disso e cancelar a força do plano é extremamente confiável e acontece muito rapidamente.

Resumo

Você pode não se sentir confortável com a ideia de o SQL Server resolver problemas de desempenho para você. Mas esse desconforto é porque você acha que vai tomar uma decisão ruim? Ou você está preocupado com a automação assumindo o seu trabalho? Pergunta bem direta, eu sei. Se for o primeiro, minha recomendação é examinar os dados capturados em sys.dm_db_tuning_recommendations (sem habilitar a correção automática de plano) e ver o que o SQL Server gostaria de fazer. Está de acordo com o que você faria? Ele encontra regressões que você pode perder? Se você não deseja habilitar o recurso porque tem medo de não ter o que fazer de repente, recomendo que você leia a postagem recente de Conor Cunningham, Como a velocidade da nuvem ajuda os DBAs do SQL Server. A Microsoft não está tentando codificá-lo para fora de um trabalho. Eles estão simplesmente tentando lidar com as frutas mais fáceis para que você possa se concentrar em tarefas mais importantes.