Bem, é um cenário hipotético, mas o que estou tentando entender é o caminho a seguir de um log post-morten (digamos, um rastreamento do SQL Server Profiler) para identificar o código em uma situação de ORM. Para não ser muito vago, considere um cenário como este:
- SQLServer 2008
- Entity Framework como um ORM
Então, nesse cenário, qual é o caminho comum para um DBA (que também é um desenvolvedor VB.Net) fazer do log para diagnosticar qual código (neste caso, consultas Linq) estão criando o problema? Nesse caso, o aplicativo está ok, mas está afetando o tempo de resposta de outros aplicativos usando o mesmo banco de dados/servidor.
Isso seria absurdamente diferente de um processo Java+Hiberate?
EDIT: quero entender o caminho do rastreamento para a metaconsulta culpada. Se o aplicativo tiver SQL, isso significa que uma sessão "Localizar nos arquivos" (talvez com algum regex, em casos extremos) pode reduzir os alvos da tarefa de inspeção a algumas dezenas de suspeitos em vez de décimos ou até centenas de arquivos de origem. Usando um ORM, como chegar a esse estágio usando um ORM (neste caso: EF)?
Eu sugeriria fortemente metadados na conexão para rastrear o aplicativo. Na cadeia de conexão, há um nome de aplicativo. Há também dados de sessão que podem ser usados na forma de CONTEXT_INFO
https://stackoverflow.com/questions/323494/sql-server-modifying-the-application-name-property-for-auditing-purposes
É claro que tudo isso requer alterações no aplicativo, mas é bom para rastreamento e auditoria em geral, portanto, prepará-lo desde o início é realmente útil.
Normalmente, quando uma consulta está "interferindo" em outra consulta, ela está bloqueando ou travando. Qualquer um deles não seria visível por meio de um rastreamento padrão do SQL Profiler.
Se você estiver enfrentando deadlocks, convém que os sinalizadores de rastreamento 1204 e 1222 sejam ativados no SQL Server para que a saída do deadlock seja enviada para os logs de erros. Você também pode executar novamente o rastreamento e adicionar os eventos de conflito.
Os problemas de bloqueio podem ser pesquisados. Você pode rolar seu próprio código de log de bloqueio ou usar uma ferramenta como o SQL Spotlight para detectar essas ocorrências. O bloqueio pode ser verificado observando a coluna master.sys.sysprocesses bloqueados para um valor <> 0. Se você decidir criar o seu próprio, um script como este pode ser usado como ponto de partida para obter as informações da sessão em execução que pode ser registrado em uma tabela ou você pode configurar um trabalho para extrair informações de sp_whoisactive .
Eu também verificaria seu rastreamento do Profiler (ou pegaria um novo) e o correlacionaria com os contadores básicos de desempenho do servidor (CPU, fila de disco, taxa de transferência de rede) para ver se algum recurso específico está sendo afunilado durante uma execução de consulta específica. Muitas vezes, é óbvio por meio do rastreamento do Profiler se uma consulta é um problema porque a quantidade de leituras ou cpu será muito alta na instrução ou no evento de lote concluído. Um log de contador que é criado durante o mesmo tempo em que um rastreamento do Profiler é obtido pode ser aberto no SQL Profiler e correlacionado diretamente com a saída do rastreamento do Profiler que é salva.
Também é uma boa ideia configurar o SQL Server Management Data Warehouse para coletar estatísticas de desempenho do servidor e da consulta ao longo do tempo. Ele tem alguns bons relatórios detalhados que o ajudarão a identificar problemas dentro de uma determinada janela de tempo. Nem sempre é tão preciso quanto um rastreamento do criador de perfil, mas pode fornecer informações úteis, como os tipos de espera que você está enfrentando e outros padrões de gargalo de recursos que podem ser facilmente correlacionados a outras consultas por meio dos relatórios de estatísticas de consulta.
Provavelmente estou fora da base aqui com minha resposta, porque realmente não vou abordar a localização do código ofensivo, além de dizer ... Conhecer o SQL executado a partir do rastreamento leva ao conhecimento da entidade ORM associada, o que leva para localizar todas as referências no Visual Studio. Espero que o código seja DRY , mas esse é um tópico separado.
Vou me concentrar um pouco mais no desempenho do SQL.
Supondo que o rastreamento tenha informações suficientes para registrar a atividade ORM (provavelmente o início/conclusão do lote TSQL), eu classificaria a saída do rastreamento por CPU, leitura, gravação e duração procurando por valores altos. Quando encontrado, eu otimizaria conforme necessário. Índices para reduzir leituras, menos inserções/atualizações sempre que possível (menos índices sempre que possível, leitura de uma tabela diferente mais indexada do que você insere/atualiza), menos processamento/gatilhos. Isso seria uma série inteira de respostas para enumerar, mas procure os principais infratores e tente abordá-los primeiro.
Tudo isso pressupõe que o ORM é o culpado. É possível que o servidor esteja enfrentando problemas não relacionados ao ORM.
Eu recomendo ler este whitepaper várias vezes e depois de identificar a origem do(s) problema(s), CPU, memória ou IO, eu começaria a percorrer as etapas de detecção específicas do gargalo identificadas no whitepaper.
Para pular o white paper e ir direto ao assunto, no nível do servidor, eu usaria o monitor de atividade integrado para examinar consultas caras recentes. Eu procuraria execuções/duração excessivas. Endereço, enxágue, repita.
Boa sorte :-)
Que tal essas técnicas usando ToTraceString?
http://blog.cincura.net/227674-how-to-show-sql-command-created-by-entity-framework/ http://www.dotnetcurry.com/ShowArticle.aspx?ID=647
Colete e correlacione com seu traço.