Estou corrigindo problemas de desempenho em um procedimento armazenado de várias instruções no SQL Server. Quero saber em qual(is) parte(s) devo dedicar meu tempo.
Eu entendo de Como leio o custo da consulta e é sempre uma porcentagem? que mesmo quando o SSMS é instruído a Incluir o Plano de Execução Real , os valores de "Custo da consulta (relativo ao lote)" ainda são baseados em estimativas de custo , que podem estar muito distantes dos reais
Eu entendo de Medindo o desempenho da consulta: “Custo da consulta do plano de execução” vs “Tempo gasto” que posso cercar a invocação do procedimento armazenado com SET STATISTICS TIME
instruções e, em seguida, obterei uma lista como esta no Messages
painel:
SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 1 ms.
SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.
[etc]
SQL Server Execution Times:
CPU time = 187 ms, elapsed time = 206 ms.
com uma mensagem de saída para cada instrução.
Posso associar 'facilmente' (embora não convenientemente) a saída de estatísticas de tempo com os planos de execução instrução por instrução no painel Plano de execução, contando-os: A quarta SQL Server Execution Times
saída de mensagem corresponde a Query 4
no painel Plano de execução e assim por diante.
Mas existe uma maneira melhor?
Não conheço uma maneira de fazer isso no plano do Management Studio, mas essa é uma das muitas coisas que o SentryOne Plan Explorer gratuito fará por você quando você gerar um plano real a partir da ferramenta - inclui todos os métricas de tempo de execução por instrução.
Uma boa maneira de fazer isso é com o Profiler. Configure uma "reprodução" do seu proc problemático em um desenvolvedor ou caixa de teste, ou seja, uma amostra de chamada para o proc com parâmetros. Em seguida, usando o Profiler, crie um rastreamento usando o modelo TSQL_SPs ou, a partir de um modelo em branco, adicione o evento SP:StmtCompleted. Adicione as colunas Duration, Reads, Writes e CPU se ainda não estiverem disponíveis. Adicione um filtro ao rastreamento em seu SPID (que você deve saber do Management Studio). Você também pode adicionar um filtro para Duração (por exemplo, maior que 1000 = maior que 1 segundo).
Você pode executar o rastreamento no Profiler, embora haja sobrecarga (NÃO faça isso em uma caixa de produção) ou exportar a definição e criar um rastreamento do lado do servidor. A sobrecarga do Profiler não é grande coisa em um desenvolvedor ou caixa de teste dedicada.
Execute o proc e deixe-o completo. Você também pode coletar o plano de execução real neste ponto.
Interrompa o rastreamento e abra o arquivo, e você verá uma análise linha por linha do seu processo, incluindo os tempos de cada etapa. Acho isso mais útil do que o plano para identificar gargalos, embora o plano seja útil ao examinar as seções relevantes a serem ajustadas.
HTH
Você também pode usar as exibições de gerenciamento dinâmico sys.dm_exec_procedure_stats e sys.dm_exec_query_stats . A primeira delas informa sobre o procedimento como um todo; o segundo pode ser usado para dividir cada consulta no procedimento. Um exemplo é mostrado abaixo:
Estatísticas do procedimento:
Dúvidas dentro do procedimento: