Pelo que sei, a Taxa de acertos do cache de procedimentos abaixo de 95% é um problema. Na minha caixa, os valores variam de 85 a 95%.
Como corrijo esse problema? O servidor parece ter bastante RAM, o que não deve ser um problema. O que mais pode ser?
Respostas:
Deixe-me resumir (e arredondar!) Os pontos de dados importantes em sua planilha:
Total Use Count 1
--------------------------------------- -----------------------
Total Plans Total MBs Avg Use Count Total Plans Total MBs
----------- --------- ------------- ----------- ---------
Adhoc 55,987 3,054 3 38,314 2,036
Proc 709 1,502 1,549 135 527
Portanto, a primeira linha mostra as coisas ruins, ocupando cerca de 2/3 do cache do seu plano (coisas que geralmente são usadas apenas uma vez, com algumas exceções muito pequenas). Você precisa tentar se livrar do máximo possível deles. A segunda linha mostra as coisas boas. Essas são as coisas que você deseja no cache do seu plano (planos com uma alta quantidade de reutilização). O restante dos dados é em grande parte irrelevante IMHO. Outro ponto: você diz que o acesso é exclusivamente por meio de procedimentos armazenados, mas se esses procedimentos usam SQL dinâmico, essas instruções são armazenadas em cache como AdHocplanos, não como Procplanos.
Em 2008 ou mais, eu diria que ligue optimize for ad hoc workloadse passe para o próximo problema - isso levaria a quantidade de MBs que seus planos de uso único atualmente ocupam até quase nada. Infelizmente, em 2005, suas opções são bastante limitadas, além de refatorar os procedimentos armazenados para usar OPTION (RECOMPILE)SQL dinâmico no nível de instrução e / ou menos / nenhum dinâmico ou ativar a parametrização forçada no nível do banco de dados - o que tenta obter uma melhor reutilização do plano. consultas semelhantes, tratando literais como parâmetros para fins de correspondência de plano. Hesito em mencionar até mesmo os guias de plano, porque eles não são tímidos e - como discutirei mais adiante nesta resposta - não tenho certeza de que vale a pena seguir esse caminho, a menos que você saiba que o cache do plano é definitivamente a fonte do seu desempenho questão.
Eu perguntei @@VERSIONporque, antes do SP2, o algoritmo para a quantidade de memória que podia ser alocada para o cache do plano era relativamente frouxo. A partir do SP2, eles reforçaram bastante isso (a mudança está documentada e explicada nesta postagem e nesta postagem ). No seu caso, o cache do plano está relativamente cheio; portanto, não é de surpreender que você esteja recebendo erros de cache. 26 GB = um limite superior de 5,8 GB; Vejo ~ 4.5 GB na planilha, mas pode haver alguma diferença de cálculo ou configuração aqui que eu não conheça.
Este artigo da MSDN fala sobre a optimize for ad hoc workloadsconfiguração do servidor adicionada em 2008 e menciona o sinalizador de rastreamento 8032, que permitirá que você aloque mais memória para seus caches (presumivelmente na ausência de definir essa configuração no nível do servidor, que agora recomendo a todos nossos clientes, ou pelo menos os 99% que não estão mais em 2005). Eu nunca testei esse sinalizador de rastreamento no 2005 SP3 ou SP4 e, sinceramente, nem tenho certeza de quando foi introduzido. Também não sei se ele resolverá o seu problema ou apenas o mudará, pois acho que mesmo se você tivesse um pouco mais de RAM alocado nos caches, ainda o estaria preenchendo e tendo muitas falhas de cache por causa da natureza de seus procedimentos armazenados.
Ou, é claro, se houver um problema a resolver que esteja diretamente relacionado ao cache do plano. Só porque a taxa de acertos do cache não é tão alta quanto seria de esperar, não significa que esteja causando o problema e, é claro, o inverso é que mesmo com uma taxa de acertos de cache de 100% - o que não parece realista, pois muitos seus planos são de uso único e ad hoc - seus usuários ainda podem estar sofrendo de problemas de desempenho causados por algo totalmente diferente.
Minha sugestão é procurar armas de fumo melhores do que planejar a taxa de acertos do cache. Obtenha mais detalhes sobre as reclamações de desempenho de seus usuários. Todas as consultas são sempre lentas? Certas consultas? Certas horas do dia / semana / ciclo de negócios? Apenas as consultas de relatórios são lentas? Leia atentamente este documento longo e reconhecidamente seco sobre as práticas recomendadas do SQL Server - em particular a seção sobre esperas e filas, que pode ajudá-lo a formular uma abordagem lógica para identificar, diagnosticar e resolver problemas de desempenho. Fazer com que um número no painel pareça melhor - um número que você nem sabe que contribui diretamente para o problema - pode ser muito satisfatório, mas se ele não resolver os problemas de desempenho dos usuários, realmente não o alcançará. qualquer lugar.
Isso também pode ser útil para ler sobre compilação / recompilação e planejar a reutilização de cache. Alguns deles estão focados em 2008 (particularmente aqueles sobre a configuração de cargas de trabalho ad hoc), mas muitas das informações ainda são úteis para 2005 e / ou para entender melhor os benefícios da atualização (dica, dica).