locked
Procedure chamada via aplicação com lentidão RRS feed

  • Pergunta

  • Boa tarde pessoal,

    Sou novo aqui e precisaria muito da ajuda de vocês. Tenho uma determinada procedure que ao ser chamada pela aplicação, demora uns 40, 45 minutos e ocorre o timeout na aplicação. Essa mesma procedure sendo chamada diretamente no SSMS processa em menos de 5 segundos. Fiz um teste logando no SQL com o usuário da aplicação que é sysadmin e processei a procedure e os dados são retornados em menos de 5 segundos.

    Alguém tem alguma idéia do que isso pode ser ?

    quinta-feira, 25 de setembro de 2014 18:58

Respostas

  • Baptistare,

    Se executa tão rápido no SSMS, então não acredito que esta lentidão esteja relacionada à sua instância SQL, mas sim no modo que o seu código (C#, VB.Net, ...) foi implementado.

    Sugiro que você faça uma revisão e tente executar a procedure, se possível utilizando o objeto SQLCommand apenas na propriedade "CommandText". 

    Veja em exemplo abaixo:

    SqlCommand cmd = new SqlCommand();
    cmd.CommandText = "EXEC SuaProc";

    Para maiores informações veja:

    http://msdn.microsoft.com/pt-br/library/d7125bke.aspx 

    http://msdn.microsoft.com/pt-br/library/ms171921.aspx

    Se ajudou na sua solução, não esqueça de marcar como resposta !

    Abraços,

    Durval Ramos
    Microsoft Partner | MTA | MCSA - SQL Server 2012 | MCSE - Data Platform
    ----------------------------------
    Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil"
    sexta-feira, 26 de setembro de 2014 14:03
  • Baptistare,

    Concordo com o Durval!!!

    Você poderia destacar um pouco mais sobre o seu ambiente e também sobre a aplicação?

    Como a Stored Procedure esta sendo passada na aplicação para ser executada? Qual componente de banco de dados esta sendo utilizado e de que forma?

    Um ponto que me chamou a atenção no retorno da análise lógica da sua tabela foi esta linha:

    Table 'MMIS_CUPOM_ITEM'. Scan count 6, logical reads 3233, physical reads 25, read-ahead reads 20, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

    Seria interessante verificar a Table MMIS_Cupom_Item, provavelmente a mesma pode estar com fragmentação ou alocação de dados mal distribuída.

    Você já verificou as estatísticas de índice desta tabela?


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitário | SoroCódigos] @JuniorGalvaoMVP | pedrogalvaojunior.wordpress.com


    sexta-feira, 26 de setembro de 2014 14:56
    Moderador
  • Pessoal, apesar da demora vim apenas para agradecer a ajuda de vcs. Infelizmente não consegui identificar o problema ocorrido visto que no dia seguinte todo o ambiente está estável e sem lentidão. Isso me parece que alguma coisa foi alterada e não fiquei sabendo, rs, mas mesmo assim agradeço as dicas recebidas e caso eu descubra o que causou o meu problema, voltarei aqui para informá-los.

    Obrigado pessoal.

    terça-feira, 30 de setembro de 2014 15:39

