As estatísticas desaparecem após a atualização incremental

Não tenho certeza se é um bug, por si só , mas é definitivamente uma ocorrência interessante. As reconstruções de partição online são novas no SQL Server 2014, portanto, pode haver alguns internos para resolver com isso.

Aqui está a minha melhor explicação para você. As estatísticas incrementais exigem absolutamente que todas as partições sejam amostradas na mesma taxa para que, quando o mecanismo mesclar as páginas de estatísticas, ele possa ter certeza de que a distribuição amostrada é comparável. REBUILDnecessariamente amostra dados a uma taxa de amostragem de 100%. Não há garantia de que a taxa de amostragem de 100% na partição 9 sempre será a taxa de amostragem exata do restante das partições. Por causa disso, parece que o mecanismo não pode mesclar as amostras e você acaba com um blob de estatísticas vazio. No entanto, o objeto de estatísticas ainda está lá:

select 
    check_time = sysdatetime(),                         
    schema_name = sh.name,
    table_name = t.name,
    stat_name = s.name,
    index_name = i.name,
    stats_column = index_col(quotename(sh.name)+'.'+quotename(t.name),s.stats_id,1),
    s.stats_id,
    s.has_filter,                       
    s.is_incremental,
    s.auto_created,
    sp.last_updated,    
    sp.rows,
    sp.rows_sampled,                        
    sp.unfiltered_rows,
    modification_counter 
from sys.stats s 
join sys.tables t 
    on s.object_id = t.object_id
join sys.schemas sh
    on t.schema_id = sh.schema_id
left join sys.indexes i 
    on s.object_id = i.object_id
    and s.name = i.name
outer apply sys.dm_db_stats_properties(s.object_id, s.stats_id) sp
where t.name = 'TransactionHistory' and sh.name = 'dbo'

Você pode preencher o blob de várias maneiras:

UPDATE STATISTICS dbo.TransactionHistory (IDX_ProductId) WITH RESAMPLE;

ou

UPDATE STATISTICS dbo.TransactionHistory (IDX_ProductId) WITH RESAMPLE ON PARTITIONS (9);

ou você pode esperar que o AutoStats seja atualizado na primeira compilação de um plano de consulta usando esse objeto:

-- look at my creative query
select * 
from dbo.TransactionHistory
where TransactionDate = '20140101';

Tendo dito tudo isso, esta postagem esclarecedora de Erin Stellato destaca o que passou a ser percebido como uma grande deficiência de estatísticas incrementais. Seus dados em nível de partição não são usados ​​pelo otimizador na geração do plano de consulta, reduzindo o benefício presumido de estatísticas incrementais. Qual é, então, o benefício atual das estatísticas incrementais? Eu diria que sua principal utilidade é a capacidade de obter amostras de tabelas grandes de forma mais consistente a uma taxa mais alta do que com as estatísticas tradicionais.

Usando seu exemplo, veja como as coisas ficam:

set statistics time on;

update statistics dbo.TransactionHistory(IDX_ProductId)
with fullscan;

--SQL Server Execution Times:
--  CPU time = 94 ms,  elapsed time = 131 ms.


update statistics dbo.TransactionHistory(IDX_ProductId)
with resample on partitions(2);

 --SQL Server Execution Times:
 --  CPU time = 0 ms,  elapsed time = 5 ms.

drop index IDX_ProductId On dbo.TransactionHistory;

CREATE NONCLUSTERED INDEX IDX_ProductId ON dbo.TransactionHistory (ProductId) 
  WITH (DATA_COMPRESSION = ROW)  
  ON [PRIMARY]

update statistics dbo.TransactionHistory(IDX_ProductId)
with fullscan;

 --SQL Server Execution Times:
 --  CPU time = 76 ms,  elapsed time = 66 ms.

Uma atualização de estatísticas de varredura completa na estatística incremental custa 131 ms. Uma atualização de estatísticas de varredura completa na estatística não alinhada por partição custa 66 ms. A estatística não alinhada é mais lenta provavelmente devido à sobrecarga incorrida com a fusão das páginas de estatísticas individuais de volta ao histograma principal. No entanto, usando o objeto estatístico alinhado à partição, podemos atualizar uma partição e mesclá-la novamente no blob do histograma principal em 5 ms. Portanto, neste ponto, o administrador com a estatística incremental se depara com uma decisão. Eles podem diminuir o tempo geral de manutenção de estatísticas atualizando apenas as partições que tradicionalmente precisam ser atualizadas ou podem experimentar taxas de amostragem mais altas, de modo que potencialmente obtenham mais linhas amostradas no mesmo período de tempo de manutenção anterior. O primeiro permite espaço para respirar na janela de manutenção, o último pode enviar estatísticas em uma tabela muito grande para um local onde as consultas obtêm planos melhores com base em estatísticas mais precisas. Isso não é uma garantia e sua milhagem pode variar.

O leitor pode ver que 66 ms não é um tempo de atualização de estatísticas doloroso nesta tabela, então tentei configurar um teste no conjunto de dados stackexchange. Existem 6.418.608 postagens (excluindo as postagens do StackOverflow e todas as postagens de 2012 - um erro de dados da minha parte) no despejo recente que baixei.

Eu particionei os dados [CreationDate]porque ... demo.

