Início / dba / Perguntas / 132193
Accepted
vonPryz
Asked: 2016-03-15 06:15:55 +0800 CST

Estatísticas incrementais: descubra quais partições foram reamostradas

  • 772

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 emsys.dm_db_stats_properties
  • Os números de partição estão disponíveis emsys.partitions
  • Os valores da função de particionamento estão emsys.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?

sql-server sql-server-2014

1 respostas

  1. Best Answer

    Minha primeira pergunta seria perguntar por que você está realmente usando incremental em primeiro lugar. Aqui está uma resposta que postei sobre estatísticas incrementais, uma postagem de blog de Erin Stellato que ilumina uma das principais reclamações e armadilhas com estatísticas incrementais (elas não são usadas no nível de partição pelo otimizador) e duas postagens de blog minhas que trabalhe avaliando qualquer caso de uso potencial para estatísticas incrementais.

    Dito isto, para saber quando as estatísticas de uma partição foram amostradas, você pode usar um DMF não documentado ( sys.dm_db_stats_properties_internal()) para obter informações no nível da partição. Tenho um comentário nesta postagem do blog que descreve como entender a hierarquia em um nível razoavelmente alto.

    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 = '<<TABLENAME>>'
    and s.name like '<<STATNAME>>%'
order by s.stats_id,isnull(sp.partition_number,1);
    • 7

relate perguntas