Quando você cria um novo banco de dados no SQL Server, a opção Estatísticas de atualização automática é habilitada por padrão. Geralmente é recomendado deixar esta opção habilitada. Idealmente, as estatísticas são gerenciadas por um trabalho agendado, e a opção automática é usada como uma rede de segurança – disponível para atualizar as estatísticas caso uma atualização agendada não ocorra ou acidentalmente não inclua todas as estatísticas existentes.

Alguns DBAs dependem exclusivamente de atualizações automáticas para gerenciar estatísticas e, desde que não existam problemas de desempenho relacionados a estatísticas desatualizadas ou com amostragem inadequada, isso é aceitável. Se você estiver contando com essa opção para gerenciar suas estatísticas e tiver algumas tabelas muito grandes, pode valer a pena implementar o sinalizador de rastreamento 2371. Como com qualquer sinalizador de rastreamento, certifique-se de testar com uma carga de trabalho representativa antes de implementá-la em produção. Você já deve estar ciente de que há momentos em que uma atualização automática pode afetar o desempenho do sistema. Por exemplo, a atualização de uma estatística pode introduzir um pico na CPU ou E/S à medida que os dados da tabela ou do índice são lidos, bem como atrasar a execução da consulta enquanto a atualização ocorre. Há outra opção de banco de dados que você pode habilitar para resolver esse atraso de consulta, e abordarei isso mais adiante neste post.

A pergunta que me fazem com frequência é:"Como você sabe se as atualizações automáticas nas estatísticas estão causando problemas de desempenho?" Uma opção é rastreá-los e vincular as atualizações a uma alteração no desempenho. Existem muitas opções para rastrear atualizações e, nesta postagem, analisaremos alguns dos métodos disponíveis para que você possa escolher e implementar o opção que melhor se adapta ao seu método existente de monitoramento de problemas de desempenho.

Rastreamento SQL

Se você estiver executando o SQL Server 2008 R2 ou inferior em seu ambiente, o SQL Trace é um método que pode ser usado para capturar atualizações automáticas. O script de definição de rastreamento usado abaixo captura apenas o evento Auto Stats, que captura quando uma estatística é atualizada automaticamente e quando uma estatística é criada automaticamente. Depois que esse rastreamento for executado por um tempo em seu ambiente, você poderá carregá-lo em uma tabela e consultar a saída para ver quais atualizações ocorreram. O script incluído abaixo mostra um exemplo usando o banco de dados de amostra de estatísticas de beisebol.

Eventos estendidos

Se você estiver executando o SQL Server 2012 ou superior, recomendo usar Eventos Estendidos para capturar atualizações automáticas. Assim como o script SQL Trace, o script de definição de sessão incluído captura apenas os eventos Auto Stats – novamente, atualizações e criações automáticas. Depois que a sessão XE for executada por um tempo, você poderá carregar a saída em uma tabela por meio da interface do usuário e, em seguida, consultá-la para ver quais atualizações ocorreram. O script incluído percorre o mesmo exemplo anterior, mas desta vez usando Eventos Estendidos para coletar os dados.

sys.dm_db_stats_properties

Uma terceira opção que você pode considerar para monitorar as atualizações de estatísticas é o sys.dm_db_stats_properties DMF, que só está disponível no SQL Server 2008 R2 SP2 e superior e no SQL Server 2012 SP1 e superior. Por mais que eu ame esse DMF, essa solução é mais complicada em termos de garantir que você capturou todos os dados e revisar a saída exige mais trabalho. Com o DMF, todas as atualizações automáticas não são rastreadas, apenas atualizamos as estatísticas de tendências para ver quando as atualizações ocorrem.

É uma tarefa simples:você cria uma tabela para armazenar as informações de estatísticas e, em seguida, captura informações do DMF para a tabela regularmente. A chave aqui é descobrir com que frequência capturar os dados. Cada hora é provavelmente um exagero, uma vez por dia pode não ser frequente o suficiente. Eu recomendo começar com um trabalho do SQL Agent que faça um instantâneo dos dados DMF a cada quatro horas. Deixe isso funcionar por alguns dias e, em seguida, verifique seus dados. Se as estatísticas forem atualizadas no máximo uma vez por dia, você poderá aumentar o intervalo para cada oito ou doze horas. Se as estatísticas forem atualizadas facilmente a cada quatro horas, reduza o intervalo para cada duas horas – você quer ter certeza de que está capturando cada atualização. Por esse motivo, para alguns sistemas, sys.dm_db_stats_properties pode não valer o esforço; uma sessão XE ou Trace pode ser mais simples.

