Obsługa dziennika transakcji po przejściu na Simple Recovery

Tło:

Niedawno odziedziczyłem ponad 50 serwerów SQL z ponad 450 bazami danych. Nocne kopie zapasowe mają w przybliżeniu 8 TB i, oczywiście, zużywamy więcej miejsca na dysku, niż byśmy chcieli. Wszystkie bazy danych są ustawione na PEŁNE odzyskiwanie, a dzienniki transakcji nigdy nie zostały utworzone. Przejrzałem wszystkie serwery SQL i zidentyfikowałem te o niskim priorytecie, które potrzebują tylko nocnej kopii zapasowej i gdzie utrata danych jest akceptowalna.

Pytanie:

Przełączam wiele baz danych o niskim priorytecie do SIMPLEtrybu odzyskiwania FULL. Czy istniejące dzienniki transakcji zostaną obcięte (podczas tworzenia punktów kontrolnych)? Niektóre z istniejących dzienników transakcji to 50–100 GB; jakie jest najlepsze podejście do określania, do czego powinienem je zmniejszyć, aby móc iść naprzód? Oczywiście nie chcę, aby były tak duże. Czy też z czasem same się skurczą (nie sądzę, żeby tak się stało)?

Przed przejściem FULLdo SIMPLEmodelu odzyskiwania zapytaj siebie, ile danych możesz stracić. W przypadku baz danych, w których w przypadku katastrofy możesz przywrócić ostatnią kopię zapasową bazy danych, SIMPLEpowinno być OK. Jeśli tak nie jest, zostań z FULL.

Aby zmniejszyć LDFplik do jak najmniejszego rozmiaru, wykonaj kroki podane przez Kimberly Tripp tutaj: 8 kroków do lepszej przepustowości dziennika transakcji

1. Poczekaj na moment, w którym aktywność bazy danych będzie niska

2. Uruchom w SSMS:

   DBCC SHRINKFILE(transaction_log_logical_filename, TRUNCATEONLY)

3. Zmodyfikuj rozmiar pliku dziennika transakcji:

   ALTER DATABASE db_name
   MODIFY FILE ( NAME = transaction_log_logical_filename, SIZE = new_size)

Przełączam wiele baz danych do trybu odzyskiwania SIMPLE z trybu odzyskiwania FULL (T-Logi i odzyskiwanie w określonym momencie nie jest konieczne). Czy istniejące dzienniki transakcji zostaną obcięte (podczas tworzenia punktów kontrolnych)?

W prostym modelu odzyskiwania silnik bazy danych wydaje automatyczne punkty kontrolne, a jego częstotliwość jest określana na podstawie interwału odzyskiwania (zaawansowane ustawienia konfiguracji serwera) lub tego, czy dziennik zapełni się w 70%.

O ile nie wystąpią jakieś długotrwałe transakcje, które opóźnią obcinanie dziennika, automatyczny punkt kontrolny obetnie nieużywaną część dziennika T.

Niektóre z istniejących dzienników transakcji to 50-100 GB, co jest najlepszym podejściem w określaniu, do czego powinienem je zmniejszyć w celu dalszego rozwoju. Oczywiście nie chcę, aby były tak duże.

Jeśli masz model odzyskiwania bazy danych ustawiony na PEŁNY dla tych baz danych z 50–100 GB dzienników T, musisz zacząć wykonywać częste kopie zapasowe dziennika T. Pamiętaj, że w modelu pełnego odzyskiwania po ustanowieniu łańcucha kopii zapasowej dziennika nawet automatyczne punkty kontrolne nie powodują obcinania dziennika.

W ostateczności możesz obciąć plik dziennika, a następnie natychmiast wykonać pełną kopię zapasową, a następnie rozpocząć tworzenie kopii zapasowych dziennika T, aby móc odzyskać dane w momencie wystąpienia awarii.

Czy też z czasem same się skurczą (nie sądzę, żeby tak się stało)?

Jak wskazał @TomTom, jest to operacja ręczna.

Zaznajomić się :

• Zarządzaj rozmiarem pliku dziennika transakcji
• JAK SKRÓCIĆ DZIENNIK SERWERA SQL - Znakomity Napisz.
• Jak działają punkty kontrolne i co się rejestruje - Autor: Paul Randal

Na wiele pytań nie możemy odpowiedzieć. Jak długi jest kawałek sznurka?

Niektóre z istniejących dzienników transakcji to 50-100 GB, co jest najlepszym podejściem w określaniu, do czego powinienem je zmniejszyć w celu dalszego rozwoju.

Tak długo, jak muszą. Sugeruję NIE kurczenie się. Obetnij dzienniki, wróć za tydzień i zobacz, ile miejsca jest zajęte, A potem zdecyduj. Ale musisz odpowiedzieć na to pytanie.

Nocne kopie zapasowe mają w przybliżeniu 8 TB i nie trzeba dodawać, że zużywamy więcej miejsca na dysku, niż byśmy chcieli.

Po co więc zamieniać je w proste? To znaczy poważnie.

Wszystkie bazy danych są ustawione na PEŁNE odzyskiwanie, a dzienniki transakcji nigdy nie zostały utworzone.

Trochę logiki powie ci, że jeśli skrócisz je RAZ, wtedy prawdopodobnie zużyjesz O wiele mniej miejsca na ich utworzenie. Może to skutkować tym, że możesz je utrzymać w trybie pełnego odzyskiwania. Wypróbuj to najpierw. Jeśli rajd jest niski, itp., Kopie zapasowe dziennika będą w przyszłości znacznie mniejsze.

Przeszedłem przez wszystkie serwery SQL i zidentyfikowałem te NISKIE priorytetowe, które potrzebują tylko nocnej kopii zapasowej, a utrata danych nawet po awarii nie będzie problemem (bazy danych faksów i podobne).

Tak. Tak jest, dopóki nie trafisz do sądu i nie zostaniesz osądzony za brak ważnych dokumentów prawnych. Czy wiesz, że dzienniki faksu mogą być częścią tego, co musisz przechowywać przez lata jako informacje istotne dla biznesu? Tak jest w mojej jurysdykcji (10 lat). Jeśli jesteś spółką akcyjną U, może być podobnie zaskoczony (SOX). Nieprzestrzeganie tego powoduje, że BARDZO źle jest w sądzie, jeśli chcesz udowodnić, że nie dostałeś faksu. Lub wysłałem jeden. Nikogo nie obchodzi, czy zdarzało się to co miesiąc, a ty masz nowsze dzienniki - nie spełniasz wymagań prawnych. Upewnij się, że jest to podpisane przez kogoś BARDZO wysoko, ponieważ Twoja firma, która nie jest krytyczna, może być powodem zwolnienia.

Czy też z czasem same się skurczą (nie sądzę, żeby tak się stało)?

Nie. I nie powinni tego robić. Zmiana rozmiaru dziennika jest operacją ręczną, z wyjątkiem baz danych o małej objętości.