Летнее время


9

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

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

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


6
Откровенно говоря, я бы запустил свои серверы в UTC.
Аарон Бертран

К сожалению, наши CST
SqlNovice

1
Конечно, но, честно говоря, это не жестко запрограммировано на материнской плате.
Аарон Бертран

Ответы:


12

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


Таким образом, я могу видеть потенциальную потерю данных в течение 75 минут ... Если я в порядке с этим, нужно ли мне менять какие-либо настройки, чтобы я мог оставить все как есть
SqlNovice

Если вы согласны с возможностью потерять 75 минут до следующего регулярно запланированного резервного копирования журнала, то я не думаю, что вам нужно вносить какие-либо изменения.
Скотт Ходжин

Более того, сервер, который меня беспокоит, всегда находится в группе доступности, поэтому, если что-то пойдет не так, я могу переключиться.
SqlNovice

@SqlNovice при условии, что ваша группа доступности находится на двух серверах, на которые не влияет одно и то же событие, и что все события зафиксированы в другом экземпляре (ах) = True. Возможно, вы принимаете больше как должное, что можно с уверенностью предположить. PS серверы не находятся в группах доступности, базы данных есть. (т. е. "" сервер, который меня беспокоит, всегда находится в группе доступности)
Джеймс Дженкинс

Извините, моя ошибка: базы данных в группе доступности - одна реплика в режиме синхронизации, а другая в асинхронном режиме
SqlNovice,
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.