Aqui estão alguns tempos para alguns cenários bastante padrão (100% - reconstrução de índice, padrão - atualização automática de estatísticas ou UPDATE STATISTICSsem uma taxa de amostragem especificada:

• Crie estatísticas não incrementais com Fullscan: tempo de CPU = 23500 ms, tempo decorrido = 22521 ms.
• Criar estatística incremental com Fullscan: tempo de CPU = 20406 ms, tempo decorrido = 15413 ms.
• Atualizar estatística não incremental com taxa de amostragem padrão: tempo de CPU = 406 ms, tempo decorrido = 408 ms.
• Atualizar estatística incremental com taxa de amostragem padrão: tempo de CPU = 453 ms, tempo decorrido = 507 ms.

Digamos que somos mais sofisticados do que esses cenários padrão e decidimos que uma taxa de amostragem de 10% é a taxa mínima que deve nos fornecer os planos de que precisamos, mantendo o tempo de manutenção em um prazo razoável.

• Atualize a estatística não incremental com amostra de 10 por cento: tempo de CPU = 2.344 ms, tempo decorrido = 2.441 ms.
• Atualizar estatística incremental com amostra de 10 por cento: tempo de CPU = 2344 ms, tempo decorrido = 2388 ms.

Até agora, não há nenhum benefício claro em ter uma estatística incremental. No entanto, se aproveitarmos o DMV não documentado sys.dm_db_stats_properties_internal() (abaixo), você poderá obter algumas informações sobre quais partições deseja atualizar. Digamos que fizemos alterações nos dados na partição 3 e queremos garantir que as estatísticas sejam atualizadas para as consultas recebidas. Aqui estão as nossas opções:

• Atualização não incremental no padrão (também o comportamento padrão da atualização automática de estatísticas): 408 ms.
• Atualização não incremental a 10%: 2441 ms.
• Atualizar estatísticas incrementais, partição 3 com reamostragem (10% - nossa taxa de amostragem definida): tempo de CPU = 63 ms, tempo decorrido = 63 ms.

Aqui é onde precisamos tomar uma decisão. Levamos a vitória de 63 ms. atualização de estatísticas baseada em partição, ou aumentamos ainda mais a taxa de amostragem? Digamos que estamos dispostos a obter o impacto inicial da amostragem em 50% em uma estatística incremental:

• Atualizar estatísticas incrementais em 50%: tempo decorrido = 16840 ms.
• Atualizar estatísticas incrementais, partição 3 com reamostragem (50% - nosso novo tempo de atualização): tempo decorrido = 295 ms.

Podemos obter amostras de muito mais dados, talvez configurando o otimizador para fazer melhores suposições sobre nossos dados (mesmo que ainda não esteja usando estatísticas em nível de partição) e podemos fazer isso mais rapidamente agora que temos estatísticas incrementais.

Uma última coisa divertida para descobrir, no entanto. E as atualizações de estatísticas síncronas? A taxa de amostragem de 50% é preservada mesmo quando os autostats são ativados?

Excluí os dados da partição 3 e executei uma consulta em CreationDate e verifiquei as taxas com a mesma consulta abaixo. A taxa de amostragem de 50% foi preservada.

Então, resumindo: Estatísticas Incrementais podem ser uma ferramenta útil com a quantidade certa de pensamento e trabalho de configuração inicial. No entanto, você deve conhecer o problema que está tentando resolver e então precisa resolvê-lo adequadamente. Se você estiver obtendo estimativas de cardinalidade ruins, poderá obter planos melhores com uma taxa de amostragem estratégica e alguma intervenção investida. No entanto, você está obtendo apenas uma pequena parte do benefício, pois o histograma usado é a página de estatísticas única e mesclada e não as informações no nível da partição. Se você está sentindo dor em sua janela de manutenção, talvez as estatísticas incrementais possam ajudá-lo, mas provavelmente exigirá que você configure um processo de intervenção de manutenção de alto nível. Sem considerar,:

• Estatísticas criadas com índices que não são alinhados por partição com a tabela base.
• Estatísticas criadas em bancos de dados secundários legíveis AlwaysOn.
• Estatísticas criadas em bancos de dados somente leitura.
• Estatísticas criadas em índices filtrados.
• Estatísticas criadas em visualizações.
• Estatísticas criadas em tabelas internas.
• Estatísticas criadas com índices espaciais ou índices XML.

Espero que isto ajude

select 
    sysdatetime(),                          
    schema_name = sh.name,
    table_name = t.name,
    stat_name = s.name,
    index_name = i.name,
    leading_column = index_col(quotename(sh.name)+'.'+quotename(t.name),s.stats_id,1),
    s.stats_id,
    parition_number = isnull(sp.partition_number,1),
    s.has_filter,                       
    s.is_incremental,
    s.auto_created,
    sp.last_updated,    
    sp.rows,
    sp.rows_sampled,                        
    sp.unfiltered_rows,
    modification_counter = coalesce(sp.modification_counter, n1.modification_counter) 
from sys.stats s 
join sys.tables t 
    on s.object_id = t.object_id
join sys.schemas sh
    on t.schema_id = sh.schema_id
left join sys.indexes i 
    on s.object_id = i.object_id
        and s.name = i.name
cross apply sys.dm_db_stats_properties_internal(s.object_id, s.stats_id) sp
outer apply sys.dm_db_stats_properties_internal(s.object_id, s.stats_id) n1
where n1.node_id = 1
    and (
            (is_incremental = 0)
               or
            (is_incremental = 1 and sp.partition_number is not null)
         )
    and t.name = 'Posts'
    and s.name like 'st_posts%'
order by s.stats_id,isnull(sp.partition_number,1)