Dlaczego tworzenie kopii zapasowej dziennika transakcji jest tak ważne?

Obecnie wdrażamy rozwiązanie do tworzenia kopii zapasowych dla klienta, a jego rozwiązanie ERP korzysta z SQL Server.

Rozwiązanie ERP zostało stworzone przez inną firmę. A oni mówią mi, że to jest bardzo ważne, aby wykonać kopię zapasową i obciąć dziennik transakcji.

Przeczytałem trochę w tym dzienniku transakcji i nie rozumiem, dlaczego jest to tak ważne, skoro i tak już tworzę kopię zapasową całego komputera (korzystamy z ArcServe UDP, który zna SQL Server i używa VSS). Rozumiem, że zadania czyszczenia na maszynie wirtualnej programu SQL Server już zajmują się obcinaniem dziennika, jednak UDP umożliwia również obcinanie dziennika programu SQL Server.

Rozumiem, że dziennik transakcji może służyć do przywracania uszkodzonych baz danych, ponieważ jest to dziennik wszystkich transakcji. Ale mam już godzinną kopię zapasową całej bazy danych, więc dlaczego miałbym się tym przejmować?

Musisz to zrobić tylko wtedy, gdy tryb odzyskiwania DB jest ustawiony na „pełny”. Jeśli jest ustawiony na „prosty”, nie trzeba wykonywać kopii zapasowej dziennika transakcji. Uważaj jednak na różnicę między tymi dwiema opcjami!

Przede wszystkim: jeśli chcesz móc przywrócić DB do określonego momentu , musisz użyć trybu „pełnego”. (Myślę, że możesz dostosować taktowanie tak dokładnie, że możesz nawet określić milisekundy dla punktu przywracania). W trybie „prostym” możesz wrócić tylko do ostatniej pełnej kopii zapasowej .

Jeśli nie wykonasz kopii zapasowej / obcinasz swój dziennik transakcji, będzie on cały czas powiększał się (w trybie pełnym). Widziałem bazy danych, w których plik .trn był ponad dwa razy większy niż sama baza danych. Zależy to od częstotliwości wprowadzania zmian w bazie danych.

Inną kwestią jest to, że kopia zapasowa dziennika jest zwykle szybsza niż pełna kopia zapasowa.

Myślę więc, że twój plan tworzenia kopii zapasowych, aby tworzyć pełne kopie zapasowe co godzinę, nie jest optymalny. Ale to zależy od twojej sytuacji:

Jeśli powiesz: OK, jeśli mogę przywrócić DB do ostatniej pełnej godziny, wszystko jest w porządku. -> Możesz również pomyśleć o ustawieniu trybu odzyskiwania na „prosty”, jeśli chcesz zachować pełną kopię zapasową co godzinę.

Moim zdaniem lepszym pomysłem byłoby wykonanie pełnej kopii zapasowej wcześnie rano, a następnie tworzenie kopii zapasowej dziennika transakcji co godzinę. Powinno to być znacznie szybsze i możesz przywrócić w dowolnym momencie. A także plik .trn nie wzrośnie zbytnio ...

Mam nadzieję że to pomoże.

Dobrze. Dbasz o to, ponieważ jeśli masz ustawiony pełny model odzyskiwania i nie wykonujesz kopii zapasowej dziennika transakcji przy użyciu kopii zapasowej SQL (a nie kopii zapasowej serwera), dziennik transakcji będzie się powiększał, dopóki nie zajmie całej dostępnej przestrzeni dyskowej. (Kiedyś widziałem, jak mniejszy kolega instaluje SQL Server na dysku systemowym i nigdy nie tworzy kopii zapasowej dziennika transakcji. Zjadł Windows .)

Tak, przywróci również do określonego momentu w czasie. Do minuty. Jak mówi Twinkles, tak, ludzie upuszczają stoły i tym podobne.

Nie wiem, czego używasz do tworzenia cogodzinnej kopii zapasowej całej bazy danych i czy jest to ten sam produkt, którego używasz dla całego komputera. Jeśli tak, przywracanie nie obsługuje kopii zapasowej nieobsługującej SQL. Czas potrzebny na skopiowanie plików MDF i LDF przez VSS może na przykład spowodować wewnętrzne niedopasowanie znaczników czasu.

Zarządzamy również kilkoma systemami ERP. Problem często polega na tym, że w nocy często wykonywane są długie zadania wsadowe, które synchronizują dane z innymi systemami. A czasem zabierają godzinę lub dłużej. Więc w przypadku awarii chcesz przejść do punktu, w którym masz spójne dane. (Co oznacza dokładnie między dwoma zadaniami wsadowymi.) Jeśli spojrzysz tylko na czas, możesz nie zawsze wiedzieć dokładnie, jaki był stan bazy danych w tym czasie.

Ale oczywiście zależy to od sytuacji. Jeśli nie masz żadnych automatycznych zadań itp., Możesz być w porządku dzięki cogodzinnej kopii zapasowej.

Istnieje kilka powodów, dla których chcesz to zrobić:

