none
Erro de timeout em INSERT RRS feed

  • Discussão Geral

  • Ola, pessoal

    Contexto: sistema web

    Estou com um problema em uma tabela especifica (movimento contabil), está dando erro de timeout.
    não é sempre, normalmente é rapido (instantaneo). Em momentos especificos (aleatorios, até então), o sistema deixa de gravar nessa tabela, e vamos conferir tem erro de timeout registrado no log (o timeout deve estar padrão, 30seg).

    - A tabela é bastante usada, mas não é um uso constante (sem parar 1 min)
    - É tambem muito usada em consultas pelo sistema.
    - Tem vários indices, que são recriados frequentemente.

    O erro dá aleatoriamente, não consigo ligar a nenhum evento de uso sistema...

    A minha ideia de vir perguntar aqui é para saber mais sobre o que pode estar relacionado a isso (um erro especifico por timeout, enquanto os processos em geral estão rodando normalmente).

    Sera que pode ser problema em indices? hardware? ou, que outros fatores mais poderiam estar relacionado a isso?

    Pode ser que seja em momentos em que a tabela é massivamente usada para consultas, isso pode comprometer o desempenho de 1 insert? Ou ainda, algum procedimento (consulta) que possa estar bloqueando a tabela?

    é estranho tambem que, junto com esse insert, foram executados outros na mesma tabela, com sucesso.


    Julio C.


    • Editado Julio Costi quarta-feira, 1 de abril de 2015 12:25
    • Tipo Alterado Matheus L. M. C. Campos quinta-feira, 2 de abril de 2015 04:19 Aguardando um erro de log preciso
    quarta-feira, 1 de abril de 2015 12:19

