Para pesquisar que estatísticas ou índices estão duplicados, baseamos-mos no primeiro campo. Isto porque, a/ as estatísticas automáticas são sobre um mesmo campo; b/ as estatísticas de um usuário podem ir sobre vários campos, devemos analisá-los para ver se um cobre o outro ou se os dois são necessários. Portanto, não vamos à procura de coincidências exatas, senão indicadores de que podem existir estatísticas ou índices a mais, e que melhorará o rendimento eliminá-los.
Para isso, por cada base de dados procuramos em todas as tabelas (sys.tables e sys.schemas) todas as estatísticas (sys.stats) e o primeiro campo segundo a ordem da estatística (sys.stats_columns), além do nome e largura da dita coluna (sys.columns).
A largura é algo informativo, pois outra coisa que podemos fazer é eliminar estatísticas de campos muitos largos pois geralmente não se usam nas consultas. Quer dizer, num campo grande, costuma-se usar LIKE para procurar em qualquer parte o dito campo e as estatísticas geralmente não ajudam nesse caso.
Se agrupamos pelo indentificador do objeto e da coluna, vamos ter aquelas estatísticas que podíamos analisar.
Se a instancia do Servidor SQL Server tem muitas bases de dados ou as bases de dados levam tempo sem se revisar, podem-nos devolver muitas estatísticas duplicadas. Dado que não costumam afetar o rendimento, podemos centrar-nos nas mais importantes, bem seja pelo seu tamanho, bem seja pelo número de filas.
Agora bem, isto podemos focar de várias maneiras. No meu caso, interessava-me saber o tamanho da primeira coluna tanto em MB como em recordes. É dizer, como não me interessavam exclusivamente as estatísticas, nem o tamanho da dita coluna, senão da coluna. Portanto, uma vez conseguidas que estatísticas apareciam duplicadas, adicionei-lhes estes dados para logo filtrar as mais importantes.
Geralmente é porque se começou a trabalhar com uma tabela, estava habilitada a criação automática de estatísticas, SQL Server cria estatísticas automáticas de coluna para realizar consultas e logo se criam os índices. É fácil encontrar tabelas que têm estatísticas em todas as suas colunas, ainda que nas aplicações não se usem as ditas colunas em buscas ou uniões. É o efeito das provas em produção onde às vezes se analisam as colunas e o SQL Server cria estatísticas para consultas que se executam uma só vez. Ditas estatísticas são idênticas se se atualizaram ao mesmo tempo. De outra maneira, os duplicados podem gerar estatísticas diferentes para os mesmos dados, que, sem a manutenção adequada, podem fazer que o optimizador de consultas gere um plano incorreto.
Vejamos um exemplo. Estas são as estatísticas automáticas e de índice:
Se nos focamos, ao se haver atualizado em simultâneo, são idênticas. Portanto, podíamos tirar a automática e teríamos um percurso menos que fazer durante a manutenção. Uma análise deste tipo pode evitar que tenham que se sacanear inutilmente milhões de linhas em manutenção das bases de dados.
As anteriores as vemos no Explorador de Objetos:
Foquemos que a consulta nos dá tanto o nome, como o identificador do campo em decimal e hexadecimal. Para as estatísticas automáticas, dito identificador hexadecimal está no nome da estatística e assim a podemos localizar rapidamente. Num exemplo, o campo IDTASK é o segundo e encontramos o duplicado em seguida.
Em outras ocasiões há que ir analisando cada uma das estatísticas para encontrar o duplicado. Por exemplo no caso dos índices “duplicados”:
Neste caso temos que existem estatísticas que começam pelo campo ATTRIBUTE_ID, o que nos indica uma utilidade adicional deste tipo de análise: algum dos índices é redundante? Para isso recorremos à análise standard de uso de índices e eliminaremos aqueles índices- o que faz desaparecer a sua estatística – que se atualizam muito e que se usam pouco. Mas em outras ocasiões veremos que, ainda há uma possível redundância, inclusive que um índice cubra o outro, todos se estão a usar para acelerar consultas especificas e por tanto não são necessários. Neste caso é melhor deixá-los.
Se nos fixamos, a ordem das colunas na vista da estatística (stats_column_id) é muito distinta à real que nos indica a vista do índice (key_ordinal). Por tanto, esta consulta deveria ser melhorada para que, se é uma estatística de índice, se buscasse o primeiro campo do índice em vez do da estatística. Mas essa complicação deixamos como tarefa.
Ainda que não seja muito necessária a análise das estatísticas duplicadas, se usamos os filtros adequados nos podem indicar as melhorias na manutenção assim como índices que podemos eliminar.
Deixe uma resposta
Quer juntar-se ao debate?Sinta-se livre para contribuir!