Я использую агент SQL Server для планирования даже задач, не связанных с базой данных - это плохая идея?

Поскольку я являюсь администратором баз данных (и во многих случаях де-факто системным администратором), 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 Agent поверх диспетчера задач Windows ... очевидно, для задач, связанных с базой данных.

Если вы можете писать код вообще или у вас есть люди, которые могут его кодировать, вы можете немало поработать с консольными приложениями и превратить их в создателя службы, такого как TopShelf (http://topshelf-project.com/). Это может быть дешево / легко взломать, чтобы немного отделиться от агента SQL для всего и начать, чтобы дать вам слой для очередей, если вы находитесь в этой точке.

Лично ты, кажется, достаточно заботишься об этом, а также знаешь достаточно о своих ошибках, и я думаю, что ты будешь в порядке. Это люди, которые не заботятся / знают, что я действительно волнуюсь. Я не сомневаюсь, что вы будете оценивать ваши решения в разумные промежутки времени и действовать соответственно.

Другим вариантом является создание таблицы для запланированных задач с хранимой процедурой для обновления таблицы очереди сообщений из нее. Затем агент SQL Server будет вызывать хранимую процедуру так часто, чтобы создавать сообщения и обновлять состояние задачи. Другие системы запрашивают таблицу очередей сообщений через соединение SQL или уровень веб-API как JSON.