Todas as Respostas

  • Julio, bom dia.

    Você já tentou monitorar pelo Profiler ou usando o Extended Events (recomendo esse último)?

    Nesse monitoramento você pode entender o que está acontecendo no momento em que o timeout ocorre.

    Em relação a sua pergunta se uma consulta pode comprometer o insert depende de HINTs que podem ser usados. Um exemplo é se alguma consulta está utilizando, por exemplo, o TABLOCKX que causa um bloqueio exclusivo na tabela (não na linha, nem na página, mas na tabela toda), semelhante a um UPDATE sem WHERE.

    Essa tabela sofre UPDATES frequentemente? Se sim, é outra coisa que deve ser investigada porque dependendo da quantidade de dados afetadas o UPDATE pode fazer um LOCK exclusivo na tabela toda e por momentos bloquear o INSERT.

    Se pode ser hardware? Sim, mas aí você teria que estar com mais sintomas nessa instância além desse time-out no insert de uma tabela especifica.

    Se pode ser problema em índice? Depende! Se você tive muitos índices nessa tabela, cada insert afeta uma linha de cada índice e, digamos que você tenha 30 índices nela, num momento onde o servidor está mais sobrecarregado, poderia ocorrer time-out sim (mas não apostaria muito nessa hipótese).

    Aconselho você a monitorar os eventos usando os Extended Events e também coletar alguns contadores de performance pelo PerfMon do Windows. Isso te ajudará no diagnóstico.

    Alguns links que podem te ajudar..

    http://sqldicas.com.br/dicas/perfmon-e-sql-server/

    http://www.brentozar.com/archive/2006/12/dba-101-using-perfmon-for-sql-performance-tuning/

    http://www.brentozar.com/archive/2006/12/dba-101-using-perfmon-for-sql-performance-tuning/

    Espero ter ajudado.



    Mariana Del Nero /* Se a resposta foi útil, não esqueça de marcá-la */


    quarta-feira, 1 de abril de 2015 12:59
  • Esta trabalhando com transação?

    Isso esta me parecendo ser transação cara. Algum lugar do sistema esta iniciando uma transação, esta tabela esta recebendo alguma alteração nesta transação (insert, update ou delete), só que a transação não esta sendo finalizada (por algum bug do sistema provavelmente). Não esta sendo aplicado o COMMIT ou ROLLBACK. Por isso, a tabela não insere os dados e estoura o tempo de resposta, porque a transação nunca acaba.

    Pode ser isso. Para testar, faça um backup da base de dados, a restaure com um outro nome e altere a configuração de transação, coloque a configuração que nunca trava a tabela e faça testes com a nova base. Se o erro parar, provavelmente é isso mesmo. Ou simplesmente revise o código do sistema em busca de transações.

    Minha suspeita é essa, transação.


    - Tiago Maia Analista de Sistemas/Desenvolvedor C#

    quarta-feira, 1 de abril de 2015 13:21
  • Obrigado pelas indicações e auxilio, Mariana

    Vou analisar isso mais profundamente nos links, até porque essa parte do sql server é meu objeto de pesquisa.

    Como é SQL Server Express no cliente, não teria como executar o profiler :( 

    Vou dar uma olhada no Extended Events, até então desconhecia essa ferramenta.

    Não se trata de um ambiente grande, seria (era para ser, ao menos) simples e sem complicações, em termos de movimento.

    -----

    Quanto ao o problema em si , passamos a analisar alguns fatos no BD do cliente, e numa tabela de logs de erros, que até o dia 09/02/2015 não tinha nenhuma dessas ocasiões de timeout nessa tabela.

    Precisamente nesta data de 09/02, deu uma sequencia de erros, um atras do outro, o cliente ficou um tempo sem sistema... Daí então, as vezes dá um erro de timeout nessa tabela especificamente (em diversos processos diferentes)...

    Dai começo a descartar quase tudo que estava pensando.. na verdade, nem sei o que pensar exatamente que pode ser... 

    Deve ser algo bem especifico... o mesmo sistema funciona redondinho em vários clientes com estrutura bem semelhante , e maiores (em movimento)... não descarto algo de servidor (windows server 2012) ou até mesmo hardware...

    Teria alguma recomendação, algo como um "reset" em alguma situação do BD?

    Reinstalar ele, ou criar outro MDF e importar as tabelas para ele.. poderia resolver algo?

    Ou algum outro comando no BD que possibilite uma recuperação nesse sentido?

    Eu sei que sem saber exatamente o que ocasiona o problema é dificil... 

    Obrigado pelas ajudas.


    Julio C.


    • Editado Julio Costi quarta-feira, 1 de abril de 2015 14:20
    quarta-feira, 1 de abril de 2015 14:13
  • Obrigadão, Tiago... estou ja vendo no codigo das partes do sistema que geram a contabilidade, algo nesse sentido. 

    No mais, veja a outra resposta (p/ Mariana), algo que está acontecendo realmente é estranho...


    Julio C.

    quarta-feira, 1 de abril de 2015 14:15
  • Julio,

    "Precisamente nesta data de 09/02, deu uma sequencia de erros," que erros exatamente? No SQL Server ou na sua aplicação? 

    Se foi no SQL Server, tente coletar os logs e coloque aqui pra tentarmos ajudar.

    Não acredito que tenha alguma coisa a ver, mas se quiser checar a integridade do seu DB, execute o DBCC CHECKDB e veja se retorna alguma inconsistência.

    Quanto ao Profiler, a ferramenta não é instalada na versão Express, mas se você tiver, nada impede de apontar para a instância do cliente.
    Eu recomendo o Extended Events porque o Profiler é pesado pro ambiente e vejo N recomendações de profissionais feras para que seja substituído pelo XEvents.


    Mariana Del Nero /* Se a resposta foi útil, não esqueça de marcá-la */

    quarta-feira, 1 de abril de 2015 14:26
  • Mariana, 

    são erros de instruções SQL mal sucedidas, que o SQL Server retorna p/ a aplicação (erros no sql server)

    poderia dar uma olhada no log?

    extrai (apenas os erros de timeout, que são os unicos relevantes, na verdade) e salvei no excel

    https://www.dropbox.com/s/ca22xh58b53bnkx/erros%20sql%20server.xlsx?dl=0

    Não tem nenhum antes desses, o sistema registra faz quase 1 ano.


    Julio C.

    quarta-feira, 1 de abril de 2015 14:36
  • Mas são erros genericos... erros "da aplicaçao" sim

    Tem algum tipo de log de erros/eventos como tem no windows p/ o SQL Server?

    ---

    XEvents, blz vou ver sobre isso, obrigado


    Julio C.

    quarta-feira, 1 de abril de 2015 14:44
  • Sim. Existem falhas que são logadas no log do próprio SQL e algumas no log do Windows (exemplo: erro na autenticação de usuário ao subir o serviço do SQL)

    No SQL o log está em Management-> SQl Server Logs.

    Olhei os erros. Você notou se eles sempre ocorrem nesses horários que estão na planilha (entre 9:30 a 10:10 geralmente)? Se sim já é uma dica de quando terá que coletar os dados.

    Realmente você vai ter que monitorar por um tempo para descobrir qual é a transação que está fazendo lock na tabela, impedindo os INSERTS e até os DELETES.
    Preste atenção em triggers também. Talvez alguma delas possa estar causando esse LOCK.


    Você pode também usar as DMVs para investigar o seu problema.
    Aqui tem um artigo simples e bom sobre o tema.

    https://www.simple-talk.com/sql/database-administration/investigating-transactions-using-dynamic-management-objects/


    Mariana Del Nero /* Se a resposta foi útil, não esqueça de marcá-la */

    quarta-feira, 1 de abril de 2015 14:59
  • Verifiquei os logs, simplesmente não vejo nada que possa interferir (nem regularmente conforme os erros, nem de outra forma);

    Os erros nem sempre tem uma regularidade de horario... até acontecem com mais frequencia no periodo da manhã, talvez o cliente tenha mais movimento na manhã, daí é pela probabilidade mesmo.

    Só um detalhe, neste dia 09/02, apos dar vários timeout em sequencia, verifiquei que o sql server foi reiniciado (provavelmente o servidor foi reiniciado), e cessaram os erros naquele momento.

    ---

    Estou pensando mais em algo do sistema bloqueando a tabela mesmo... ou terem instalado alguma coisa no servidor que mata o processamento da maquina, e com isso nem ter registrado no log (nada de erros).

    ---

    Vou verificar sobre o que voce comentou, das DMV's,

    Obrigado!!


    Julio C.

    quarta-feira, 1 de abril de 2015 17:30
  • Bom dia a todos,

    Por se tratar de um erro aonde a inconsistência dos LOGs não  nos gera uma solução direta estarei transformando essa duvida em uma discussão geral porem Julio se sinta a vontade para transforma-la em uma duvida quando bem entender e da mesma forma marcar a solução que lhe chegou mais próximo de uma solução no decorrer dos dias.

    Abraços


    Matheus Leopardi Mello Canelada Campos

    Esse conteúdo e fornecido sem garantias de qualquer tipo, seja expressa ou implícita

    TechNet Community Support

    Por favor, lembre-se de Marcar como Resposta as respostas que resolveram o seu problema. Essa e uma maneira comum de reconhecer aqueles que o ajudaram e fazer com que seja mais fácil para os outros visitantes encontrarem a resolução mais tarde.

    quinta-feira, 2 de abril de 2015 04:19
  • Estou vendo sobre os Extend Events

    Como o SQL Express no cliente é 2008 R2, não tem o Extend Events nativo,

    achei um video ( https://www.youtube.com/watch?t=74&v=xVu5rzVArMk ) onde indica uma ferramenta de terceiros, interessante (estou tendo problemas tambem com ela, mas é outro assunto)

    Mas comecei a mexer numa maquina que eu tenho o sql 2012, e tem muitas opções mesmo, fiquei até meio perdido (para o meu objetivo no momento);

    Mariana (e outros), tem como me recomendar um tutorial (video, ou texto..) simples para simplesmente captar as consultas que são executadas? eu conseguia isso com o profiler

    Obrigado!


    Julio C.

    quinta-feira, 2 de abril de 2015 13:28
  • Julio,

    Eu pegaria os seguintes eventos e colunas, através do Profiler

    Locks
    Lock:TimeOut
    Lock:TimeOut (timeout >0)

    Stored Procedures
    RPC: Completed

    TSQL
    SQL:BatchCompleted

    Transactions
    TM: Begin Tran Starting
    TM: Begin Tran Completed
    TM: Commit Tran Completed
    TM: Rollback Tran Completed


    COLUNAS: TextData, ApplicationName, Cpu, Reads, Writes, Duration, ClientProcessID, StartTime, EndTime, Spid, EventSequence, TransactionID, XactSequence

    No link abaixo tem um artigo (desculpe por ser em inglês, mas as vezes as referências em português são escassas ou inexistentes) que pode te ajudar com a ferramenta, em como configurar as opções que passei acima.

    Execute por algum tempo, mas não muito porque isso pode prejudicar seu ambiente. Faça até capturar alguns timeouts.

    Depois se quiser subir no DROPBOX o arquivo, posso te ajudar a analisar e ver se descobrimos algo.


    Mariana Del Nero /* Se a resposta foi útil, não esqueça de marcá-la */

    quinta-feira, 2 de abril de 2015 14:49

  • Ola,

    voce comentou de um artigo, mas acho que faltou o link (quanto a ser em ingles, tranquilo)

    ---

    mexendo ontem, eu pensei mesmo nessas opções das transactions.. e não vi do tsql

    Um problema: 

    - é que os timeout estão sendo muuuito esporádicos, tem dias que não dá, alias, antes do ultimo, fazia mais de uma semana.

    Voce diz que deixar rodando muito tempo pode pesar demais, mas estamos falando do Extend Events, ou do profiler?  Mesmo o extend events, pode?

    ---

    sobre as DMV que vc comentou antes, eu lembrei que ja usava para estatistica de fragmentação de indices.

    Mas para algo mais especifico como monitorar possiveis erros (descobrir oq acontecia no momento), é preciso usa-las em algo que fique rodando? (profiler ou xevents)

    ou elas por si só mantem informações registradas?

    ---

    Desde já, muuuuuito obrigado pela disponibilidade, e por todas as sugestões até então :)


    • Editado Julio Costi quinta-feira, 2 de abril de 2015 19:54
    quinta-feira, 2 de abril de 2015 19:53
  • Me desculpe. O link é:

    http://blog.sqlauthority.com/2009/08/03/sql-server-introduction-to-sql-server-2008-profiler-2/

    O Profiler é algo pra você monitorar pequenos períodos. Eu, antes do XEvents, para monitar um ambiente pelo profiler, sempre fazia ciclos de 15 - 20 minutos de coleta (meu ambiente é bem concorrido chegando a 5000 conexões simultâneas) pelo fato dele onerar o ambiente.

    O XEvent já é mais leve, mas mesmo assim não deixaria executando por horas.

    Faça o seguinte: identifique o horário mais provável que ocorre seus timeouts e tente monitorar esses horários em períodos curtos (15 - 20 minutos) até que consiga capturar o timeout.

    Minha aposta é que vendo o que está acontecendo no servidor ao mesmo tempo que o timeout, você consiga ver qual ou quais comandos estão bloqueando a tabela.


    Em relação as DMVs, elas guardam vários dados da instância e são acessadas com um SELECT.

    Elas  não tem o ônus do Profiler e muitas vezes ajudam bastante. Por isso sugeri o link 

    https://www.simple-talk.com/sql/database-administration/investigating-transactions-using-dynamic-management-objects/


    Mariana Del Nero /* Se a resposta foi útil, não esqueça de marcá-la */

    quinta-feira, 2 de abril de 2015 20:20
  • Blz, vou ver sobre as DMVs com mais calma

    --

    Mas em relação a performance, o ambiente não é concorrido assim (a ponto de usar o Express mesmo, e ser bem tranquilo quanto a performance em geral, apenas com esses problemas pontuais - que não tem a ver com performance, imagino).

    Só não ficou claro: 

    Voce mencionou: "Eu pegaria os seguintes eventos e colunas, através do Profiler"

    Nesse caso (o exemplo apos isso) é do profiler mesmo, e não do xevents?

    ---

    Descartei a hipotese de bloqueio da tabela, fizemos muitos testes e achei que não tem como ser isso. Tambem aposto em algo que acontece no servidor no momento do insert falha..

    Num dos "timeout" eu identifiquei um problema de relativa gravidade no sistema, porém, que por si só não  teria a ver com o timeout na sequencia

    Noutros, não teve nada a ver com outros eventos do sistema.

    -

    Uma possivel solução paliativa seria capturar e identificar o timeout, e fazer executar novamente (1 ou 2 vezes); mas não gosto nada desse tipo de solução.

    --

    Vou ver como planejar esse monitoramento.

    Muito obrigado


    Julio C.



    • Editado Julio Costi quinta-feira, 2 de abril de 2015 20:31
    quinta-feira, 2 de abril de 2015 20:29
  • Possivel resolução (outro topico por mim mesmo)

    https://social.msdn.microsoft.com/Forums/pt-BR/1f29256b-754a-4db5-8124-8ab8adf072b0/timeout-em-insert?forum=520

    (era possivelmente problema com locks)


    • Editado Julio Costi quinta-feira, 9 de junho de 2016 19:48
    sexta-feira, 6 de maio de 2016 21:47