Как точно определить, выполняется ли задание SQL Server, и обработать уже запущенное задание?

) В настоящее время я использую подобный код, чтобы определить, выполняется ли задание SQL-сервера. (это это SQL Server 2005, все SP ' s)

return (select isnull(  
(select top 1 CASE 
    WHEN current_execution_status = 4 THEN 0
    ELSE 1
    END
from openquery(devtestvm, 'EXEC msdb.dbo.sp_help_job')
where current_execution_status = 4 and
    name = 'WQCheckQueueJob' + cast(@Index as varchar(10))
), 1)
)

Проблем нет, и, вообще говоря, все работает отлично.

Но .... (всегда но)

Иногда я вызываю это и возвращаюсь к ответу: "работа не running "результат, после чего я попытаюсь запустить задание через

exec msdb.dbo.sp_start_job @JobName

, и SQL вернет, что" SQLAgent отказался запустить задание, потому что у него уже есть ожидающий запрос ".

Хорошо. Тоже не проблема. Вполне возможно, что есть небольшое окно, в котором целевое задание может быть запущено до того, как этот код сможет его запустить, но после проверки, запущено ли оно. Тем не менее, я могу просто заключить это в уловку попытки и просто проигнорировать ошибку, верно?

begin try
if dbo.WQIsQueueJobActive(@index) = 0 begin
    exec msdb.dbo.sp_start_job @JobName
    break
end         
end try begin catch
    -- nothing here
end catch

вот в чем проблема.

В 9 случаях из 10 это работает нормально. Агент SQL выдаст ошибку, она будет обнаружена, и обработка просто продолжится, поскольку задание уже выполняется, без вреда для себя.

Но иногда я получаю сообщение в представлении истории заданий (помните о приведенном выше коде, чтобы определить, выполняется ли конкретное задание, и запустить его, если на самом деле не выполняется другое задание) о том, что задание не выполнено, потому что «SQLAgent отказался запустить задание, потому что у него уже есть ожидающий запрос».

Конечно, это именно та ошибка, которую TRY CATCH должен обрабатывать!

Когда это происходит, выполняемое задание просто умирает, но не сразу, насколько я могу судить, просто довольно близко. Я повсюду веду журналы, и нет никакой последовательности. Один раз он выйдет из строя, он будет в месте a, в следующий раз в месте b. В некоторых случаях между местом A и местом B нет ничего, кроме

select @var = 'message'

. Очень странный. В основном, Текущий поток управления выглядит следующим образом:

1. Изменение таблицы (обновление или вставка) ...
2. запускает триггер, который вызывает ...
3. сохраненную процедуру, которая вызывает ...
4. sp_Start_Job which. ..
5. запускает конкретное задание, которое ...
6. вызывает другую сохраненную процедуру (называемую CheckQueue), которая ...
7. выполняет некоторую обработку и ...
8. проверяет несколько таблиц и, в зависимости от их содержимого, может ...
9. вызвать процедуру sp_start_job для другого задания, чтобы запустить второе одновременное задание для обработки дополнительной работы (это второе задание также вызывает функцию CheckQueue. но два вызова работают с совершенно разными наборами данных)