Kopie zapasowe dziennika transakcji Szeregowe czy równoległe?

Zdarza się, że używamy SQL Server 2012 Standard Edition. Zdarza się również, że używam skryptów Oli Hallengren do zapewnienia łatwej, bardziej elastycznej struktury do wykonywania kopii zapasowych i konserwacji.

To pytanie dotyczy nie tyle skryptów Oli, ile najlepszych praktyk. Zdaję sobie sprawę, że ostateczną odpowiedzią jest „to zależy od wymagań twojej firmy”. Ale staram się zasięgnąć porady społeczności, jak najlepiej spełnić to, co rozumiem o wymaganiach naszej firmy.

Chcę konfigurować kopie zapasowe dziennika transakcji co 15 minut. W ten sposób mamy nadzieję, że stracimy nie więcej niż 15 minut danych. Czy powinienem skonfigurować jedno zadanie korzystające z ALL_DATABASES? czy lepiej jest ustawić jedno zadanie dla każdej bazy danych i uruchomić je wszystkie równolegle? Pytam, ponieważ mam wrażenie, że na podstawie tego, jak widzę działanie skryptu Oli, kopie zapasowe są uruchamiane seryjnie. Wadą numeru seryjnego byłoby to, że każda kolejna kopia zapasowa czeka na zakończenie drugiej. Może to potencjalnie zwiększyć czas między kopiami zapasowymi (tj. Dłuższy niż 15 minut). Dodatkowo martwi mnie to, że awaria jednej kopii zapasowej powstrzymuje inne, i nie chciałbym, żeby tak było. Chciałbym, aby inni kontynuowali tworzenie kopii zapasowej.

Czy to prawda, że ​​skrypty Oli wykonują się szeregowo, a awaria zatrzymuje kolejne kopie zapasowe?

I czy lepiej jest mieć pracę dla każdej bazy danych? czy pojedyncze zadanie, które robi wszystko? Moją skłonność do oddzielnych zadań, ale chcę zrozumieć, co zwykle robią SQL Server DBA.

Czy powinienem skonfigurować jedno zadanie korzystające z ALL_DATABASES? czy lepiej jest ustawić jedno zadanie dla każdej bazy danych i uruchomić je wszystkie równolegle?

Sugerowałbym skonfigurować jedno zadanie, które tworzyłoby kopie zapasowe dzienników transakcji (szeregowo). Dzięki temu kopie zapasowe nie będą w dużym stopniu użyteczne dla operacji we / wy, ponieważ kopie zapasowe dla bazy danych są uruchamiane pojedynczo.

Jakie mogą być wady związane z równoległym bieganiem

1. Załóżmy, że masz 50 baz danych i planujesz tworzenie kopii zapasowej dziennika transakcji wszystkich baz danych, a wszystkie zaczną działać równolegle, to z pewnością wykorzysta wiele operacji wejścia / wyjścia. A jeśli na dysku, na którym jest tworzona kopia zapasowa plików, znajdują się inne pliki danych, zobaczysz powolność. Zauważyłem, że tworzenie kopii zapasowej staje się powolne, gdy słabe zapytanie wymagające dużej liczby operacji we / wy działa wraz z zadaniem tworzenia kopii zapasowej.

2. Ponownie załóżmy, że masz 50 baz danych, czy zarządzanie 50 zadaniami w agencie SQL Server nie byłoby trudne, a co byłoby warunkiem, jeśli masz 100-200 baz danych Po prostu nie spodobałoby mi się, gdy otworzysz agenta SQL Server i zobaczysz dużo zadań, po prostu to proste. Jestem pewien, że ta sama sprawa byłaby z tobą.

Wadą numeru seryjnego byłoby to, że każda kolejna kopia zapasowa czeka na zakończenie drugiej. Może to potencjalnie zwiększyć czas między kopiami zapasowymi (tj. Dłuższy niż 15 minut).

Kopie zapasowe dziennika transakcji są przeważnie małe, a jeśli baza danych jest zajęta i generuje wiele zapisów dziennika, konieczna może być zmiana częstotliwości tworzenia kopii zapasowych. Najczęściej widziałem tworzenie kopii zapasowej dziennika transakcji w porządku, gdy częstotliwość wynosi 15 minut. Nie sądzę, że powinienem być dla ciebie przedmiotem troski.

Dodatkowo martwi mnie to, że awaria jednej kopii zapasowej powstrzymuje inne, i nie chciałbym, żeby tak było

