Хороший спосіб викликати кілька завдань агента SQL Server послідовно з однієї основної роботи?

У мене є кілька завдань агента SQL Server, які повинні виконуватися послідовно. Щоб зберегти хороший огляд завдань, які слід виконати, я створив основне завдання, яке викликає інші завдання з викликом EXEC msdb.dbo.sp_start_job N'TEST1'. В sp_start_jobобробки миттєво (Job Step 1), але тоді я хочу , щоб моя основна робота чекати , поки робота TEST1НЕ буде закінчена до виклику наступного завдання.

Отже, я написав цей невеликий сценарій, який починається виконувати відразу після виклику завдання (Job Step 2), і змушує основне завдання чекати, поки доповнене завдання закінчиться:

WHILE 1 = 1
  BEGIN
    WAITFOR DELAY '00:05:00.000';

    SELECT *
    INTO   #jobs
    FROM   OPENROWSET('SQLNCLI', 'Server=TESTSERVER;Trusted_Connection=yes;',
           'EXEC msdb.dbo.sp_help_job @job_name = N''TEST1'',
           @execution_status = 0, @job_aspect = N''JOB''');

    IF NOT (EXISTS (SELECT top 1 * FROM #jobs))
      BEGIN
        BREAK
      END;

    DROP TABLE #jobs;

  END;

Це працює досить добре. Але я відчув, що розумніші та / або безпечніші ( WHILE 1 = 1?) Рішення повинні бути можливими.

Мені цікаво наступні речі, сподіваюся, що ви зможете надати мені деякі відомості:

• Які проблеми з цим підходом?
• Чи можете ви запропонувати кращий спосіб зробити це?

( Спочатку я опублікував це питання в StackOverflow , тому що я зосереджувався на вдосконаленні коду. Все-таки дійсний. Але я здогадуюсь, що люди тут взагалі мають розумніші речі сказати, чому я не повинен намагатися робити це так, як я я зараз це роблю або пропоную хороші альтернативи.)

EDIT (25 липня)
Мабуть, в моєму сценарії не так вже й неправильно, згідно з низькою кількістю відповідей, що вказують на проблеми з ним :-) Альтернативою цьому сценарію, як видається, є використання інструменту, призначеного для цього завдання (на зразок SQL Sentry Event Manager або ...) - або написати такий інструмент самостійно. Ми не будемо купувати такий інструмент у моєї нинішньої компанії, тому поки що я просто дотримуюся сценарію.

Відмова: Я працюю в SQL Sentry.

У нашому продукті SQL Sentry Event Manager створена спеціально для цього: ланцюжок завдань і упорядкування їх у різних замовленнях робочого процесу.

Я почав використовувати SQL Sentry років тому, перш ніж я колись приєднався до компанії, щоб зробити саме це. Що я хотів, це спосіб почати роботу з відновлення на нашому тестовому сервері одразу після завершення резервного копіювання на виробництві.

Я спочатку реалізував - це лише істотний буфер між часом початку роботи резервного копіювання та часом початку відновлення. Це було не зовсім безглуздо; оскільки резервні часи варіювали, буфер часто залишав нас витраченим часом, коли відновлення не було розпочато, хоча воно могло мати. І іноді буфера було недостатньо.

Наступне, що я реалізував, було схожим на те, що у вас є - я написав завдання на тестовий сервер, який розпочався незабаром після запланованого резервного копіювання, і продовжував опитувати, щоб побачити, коли робота закінчена. Пізніше було внесено поправки, щоб просто зробити другий крок у роботі резервного копіювання, яка оновила таблицю на тестовому сервері. Не дуже сильно відрізняється, окрім завдання відновлення, потрібно було лише спостерігати за таблицею на місцях, а не віддалено контролювати історію завдань. Думаючи, що це могло стати тригером на тій таблиці, яка викликала, sp_start_jobтому робота не повинна запускатися кожні n хвилин (або взагалі плануватися).

Остаточне рішення полягало в тому, щоб з'єднати завдання разом ... коли резервне копіювання на сервері A закінчується, менеджер подій запускає завдання відновлення на сервері B. І якщо була третя робота, і четверта робота, або умовна логіка, що базується на тому, що робити коли робота провалюється проти успішної роботи тощо, це все можна врахувати. Дизайнер робочого процесу нагадає вам про SSIS:

Основна механіка того, що я описую, - це, звичайно, не ракетна хірургія. Ви можете написати цей тип обмотки на ланцюжок самостійно, якби сіли та зробили це. Просто пропонуємо вам одну альтернативу там, де не потрібно.

Основна проблема вашого підходу полягає в тому, що вам доведеться постійно обводити цикл, поки щось не відбудеться (що може бути жахливо довгим або навіть ніколи), і це не зовсім правильно. Тому я думаю, ви задаєте це питання.

Отже, як щодо використання підходу, керованого даними до вашої проблеми? Наприклад, створіть таблицю "аудиту", до якої пише кожне завдання під час його запуску та завершення:

Назва роботи | Час початку | Час закінчення
--------- + ------------------- + ------------------
Тест1 2012-07-26 07:30 2012-07-26 07:35

Створіть таблицю "обробки", в якій перераховані всі завдання та порядок їх виконання:

Назва роботи | Виконати замовлення
--------- + ---------
Тест1 | 1
Тест2 | 2
Тест3 | 3

Створіть тригер вставлення на таблиці аудиту, щоб після завершення завдання та вставлення запису аудиту тригер запитував таблицю обробки для наступного завдання (за допомогою Run Order) та потім запускав його.

Переваги цього підходу:

1. Це досить просто розробляти і підтримувати.
2. Це дає можливість додавати нові завдання або змінювати порядок існуючих завдань через таблицю обробки, не змінюючи рядок коду.
3. Таблиця аудиту дає певну видимість того, коли все сталося.
4. Він не витрачає цикли процесора. Курок спрацює лише тоді, коли щось сталося.
5. Він відчуває себе правильно 😉

HTH