window.lintrk('track', { conversion_id: 13086145 }); O dia em que o SQL Agent parou de gravar no histórico
top of page

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

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. Até a próxima!

bottom of page