TL;DR: É possível descobrir quais partições foram reamostradas e quais não foram quando estatísticas incrementais são usadas? A plataforma é a edição SQL Server 2014 Enterprise.
A versão longa com algumas informações básicas é assim.
Assumindo um ambiente DW bastante típico, há uma tabela particionada. O particionamento é baseado em uma coluna de data. Isso é feito quando os dados de preparação são carregados em uma tabela separada e, após o pré-processamento, a alternância de partição é usada para mover os dados para a tabela de fatos de produção. Ah, e um índice columnstore clusterizado está em uso. Existem cerca de mil partições usadas. O banco de dados está sendo executado em uma máquina virtual.
Existem cerca de 7,5 gigarows (100 GB) na tabela de fatos. O crescimento diário é de cerca de cinco megarows. Esta é uma taxa de crescimento muito pequena para acionar a atualização automática de estatísticas, salve o sinalizador de rastreamento 2371 (que não foi tentado).
A reação instintiva do desenvolvedor às estatísticas desatualizadas foi atualizá-las. Para 7,5 gigarows, a atualização completa de todas as estatísticas leva cerca de cinco horas. Para uma única atualização de estatísticas, o desempenho do processamento é de cerca de 20 minutos ou 90 megarows por segundo.
Como o sistema está em uma plataforma VM, as regras de negócio limitam seus custos. Nem a memória nem o IOPS são facilmente aumentados. O trabalho de atualização de cinco horas é muito lento para ser incluído no processo ETL noturno; portanto, as estatísticas permanecem desatualizadas, são atualizadas em um horário inesperado ou serão atualizadas em uma janela de manutenção.
Como o SQL Server é a versão Enterprise Edition 2014, ele oferece suporte a estatísticas incrementais que soam exatamente como a solução. Depois de converter as estatísticas em incrementais, o processamento de uma única estatística para partição única leva apenas 20 segundos. O total geral da partição recém-comutada é de cerca de cinco minutos. Isso parece ótimo e certamente se encaixa no processo ETL.
O que me pergunto é como gerenciar estatísticas incrementais no ambiente de partição comutada. Supondo que as estatísticas sejam convertidas e atualizadas como incrementais na data D, como descobrir as partições não processadas, digamos, na data D+2? A atualização de estatísticas no processo ETL é trivial, pois o processo de troca obviamente está ciente do ID da partição. Mas se houver partições que não foram reamostradas, como encontrá-las?
- A última atualização das estatísticas pode ser encontrada em
sys.dm_db_stats_properties - Os números de partição estão disponíveis em
sys.partitions - Os valores da função de particionamento estão em
sys.partition_range_values
Pode-se escolher a data da última atualização L para uma estatística e compará-la com a data de hoje T. Em seguida, calcule qual partição id L aponta e se é igual à de T. Em seguida, prossiga com a atualização de todos os IDs de partição [L, T). Isso parece complicado e sujeito a erros, então existe uma maneira melhor? Um DMV que mostre quais partições são usadas para reamostragem seria bom, mas não existe, existe?