1. System bazy danych jest zwykle zajęty, być może wykonuje tysiące transakcji na sekundę. Dane można rozłożyć na kilka plików w różnych systemach plików. Nie jest trywialne upewnienie się, że baza danych znajduje się w spójnym (możliwym do użycia) stanie po przywróceniu. Jeśli Twoje rozwiązanie do tworzenia kopii zapasowych spełnia Twoje zadanie, świetnie, ale lepiej upewnij się o tym, zanim postawisz na to swoją pracę.
2. Przykład: ktoś przez pomyłkę upuszcza tabelę z ważnymi danymi. Jeśli masz kopię zapasową bazy danych z możliwością odzyskiwania w określonym momencie, możesz szybko przywrócić dane bez konieczności przywracania całego systemu.
3. Jeśli baza danych jest w trybie pełnego odzyskiwania, dziennik transakcji SQL Server powiększy się. Przestrzeń dyskowa w dzienniku transakcji jest ponownie wykorzystywana tylko wtedy, gdy kopia zapasowa dziennika transakcji została utworzona. Jeśli kopia zapasowa dziennika transakcji nie będzie regularnie wykonywana, system plików zapełni się, dopóki nie pozostanie wolne miejsce. W tym momencie wszystko natychmiast się zatrzyma , ponieważ nie można rozpocząć żadnych nowych transakcji.

Kiedy Twoja baza danych wykracza poza to, co możesz wykonać w ciągu godziny, potrzebujesz innego modelu.

Pełna kopia zapasowa bazy danych obetnie dzienniki, ale musi ona być „świadoma SQL”, ponieważ w tym scenariuszu jest to oprogramowanie do tworzenia kopii zapasowych, które informuje serwer SQL, co utworzył kopię zapasową i co obciąć.

Jak wspominają inni, jeśli baza danych ma model odzyskiwania „Pełny”, dziennik transakcji będzie się rozwijał w nieskończoność, aż do utworzenia kopii zapasowej w pełni zgodnej z SQL.

Odzyskiwanie jest tutaj naprawdę problemem, a nie Kopią zapasową. I to nie jest decyzja techniczna, to decyzja biznesowa!

Jeśli właściciele firm są w porządku, tracąc godzinę lub więcej transakcji w bazie danych (co może być BARDZO trudne lub niemożliwe do ponownego wykonania!), Oznacza to, że model działa. Jeśli są one w porządku, a system jest wyłączony przez wiele godzin podczas przywracania całej bazy danych z kopii zapasowej, oznacza to, że model działa.

Jeśli jednak Twoja firma uważa swój system ERP za kluczowy zasób dla ich działania (czyż nie wszystkie?), Wówczas ustalenie maksymalnego akceptowalnego czasu odzyskiwania (znanego również jako RTO, Recovery Time Objective) dla swoich krytycznych usług będzie decyzją biznesową.

Ponadto właściciele firm lub interesariusze systemu muszą określić, ile danych chcą ryzykować utratą w wyniku incydentu, czyli RPO (Recovery Point Objective).

Odpowiedź, jeśli ich zapytasz, może brzmieć: „Żaden danych nie można utracić! System ERP musi być dostępny 24/7/365!” ... co, jak wszyscy wiemy, jest mało prawdopodobne, aby było opłacalne. Jeśli przedstawisz im koszty związane z budowaniem tak w pełni redundantnego systemu non-stop, wymyślą bardziej rozsądną liczbę ...;)

Chodzi o to, że jeśli możesz uniknąć utraty jakichkolwiek transakcji, oszczędzasz firmie potencjalnie setki lub tysiące straconych godzin pracy. Daje to OGROMNE oszczędności w każdej firmie i rośnie wraz z rozmiarem Twojej firmy ...

Wszyscy dobrze na to odpowiedzieli, ale chciałbym dodać kolejną ważną notatkę ... lub dwie.

Bardzo ważna jest znajomość szczegółów modeli odzyskiwania programu SQL Server i wymagań biznesowych dotyczących utraty danych; jednak w tym przypadku konieczne jest zrozumienie, w jaki sposób produkt kopii zapasowej działa z programem SQL Server. (W oparciu o powyższe komentarze brzmi to tak, jakbyś tworzył kopie zapasowe woluminów dyskowych za pomocą kopii VSS, co oznacza, że ​​kopie zapasowe programu SQL Server mogą być dodatkowo wymagane lub nie.)

Po niedawnej ocenie podobnego produktu niektóre ważne kwestie, o które możesz zapytać, to:

• Jak przywraca się dane do momentu pełnego przywrócenia bazy danych?
• W jaki sposób obsługiwane jest początkowe tworzenie kopii zapasowej nowej bazy danych przy pełnym odzyskiwaniu?
• Czy produkt kopii zapasowej wymaga przywracania kopii zapasowych dziennika SQL Server do określonego momentu? (W moim przypadku odpowiedź brzmiała „tak”).
• Czy twoja infrastruktura pamięci masowej może obsłużyć ilość danych dla kopii / różnic VSS (w danym przedziale) oprócz normalnego obciążenia SQL?

Mam nadzieję, że to jest pomocne.

