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 é significativa
Outro 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
Numero auto de Recompile
