Czas letni

W moim środowisku istnieją serwery działające na natywnej kopii zapasowej i plany Ola Hallengren. Nasze serwery to kombinacja 2008, 2012 i 2014. Wszystkie pełne kopie zapasowe są wykonywane o godzinie 12.00, a kopie zapasowe dziennika są zapisywane co 15 minut.

Nigdy wcześniej nie liczyłem czasu letniego, więc powiedz mi, jakie zmiany powinienem wprowadzić.

Czy wpłynie to na pełne kopie zapasowe o godzinie 12:00 i co stanie się z kopiami zapasowymi dziennika?

Ekspert SQL Server Paul Randal zajmuje się tym tematem w jaki sposób czas letni wpływa na odzyskiwanie po awarii? . Jest to stosunkowo krótki post, więc cytuję go w całości. Ponieważ martwiłeś się o kopie zapasowe dziennika transakcji, zwróciłem również uwagę na post, aby zwrócić na to uwagę.

Powszechnie wiadomo, że SQL Server poprawnie radzi sobie z czasem letnim (DST), więc dlaczego powinno Cię to obchodzić?

Cóż, nie jest to tak powszechna wiedza, że ​​pod koniec czasu letniego, kiedy zegary cofają się o godzinę (zawsze o 02:00 w USA), SQL Agent zasadniczo zatrzymuje się na godzinę (w wersji co najmniej SS2000). Oznacza to, że jeśli masz zadanie, które robi coś co 15 minut, pomiędzy wykonywaniem zadania o 01:45 a wykonywaniem zadania o 02:00 będzie przerwa 75 minut. Dzieje się tak, ponieważ o godzinie 02:00 czas jest ustawiany z powrotem na 01:00, ale następny czas wykonywania wszystkich zadań pozostaje taki sam - więc twoje zadanie nie może zostać wykonane, dopóki nie będzie następnego zaplanowanego czasu 02:00. Tak więc na półkuli północnej każdej jesieni, a na półkuli południowej każdej wiosny, tracisz godzinę pracy w SQL Agent. Mimo to, dlaczego miałbyś się przejmować?

Cóż, to zależy od tego, jakie zadania są opóźnione o godzinę. Jeśli masz zadanie, które wykonuje kopię zapasową dziennika co 15 minut, to w dniu, w którym kończy się czas letni , faktycznie istnieje 75-minutowa przerwa między kopiami zapasowymi dziennika. Jeśli masz umowę SLA, która ogranicza maksymalną ilość utraconej pracy do 15 minut w przypadku katastrofy, to przez te 75 minut jesteś narażony na potencjalną niemożność spełnienia tej umowy!

To może być dość poważna sprawa, szczególnie jeśli coś pójdzie nie tak w tej godzinie (nie mniej lub bardziej prawdopodobne niż coś pójdzie nie tak w innym czasie, ale nadal możliwe). W takim przypadku musisz wymyślić alternatywne rozwiązanie. Kilka sposobów obejścia problemu, o których mogę pomyśleć:

• Niech ktoś się nie spóźni w tej godzinie i ręcznie wykona kopie zapasowe dziennika.
• Przełącz się na dublowanie bazy danych, które stale przesyła dziennik do nadmiarowego serwera, więc nie ma to wpływu na problem DST.

Oba są realnymi rozwiązaniami, ale myślę, że najlepsze jest utworzenie zadania agenta SQL, które będzie działać o 01:59 i tworzy dodatkowe zadania tworzenia kopii zapasowych do uruchomienia o 01:00, 01:15, 01:30 i 01:45. Nie rozumiem, dlaczego to nie powinno być możliwe. Dziś o 10:36 utworzyłem proste zadanie agenta, aby wydrukować datę do pliku i ustawić, aby była wykonywana o 09:40 - w przeszłości. Następnie cofnąłem czas systemowy o godzinę i zadanie wykonało się idealnie. Jedynym minusem tego rozwiązania jest to, że musisz tworzyć i planować dodatkowe zadania za pomocą SP T-SQL Agent SP osadzonych w krokach zadania dla zadania 01:59 - żmudne, ale nie trudne. Może ktoś mógłby wysłać mi skrypt, a ja opublikuję go na blogu?

Dlatego, że DST zbliża się do końca 4 listopada, jest to zdecydowanie coś, o czym należy pamiętać, nawet jeśli nie chcesz zadawać sobie trudu radzenia sobie z dodatkową godziną ekspozycji. Na marginesie - daty rozpoczęcia i zakończenia DST zmieniły się w tym roku. Artykuł 931975 z bazy wiedzy omawia, które części programu SQL Server nie są świadome zmian dat i co można z tym zrobić.