Usuário com melhor resposta
Numero auto de Recompile

Pergunta
-
Ola galera,
Estou com uma dúvida e gostaria de ver com vocês se estou analisando corretamente o numero de recompilações em meu banco de dados. Meu banco de dados tem 150GB (espaço em disco) com 150 usuários (SQL Server 2005).
Estou suspeitando que o numero de recompilações esta muito auto analisando o seguinte:
Coloquei para executar o PerfMon e encontrei no contador (SQLServer: SQL Statistics - SQL Re-Compilation/sec) a média de 38.
Segue imagem em anexo, e no momento a média estava 43:Tambem executei o SQL Profiler, pegando o Evento: SP: Recompile e realmente mostra centenas de consultas, triggers e procedures.
Exemplo:
Será que esta minha analise esta correta e realmente o numero de recompilações esta muito alta, pois segundo a microsoft, este numero deve esta proxima de 0 (zero).
Já agradeço a atenção de todos!
Alex Souza
http://pessoalex.wordpress.com
Alex Souza http://pessoalex.wordpress.com- Editado Antonio Alex Souza quarta-feira, 11 de janeiro de 2012 18:35
- Movido Gustavo Maia Aguiar quarta-feira, 11 de janeiro de 2012 19:54 (De:SQL Server - Desenvolvimento Geral)
Respostas
-
Boa Noite,
Idealmente falando teríamos zero recompilações, zero page splits, zero scans e todas as outras estatísticas que pudessem denotar problemas, mas isso é ideal e sinceramente está muito longe do real até porque tais contadores são de natureza completamente relativa e sozinho não são capazes de caracterizar uma real situação de problema.
Você está com 38 recompilações por segundo e a documentação manda que esse número fique próximo de zero. A documentação está correta, mas certamente incompleta. 38 recompilações por segundo é um número superior a zero recompilações por segundo, mas será que ele é alto o suficiente. Se você tivesse 40 comandos por segundo e 38 recompilações por segundo eu diria que você teria um grande problema, mas se você tiver por exemplo 3.800 comandos por segundo e tiver apenas 38 recompilações por segundo, você certamente estaria em um "céu de brigadeiro", pois, apenas 1% dos seus comandos seriam recompilações. O que quero dizer aqui ? Que se você analisar esse contador sozinho, não irá chegar a muitas conclusões. É preciso comparar o "quanto" a recompilação é de fato nociva e isso só será possível com duas abordagens:
- Se você tiver uma linha de base mostrando que o número de recompilações aumentou de uma hora pra outra
- Se você comparar o número de recompilações por segundo com o número de comandos por segundo para ver se realmente a recompilação é significativaOutro ponto é achar que a recompilação é necessariamente ruim. Sabemos que o uso de tabelas temporárias com # tem grandes chances de provocar recompilações dentro de stored procedures e sabemos também que o uso de variáveis do tipo TABLE evitam esse problema. O que precisamos lembrar é que variáveis do tipo tabela não mantém estatísticas apuradas de seus dados e que emboram possam evitar o RECOMPILE podem levar a estratégias lentas e demoradas que incorrerão em custo muitos maiores que a recompilação de uma #. Então nesse ponto, trata-se de utilizar estrategicamente a recompilação para uma melhora de performance (ainda que o contador possa depor contra você).
Outro ponto é o próprio otimizador. Ter o mesmo plano sempre irá evitar que você tenha de recompilá-lo, mas será que isso é necessariamente bom ? Há várias situações em que a distribuição dos dados pode levar a execuções ineficientes quando se utiliza um único plano de execução e aí embora o RECOMPILE não aconteça, o resultado pode ser bem pior do que se ele acontecesse.
Não estou dizendo que não devemos nos preocupar com a recompilação, mas apenas que você precisa analisar mais a fundo. Apenas o contador não irá levá-lo a conclusões e estratégias interessantes. Não pense primeiro na quantidade de recompilações. Tente primeiro ver se elas são de fato relevantes para a quantidade de comandos por segundo e depois tente entender que instruções estão provocando tantas recompilações. Se elas puderem ser revistas ótimo. Se forem estrategicamente necessárias, não haverá muito o que fazer.
[ ]s,
Gustavo Maia Aguiar
Blog: http://gustavomaiaaguiar.wordpress.com
Vídeos: http://www.youtube.com/user/gmasql
Classifique as respostas. O seu feedback é imprescindível- Sugerido como Resposta Gustavo Maia Aguiar quinta-feira, 12 de janeiro de 2012 21:30
- Marcado como Resposta Junior Galvão - MVPMVP, Moderator sexta-feira, 13 de janeiro de 2012 00:36