none
Estatísticas de objetos - SQL Server 2005 e 2008 RRS feed

  • Pergunta

  • Como é possível identificar se as estatísticas de um banco estão desatualizadas? Existe alguma maneira, script, etc. que possa auxiliar nesta identificação, ao invés de executar para todo o banco de dados, fazer apenas nos objetos necessários? Em alguns sites da internet, há regras para a fragmentação de objetos, sendo recomendado pela própria Microsoft por exemplo, que objetos fragmentados em 30% ou mais, faz-se REBUILD caso contrário REORGANIZE, no entanto, meu questionamento é se existe algum padrão para as estatísticas. Ou seja, como posso identificar apenas os objetos que precisam de atualizar as estatísticas?
    quinta-feira, 26 de maio de 2011 14:26

Respostas

  • Oi Eduardo,

    Sim, se as tabelas são manipuladas sua distribuição de dados pode mudar e precisamos ficar de olho nas estatísticas. Controlar essa distribuição para uma dúzia de tabelas pode ser factível, mas quando o número aumenta não é nem viável manter uma administração tão fina.

    A questão é que você terá que escolher entre processar tudo sem observar esses detalhes ou controlar estatística a estatística para processar somente o que é realmente interessante. Na primeira abordagem você poderá ser ineficiente mas facilitará a administração. Na segunda abordagem você só irá processar as estatísticas que realmente devem ser processadas, mas o overhead administrativo será tão intenso que talvez não se justifique.

    Vale a pena lembrar que o REINDEX já atualiza as estatísticas (do índice) e essa atualização já influencia no seu uso.

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.wordpress.com


    Classifique as respostas. O seu feedback é imprescindível
    • Marcado como Resposta eduardomilen sexta-feira, 27 de maio de 2011 22:30
    quinta-feira, 26 de maio de 2011 20:10

Todas as Respostas

  • Bom Dia,

    Uma vez que as estatísticas dependam inteiramente dos dados que a compõe e que esses dados terão um aspecto inteiramente relativo ao négocio que suportam não é possível determinar um padrão que se aplique a todos os bancos de dados. Se você tem uma coluna de estado civil por exemplo, manter a estatística atualizada ou não fará pouca diferença, pois, independente da quantidade de registros, a proporção entre os estados civis irá se manter além do que essa é uma coluna muito pouco provável de usar índices em sua pesquisa (é possível que sequer possua estatística).

    Em contrapartida, uma coluna CPF normalmente possui uma boa seletividade e é uma forte candidata ao uso dos índices. Mas do que adianta os índices se as estatísticas estiverem desatualizadas ? Você pode ter uma tabela com 100 registros em uma única página e nesse caso, o índice será inútil. À medida que a tabela cresça e atinja por exemplo 1 milhão de registros, a estatística será imprescindível para que o índice seja avaliado. Se sua tabela chega a grandes quantidades, mas a estatística está desatualizada então a escolha poderá ser ruim.

    São duas situações diferentes que podem ocorrer em qualquer SGBD (Estado Civil e CPF). Veja que não há implementação certa para nenhuma das duas situações. Até o conceito de "desatualizadas" é relativo. O que é uma estatística "desatualizada" ? Se considerarmos que os dados são gravados em taxa superior à atualização de estatísticas é perfeitamente aceitável que elas nunca irão refletir a realidade tornando portanto desatualizadas por padrão. A questão é saber por quanto tempo uma estatística pode ficar desatualizada. Mesmo assim é difícil ter definições. Se o padrão de distribuição de dados de uma coluna bem como sua taxa de crescimento mantiverem-se constantes, pode ser que a estatística possa suportar ficar desatualizada até por meses.

    Para saber a última data de atualização de uma estatística, use a seguinte procedure:

    EXEC sp_autostats 'tabela'
    

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.wordpress.com


    Classifique as respostas. O seu feedback é imprescindível
    quinta-feira, 26 de maio de 2011 15:05
  • Gustavo,

     

    Boa tarde.

    Grato pelo retorno.

    No entanto, se as tabelas sofrem constantes atualizações, deleções, inserções, etc. e possuam quantidade considerável de registros, é um ponto de observação.

    Como a padronização é complexa de ser feita, devido à dependência dos objetos e o comportamento da aplicação que acessa estes dados conforme sua citação, a seletividade de uma coluna CPF por exemplo, é forte candidata de ter um indice e, tendo rotinas de desfragmentação destes, as estatísticas tornam-se a manutenção "consequente" para melhorar o acesso aos dados. Correto?

    A intenção da padronização a que refiro, é para que este tipo de manutenção ocorra apenas em objetos que realmente necessitam de maneira que os ciclos de processamento possam ser melhor aproveitados, assim como existe a regra para as manutenções dos índices.

     

     

    quinta-feira, 26 de maio de 2011 17:23
  • Oi Eduardo,

    Sim, se as tabelas são manipuladas sua distribuição de dados pode mudar e precisamos ficar de olho nas estatísticas. Controlar essa distribuição para uma dúzia de tabelas pode ser factível, mas quando o número aumenta não é nem viável manter uma administração tão fina.

    A questão é que você terá que escolher entre processar tudo sem observar esses detalhes ou controlar estatística a estatística para processar somente o que é realmente interessante. Na primeira abordagem você poderá ser ineficiente mas facilitará a administração. Na segunda abordagem você só irá processar as estatísticas que realmente devem ser processadas, mas o overhead administrativo será tão intenso que talvez não se justifique.

    Vale a pena lembrar que o REINDEX já atualiza as estatísticas (do índice) e essa atualização já influencia no seu uso.

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.wordpress.com


    Classifique as respostas. O seu feedback é imprescindível
    • Marcado como Resposta eduardomilen sexta-feira, 27 de maio de 2011 22:30
    quinta-feira, 26 de maio de 2011 20:10