Está praticamente tudo no título. Eu tenho um SQL Server que está mostrando que mais de 90% do uso da CPU e do IO lógico executado é devido a "Consultas Adhoc". O restante do uso aparece sob o nome real do banco de dados. Isso tudo é do relatório "Painel do servidor".
Tenho alguns bancos de dados neste servidor que são acessados diretamente por aplicativos de fornecedores sobre os quais não tenho controle. Eles são de uso muito baixo em geral; Eu tenho dois bancos de dados que são acessados e usados por aplicativos internos escritos em Entity Framework e Linq-To-SQL. Estou me perguntando se é por isso que minhas "Consultas Adhoc" estão mostrando um uso tão alto em vez dos nomes de meus bancos de dados internos.
A razão pela qual estou perguntando é porque tenho notado um desempenho um tanto degradado e a CPU em meu servidor está executando 95% no processo sqlserver.exe por longos períodos de tempo, com "picos de queda" mínimos para 10-15% de uso.
Sim. Linq-To-Sql e EF enviam consultas dinâmicas (Ad-Hoc) ao banco de dados. Você pode provar isso executando um rastreamento do criador de perfil e depurando o aplicativo.
A boa notícia é que você sempre obterá o plano de consulta mais atualizado, com base nas estatísticas atuais. A má notícia é que o plano terá que ser compilado a cada execução. Isso raramente é bom e somente quando a consulta geralmente retorna quantidades variáveis de dados.
Eu vejo isso todos os dias. O desenvolvedor Bob está mais preocupado com o RAD (expulsar o aplicativo e parecer uma estrela do rock) do que com o desempenho do aplicativo. Ele usa essa nova ferramenta de geração de código sql automática e de ponta. As consultas são rápidas no app porque são apenas 2500 registros no banco de dados e tudo cabe na memória. 12 meses depois, o volume do aplicativo aumentou 100.000%, agora é super lento e o banco de dados é culpado. A solução é reescrever o aplicativo com o sql adequado ou jogar o hardware no problema. Na minha opinião, o sql auto-mágico garante que seu aplicativo não seja bem dimensionado com um volume significativo.
"A geração de código dinâmico é a maneira mais rápida de criar SQL lento e a maneira mais lenta de criar SQL rápido." Brent Ozar
Seu maior desafio não está na velocidade do código compilado. Está na sua capacidade de ler e analisar com eficiência conjuntos de dados que não cabem na memória.