Show_Statistics e ColumnStore Index!

Posted on junho 29, 2012

1


 

O Problema

 

Estou trabalhando bastante com o SQL Server 2012, não somente para estudos, certificação, demos, apresentações, mais tambêm estamos realizando a compra desse novo produto para nossa empresa, por isso temos testado periodicamente novos recursos para a efetiva implementação.

 

Com os novos recursos, um no qual estou trabalhando bastante é o ColumnStore Index, se deseja saber mais a respeito veja aqui – https://luanmorenodba.wordpress.com/2012/03/16/entenda-o-columnstore-indexes/ e https://luanmorenodba.wordpress.com/2012/06/05/desvendando-o-columnstore-index/ 

 

Porém, durante a criação de um ColumnStore Index em uma determinada tabela, necessitei analisar as estatísticas para analisar quantidade de registros, passos do histograma e principalemente mensurar informações de densidade dos campos.

 

Porém quando realizei a consulta, obtive o seguinte retorno:

 

DBCC SHOW_STATISTICS(‘FactInternetSales’,‘CSIidxNCL_FactInternetSales’)

 

image

(Figura 1 – Estatísticas da tabela. Tabela meramente ilustrativa, somente para exemplo do caso citado acima.)

 

Workaround e Solução

 

Bem, passei por alguns livros, whitepapers, blogs e pesquisas com outras pessoas, porém nada encontrei.

 

Fui encontrar a resposta no blog de nada mais nada menos – Conor Cunningham para quem não o conhece veja – http://sqlbits.com/Speakers/Conor_Cunningham  – podemos falar que o cara é simplesmente o pai do cara… .)

 

image

(Figura 2 – Informações do ColumnStoreIndex)

 

Como  todo columnstore index só pode ser um índice não cluster e o mesmo reside não em ROW Store mais em LOB, a logica de seleção é limitada por padrões de star joins como a Figura 1 acima mostra. A utilização de star joins é somente utilizada pelo QO em cenários complexos, sendo assim o QO possui uma ordem lógica de processamento.

 

Como o QO é baseado em custo relativo que estima planos com o menor custo de processamento possível, ele realiza duas principais divisões:

 

A quantidade total de linhas processadas para cada nível do plano é conhecido como cardinalidade e o custo na modelagem do algoritmo dos operadores para a consulta.

 

Sendo assim,o QO considera as otimizaões do star join após a estimativa da cardinalidade do plano. Com isso o optmizer não necessita gerar uma estimativa de cardinalidade e estatísica para o ColumnStore index.

 

Porém, no Post do Conor Cunningham ele diz =  “In the future we hope to extend this to expose more of the information in the BLOB – for now, we have some extra information that is (almost) peeking through.”

 

Então esperamos ansiosamente para isso.