Prosty czy pełny model odzyskiwania baz danych?

Kiedy powinienem korzystać z pełnego modelu odzyskiwania, a kiedy powinienem używać prostego modelu odzyskiwania dla baz danych?

Zawsze korzystałem z pełnego modelu odzyskiwania, ponieważ jest on domyślny, ale dzisiaj napotkałem ten błąd:

Dostawca Microsoft OLE DB dla SQL Server (0x80040E14) Dziennik transakcji dla bazy danych „NAZWA BAZY DANYCH” jest pełny. Aby dowiedzieć się, dlaczego miejsca w dzienniku nie można ponownie wykorzystać, zobacz kolumnę log_reuse_wait_desc w sys.databases

Ta konkretna baza danych jest w rzeczywistości jedną z najmniejszych i najbardziej nieaktywnych baz danych na moim serwerze, więc nie mam pojęcia, jak dziennik może być pełny w tej bazie danych, a nie w innych.

Aby zmniejszyć dziennik i ponownie umożliwić dostęp do bazy danych, zmieniłem model odzyskiwania z FULL na SIMPLE i zmniejszyłem dziennik pliku logicznego za pomocą następującego polecenia

alter database myDbName SET recovery simple
go
dbcc shrinkfile('LOG FILE LOGICAL NAME', 100)
go

Pomogło, ale teraz muszę zrozumieć DLACZEGO to pomogło, JAK ta sytuacja się rozpoczęła i JAK temu zapobiec w przyszłości?

EDYTOWAĆ:

Każdej nocy o godzinie pierwszej robimy skryptową kopię zapasową każdej bazy danych na serwerze. Odbywa się to za pomocą 31-wierszowego skryptu, w którym najważniejsza jest część

set @Filename = 'D:\backup\' + convert(varchar, getDate(), 112) + ' - ' + @DBName + '.bak'
set @Description = 'Full backup of database ' + @Filename
BACKUP DATABASE @DBName TO DISK = @Filename WITH INIT , NOUNLOAD , NAME = @Description, NOSKIP , STATS = 10, NOFORMAT

Czy nowy model odzyskiwania i baza danych będą sprzeczne z tym skryptem?

Nie wykonujemy żadnego innego rodzaju tworzenia kopii zapasowych baz danych, a zatem nie dzienników transakcji, prawda?

Kiedy powinienem korzystać z pełnego modelu odzyskiwania, a kiedy powinienem używać prostego modelu odzyskiwania dla baz danych?

Należy skorzystać z pełnego modelu odzyskiwania, gdy wymagane jest odzyskanie bazy danych w określonym momencie. Powinieneś używać prostego modelu odzyskiwania, gdy nie potrzebujesz odzyskiwania bazy danych w określonym momencie i gdy ostatnia pełna lub różnicowa kopia zapasowa wystarcza jako punkt odzyskiwania. (Uwaga: istnieje inny model odzyskiwania, z logowaniem zbiorczym. Aby uzyskać więcej informacji na temat modelu z logowaniem zbiorczym, zobacz ten odnośnik )

Dostawca Microsoft OLE DB dla SQL Server (0x80040E14) Dziennik transakcji dla bazy danych „NAZWA BAZY DANYCH” jest pełny. Aby dowiedzieć się, dlaczego miejsca w dzienniku nie można ponownie wykorzystać, zobacz kolumnę log_reuse_wait_desc w sys.databases

Przyczyną tego błędu (najprawdopodobniej) jest to, że nie utworzono kopii zapasowej dziennika transakcji. Jeśli nie zostanie utworzona kopia zapasowa, będzie nadal fizycznie powiększać plik dziennika transakcji (pod warunkiem, że autogrowth jest włączony i maksymalny rozmiar pozwala), ponieważ nie może ponownie użyć żadnej z „części” dziennika transakcji (wirtualne pliki dziennika). Może jedynie oznaczyć te VLF do ponownego użycia i pozwolić na „zawinięcie” natury dziennika transakcji podczas tworzenia kopii zapasowej dziennika transakcji (i kilka innych wymagań, takich jak brak aktywnych transakcji, niektóre aspekty replikacji itp.).

Aby zmniejszyć dziennik i ponownie umożliwić dostęp do bazy danych, zmieniłem model odzyskiwania z FULL na SIMPLE i zmniejszyłem dziennik pliku logicznego za pomocą następującego polecenia

......

Pomogło, ale teraz muszę zrozumieć DLACZEGO to pomogło, JAK ta sytuacja się zaczęła i JAK temu zapobiec w przyszłości?

Pomogło ci to, ponieważ ustawiając bazę danych na prosty model odzyskiwania, powiedziałeś SQL Serverowi, że nie dbasz już o odzyskiwanie w określonym momencie, oraz wymóg zapewnienia, że ​​wirtualne pliki dziennika nie muszą być dłużej zachowywane i oznaczane jako aktywne, teraz proces punktu kontrolnego zaznacza te VLF jako nieaktywne.

Fragment / cytat zaczerpnięty z tego odniesienia MSDN :

W ramach prostego modelu odzyskiwania, o ile jakiś czynnik nie opóźnia obcinania dziennika, automatyczny punkt kontrolny obciąża nieużywaną sekcję dziennika transakcji. Natomiast w przypadku modeli odzyskiwania z pełnym i masowym logowaniem, po ustanowieniu łańcucha kopii zapasowej dziennika, automatyczne punkty kontrolne nie powodują obcinania dziennika.

Następnie zmniejszyłeś fizyczny plik bazy danych, a ponieważ w dzienniku transakcji było wolne miejsce, teraz mógł fizycznie zmniejszyć plik NTFS.

Czytanie warte spędzenia czasu na:

1. Modele odzyskiwania
2. Zarządzanie dziennikami transakcji (Gail Shaw)
3. Czynniki, które mogą opóźnić obcinanie dziennika

EDYCJA po edycji :

Czy nowy model odzyskiwania i baza danych będą sprzeczne z tym skryptem?

To BACKUP DATABASEpolecenie będzie działać z dowolnym modelem odzyskiwania. Jeśli chodzi o rutynową bazę danych, zmniejsz się ... NIE ZRÓB TO !!!! Poważnie, odpowiednio zmień rozmiar bazy danych, a jeśli korzystasz z pełnego modelu odzyskiwania, upewnij się, że wykonujesz rutynowe i częste pliki dziennika transakcji, nie tylko po to, aby utrzymać rozmiar dziennika transakcji na dystans, ale także spełniać obiekty punktu odzyskiwania.

Nie wykonujemy żadnego innego rodzaju tworzenia kopii zapasowych baz danych, a zatem nie dzienników transakcji, prawda?

Jeśli baza danych korzysta z pełnego modelu odzyskiwania, to tak, powinieneś robić kopie zapasowe dziennika transakcji. Jeśli odzyskiwanie bazy danych jest proste, nie można fizycznie wykonać kopii zapasowej dziennika transakcji.

Co do tego, jakiego modelu odzyskiwania użyć (prosty vs. pełny), nie możemy podjąć tej decyzji za Ciebie. Tylko Ty, Twój zespół biznesowy i Twoje umowy SLA mogą.