locked
Travamento de query RRS feed

  • 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/

    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/

    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/

    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/

    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

    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