Zmniejszenie pliku dziennika nie zmniejsza rozmiaru

Mam bazę danych, która ma plik danych 350 MB (.mdf) i plik dziennika 4,9 GB (.ldf). Model odzyskiwania jest ustawiony na FULL.

Kiedy próbuję zmniejszyć plik dziennika, nie zmniejsza się.

Wiem, że zmniejszanie bazy danych nie jest dobre i nie należy tego robić. Ale nadal próbuję to zrobić, aby zmniejszyć plik dziennika.

Kiedy pobiegłem

DBCC SQLPerf(logspace) 

Odkryłem, że rozmiar dziennika wynosi 4932 MB, a używane miejsce dziennika to 98,76% !

Potem spróbowałem tego polecenia

USE <databasename>;
DBCC loginfo;

Teraz prawie wszystkie VLF mają „status 2”, co oznacza, że ​​wszystkie są w użyciu.

Próbowałem zrobić kopię zapasową dziennika, a następnie zmniejszyć plik dziennika. Kurczenie się nie zmniejszyło rozmiaru.

Zmieniłem model odzyskiwania na SIMPLEi próbowałem ponownie zmniejszyć, ale to też nie pomogło.

Sprawdziłem otwarte transakcje

DBCC opentran (database);

i stwierdził, że żadna transakcja nie jest teraz otwarta.

Co powstrzymuje mnie przed zmniejszaniem pliku dziennika? Jak mogę to rozwiązać?

Oto odpowiedź na moje własne pytanie.

Uruchom poniższe zapytanie, aby uzyskać informacje na temat ponownego użycia pliku dziennika:

SELECT log_reuse_wait_desc
FROM sys.databases
WHERE name = 'DBName'

Mam następujące dane wyjściowe:

log_reuse_wait_desc
-------------------
REPLICATION 

W bazie danych pozostały pewne obiekty związane z replikacją, nawet po usunięciu replikacji.

Aby usunąć replikację z bazy danych, sp_removedbreplicationmożna użyć. Ale to nie działało dla nas, ponieważ replikacja nie była wówczas aktywna i faktycznie replikacja została usunięta na długo wcześniej.

Rozwiązaniem było zaimportowanie zawartości bazy danych do innej bazy danych przy użyciu opcji importu programu SQL Server.

Będą kroki do zmniejszenia dziennika

Wykonaj kopię zapasową dziennika transakcji za pośrednictwem SSMS lub T-SQL, a następnie wykonaj zmniejszenie

polecenia dla SSMS są w ramach zadań, jeśli klikniesz prawym przyciskiem myszy nazwę bazy danych

BACKUP LOG <Databasename> TO DISK N'<path\database_log.ldf';
GO

DBCC SHRINKFILE (<FileName>, <TargetSize>) WITH NO_INFOMSGS

Prawdopodobnie będziesz musiał to zrobić wiele razy

Jeśli transakcja lub zadanie blokuje działanie, użyj Monitora aktywności, aby zidentyfikować proces i zabić go, lub użyj Monitora aktywności zadania SQL Agent, aby zakończyć zadanie.

źródło: http://support.microsoft.com/kb/907511

Przeczytaj Jak zmniejszyć dziennik SQL Server, aby uzyskać wyjaśnienie, w jaki sposób okrągły charakter dziennika może zapobiec zmniejszeniu po obcięciu. Możliwe jest, że zalogujesz ostatni punkt LSN do VLF, który znajduje się na końcu LDF. Przeciwdziałaj intuicyjnie, musisz przesuwać dziennik, generując zapisy dziennika, aby mógł się skurczyć.

Najpierw musisz utworzyć kopię zapasową, w zależności od modelu kopii zapasowej skonfigurowanego dla bazy danych, zanim będzie możliwe zmniejszenie bazy danych.

Możesz spróbować uruchomić to:

USE <databasename>
GO

BACKUP DATABASE <databasename> TO DISK '<absolute path goes here>\<databasename>.bak';
GO

Lub możesz to zrobić z SSMS i użyć dostępnych narzędzi graficznych (zobacz tutaj, aby uzyskać szczegółowe informacje: http://msdn.microsoft.com/en-us/library/ms187510.aspx )

Po utworzeniu kopii zapasowej bazy danych możesz ją skompresować. Zmniejszenie bazy danych nie jest jednak dobrym pomysłem, ponieważ wystąpi duża fragmentacja indeksu, a wyszukiwanie danych będzie spowolnione.

Mam nadzieję że to pomoże.

Odkryłem, że muszę wykonać 2 lub 3 kopie zapasowe zarówno bazy danych, jak i dziennika transakcji, aby dziennik transakcji faktycznie zmniejszył swój rozmiar. Mam bazę danych, która została utworzona przy użyciu pełnego modelu odzyskiwania. Każdej nocy wykonuje kopie zapasowe bazy danych i dziennika transakcji, ale nieuchronnie dziennik transakcji wydaje się stale powiększać w ciągu 2-3 tygodni. Kiedy pozostała ilość miejsca na dysku osiągnie 1 GB, zobaczę, że dziennik transakcji wynosi około 30 GB. Postępowałem zgodnie z zaleceniami Microsoft i po czwartej lub piątej iteracji tworzenia kopii zapasowej zarówno bazy danych, jak i dziennika transakcji, dziennik transakcji w końcu zwolni dodatkową przestrzeń i zmniejszy się. Następnie wracam i usuwam wiele utworzonych kopii zapasowych.

Pracuję nad replikacją, która blokuje zmniejszający się plik dziennika:

1. Ustaw DB Recovery Model na Simple
2. Przełącz DB w tryb offline
3. Utwórz kopię zapasową pliku dziennika (na wszelki wypadek)
4. Usuń plik dziennika
5. Przełącz DB w tryb online

W moim przypadku zadziałało. Po przejściu do DB online log został utworzony automatycznie, a jego rozmiar wynosił 512 kb zamiast 70 GB. Ale to tylko obejście. Problem root nie został rozwiązany. W moim przypadku używamy replikacji.