ATUALIZAÇÕES nas Estatísticas

• O número de etapas em um histograma é limitado a 300. No SQL Server 6.5 e anteriores, um histograma teria o número de etapas que caberia em uma página de 2K, com base no tamanho da primeira coluna na chave.
• A opção de banco de dados "atualizar estatísticas automaticamente" é introduzida; anteriormente as estatísticas eram atualizadas apenas manualmente.

• O número de etapas no histograma é reduzido de 300 para 200 (tecnicamente 201, se você incluir a etapa para NULL, supondo que a primeira coluna na chave permita NULLs).

• As atualizações de estatísticas que usam FULLSCAN podem ser executadas em paralelo.
• Os sinalizadores de rastreamento 2389 e 2390 são introduzidos no SP1 para ajudar com o problema de chave ascendente, descrito na postagem, Chaves ascendentes e Estatísticas de correção rápida automática. Um exemplo detalhado desse cenário é fornecido em minha postagem Trace Flag 2389 e no novo Cardinality Estimator.
• A opção de instância "Atualizar estatísticas automaticamente de forma assíncrona" é introduzida. Observe que para que isso tenha efeito, a opção ‘Atualizar Estatísticas Automaticamente’ também deve estar habilitada. Se você não estiver claro sobre o que essa opção faz, revise a documentação em ALTER DATABASE SET Options. Essa é uma configuração que Glenn recomenda (conforme observado em sua postagem referenciada abaixo), mas acho importante estar ciente dos possíveis problemas, conforme observado em Como as atualizações automáticas das estatísticas podem afetar o desempenho da consulta.
  
  Observação: Há um vazamento de memória relacionado a essa configuração no SQL Server 2008 por meio do SQL Server 2012; consulte a postagem de Glenn Important Hotfix for SQL Server 2008 para obter mais detalhes.

• As estatísticas filtradas são introduzidas e podem ser criadas separadamente de um índice filtrado. Existem algumas limitações em torno de índices filtrados em relação ao Query Optimizer (veja o post de Tim Chapman The Pains of Filtered Indexes e o post de Paul White Limitações do Optimizer with Filtered Indexes), e é importante entender o comportamento do contador que rastreia as modificações (e assim pode acionar atualizações automáticas). Veja a postagem de Kimberly Índices filtrados e estatísticas filtradas podem ficar seriamente desatualizados para obter mais detalhes, e também recomendo verificar seu procedimento armazenado que analisa a distorção de dados e recomenda onde você pode criar estatísticas filtradas para fornecer mais informações ao Otimizador de consultas. Implementei isso para vários clientes grandes que têm VLTs e distribuição distorcida entre colunas frequentemente usadas em predicados.
• Duas novas visualizações de catálogo, sys.stats e sys.stats_columns, foram adicionadas para fornecer informações mais fáceis sobre estatísticas e colunas incluídas. Use essas duas visualizações em vez de sp_helpstats, que está obsoleta e fornece menos informações.

• É disponibilizado o sinalizador de rastreamento 2371, que pode ser usado para reduzir o número de modificações necessárias para que ocorram atualizações automáticas nas estatísticas. Como lembrete, sou fã de atualizar estatísticas regularmente por meio de um trabalho agendado e deixar a atualização automática ativada por segurança.

• A função sys.dm_db_stats_properties está incluída, que fornece as mesmas informações encontradas no cabeçalho de DBCC SHOW_STATISTICS, bem como uma coluna de modificação que pode ser usada para rastrear alterações e determinar programaticamente se uma atualização é necessária. Lembra da minha preferência por usar um trabalho para atualizar estatísticas? Esse trabalho ficou muito mais inteligente com este DMF... agora posso ver quantos dados foram modificados e APENAS atualizar estatísticas se uma certa porcentagem de dados for alterada. Liso.

• A atualização das estatísticas não invalidará os planos SE nenhuma linha tiver sido alterada. Este é um que surpreende muitas pessoas, e Kimberly tem um post divertido, O que causou esse plano terrivelmente errado - você deve atualizar as estatísticas?, que mostra sua aventura em descobrir isso.

• DBCC SHOW_STATISTICS requer apenas a permissão SELECT – anteriormente, era necessário que um usuário fosse membro de sysadmin ou membro da função de banco de dados db_owner ou db_ddladmin. Isso pode ser desabilitado globalmente com o sinalizador de rastreamento 9485.
• Inclui sys.dm_db_stats_properties (consulte a nota 2008R2 SP2 acima)

