Я використовую агент SQL Server для планування навіть завдань, які не мають бази даних - це погана ідея?

Оскільки я DBA (і в багатьох випадках de-facto sysadmin), SQL Server встановлюється майже на кожному сервері, з яким я повинен регулярно працювати. Нещодавно я зрозумів, що використовую агент SQL як планувальник завдань у майже будь-якому випадку, а не рідний планувальник завдань Windows.

З моєї точки зору, агент SQL має ряд переваг перед рідним планувальником завдань Windows:

• Віддалений (з моєї робочої станції) запуск / зупинка / моніторинг завдань
• Спільні графіки (а не кожне завдання самостійно)
• Кілька кроків і контроль потоку
• Різні види завдань
• Попередження про помилку / завершення
• Можна налаштувати, щоб діяти як різні користувачі
• (Помірно) описові повідомлення про помилки, а не просто код помилки

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

Чи добре покладатися на агент SQL таким чином? Якщо ні, чи варто мені розглянути сторонній планувальник завдань Windows, щоб отримати частину потрібних функцій?

Особисто я думаю, що найбільшим застереженням буде складність у дотриманні переліку робочих місць. Наскільки мені відомо, ви не можете створити папки, щоб організувати завдання, тому велика кількість була б громіздкою. Я не впевнений у цьому на 100%, оскільки жоден з моїх серверів не має більше десятка робочих місць. Планувальник завдань Server 2008 і пізніших версій забезпечує набагато простішу організацію, IMO, і взагалі має набагато кращий функціонал, ніж попередні версії. Я впевнений, що сторонні додатки роблять ще кращу роботу. Я б плакала, якби мені довелося використовувати планувальник завдань Server 2003 або at.exe.

Другий застереження, про який я можу подумати, потенційно може поставити занадто велике навантаження на сервер SQL. Агент - це невелика програма, але виконання тривалої або складної задачі може легко споживати багато ресурсів. Ці ресурси недоступні для двигуна SQL. Оскільки двигун SQL запрограмований на 80% наявної системної пам'яті, це може бути проблемою.

По-третє, може бути проблемою резервне копіювання. Вам не потрібно буде створити резервну копію файлової системи, але і MSDB базу даних, щоб забезпечити відновлення завдань (або використовувати щось для скриптування завдань у текстовий файл). Це додає шару складності для відновлення після аварій.

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

На своїй попередній роботі я робив саме це, здебільшого тому, що всі роботи виконувались з нашого центрального, первинного кластера, який був найпомітнішим сервером. Я міг бачити всі наші заплановані завдання в одному місці, замість того, щоб переходити на перевірку матеріалів командного рядка на купі серверів.

Хоча це значною мірою суб'єктивно (і в цьому форматі "скласти" відповідь буде складно отримати), я не думаю, що в цьому підході є щось суттєво неправильне, ніж це стає єдиною точкою невдачі.

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

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

Я б, швидше за все, взяв агента SQL над менеджером завдань Windows ... очевидно, для завдань, пов’язаних із базою даних.

Якщо ви взагалі можете кодувати, або у вас є люди, які можуть кодувати, ви можете зробити трохи з консольними програмами та перетворити їх у програму для створення таких служб, як TopShelf (http://topshelf-project.com/). Це може бути дешевим / легкий хак, щоб отримати трохи роз'єднання від SQL Agent на все і почати також надавати вам шар для черги, якщо ви в цьому місці.

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

Інший варіант - створити таблицю для запланованих завдань із збереженою процедурою для оновлення таблиці черги повідомлень з неї. Тоді агент SQL Server так часто викликає збережену процедуру для створення повідомлень та оновлення стану завдання. Інші системи запитують таблицю черги повідомлень через з'єднання SQL або рівень веб-API як JSON.