Каква е практиката за планиране на множество взаимозависими задания на SQL Server Agent?

Начинът, по който моят екип в момента планира задачи, е чрез SQL Server Job Agent. Много от тези задания имат зависимости от други вътрешни сървъри, които от своя страна имат свои собствени задания на SQL Server, които трябва да се изпълняват, за да поддържат данните си актуални.

Това създаде зависимости в началния час и продължителността на всяка от нашите задачи на SQL Server. Задача А може да зависи от завършването на Задача Б, така че планираме Задача Б за определено приблизително време предварително за Задача А. Целият този процес е много субективен и не може да се мащабира, т.к. ние добавяме повече работни места и сървъри, които създават повече зависимости.

Бих искал да се измъкна от субективното планиране на тези работни места и да се надявам, че доминото пада в правилния ред. Чудя се какви са приетите практики за планиране на задачи на SQL Server. Хората използват ли SSIS за свързване на работни места? Има ли вече вграден инструментариум в SQL Server Job Agent за справяне с това?

Какъв е приетият начин за обработка на планирането на множество задания на SQL Server със зависимости едно от друго?


person stevebot    schedule 20.09.2012    source източник
comment
Използвате ли инструмент за планиране на работа на трета страна, като Control M?   -  person rvphx    schedule 21.09.2012
comment
@Rajiv Не в момента, не се колебайте да оставите отговор как Control M може да направи планирането на работните ни места по-управляемо.   -  person stevebot    schedule 21.09.2012


Отговори (3)


Използвал съм Control-M преди, за да планирам множество взаимозависими задачи в различна среда. Control-M обикновено работи, като използва пакетни файлове (доколкото си спомням) за изпълнение на SSIS пакети.

Имахме сложна среда, хостваща 2 хранилища за данни един до друг (1 международен и 1 местен в САЩ). Имаше задачи, които зависеха от други задачи и тези задачи от други и т.н., но с помощта на Control-M можехме лесно да вземем решение за зависимостта (има наистина хубав и интуитивен GUI). Друг инструмент, който ми идва наум, е Tidal Scheduler.

Няма установен стандарт за планиране на работа, но мисля, че е безопасно да се каже, че графиците за работа зависят изцяло от това, от което се нуждае една организация. Например работните места в областта на финансите може да зависят от продажбите и продажбите на инвентар и т.н. Но въпросът е, че ако трябва да имате взаимозависимост на работата, използването на софтуер на трета страна като Control-M е безопасен залог. Той може да контролира работните места в различни среди и да ви даде истинско усещане за контрол върху работата в цялата компания.

person rvphx    schedule 20.09.2012

Ние също имахме изискването да управляваме зависимостите между множество задачи на агенти - след като разгледахме различни инструменти на трети страни и ги отхвърлихме по различни причини (главно до вътрешните ограничения, свързани с използването на софтуер на трети страни), решихме да създадем наше собствено решение.

Решението се съсредоточава около конфигурационна база данни, която съдържа подробности за процесите (задачи), които трябва да се изпълняват и как са групирани (партиди), заедно със зависимостите между процесите.

Обобщение на използваните конфигурационни таблици:

Партида - дефиниция на високо ниво на група от свързани процеси, включва метаданни като максимални едновременни процеси и текуща партидна инстанция и т.н. Процес - метаданни, свързани с процес (задача), като име, максимално време на изчакване, най-ранно време на изпълнение, статус ( активиран / деактивиран), партида (към коя партида принадлежи процесът), име на задача на процеса и т.н. Партиден екземпляр - активният екземпляр на дадена партида Процесен екземпляр - активни екземпляри на процеси за даден пакет Процес Зависимост - матрица на зависимости Състояние на партиден екземпляр - търсене за състояние на партиден екземпляр Състояние на екземпляр на процеса - цикъл за състояние на екземпляр на процеса

Всяка партида има 2 контролни задачи - НАЧАЛО НА ПАРТИЯ и АКТУАЛИЗИРАНЕ НА ПАРТИЯ. Първият се занимава със стартирането на всички процеси, които му принадлежат, а вторият е последният, който се изпълнява във всяка дадена партида и се занимава с актуализирането на статусите на резултатите.

Всеки процес има задание на агент, свързано с него, което се изпълнява от заданието START BATCH - процесите имат ограничена едновременност (дефинирано в конфигурацията на пакета), така че процесите се стартират до максимум x наведнъж и след това START BATCH изчаква, докато свободен слот става достъпен преди започване на следващия процес.

Стъпките на работата на агента на процеса извикват шаблонен SSIS пакет, който се занимава с действителната работа на ETL и с вземането на решение дали процесът трябва да се изпълнява и трябва да изчака зависимости и т.н.

В момента търсим да преминем към решение на Service Broker за по-голяма гъвкавост и контрол.

Както и да е, вероятно твърде много подробности и недостатъчен пример тук, така че проектът VS2010 е наличен при поискване.

person Dewi    schedule 15.01.2013

Не съм сигурен доколко това ще помогне, но в крайна сметка създадохме решение за имейл за планиране.

Създадохме имейл четец, който има достъп до пощенска кутия за обмен. Когато задачите приключат, те изпращат имейл до четеца на поща, за да започнат друга работа. Другата хубава част е, че повечето приложения имат вградени известия по имейл, така че наистина няма много възможности за персонализирано програмиране.

Наистина го създадохме само за обработка на файлове с данни, идващи от много други партньори. Беше много по-лесно да им дадете имейл адрес, вместо да ги настройвате с ftp сайт и т.н.

Приложението за четене на поща вече е разраснато, за да включва основно филтриране, планиране на час от деня, използване на семафори за предотвратяване на едновременни задачи и т.н. Наистина работи чудесно.

person Dayton Brown    schedule 24.09.2012