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ć?
źródło
[dba.se]
→ Administratorzy baz danych ;)Odpowiedzi:
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.
źródło
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.
źródło
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.
źródło
Istnieje kilka powodów, dla których chcesz to zrobić:
źródło
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 ...
źródło
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:
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.
źródło
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.
źródło
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:
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.
źródł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.
źródło