Como um DBA, existem certas coisas que podem causar tristeza e frustração. Um desses problemas é a sobrescrita de agendamentos de tarefas no SQL Server. Embora possa não ser considerado um bug, é definitivamente um problema que pode pegar você de surpresa se você não estiver ciente disso.

Quando você cria um script de uma Tarefa do Agente SQL, você notará que o agendamento da tarefa possui um parâmetro schedule_uid. Esse parâmetro é usado para identificar o agendamento da tarefa. No entanto, o problema está no fato de que se você criar outro agendamento de tarefa com o mesmo schedule_uid, ele irá sobrescrever o agendamento de todas as tarefas que o estão usando. Em outras palavras, todas as outras tarefas que estão usando esse schedule_uid começarão a usar o novo agendamento.

Normalmente, os UIDs são considerados únicos e as chances de colisão são baixas. No entanto, se você copiar frequentemente tarefas entre servidores SQL, há uma boa chance de que esse problema eventualmente o afete. Isso já aconteceu conosco mais de uma vez.

Vamos dar uma olhada em um exemplo para entender melhor esse problema. Suponha que temos uma tarefa chamada ‘Tarefa de Teste’ com um agendamento definido para ser executado a cada 5 minutos. Quando criamos um script dessa tarefa, vemos que a seção de agendamento inclui o schedule_uid:

EXEC @ReturnCode = msdb.dbo.sp_add_jobschedule
    @job_id = @jobId,
    @name = N'5 Minutos',
    @enabled = 1,
    @freq_type = 4,
    @freq_interval = 1,
    @freq_subday_type = 4,
    @freq_subday_interval = 5,
    @freq_relative_interval = 0,
    @freq_recurrence_factor = 0,
    @active_start_date = 20170123,
    @active_end_date = 99991231,
    @active_start_time = 0,
    @active_end_time = 235959,
    @schedule_uid = N'89ef7def-1c85-4791-80e6-fc494514e356'

O problema está no schedule_uid. Se criarmos outro agendamento de tarefa com o mesmo schedule_uid, ele irá sobrescrever o agendamento de todas as tarefas que o estão usando. Vamos criar uma segunda tarefa chamada ‘Minha Nova Tarefa’ com o mesmo schedule_uid:

EXEC @ReturnCode = msdb.dbo.sp_add_jobschedule
    @job_id = @jobId,
    @name = N'Diário',
    @enabled = 1,
    @freq_type = 4,
    @freq_interval = 1,
    @freq_subday_type = 1,
    @freq_subday_interval = 0,
    @freq_relative_interval = 0,
    @freq_recurrence_factor = 0,
    @active_start_date = 20170203,
    @active_end_date = 99991231,
    @active_start_time = 10000,
    @active_end_time = 235959,
    @schedule_uid = N'89ef7def-1c85-4791-80e6-fc494514e356'

Agora, se olharmos o agendamento da ‘Minha Nova Tarefa’, ele parece estar correto. No entanto, o que não percebemos é que, como usamos o mesmo schedule_uid, ele sobrescreveu o agendamento da ‘Tarefa de Teste’ também. Isso pode levar a confusão e comportamento inesperado.

Embora possa parecer um bug, o procedimento armazenado sp_add_jobschedule não falha se um agendamento com um schedule_uid correspondente já existir. Em vez disso, ele simplesmente sobrescreve os detalhes do agendamento e continua, deixando os DBAs para limpar a bagunça.

Então, como podemos evitar esse problema? A solução é simples. Tudo que você precisa fazer é remover o schedule_uid da etapa sp_add_jobschedule e ele não irá sobrescrever nenhum dos agendamentos de tarefas existentes. Em vez disso, ele atribuirá um novo UID durante a criação.

Esse problema geralmente surge ao copiar Tarefas do Agente SQL entre servidores e ambientes. Já encontramos esse problema várias vezes, onde alguém estava criando ou copiando uma tarefa que incluía o schedule_uid e isso inadvertidamente alterava os agendamentos de tarefas existentes. Pode levar meses para descobrir e corrigir esses problemas.

Esperamos que este post do blog evite que alguém tenha que lidar com esse problema, como já tivemos que fazer no passado. Lembre-se de ter cuidado ao lidar com agendamentos de tarefas e garantir que você não os sobrescreva inadvertidamente.

Boa sorte e feliz scripting!