• A atualização cumulativa 1 apresenta uma correção relacionada a chaves ascendentes que não são identificadas corretamente, mesmo com os sinalizadores de rastreamento 2389 e 2390 em uso. Isso requer o sinalizador de rastreamento 4139 além de CU1, conforme observado no KB 2952101.

• O novo Estimador de cardinalidade é introduzido, implementado definindo o modo de compatibilidade do banco de dados para 120 ou usando o sinalizador de rastreamento 2312. Se você não leu nada sobre o novo CE, recomendo começar com a documentação de Estimativa de cardinalidade e depois ler Joe O whitepaper do Sack, Otimizando seus planos de consulta com o estimador de cardinalidade do SQL Server 2014, para obter detalhes detalhados.
• O comportamento dos sinalizadores de rastreamento 2389 e 2390 para chaves ascendentes agora é implementado por meio do modo de compatibilidade do banco de dados. Se o modo de compatibilidade do banco de dados estiver definido como 120 (ou superior em versões posteriores), você não precisará usar os sinalizadores de rastreamento 2389 e 2390 para SQL Server para identificar estatísticas com chaves crescentes.
• As estatísticas incrementais são introduzidas para partições e podem ser visualizadas por meio do novo DMF sys.dm_db_incremental_stats_properties. As estatísticas incrementais fornecem uma maneira de atualizar as estatísticas de uma partição sem atualizá-las para a tabela inteira. No entanto, as informações estatísticas adicionais das estatísticas incrementais não são usadas pelo Otimizador de consulta, mas são dobradas no histograma principal da tabela.
• CU2 inclui a mesma correção mencionada acima para o SQL Server 2012 SP2 que também requer o sinalizador de rastreamento 4139.

• O sinalizador de rastreamento 7471 é retroportado para CU6, originalmente disponível no SQL Server 2016, conforme indicado abaixo.

• O sinalizador de rastreamento 2371 não é mais necessário para reduzir o limite para atualizações automáticas de estatísticas se o modo de compatibilidade do banco de dados estiver definido como 130. Consulte Controlando o comportamento do Autostat (AUTO_UPDATE_STATISTICS) no SQL Server.
• As atualizações nas estatísticas podem ser executadas em paralelo ao usar SAMPLE, não apenas FULLSCAN. Isso está vinculado ao modo de compatibilidade (deve ser 130), mas pode fornecer atualizações mais rápidas e, assim, diminuir as janelas de manutenção. Aaron Bertrand fala sobre esse aprimoramento em seu post, Uma melhoria potencial para atualizações de estatísticas:MAXDOP.
• O sinalizador de rastreamento 7471 foi introduzido no CU1 para permitir que vários comandos UPDATE STATISTICS sejam executados simultaneamente para uma única tabela e Jonathan fornece alguns ótimos exemplos de como isso pode ser usado em sua postagem Suporte aprimorado para recriações de estatísticas paralelas.

• A opção de dica de consulta ENABLE_HIST_AMENDMENT_FOR_ASC_KEYS é introduzida, juntamente com o argumento FOR HINT, que é o equivalente ao sinalizador de rastreamento 4139.
• O DMF sys.dm_db_stats_histogram é exposto em CU2, que é uma alternativa à saída do histograma do DBCC SHOW_STATISTICS. A informação em ambos é a mesma, use o que for mais fácil para você ou se ajuste melhor ao problema que você precisa resolver.
• A opção PERSIST_SAMPLE_PERCENT é introduzida no CU4, que pode ser usada para forçar a mesma taxa de amostragem a ser usada toda vez que uma estatística for atualizada daqui para frente, e exemplos desse comportamento podem ser encontrados na postagem Taxa de amostragem de estatísticas persistentes.

• A opção PERSIST_SAMPLE_PERCENT está disponível em CU1 (consulte a entrada 2016 SP1 para obter informações adicionais).
• Os atributos StatsInfoType e OptimizerStatsUsageType são adicionados ao plano de consulta, que lista as estatísticas usadas durante a otimização da consulta. Isso está disponível em CU3 e está vinculado à versão CE (120 e superior). Isso é bem legal! Ainda não tive a chance de brincar com isso, mas para obter essas informações anteriormente, você precisava usar sinalizadores de rastreamento não documentados.
• CU3 também introduziu a opção MAXDOP para CREATE STATISTICS e UPDATE STATISTICS, que pode ser usada para substituir o valor MAXDOP para a instância ou banco de dados.
• Mais uma adição na CU3:os atributos UdfCpuTime e UdfElapsedTime podem ser encontrados no Plano de consulta, que representam estatísticas de execução para UDFs de valor escalar.

Resumo