• Início

  • Soluções

    • Advanced Analytics e IA
    • Database
    • Development
    • Cloud Solutions
  • Cursos

  • Carreira

    • Acelera Jovem
  • Comunidade

  • Blog

  •  

    Use tab to navigate through the menu items.
    Para ver como funciona, vá para o seu site online.
    • Todos os posts
    • Categorias
    • Meus Posts
    dataside
    03 de mai.

    O dia em que o SQL Agent parou de gravar no histórico

    em A.I. e Machine Learning

    Neste artigo técnico, o dataholic Fábio Ramos aborda sobre o caso em que o SQL Agent parou de gravar no histórico e mostra como encontrou a solução. Vem aprender com ele!


    Olá, pessoal! Neste artigo vou mostrar um caso real que aconteceu envolvendo o SQL Agent.


    Resumo do caso:


    Cliente ao consultar o histórico de um Job, evidenciou que o mesmo não estava no histórico de execução. O último registro que tinha era de meses atrás. A duração desse último registro é que estava sendo executado há muito tempo.


    Simulei no meu ambiente o mesmo cenário.


    Job com 3 steps:


    Percebam que antes do “problema” (em verde), o histórico estava sendo gravado sem problemas.


    Porém, ficou congelado ali no Step2 como In Progress e a duração só aumentando:


    Executei um Refresh, e a duração saiu de 6 minutos para 11:


    Início do troubleshooting, como pode um waitfor delay de 5 segundos estar ainda em execução?


    WhoIsActive? Nada.


    Vamos filtrar na sys.sysprocess, vai que… Para isso, executei a query abaixo para pegar o hexadecimal, para que eu possa filtrar pelo “Program Name” do job:


    Nada também:


    Tá, e se eu executar o job? Se ele de fato estiver em execução, tomarei um erro…


    Job executado com sucesso:


    Consultando o histórico novamente, nada mudou, não gravou o histórico e a duração continua acumulando:


    Será que meu Agent está expurgando esses dados? Também não está limitado…


    E se reiniciar o Agent? Vamos lá…


    Mesmo cenário:


    Quase sem opções, decidi ligar o Profiler e rastrear o Job.

    Eis que encontro o erro “Arithmetic overflow error converting IDENTITY do data type int”:


    Peguei o trecho e executei na mão:


    Vamos abrir essa procedure e ver o que tem na linha 125:


    Consultando a estrutura da tabela, temos um identity pela coluna instance_id, que é um INT:


    Verificando o valor atual desde IDENTITY:


    Pois é, chegou ao seu limite…


    Lembrando que os Jobs internos de expurgo de Job History do SQL Server, utilizam DELETE, com isso o valor do identity segue a vida incrementando.


    Após isso, foi feito o recycle do IDENTITY na tabela:


    Realizei a limpeza também do histórico deste Job, para que não continue com aquela sujeira de estar executando há muito tempo:


    Histórico gravando novamente:


    Caso você queira simular este problema, basta durante a execução de algum Job aumentar o IDENTITY da sysjobhistory para o limite do INT:


    Espero que tenham gostado e que eu tenha agregado um pouco de conhecimento à vocês.