Um script de amostra final mostra um exemplo de como você usaria sys.dm_db_stats_properties para atualizar tendências nas estatísticas. Esteja ciente de que este script captura apenas informações de estatísticas para uma tabela. Se você alterar o script para capturar todas as tabelas do banco de dados, haverá muito mais dados para analisar.

Próximas etapas

Faça download dos scripts de amostra e decida qual método você deve usar para rastrear atualizações de estatísticas.

Depois de ter os dados que mostram quando as atualizações automáticas ocorrem, você precisa vinculá-los aos problemas de desempenho conhecidos. Como tal, se você não estiver acompanhando nenhuma métrica de desempenho, os dados de atualização de estatísticas automáticas não ajudarão em nenhum tipo de correlação. Supondo que você tenha carimbos de data/hora para qualquer problema de desempenho, você pode compará-lo com o StartTime e EndTime do Trace, o timestamp do XE, ou last_updated do sys.dm_db_stats_properties DMF, para determinar se a atualização automática afetou o desempenho do sistema.

Se você não puder fazer nenhuma correlação entre as atualizações e os problemas de desempenho, poderá descartar as atualizações como a causa do problema e focar em outra área. Se as atualizações forem a causa raiz, você terá duas opções:desabilitar a opção Estatísticas de atualização automática ou habilitar a opção Estatísticas de atualização automática de forma assíncrona. Ambos têm prós e contras que você, como DBA, deve considerar.

Desativando estatísticas de atualização automática

Se você optar por desabilitar a opção de atualização automática de estatísticas, as duas coisas mais importantes a saber são:

1. Você deve gerenciar suas estatísticas por meio de uma tarefa de manutenção ou tarefa personalizada.
2. As consultas não serão recompiladas quando você atualizar as estatísticas no SQL Server 2008 R2 e abaixo.

Vejo o segundo item como um desafio maior – sou um grande defensor do gerenciamento de estatísticas e espero que seja algo que os DBAs estejam fazendo de qualquer maneira. O problema maior é que, mesmo atualizando as estatísticas normalmente faz com que as consultas sejam recompiladas (para aproveitar as estatísticas atualizadas), isso não ocorrem quando a opção de atualização automática de estatísticas está desabilitada. Já escrevi sobre isso anteriormente e recomendo revisar essas informações se você não estiver familiarizado com esse comportamento. Veja também um post de acompanhamento para opções para resolvê-lo.

Em geral, este não é o caminho que eu recomendo. Existem casos extremos muito específicos em que isso pode ser apropriado, mas prefiro ver um DBA realizar atualizações manuais (por meio de trabalhos agendados) para evitar as atualizações automáticas e deixar a opção ativada como medida de segurança.

Ativando estatísticas de atualização automática de forma assíncrona

Quando você habilita a opção Atualização automática de estatísticas de forma assíncrona, se uma estatística tiver sido invalidada e uma consulta que usa essa estatística for executada, a estatística não será atualizada até que a consulta seja concluída – a atualização é assíncrona. O benefício aqui é que a atualização não afetará a consulta que foi executada; a desvantagem é que a consulta usará o plano existente, que pode não ser mais o plano ideal. Se o plano ainda é ideal dependerá de sua carga de trabalho (por exemplo, uma carga de trabalho de relatórios com consultas de longa duração). Como DBA, você deve pesar os prós e os contras de habilitar essa opção e determinar o que é melhor para seu banco de dados. Observe que, se você estiver executando o SQL Server 2008 a 2012, haverá um vazamento de memória associado a essa configuração. A Microsoft tem atualizações cumulativas disponíveis que fornecem uma correção, mas se você ainda não as tiver aplicado, você enfrenta outra decisão:aplique o CU para poder habilitar a opção ou não aplique o CU e não habilite o opção.

Resumo

A única maneira de saber se as atualizações automáticas nas estatísticas estão afetando o desempenho da consulta é ver uma atualização ocorrer ao mesmo tempo que um problema ou capturar quando ocorrem atualizações e correlacionar os dados com informações adicionais que você está capturando sobre problemas de desempenho. A última opção permite que você seja proativo – mesmo que não tenha problemas de desempenho, pode ser uma boa ideia saber com que frequência as atualizações automáticas ocorrem. Atualizações frequentes podem significar que você precisa revisitar o trabalho do Agente que gerencia estatísticas manualmente. Em geral, deixe a opção de atualização automática de estatísticas habilitada, mas tenha um método para gerenciar estatísticas e use a opção como rede de segurança.