Эксперт по SQL Server Пол Рэндал (Paul Randal) обращается к этой самой теме в разделе Как летнее время влияет на аварийное восстановление? , Это относительно короткий пост, поэтому я цитирую его целиком. Поскольку вы были обеспокоены резервными копиями журналов транзакций, я также выделил часть сообщения, чтобы обратить на это ваше внимание.
Общеизвестно, что SQL Server корректно справляется с переходом на летнее время (DST), так что вас это должно волновать?
Что ж, не очень общеизвестно, что в конце летнего времени, когда часы возвращаются на один час назад (всегда в 02:00 в США), агент SQL, по сути, делает паузу на час (по крайней мере, в SS2000 и далее). Это означает, что если у вас есть работа, которая делает что-то каждые 15 минут, между выполнением работы в 01:45 и выполнением работы в 02:00 будет промежуток в 75 минут. Это происходит потому, что в 02:00 время возвращается к 01:00, но время следующего выполнения всех заданий остается прежним - поэтому ваше задание не может быть выполнено до следующего запланированного времени 02:00. Таким образом, в северном полушарии каждую осень и в южном полушарии каждую весну вы теряете час работы с агентами SQL. Тем не менее, почему вы должны заботиться?
Ну, это зависит от того, какие работы задерживаются на час. Если у вас
есть задание, которое делает резервное копирование журнала каждые 15 минут, то в день
окончания
летнего времени на самом деле между резервными копиями журнала будет 75 минут. Если у вас есть Соглашение об уровне обслуживания (SLA), которое ограничивает максимальный объем
потерянной работы до 15 минут в случае аварии, то в течение этих 75
минут вы потенциально не сможете выполнить этот SLA!
Это может быть довольно большой проблемой, особенно если что-то пойдет не так в течение этого часа (не более или менее вероятно, чем что-то пойдет не так в любое другое время, но все же возможно). В этом случае вам нужно придумать альтернативное решение. Несколько способов обойти проблему, о которой я могу думать:
- Попросите кого-нибудь ложиться спать поздно в течение этого часа и делать резервные копии журнала вручную
- Переключитесь на зеркальное отображение базы данных, которое непрерывно передает журнал на резервный сервер и, таким образом, не затрагивает проблему DST.
Оба эти решения являются жизнеспособными, но я думаю, что лучше всего создать задание агента SQL, которое выполняется в 01:59 и создает дополнительные задания резервного копирования для запуска в 01:00, 01:15, 01:30 и 01:45. Я не понимаю, почему это не должно быть возможно. Сегодня в 10:36 я создал простую агентскую работу для печати даты в файл и настроил ее на выполнение в 09:40 - в прошлом. Затем я установил системное время на один час, и работа была выполнена идеально. Единственным недостатком этого решения является то, что вам необходимо создавать и планировать дополнительные задания с использованием пакетов SP агента T-SQL, встроенных в этапы задания для вашего задания 01:59 - утомительно, но не сложно. Может быть, кто-то может выслать мне сценарий, и я опубликую его в качестве дополнения?
Так что, когда DST подходит к концу 4 ноября, вам определенно стоит об этом знать, даже если вы не хотите справляться с дополнительным часом воздействия. Кроме того, даты начала и окончания летнего времени изменились в этом году. В статье 931975 КБ обсуждается, какие части SQL Server не знают об измененных датах и что вы можете с этим сделать.