Usuário com melhor resposta
Travamento de query

Pergunta
-
Olá Pessoal!
Estou passando por um cenário curioso e preciso do apoio de vocês.
Em alguns cenários que estive analisando ultimamente me deparei com travamentos em uma aplicação .Net.
Após análise, identificamos a query a ocasionar o travamento. A query não fazia parte de nenhum lock e constava no banco com status runnable e aparentemente aguardando recursos do SO com o wait SOS_SCHEDULER_YIELD.
A query realmente se utilizava de plano paralelo por ter certa complexidade e ter envolvidas tabelas com grande volume de dados.
No entanto, a query trava apenas quando disparada por esta aplicação.
Ao executar a mesma via SSMS ela não trava! Sendo executada em no máximo 2 segundos.Executando a query via ssms tanto via sp_executesql quanto cursor, quanto explicitamente a query não trava, já quando executada via aplicação ocorre o travamento.
Alguma sugestão de troubleshoot ou alguma experiência semelhante ajudará bastante.
Rafael Cardoso de Araújo MCTS - SQL Server 2005
domingo, 29 de janeiro de 2017 13:04
Respostas
-
Rafael,
Outra tentativa é pegar um profile para ver como a aplicação está enviando os comandos/parâmetros para o banco.
https://www.fabriciolima.net/blog/2010/06/05/passo-a-passo-para-encontrar-as-querys-mais-demoradas-do-banco-de-dados-parte-1/
https://www.fabriciolima.net/blog/2011/01/26/querys-do-dia-a-dia-acompanhando-as-querys-mais-demoradas-do-banco-de-dados/
Como o Reginaldo disse, isso realmente está com cara de planos diferentes para a execução manual e pela aplicação.
O WAIT é um gargalo de CPU com esse plano da aplicação. Deve estar bombando a CPU.
Fabrício França Lima MCITP - SQL Server Database Administrator Trabalho com SQL Server desde 2006 Treinamento DBA ONLINE: http://www.fabriciolima.net/blog/cursos-online/treinamento-tarefas-do-dia-a-dia-de-um-dba-online/
- Marcado como Resposta Rafael Cardoso de Araújo terça-feira, 31 de janeiro de 2017 12:29
terça-feira, 31 de janeiro de 2017 01:23 -
Não conseguiu comparar os planos com essa dica do Reginaldo?
SP_WHOISACTIVE @GET_PLANS = 1
Fabrício França Lima MCITP - SQL Server Database Administrator Trabalho com SQL Server desde 2006 Treinamento DBA ONLINE: http://www.fabriciolima.net/blog/cursos-online/treinamento-tarefas-do-dia-a-dia-de-um-dba-online/
- Marcado como Resposta Rafael Cardoso de Araújo terça-feira, 31 de janeiro de 2017 12:29
terça-feira, 31 de janeiro de 2017 01:24
Todas as Respostas
-
Bom dia Rafael,
Essa query é parametrizada na aplicação ?
Verifique se os tipos de dados dos parametros que estão sendo passados esta de acordo com o tipo de dado dos campos nos filtros, isso pode gerar um plano ruim e escolher fazer uma operação de 'Scan' que é o que esta parecendo, tente identificar a diferença entre os planos de execução, o plano executado pela aplicação e o plano executado pelo SSMS, voce pode tentar utilizar também o Hint OPTION(RECOMPILE) na aplicação para verificar se ela escolhe um plano melhor em momento de execução, bom de primeira impressão me parece ser uma mudança de plano de execução onde a aplicação esta realizando algum SCAN, pela SP_WHOISACTIVE @GET_PLANS = 1 voce conseguira pegar esse plano que a aplicação esta usando.
Post mais comentarios para podermos te ajudar.
Ate mais.
Reginaldo Silva
segunda-feira, 30 de janeiro de 2017 11:37 -
Reginaldo,
Vou realizar estas verificações e posto novas observações assim que as obtiver.
Em tempo, muito obrigado pelo apoio.
Att,
Rafael Cardoso de Araújo MCTS - SQL Server 2005
segunda-feira, 30 de janeiro de 2017 12:21 -
Reginaldo,
Bom dia!
Ao realizar a execução da query com a option recompile, mesmo em um lab, dentro da sp_executeSQL que é a forma que a aplicação executa ocorre o mesmo travamento com o mesmo wait.
Neste caso estou entendendo que a cada execução da aplicação está sendo forçada a recompilação da query.
Att,Rafael Cardoso de Araújo MCTS - SQL Server 2005
segunda-feira, 30 de janeiro de 2017 12:45 -
Entendi,
Tente capturar o plano de execução a aplicação esta utilizando, ja peguei diversos casos em qua a aplicação passa parametros do tipo NVARCHAR para um campo do tipo INT por exemplo, e isso faz que gere um plano ruim, em muitos casos levando a fazer 'SCANS' operação custosa para tabelas grandes, mas o importante agora é identificar se existe uma variação no plano de execução.
Att
segunda-feira, 30 de janeiro de 2017 13:09 -
Rafael,
Outra tentativa é pegar um profile para ver como a aplicação está enviando os comandos/parâmetros para o banco.
https://www.fabriciolima.net/blog/2010/06/05/passo-a-passo-para-encontrar-as-querys-mais-demoradas-do-banco-de-dados-parte-1/
https://www.fabriciolima.net/blog/2011/01/26/querys-do-dia-a-dia-acompanhando-as-querys-mais-demoradas-do-banco-de-dados/
Como o Reginaldo disse, isso realmente está com cara de planos diferentes para a execução manual e pela aplicação.
O WAIT é um gargalo de CPU com esse plano da aplicação. Deve estar bombando a CPU.
Fabrício França Lima MCITP - SQL Server Database Administrator Trabalho com SQL Server desde 2006 Treinamento DBA ONLINE: http://www.fabriciolima.net/blog/cursos-online/treinamento-tarefas-do-dia-a-dia-de-um-dba-online/
- Marcado como Resposta Rafael Cardoso de Araújo terça-feira, 31 de janeiro de 2017 12:29
terça-feira, 31 de janeiro de 2017 01:23 -
Não conseguiu comparar os planos com essa dica do Reginaldo?
SP_WHOISACTIVE @GET_PLANS = 1
Fabrício França Lima MCITP - SQL Server Database Administrator Trabalho com SQL Server desde 2006 Treinamento DBA ONLINE: http://www.fabriciolima.net/blog/cursos-online/treinamento-tarefas-do-dia-a-dia-de-um-dba-online/
- Marcado como Resposta Rafael Cardoso de Araújo terça-feira, 31 de janeiro de 2017 12:29
terça-feira, 31 de janeiro de 2017 01:24 -
Fabricio e Reginaldo,
Muito Obrigado pelo apoio.
As informações passadas me auxiliaram bastante na resolução do incidente.
Consegui pegar a query via profiler e em seguida verifiquei a mesma no cache via o comando abaixo:
SELECT UseCounts, Cacheobjtype, Objtype, TEXT, query_plan, plan_handle
FROM sys.dm_exec_cached_plans
CROSS APPLY sys.dm_exec_sql_text(plan_handle)
CROSS APPLY sys.dm_exec_query_plan(plan_handle)
WHERE TEXT like '%%'Como os métodos de envio da query ao banco são do .net porém encapsulados de forma específica pela aplicação, após a busca realizei a limpeza do cache específico da consulta via o comando abaixo:
DBCC FREEPROCCACHE (Plan_handle)
Após limpar o cache específico, realizei a análise do plano de execução e criei duas estatísticas. Após este procedimento a query tanto via SSMS e APP voltaram a performar.
Muitíssimo obrigado pelo apoio de todos.
Att,
Rafael Cardoso de Araújo MCTS - SQL Server 2005
- Sugerido como Resposta Junior Galvão - MVPMVP terça-feira, 31 de janeiro de 2017 15:03
terça-feira, 31 de janeiro de 2017 12:29 -
Rafael,
Qual versão do SQL Server você esta utilizando? A partir do Management Studio 2016 temos a capacidade de comparar planos de execução distintos e identificar a possíveis diferenças.
Pedro Antonio Galvao Junior [MVP | MCC | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]
terça-feira, 31 de janeiro de 2017 15:02 -
Fabricio e Reginaldo,
Muito Obrigado pelo apoio.
As informações passadas me auxiliaram bastante na resolução do incidente.
Consegui pegar a query via profiler e em seguida verifiquei a mesma no cache via o comando abaixo:
SELECT UseCounts, Cacheobjtype, Objtype, TEXT, query_plan, plan_handle
FROM sys.dm_exec_cached_plans
CROSS APPLY sys.dm_exec_sql_text(plan_handle)
CROSS APPLY sys.dm_exec_query_plan(plan_handle)
WHERE TEXT like '%%'Como os métodos de envio da query ao banco são do .net porém encapsulados de forma específica pela aplicação, após a busca realizei a limpeza do cache específico da consulta via o comando abaixo:
DBCC FREEPROCCACHE (Plan_handle)
Após limpar o cache específico, realizei a análise do plano de execução e criei duas estatísticas. Após este procedimento a query tanto via SSMS e APP voltaram a performar.
Muitíssimo obrigado pelo apoio de todos.
Att,
Rafael Cardoso de Araújo MCTS - SQL Server 2005
Rafael,
Você citou algo bem importante criou duas estatísticas algo que pode ajudar muito, agora uma sugestão antes de criar novas estatísticas, force o SQL Server a atualizar todas as estatísticas internas e externas do seu banco de dados através do uso da system stored procedure sp_updatestats.
Pedro Antonio Galvao Junior [MVP | MCC | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]
terça-feira, 31 de janeiro de 2017 15:04 -
Pedro,
Boa tarde!
O interessante é que neste caso havia um job de atualização de estatísticas diário e inclusive foi executado para as tabelas envolvidas. Você acredita que poderia ser uma situação relacionada a este procedimento não estar sendo realizado com full scan?
Att
Rafael Cardoso de Araújo MCTS - SQL Server 2005
terça-feira, 31 de janeiro de 2017 15:21 -
Pedro,
Infelizmente o ambiente era SQL Server 2008R2.
Via SSMS 2016 eu conseguiria comparar os planos gerados no 10.50?
Att
Rafael Cardoso de Araújo MCTS - SQL Server 2005
terça-feira, 31 de janeiro de 2017 15:22 -
Rafael,
Infelizmente não.
Pedro Antonio Galvao Junior [MVP | MCC | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]
terça-feira, 31 de janeiro de 2017 16:42