Doświadczenie mojego zespołu z naszą ostatnią oceną dostarczyło bardzo interesujących odpowiedzi na powyższe pytania. Jedno jest pewne, tworzenie kopii zapasowych jest dla nas bardziej złożone dzięki produktowi do tworzenia kopii zapasowych VSS.

Jak już wielu powiedziało, jeśli używasz narzędzia innej firmy do tworzenia kopii zapasowych / migawek maszyny wirtualnej lub magazynu, nadal istnieje ryzyko, że nie będziesz mieć prawidłowej kopii zapasowej. Wszystkie narzędzia innych firm, które zarządzają kopiami zapasowymi SQL Server, zaimplementują i połączą się z SQL Server za pomocą VSS. Robi to, aby zażądać, aby SQL Server wyciszył wszystkie operacje we / wy do plików danych, aby można było wykonać spójną migawkę. Jeśli nie, możesz mieć wiele transakcji w różnych stanach, a przywracanie nie będzie wiedziała, czy transakcje te można przenieść do przodu czy do tyłu.

Nie pracowałem z każdym narzędziem do tworzenia migawek VM / Storage, ale te, z którymi pracowałem, nigdy nie były w stanie wykonać migawki w miejscu, w którym znajdowały się systemowe bazy danych - SQL Server nie może wyciszyć tych baz danych. Wszystkie wykonały kopię zapasową tych baz danych w sposób strumieniowy - tj. ... wydając polecenia BACKUP DATABASE, a następnie przyciągając sam plik kopii zapasowej.

Co więcej, jak już powiedziano, jeśli jesteś w FULL modelu odzyskiwania i nie wydajesz regularnie instrukcji BACKUP LOG, dziennik transakcji będzie się powiększał, dopóki na dysku nie pozostanie wolne miejsce.

Prawdziwe pytanie, które musisz zadać, a mogłem je pominąć powyżej ... czy udało ci się wielokrotnie odtworzyć te kopie zapasowe i czy jesteś zadowolony z spójności danych w tych przywracaniach. Osobiście, nawet to by mi nie wystarczyło, nadal wydaje się rzut kostką, a to dobre DBA nigdy nie bierze, jeśli chodzi o tworzenie kopii zapasowych i odzyskiwanie.

Uznaj, że dzienniki transakcji nie są po prostu mechanizmem odzyskiwania. Właściwe utrzymanie dziennika może również odgrywać kluczową rolę w ogólnej wydajności bazy danych (tj. Przepustowości transakcji).

Często tworzenie kopii zapasowej plików dziennika ma kilka rzeczy:

1. Zmniejsza liczbę VLF w fizycznych plikach dziennika, co jest dobre dla wydajności.
2. Lepiej przygotuj się do korzystania z kopii zapasowych dziennika na wypadek konieczności odzyskania bazy danych.
3. Jest to nieco szybsze niż pełna kopia zapasowa

Jeśli możesz uniknąć wykonywania pełnej kopii zapasowej co godzinę, nie jestem pewien, ile skorzystałbyś z częstszych kopii zapasowych dzienników. W końcu, jak rozumiem, pełna kopia zapasowa utworzy również tyle dzienników, ile jest konieczne, aby zapewnić pełne przywrócenie.

Z drugiej strony, jeśli twoja aplikacja generuje mnóstwo transakcji pomiędzy twoimi cogodzinnymi pełnymi kopiami zapasowymi, może to wyjaśniać, dlaczego pierwotni twórcy sugerowali bardziej szczegółową konserwację dziennika. Wiele transakcji może zwiększyć liczbę VLF w dziennikach, co może skutkować obniżeniem wydajności, dopóki dziennik nie zostanie obcięty. Widziałem to wyrażone jako błąd „upłynął limit czasu zapytania” w aplikacji (krótko przed zawieszeniem się).

Zalecenia związane z obsługą dziennika transakcji zostały bardzo dobrze opisane w tym artykule 8 kroków do lepszej przepustowości dziennika transakcji . Dodatkowo w tym artykule Najważniejsze wskazówki dotyczące efektywnego zarządzania bazą danych wspomina o nieco arbitralnej liczbie VLF, do której należy dążyć (<200), co dla mnie bardzo dobrze działało.

Inne osoby podały już większość powodów tworzenia kopii zapasowej translog itp. Wydaje się, że istnieją wątpliwości, dlaczego jest to dobra strategia, gdy już tworzysz kopię zapasową serwera.

Wymyśliłem kilka dobrych powodów, które nie są powyżej. Co się stanie, jeśli aplikacja innej firmy nie wykona kopii zapasowej, którą można przywrócić? Czy próbowałeś przywrócić kopię zapasową? Co powiesz na nowy serwer, który właśnie zbudowałeś z szablonów (pomyśl DR)? Co powiesz na inny serwer w Twojej domenie, który ma inne zestawienie? lub wystąpienie SQL?

Przyjmuję zbędne kopie zapasowe bez żadnego innego powodu niż czasami aplikacja innej firmy nie jest najszybszym sposobem na przywrócenie. Czasami wpływa to również na pamięć, na którą oszczędza Twoja aplikacja innej firmy, lub jest uszkodzona z własnych powodów.