Zmniejszenie pliku dziennika nie zmniejsza rozmiaru


24

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ć?

Odpowiedzi:


12

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.


Miałem ten sam problem i wykorzystałem to, aby zobaczyć, że w db była aktywna transakcja. log_reuse_wait_descdał ACTIVE_TRANSACTION. Gdy tylko transakcja się zakończyła, skurcz zadziałał dobrze.
squillman

10

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


Ale napotkany problem jest inny. Zobacz moją odpowiedź poniżej
Navaneet

Cieszę się, że to zrozumiałeś, dzięki za aktualizację!
Cougar9000 30.04.13

Niepoprawna składnia - brakuje znaku równości: KOPIA ZAPASOWA <Nazwa bazy danych> DO DYSKU = N '<ścieżka \ baza_danych.ldf';
Odwrócony inżynier

9

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ć.


0

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.


Wiem, jak wykonać kopię zapasową i obciąć dziennik i zmniejszyć rozmiar pliku dziennika. Ale dla tej bazy danych mam problem. Właśnie uruchomiłem zapytanie wybierz log_reuse_wait_desc z sys.databases gdzie name = 'dbname' i stwierdziłem, że przyczyną problemu jest replikacja. Ale nie mam na nim ustawionej replikacji. Jak więc usunąć replikację z tej bazy danych, która jest pokazana w dzienniku, użyj ponownie wait_desc?
Navaneet

Z jakiej wersji programu SQL Server korzystasz?
Toni Kostelac

Replikacja może być ustawiona jako zadanie, więc otwórz folder SQL Server Agent i rozwiń folder Jobs, sprawdź, czy jest skonfigurowane zadanie replikacji, a jeśli tak, wyłącz je, klikając prawym przyciskiem myszy i wybierając Zatrzymaj zadanie
Toni Kostelac

Jeśli używasz programu SQL Server 2005 i nowszych wersji, sp_removedbreplication „DB_NAME” usunie replikację. W przypadku serwera SQL 2000 .. patrz blogs.msdn.com/b/repltalk/archive/2010/11/17/…
Kin Shah

Ale napotkany problem jest inny. Zobacz moją odpowiedź
Navaneet

0

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.


Myślę, że robisz coś złego. Jeśli właściwie wykonasz kopię zapasową dziennika, nieużywany dziennik powinien zostać obcięty. Polecenia podane w moim pytaniu mogą pomóc rozwiązać problem.
Navaneet,

-8

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.


4
To okropna rada, nigdy nie usuwaj dziennika transakcji, z tego mogą wynikać różnego rodzaju problemy, takie jak korupcja
Tom V - Team Monica
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.