Смещение времени начала расписаний заданий агента SQL Server между экземплярами

У меня есть задание агента, настроенное на запуск резервного копирования журнала каждые два часа с 2:00 до 23:59 (оставляя окно для запуска полного или дифференциального резервного копирования). Подобная работа настроена в каждом из моих 50 или около того экземпляров. Возможно, со временем я добавлю несколько сотен экземпляров (мы размещаем SQL-серверы для некоторых наших клиентов). Все они выполняют резервное копирование на один и тот же том диска SAN. Это вызывает проблемы с задержкой и иным образом влияет на производительность.

Я хотел бы сместить время выполнения задания на каждом экземпляре на 5 минут, чтобы первый экземпляр запускал задание в 2:00, 4:00 и т. д., второй экземпляр запускал его в 2:05, 4:05. и т. д., экземпляр номер три будет запускать его в 2:10, 4:10 и т. д. и так далее. Если я смещаю время начала задания для каждого экземпляра (2:00, например, один, 2:05, например, два, 2:10, например, три и т. д.), могу ли я разумно ожидать, что получу желаемый результат? не все экземпляры запускают задание одновременно?


sql-server job-scheduling sql-agent-job sql-server-agent
person Mark Freeman    schedule 28.08.2013    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Если это тот же разговор, который мы только что вели в Твиттере: когда вы указываете агенту SQL Server запускаться каждые n минут или каждые n часов, следующий запуск основан на времени запуска, а не на закончить время. Таким образом, если вы настроите задание на экземпляре 1 для запуска в 2:00 и каждые 2 часа, второй запуск будет выполняться в 4:00, независимо от того, занял ли первый запуск 1 минуту, 12 минут, 45 минут и т. д.

Есть некоторые предостережения:

  • могут быть небольшие задержки из-за внутренней синхронизации агента, но я никогда не видел этого больше, чем на несколько секунд
  • если первый запуск в 2:00 занимает более 2 часов (но менее 4 часов), следующий запуск задания будет в 6:00 (запуск в 4:00 пропускается, не работает в 4:10 или 4:20, чтобы «наверстать упущенное»)

Было еще одно предложение добавить WAITFOR для смещения времени начала (и мы должны отказаться от случайного WAITFOR, потому что это, вероятно, не то, что вам нужно - случайное ‹> уникальное). Если вы хотите жестко запрограммировать разную задержку для каждого экземпляра (1 минута, 2 минуты и т. д.), то гораздо проще сделать это с помощью расписания, чем путем добавления шагов ко всем вашим заданиям. ИМХО.

person Aaron Bertrand    schedule 28.08.2013
comment
Вот почему я разместил URL-адрес этой страницы в своем твите. Задания обычно завершаются через несколько минут (размер всех баз данных составляет менее 10 ГБ). Вариации в несколько секунд меня не беспокоят. Я просто не хочу, чтобы 50 резервных копий журналов одновременно пытались записать в один и тот же целевой ресурс. Вы, кажется, предоставили это. Спасибо! Я искал уверенность в том, что если я установлю эти смещения времени начала сейчас, я получу ожидаемые результаты, начиная с 2:00 сегодня вечером. - person Mark Freeman; 28.08.2013
comment
@Mark Извините, я не нажал на ссылку. - person Aaron Bertrand; 28.08.2013

arrow_upward
0
arrow_downward

Возможно, вы могли бы настроить централизованную БД, которая управляет «расписанием», и чтобы задания добавляли/обновляли строку при запуске. Таким образом, каждый последующий сервер может запускать задание, которое «опрашивает», когда его можно запускать. Таким образом, любая задержка в заданиях заставит другие ждать, поэтому у вас не будет разницы во времени, когда один из серверов отключается.

Будучи немного параноиком, я бы добавил общий сценарий, в котором говорится, что после «x» минут ожидания все равно продолжается, чтобы задержка не росла достаточно далеко, чтобы задания не выполнялись.

person Shawn E    schedule 28.08.2013
comment
Очень сложный. Я не хочу настраивать связанные серверы на каждом экземпляре, чтобы они могли взаимодействовать с центральной базой данных и писать много кода, если простое изменение времени запуска в расписании заданий решит проблему. Не будет большой проблемой, если некоторые из них в конечном итоге перекроются, но все они попадут в одно время, безусловно, проблема. - person Mark Freeman; 28.08.2013