Todas as Respostas

  • Você verificou se possui conexões abertas que não foram fechadas?

    No seu sqlcommand, adicione commandtimeout = 0;

    Isso fará com que a execução não dê timeout...

    Poste parte do código para ajudarmos no seu problema.


    Se o meu conteúdo resolveu o seu problema ou sua dúvida, então marque como "Resposta", ou se foi útil, "Vote". Pois isso ajudará outras pessoas com o mesmo problema ou dúvida.

    quinta-feira, 25 de setembro de 2014 19:15
  • Baptistare,

    Esse diferença esta muito grande... de 45 minutos para 5 segundos ...

    Você executou a procedure no SSMS da mesma maquina que esta usando sua aplicação ?

    Se foi, o problema é na sua aplicação, não é problema na procedure e nem na rede.

    Se não foi, você pode fazer um teste instalando o "Client Tools Connectivity" na maquina que esta rodando sua aplicação.


    Tulio Rosa | http://tuliorosa.com.br | Se resolveu seu problema, marque como resposta ou vote

    quinta-feira, 25 de setembro de 2014 19:28
  • Tulio, não, loguei no ssms em minha máquina com o mesmo usuário da aplicação e com o comando executado via aplicação rodei e pelo ssms me retorna muito rápido. O que não estou entendendo é que essa mesma procedure chamada via aplicação, ao monitorar a solicitação via dm_exec_requests, o tempo de cpu e de logical reads só aumenta até a conexão cair via aplicação. Quanto ao teste de conectividade, isso está ocorrendo desde manhã e alguns processos que o usuário roda pela aplicação demoram mas retornam, mas chegou em um determinado processo que não retorna nada e da o timeout.

    Fiz um teste a pouco capturando as leituras lógicas e físicas pelo SSMS e ele me retorna o seguinte:

    Table 'MCAD_FILIAL'. Scan count 0, logical reads 3, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.


    (2 row(s) affected)
    Table 'MRTG_NF_CLIENTE'. Scan count 4, logical reads 4890, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
    Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
    Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
    Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
    Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
    Table 'MMIS_CUPOM_ITEM'. Scan count 6, logical reads 3233, physical reads 25, read-ahead reads 20, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
    Table 'pk_mrtgr_encom_pend_hist'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
    Table 'MRTG_DEVCONS'. Scan count 9, logical reads 36, physical reads 22, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
    Table 'MRTG_ITEMDEVCONS'. Scan count 2, logical reads 33, physical reads 19, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
    Table 'MCAD_PRODUTO'. Scan count 2, logical reads 24, physical reads 7, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

    Essa mesma procedure acompanhada pela dmv dm_exec_requests, me mostra um número muito maior de leitura lógicas, mais de 6 milhões de leituras e aumentando.

    quinta-feira, 25 de setembro de 2014 20:07
  • Tulio, não, loguei no ssms em minha máquina com o mesmo usuário da aplicação e com o comando executado via aplicação rodei e pelo ssms me retorna muito rápido. O que não estou entendendo é que essa mesma procedure chamada via aplicação, ao monitorar a solicitação via dm_exec_requests, o tempo de cpu e de logical reads só aumenta até a conexão cair via aplicação. Quanto ao teste de conectividade, isso está ocorrendo desde manhã e alguns processos que o usuário roda pela aplicação demoram mas retornam, mas chegou em um determinado processo que não retorna nada e da o timeout.

    Fiz um teste a pouco capturando as leituras lógicas e físicas pelo SSMS e ele me retorna o seguinte:

    Table 'MCAD_FILIAL'. Scan count 0, logical reads 3, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.


    (2 row(s) affected)
    Table 'MRTG_NF_CLIENTE'. Scan count 4, logical reads 4890, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
    Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
    Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
    Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
    Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
    Table 'MMIS_CUPOM_ITEM'. Scan count 6, logical reads 3233, physical reads 25, read-ahead reads 20, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
    Table 'pk_mrtgr_encom_pend_hist'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
    Table 'MRTG_DEVCONS'. Scan count 9, logical reads 36, physical reads 22, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
    Table 'MRTG_ITEMDEVCONS'. Scan count 2, logical reads 33, physical reads 19, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
    Table 'MCAD_PRODUTO'. Scan count 2, logical reads 24, physical reads 7, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

    Essa mesma procedure acompanhada pela dmv dm_exec_requests, me mostra um número muito maior de leitura lógicas, mais de 6 milhões de leituras e aumentando.

    Baptistare,

    Só para entender, você já executou a procedure da mesma maquina que tem o SSMS e sua aplicação ?

    Precisa fazer o teste executando da mesma maquina, para descartar algumas possibilidades, pode ser da sua maquina, mas tem que executar o SSMS e a aplicação.


    Tulio Rosa | http://tuliorosa.com.br | Se resolveu seu problema, marque como resposta ou vote

    quinta-feira, 25 de setembro de 2014 20:50
  • Deleted
    quinta-feira, 25 de setembro de 2014 21:07
  • Baptistare,

    Se executa tão rápido no SSMS, então não acredito que esta lentidão esteja relacionada à sua instância SQL, mas sim no modo que o seu código (C#, VB.Net, ...) foi implementado.

    Sugiro que você faça uma revisão e tente executar a procedure, se possível utilizando o objeto SQLCommand apenas na propriedade "CommandText". 

    Veja em exemplo abaixo:

    SqlCommand cmd = new SqlCommand();
    cmd.CommandText = "EXEC SuaProc";

    Para maiores informações veja:

    http://msdn.microsoft.com/pt-br/library/d7125bke.aspx 

    http://msdn.microsoft.com/pt-br/library/ms171921.aspx

    Se ajudou na sua solução, não esqueça de marcar como resposta !

    Abraços,

    Durval Ramos
    Microsoft Partner | MTA | MCSA - SQL Server 2012 | MCSE - Data Platform
    ----------------------------------
    Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil"
    sexta-feira, 26 de setembro de 2014 14:03
  • Baptistare,

    Concordo com o Durval!!!

    Você poderia destacar um pouco mais sobre o seu ambiente e também sobre a aplicação?

    Como a Stored Procedure esta sendo passada na aplicação para ser executada? Qual componente de banco de dados esta sendo utilizado e de que forma?

    Um ponto que me chamou a atenção no retorno da análise lógica da sua tabela foi esta linha:

    Table 'MMIS_CUPOM_ITEM'. Scan count 6, logical reads 3233, physical reads 25, read-ahead reads 20, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

    Seria interessante verificar a Table MMIS_Cupom_Item, provavelmente a mesma pode estar com fragmentação ou alocação de dados mal distribuída.

    Você já verificou as estatísticas de índice desta tabela?


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitário | SoroCódigos] @JuniorGalvaoMVP | pedrogalvaojunior.wordpress.com


    sexta-feira, 26 de setembro de 2014 14:56
    Moderador
  • Pessoal, apesar da demora vim apenas para agradecer a ajuda de vcs. Infelizmente não consegui identificar o problema ocorrido visto que no dia seguinte todo o ambiente está estável e sem lentidão. Isso me parece que alguma coisa foi alterada e não fiquei sabendo, rs, mas mesmo assim agradeço as dicas recebidas e caso eu descubra o que causou o meu problema, voltarei aqui para informá-los.

    Obrigado pessoal.

    terça-feira, 30 de setembro de 2014 15:39