Ogromny dziennik transakcji z bazą danych SQL Server w prostym trybie odzyskiwania

Question

Mam dość dużą bazę danych SQL Server, która używa trybu odzyskiwania SIMPLE. Naprawdę nie potrzebujemy aż do drugiego powrotu do zdrowia, więc wolałbym pozostać w tym trybie.

Z jakiegoś powodu dziennik transakcji dla tej bazy danych jest masywny (410 GB) z 99% nieprzydzielonego miejsca.

Próbowałem zmniejszyć plik przy użyciu (DBCC SHRINKFILE (MyDatabase_log, 20000)), ale nie wydaje się działać.

Ktoś ma jakieś wskazówki, dlaczego prosta baza danych trybu odzyskiwania ma tak duży plik? Naprawdę chciałbym, żeby to się zmniejszyło.

Answer 1

Oznacza to, że raz miałeś jedną transakcję, która trwała tak długo, że zmusiła dziennik do wzrostu 410 GB. Dziennika nie można użyć ponownie, jeśli istnieje aktywna transakcja, ponieważ nie można usunąć informacji o wycofaniu. Taki przykład może mieć miejsce, gdy ktoś otworzy zapytanie SSMS, rozpocznie transakcję, zaktualizuje rekord, a następnie przejdzie w wakacje. Transakcja będzie aktywna i wymusi wzrost logu do momentu zatwierdzenia lub wycofania. Kiedy transakcja zostanie ostatecznie zakończona, zużyta przestrzeń może zostać ostatecznie odzyskana, pozostawiając ogromny pusty plik dziennika.

Innym scenariuszem jest sytuacja, w której w jednej transakcji zaktualizowano około 200 GB danych. Dziennik będzie zapisywał obrazy przed i po zmian, zużywając w ten sposób dwukrotnie więcej miejsca i nie może być ponownie użyty, ponieważ jest to jedna pojedyncza transakcja.

Aktualizacja

I zapomniał wspomnieć replikacji, który jest również czynnikiem, który może zapobiec dziennika obcięcia. I podobnie jest Mirroring, transakcja rozproszona (technicznie to jest to samo, co "aktywna transakcja", ale implikacja DTC czyni to odrębnym przypadkiem). Pełna lista i objaśnienia znajduje się pod adresem Factors That Can Delay Log Truncation.

Answer 2

Brakuje argument w dbcc shrinkfile:

dbcc shrinkfile (MyDatabase_log, 20000, TRUNCATEONLY) 

NOTRUNCATE jest domyślnym, który porusza przydzielone bloki na początku nieprzydzielone miejsce. TRUNCATEONLY usuwa nieprzydzielone miejsce. Więc jeśli zrobisz NOTRUNCATE, a następnie TRUNCATEONLY, otrzymasz jeden odchudzony dziennik.

Answer 3

Jeśli masz tylko jeden plik mdf i jeden plik dziennika, najprawdopodobniej najprościej będzie odłączyć bazę danych, zmienić nazwę dziennika i ponownie dołączyć bazę danych. SQL Server utworzy nowy plik dziennika. Następnie można bezpiecznie usunąć ogromny plik dziennika.

To jednak nie zadziała, jeśli masz wiele plików danych.

Answer 4

Wydawca replikacji? Czy to może być przyczyna ogromnego dziennika transakcji?

Answer 5

Jak powiedział w innych odpowiedzi, transakcje aktywne i Replications są typowe przyczyny tego problemu.
Kolejnym, mniej widocznym, jest Zmiana przechwytywania danych (CDC).

miałem podobny problem niedawno i procedura, która pozwoliła mi uwolnić dziennik była następująca:

• Wyłącz CDC: EXEC sys.sp_cdc_disable_db
• Utwórz publikację na dowolnej tabeli w bazie danych, o którym mowa
• Usuń tę/wszystkie publikacje. EXEC sp_removedbreplication 'my_db' to wygodny sposób na zrobienie tego.
• Shrink dziennik jako pożądany

jestem pewien dlaczego tworzenie/skreślenie tego manekina/nigdy wykorzystane publikacji była konieczna ale tak było. Wstępnie w bazie danych mogły znajdować się wcześniejsze publikacje, które nie były prawidłowo usuwane (często mówi się, że bazy danych zostały przywrócone z poprzedniej kopii zapasowej).

Innym przydatnym idiom diagnostyczny jest sprawdzenie log_reuse_wait_desc w sys.databases na bazie naruszającego. To pole brzmi: REPLICATION, dopóki nie ukończyłem powyższej procedury.

SELECT log_reuse_wait_desc, * FROM sys.databases where name = 'my_db'