Powiedziałbym, że nie przejmuj się tym. Kopie zapasowe dziennika transakcji nie mogą zawieść, chyba że popełnisz jakiś błąd. Błędy mogą być

1. Właściciel wykonujący zadanie zostanie usunięty z AD

2. Ktoś zmienił model odzyskiwania bazy danych.

3. Za mało miejsca na dysku

Poza powyższym nie widziałem żadnego powodu niepowodzenia tworzenia kopii zapasowej dziennika transakcji. Jest bardzo solidny, na którym możesz polegać.

Zasadniczo zawsze wykonuj kopie zapasowe dziennika T szeregowo; wiele moich wystąpień ma kilkadziesiąt baz danych, a kilka z nich jest bardzo aktywnych, a tworzenie kopii dzienników transakcji zajmuje tylko kilka sekund; do około pół minuty, gdy jest szczególnie zajęty.

Równoległe wykonywanie kopii zapasowych byłoby naprawdę korzystne, jeśli spełnione są wszystkie następujące warunki:

• Twoje bazy danych i pliki dziennika znajdują się na unikalnych niezależnych wrzecionach (lub znajdują się na dyskach półprzewodnikowych w dowolnej kombinacji)

  • W przypadku kopii zapasowych tylko w dzienniku T tylko pliki dziennika muszą spełniać ten wymóg.

• Twoje cele tworzenia kopii zapasowych dla każdej bazy danych znajdują się na osobnych wrzecionach.

• Nie używasz współdzielonej SAN HBA lub iSCSI lub innej przepustowości między wystąpieniem SQL Server a nośnikiem.

• tzn. IOPS z odczytu bazy danych A i zapisu kopii zapasowej A NIE używaj tych samych dysków, co odczyt bazy danych B i zapisu kopii zapasowej B.

Jeśli wszystkie są prawdziwe, to możliwe, że pewien stopień równoległości zmniejszy całkowity czas w kalendarzu. Jeśli to wszystko nie jest prawdą, najprawdopodobniej spowodujesz uszkodzenie jednego lub więcej zestawów dysków, a równoległe tworzenie kopii zapasowych zajmie więcej czasu kalendarzowego niż szeregowego, ale może również spowodować fragmentację systemu plików lub poziomu pamięci, ponieważ piszesz jednocześnie kopię zapasową A i kopię zapasową B!

Nie martw się, że jedna kopia zapasowa nie powiedzie się, a reszta się powiedzie - jeśli wystąpi błąd, i tak musisz wszystko sprawdzić, a jedyne przypadki, w których widziałem, że kopie zapasowe nie powiodły się, są spowodowane:

• Awaria dysku

• Awaria oprogramowania kompresji Hyperbac / Litespeed / strony trzeciej (jeśli masz oprogramowanie między SQL a dyskiem, który ulega awarii)

  • Jako ostrzeżenie, niepowodzenie może przybrać formę zadania kopii zapasowej, które nigdy się nie kończy, dlatego warto sprawdzić „zadania trwające dłużej niż oczekiwano”, które wysyłają alerty.

• Awaria produktu szyfrującego (jeśli masz oprogramowanie między SQL a dyskiem, który ulega awarii)

• Awaria sieci (jeśli pliki bazy danych lub, bardziej prawdopodobne, pliki kopii zapasowej, znajdują się w sieci)

• Uprawnienia

  • najczęściej z nowymi instalacjami

  • lub zupełnie nowe lokalizacje kopii zapasowych

  • zmiana użytkownika usługi SQL Server (co wymaga uprawnień do normalnych kopii zapasowych)

  • blokowanie użytkownika usługi SQL Server, ponieważ jest używany przez więcej niż jedną instancję SQL Server

• Błędy konfiguracji

• Brak energii

• Awaria systemu operacyjnego

Większość z nich nie wpłynie na jedno, a nie na inne, chyba że zostaną również spełnione powyższe warunki.

Aby dodać, Ola projektuje swoje skrypty, w których jeśli kopia zapasowa jednej bazy danych nie powiedzie się z jakiegokolwiek powodu, podejmowana jest próba wykonania kolejnej (kolejnych). Jak wspomniano wcześniej, można skonfigurować alert informujący o niepowodzeniu zadania, ponieważ zadanie tworzenia kopii zapasowej nadal nie powiedzie się, nawet jeśli tylko jedna baza danych nie powiedzie się ze wszystkich baz danych użytkowników - zakładając, że tworzysz kopię zapasową wszystkich baz danych (jedna praca dla wszystkich).