Летнее время

В моей среде есть серверы, работающие с собственным резервным копированием, и планы Ola Hallengren. Наши серверы представляют собой комбинацию 2008, 2012 и 2014 годов. Все полные резервные копии создаются в 12:00, а резервные копии журналов - каждые 15 минут.

Я никогда не учитывал переход на летнее время, поэтому, пожалуйста, скажите мне, какие корректировки я должен внести.

Будут ли затронуты полные резервные копии в 12:00 и что произойдет с резервными копиями журналов?

Эксперт по 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 не знают об измененных датах и ​​что вы можете с этим сделать.