To wydaje się być częstym pytaniem na większości forów i w Internecie, zadaje się je tutaj w wielu formatach, które zwykle brzmią tak:

W SQL Server -

• Z jakich powodów dziennik transakcji staje się tak duży?
• Dlaczego mój plik dziennika jest tak duży?
• Jakie są sposoby zapobiegania występowaniu tego problemu?
• Co mam zrobić, gdy uzmysłowię sobie podstawową przyczynę i chcę przywrócić prawidłowy rozmiar pliku dziennika transakcji?

Krótsza odpowiedź:

Prawdopodobnie masz uruchomioną długo działającą transakcję (konserwacja indeksu? Usuwanie lub aktualizacja dużych partii?) Lub znajdujesz się w „domyślnym” (więcej poniżej, co to znaczy domyślnie) trybie odzyskiwania Fulli nie wykonałeś kopii zapasowej dziennika (lub nie biorą ich wystarczająco często).

Jeśli jest to problem z modelem odzyskiwania, prostą odpowiedzią może być Przełączenie do Simpletrybu odzyskiwania, jeśli nie potrzebujesz odzyskiwania w określonym czasie i regularnych kopii zapasowych dziennika. Jednak wiele osób czyni tę odpowiedź bez zrozumienia modeli odzyskiwania. Czytaj dalej, aby zrozumieć, dlaczego to ważne, a następnie zdecyduj, co robisz. Możesz także po prostu zacząć tworzyć kopie zapasowe dziennika i kontynuować Fullodzyskiwanie.

Mogą być inne powody, ale są one najczęstsze. Ta odpowiedź zaczyna nurkować na najczęstsze dwa powody i daje podstawowe informacje na temat przyczyn i przyczyn, a także odkrywa inne powody.

Dłuższa odpowiedź: jakie scenariusze mogą powodować wzrost dziennika? Istnieje wiele przyczyn, ale zazwyczaj są to dwa następujące wzorce: Istnieje nieporozumienie dotyczące modeli odzyskiwania lub istnieją długotrwałe transakcje. Czytaj dalej, aby poznać szczegóły.

Główny powód 1/2: Niezrozumienie modeli odzyskiwania

( Będąc w trybie pełnego odzyskiwania i nie wykonując kopii zapasowych dziennika - jest to najczęstszy powód - zdecydowana większość osób, które mają ten problem ).

Chociaż ta odpowiedź nie jest głębokim zanurzeniem w modelach odzyskiwania programu SQL Server, temat modeli odzyskiwania ma zasadnicze znaczenie dla tego problemu.

W SQL Server istnieją trzy modele odzyskiwania :

• Full,
• Bulk-Logged i
• Simple.

Na razie zignorujemy, Bulk-Loggedpowiedzmy, że jest to model hybrydowy i większość osób, które są w tym modelu, istnieje z jakiegoś powodu i rozumie modele odzyskiwania.

Dwie sprawy, na których nam zależy, i ich zamieszanie są przyczyną większości przypadków osób mających ten problem Simplei Full.

Przerwa: Odzyskiwanie w ogóle

Zanim porozmawiamy o modelach odzyskiwania: porozmawiajmy ogólnie o odzyskiwaniu. Jeśli chcesz pogłębić ten temat, po prostu przeczytaj blog Paula Randala i dowolną liczbę postów na jego temat. Jednak w przypadku tego pytania:

1. Odzyskiwanie
   po awarii / ponownym uruchomieniu Jednym z celów pliku dziennika transakcji jest przywrócenie po awarii / ponownym uruchomieniu . Do wycofywania i wycofywania pracy wykonanej (wycofywanie / ponawianie) przed awarią lub restartem oraz pracy, która została rozpoczęta, ale nie została ukończona po awarii lub ponownym uruchomieniu (wycofywanie / cofanie). Zadaniem dziennika transakcji jest sprawdzenie, czy transakcja się rozpoczęła, ale nigdy się nie zakończyła (wycofano lub nastąpiła awaria / restart przed zatwierdzeniem transakcji). W tej sytuacji dziennikiem jest powiedzenie „Hej, to się nigdy nie skończyło, cofnijmy go” podczas odzyskiwania. Zadaniem dziennika jest również sprawdzenie, czy coś skończyłeś i aplikacja kliencka została poinformowana, że ​​została zakończona (nawet jeśli nie stwardniała jeszcze do pliku danych) i powiedz„Hej… to się naprawdę wydarzyło, przewińmy to do przodu, sprawmy, żeby aplikacje tak myślały” po ponownym uruchomieniu. Teraz jest więcej, ale to jest główny cel.

2. Odzyskiwanie punktu w czasie
   Drugim celem pliku dziennika transakcji jest umożliwienie nam odzyskania danych do określonego momentu w wyniku „wylewania” w bazie danych lub zagwarantowanie punktu odzyskiwania w przypadku awarii sprzętu obejmujące dane i / lub pliki dziennika bazy danych. Jeśli ten dziennik transakcji zawiera rekordy transakcji, które zostały uruchomione i zakończone w celu odzyskania, SQL Server może następnie użyć tych informacji, aby uzyskać bazę danych tam, gdzie była przed wystąpieniem problemu. Ale nie zawsze jest to dla nas dostępna opcja. Aby to zadziałało, musimy mieć naszą bazę danych we właściwym modelu odzyskiwania i musimy wykonywać kopie zapasowe dziennika .

Modele odzyskiwania

W modelach odzyskiwania:

• Prosty model odzyskiwania
  Tak więc z powyższym wprowadzeniem najłatwiej jest Simple Recoverynajpierw porozmawiać o modelu. W tym modelu mówisz do programu SQL Server: „Nie mam nic przeciwko używaniu pliku dziennika transakcji do awarii i restartu odzyskiwania ...” (Naprawdę nie masz tam wyboru. Sprawdź właściwości ACID i to powinno szybko mieć sens). „... ale kiedy już nie będziesz go potrzebować do tego celu odzyskiwania po awarii / ponownym uruchomieniu, śmiało i ponownie użyj pliku dziennika.”

  SQL Server nasłuchuje tego żądania w prostym odzyskiwaniu i zachowuje tylko informacje potrzebne do przywrócenia działania po awarii / ponownym uruchomieniu. Po upewnieniu się, że SQL Server może odzyskać, ponieważ dane są zahartowane w pliku danych (mniej więcej), dane, które zostały zahartowane, nie są już potrzebne w dzienniku i są oznaczone do obcięcia - co oznacza, że ​​zostaną ponownie użyte.

• Pełny model odzyskiwania
  Za pomocą Full Recoveryprogramu SQL Server informujesz, że chcesz odzyskać dane do określonego punktu w czasie, o ile plik dziennika jest dostępny lub do określonego momentu objętego kopią zapasową dziennika. W takim przypadku, gdy SQL Server osiągnie punkt, w którym bezpiecznie byłoby obciąć plik dziennika w prostym modelu odzyskiwania, nie zrobi tego. Zamiast tego pozwala, aby plik dziennika nadal się powiększał i pozwoli mu dalej się rozwijać, dopóki nie zostanie wykonana kopia zapasowa dziennika (lub zabraknie miejsca na dysku z plikami dziennika) w normalnych okolicznościach.

Zmiana z Simple na Full ma Gotcha.

Istnieją tutaj zasady i wyjątki. Poniżej szczegółowo omówimy długoterminowe transakcje.

Ale jednym zastrzeżeniem, o którym należy pamiętać w trybie pełnego odzyskiwania, jest to: jeśli po prostu przełączysz się w Full Recoverytryb, ale nigdy nie weźmiesz początkowej pełnej kopii zapasowej, SQL Server nie zaakceptuje twojej prośby o Full Recoverymodel. Twój dziennik transakcji będzie działał tak, jak ma, Simpledopóki nie przejdziesz do pełnego modelu odzyskiwania ORAZ nie weźmiesz pierwszego Full Backup.

Pełny model odzyskiwania bez kopii zapasowych dziennika jest zły.

Więc to jest najczęstszy powód niekontrolowanego wzrostu kłód? Odpowiedź: Przebywanie w trybie pełnego odzyskiwania bez tworzenia kopii zapasowych dziennika.

Zdarza się to cały czas ludziom.

Dlaczego jest to tak powszechny błąd?

Dlaczego tak się dzieje cały czas? Ponieważ każda nowa baza danych otrzymuje swoje początkowe ustawienie modelu odzyskiwania, patrząc na bazę danych modelu.

Początkowe ustawienie modelu odzyskiwania modelu jest zawsze Full Recovery Model- dopóki ktoś tego nie zmieni. Można więc powiedzieć, że „domyślny model odzyskiwania” to Full. Wiele osób nie zdaje sobie z tego sprawy i ich bazy danych działają Full Recovery Modelbez kopii zapasowych dzienników, dlatego plik dziennika transakcji jest znacznie większy niż to konieczne. Dlatego tak ważna jest zmiana wartości domyślnych, gdy nie działają one dla Twojej organizacji i jej potrzeb)

Pełny model odzyskiwania ze zbyt małą liczbą kopii zapasowych dziennika jest zły.

Możesz także wpaść w kłopoty, nie wykonując wystarczająco często kopii zapasowych dzienników.
Biorąc dzienną kopię zapasową dziennika, może to brzmieć dobrze, powoduje, że przywracanie wymaga mniej poleceń przywracania, ale pamiętając powyższą dyskusję, plik dziennika będzie się powiększał i powiększał, dopóki nie wykonasz kopii zapasowych dziennika.

Jak dowiedzieć się, jakiej częstotliwości kopii zapasowej dziennika potrzebuję?

Należy wziąć pod uwagę częstotliwość tworzenia kopii zapasowych dziennika, mając na uwadze dwie rzeczy:

1. Potrzeby odzyskiwania - mam nadzieję, że powinno to być pierwsze. W przypadku uszkodzenia dysku zawierającego dziennik transakcji lub poważnego uszkodzenia, które wpływa na kopię zapasową dziennika, ile danych można utracić? Jeśli liczba ta nie przekracza 10-15 minut, musisz robić kopię zapasową dziennika co 10-15 minut, koniec dyskusji.
2. Wzrost dziennika - jeśli Twoja organizacja może stracić więcej danych ze względu na możliwość łatwego odtworzenia tego dnia, możesz mieć kopię zapasową dziennika znacznie rzadziej niż 15 minut. Może Twoja organizacja ma się dobrze co 4 godziny. Ale musisz sprawdzić, ile transakcji generujesz w ciągu 4 godzin. Czy zezwolenie na ciągły wzrost dziennika w ciągu tych czterech godzin spowoduje, że plik dziennika będzie zbyt duży? Czy to oznacza, że ​​tworzenie kopii zapasowych dziennika trwa zbyt długo?

Główny powód 2/2: Transakcje długoterminowe

( „Mój model odzyskiwania jest w porządku! Dziennik wciąż rośnie! )

Może to być również przyczyną niekontrolowanego i nieograniczonego wzrostu kłód. Bez względu na model odzyskiwania, ale często pojawia się jako „Ale jestem w prostym modelu odzyskiwania - dlaczego mój dziennik wciąż rośnie ?!”

Powód jest prosty: jeśli SQL używa tego dziennika transakcji do celów odzyskiwania, jak opisano powyżej, to musi wrócić do początku transakcji.

Jeśli masz transakcję, która zajmuje dużo czasu lub wprowadza wiele zmian, dziennik nie może zostać obcięty w punkcie kontrolnym dla żadnej ze zmian, które są nadal w otwartych transakcjach lub które rozpoczęły się od czasu rozpoczęcia tej transakcji.

Oznacza to, że duże usunięcie, usunięcie milionów wierszy w jednej instrukcji usuwania to jedna transakcja, a dziennik nie może obciąć, dopóki całe usunięcie nie zostanie wykonane. W Full Recovery Modeltym usunięciu jest rejestrowane i może to być wiele rekordów dziennika. To samo dotyczy prac związanych z optymalizacją indeksu podczas okien konserwacji. Oznacza to również, że słabe zarządzanie transakcjami oraz nieoczekiwanie i zamykanie otwartych transakcji może naprawdę zaszkodzić tobie i twojemu plikowi dziennika.

Co mogę zrobić z tymi długoterminowymi transakcjami?

Możesz się tutaj uratować poprzez:

• Prawidłowo dopasuj rozmiar pliku dziennika, aby uwzględnić najgorszy scenariusz - taki jak konserwacja lub znane duże operacje. A kiedy powiększysz swój plik dziennika, powinieneś zapoznać się z tymi wskazówkami (i dwoma linkami, do których ona cię wysyła) autorstwa Kimberly Tripp. Właściwy dobór jest tutaj niezwykle ważny.
• Obserwowanie wykorzystania transakcji. Nie rozpoczynaj transakcji na serwerze aplikacji i nie zaczynaj długich rozmów z SQL Server, ryzykując zbyt długo otwartą.
• Obserwowanie transakcji dorozumianych w wyciągach DML. Na przykład: UPDATE TableName Set Col1 = 'New Value'jest transakcją. Nie umieściłem BEGIN TRANtam i nie muszę, wciąż jest to jedna transakcja, która po prostu automatycznie zatwierdza się po zakończeniu. Jeśli więc wykonujesz operacje na dużej liczbie wierszy, rozważ podzielenie tych operacji na łatwiejsze do zarządzania porcje i pozostawienie dziennika do odzyskania. Lub rozważ odpowiedni rozmiar, aby sobie z tym poradzić. A może zajrzyj do zmiany modeli odzyskiwania podczas okna ładowania zbiorczego.

Czy te dwa powody dotyczą również wysyłania kłód?

Krótka odpowiedź: tak. Dłuższa odpowiedź poniżej.

Pytanie: „Korzystam z wysyłki dzienników, więc moje kopie zapasowe dzienników są zautomatyzowane ... Dlaczego wciąż widzę wzrost dzienników transakcji?”

Odpowiedź: czytaj dalej.

Co to jest wysyłka dziennika?

Przesyłanie dziennika jest dokładnie tak, jak się wydaje - kopie zapasowe dziennika transakcji są wysyłane na inny serwer w celu odzyskiwania po awarii. Jest trochę inicjalizacji, ale potem proces jest dość prosty:

• Zadanie tworzenia kopii zapasowej dziennika na jednym serwerze,
• zadanie do skopiowania kopii zapasowej dziennika i
• zadanie przywracania go bez odzyskiwania (albo NORECOVERYalbo STANDBY) na serwerze docelowym.

Istnieją również zadania do monitorowania i ostrzegania, jeśli sprawy nie pójdą zgodnie z planem.

W niektórych przypadkach przywracanie dziennika może być konieczne tylko raz dziennie lub co trzeci dzień lub raz w tygodniu. W porządku. Jeśli jednak wprowadzisz tę zmianę we wszystkich zadaniach (w tym w przypadku kopii zapasowej dziennika i kopii), oznacza to, że czekasz cały czas na wykonanie kopii zapasowej dziennika. Oznacza to, że będziesz mieć duży przyrost dzienników - ponieważ jesteś w trybie pełnego odzyskiwania bez kopii zapasowych dzienników - i prawdopodobnie oznacza to również duży plik dziennika do skopiowania. Należy jedynie zmodyfikować harmonogram zadania przywracania i pozwolić, aby kopie zapasowe i kopie dziennika były wykonywane częściej, w przeciwnym razie wystąpi pierwszy problem opisany w tej odpowiedzi.

Ogólne rozwiązywanie problemów za pomocą kodów stanu

Istnieją inne powody niż te dwa, ale są one najczęstsze. Bez względu na przyczynę: istnieje sposób, aby przeanalizować przyczynę tego niewyjaśnionego wzrostu logów / braku obcięcia i zobaczyć, co to jest.

Poprzez zapytanie do sys.databaseswidoku katalogu można zobaczyć informacje opisujące powód, dla którego plik dziennika może oczekiwać na obcięcie / ponowne użycie.

Istnieje kolumna wywoływana log_reuse_waitz identyfikatorem odnośnika kodu przyczyny i log_reuse_wait_desckolumna z opisem przyczyny oczekiwania. Z cytowanych książek online jest większość powodów (te, które prawdopodobnie zobaczysz i te, które możemy wyjaśnić. Brakujące są nieużywane lub do użytku wewnętrznego) z kilkoma uwagami na temat oczekiwania kursywa :

• 0 = nic
  Jak to brzmi… Nie powinno czekać

• 1 = Punkt kontrolny
  Oczekiwanie na wystąpienie punktu kontrolnego. To powinno się zdarzyć i powinno być w porządku - ale są pewne przypadki, w których można tu szukać późniejszych odpowiedzi lub zmian.

• 2 = Kopia
  zapasowa dziennika Czekasz na kopię zapasową dziennika. Albo masz je zaplanowane i stanie się to wkrótce, albo masz pierwszy opisany tutaj problem i teraz wiesz, jak go naprawić

• 3 = Aktywna kopia zapasowa lub przywracanie
  W bazie danych działa operacja tworzenia kopii zapasowej lub przywracania

• 4 = Aktywna transakcja
  Istnieje aktywna transakcja, która musi zostać zakończona (w obu kierunkach - ROLLBACKlub COMMIT) przed utworzeniem kopii zapasowej dziennika. Jest to drugi powód opisany w tej odpowiedzi.

• 5 = Kopia lustrzana bazy danych Kopia lustrzana
  opóźnia się lub ma opóźnienie w przypadku kopii lustrzanej o wysokiej wydajności lub kopia lustrzana jest z jakiegoś powodu wstrzymana

• 6 = Replikacja
  Mogą występować problemy z replikacją, które mogą to powodować - na przykład brak działania agenta czytającego dzienniki, bazy danych, która uważa, że ​​jest zaznaczona do replikacji, której już nie ma, i różne inne przyczyny. Możesz także zobaczyć ten powód i jest to całkowicie normalne, ponieważ patrzysz na właściwy czas, podobnie jak transakcje są konsumowane przez czytnik dziennika

• 7 = Tworzenie migawki bazy danych
  Tworzysz migawkę bazy danych, zobaczysz to, jeśli spojrzysz na odpowiedni moment podczas tworzenia migawki

• 8 = Skanowanie dziennika
  Nie spotkałem jeszcze problemu z ciągłym działaniem. Jeśli patrzysz wystarczająco długo i wystarczająco często, możesz to zobaczyć, ale nie powinno to być przyczyną nadmiernego wzrostu dziennika transakcji, co widziałem.

• 9 = Dodatkowa replika grup dostępności AlwaysOn stosuje rekordy dziennika transakcji tej bazy danych do odpowiedniej pomocniczej bazy danych. O najjaśniejszym jak dotąd opisie ..

Ponieważ nie jestem do końca zadowolony z żadnej z odpowiedzi na Stack Overflow , w tym z najbardziej pozytywnie ocenionej sugestii, a ponieważ jest kilka rzeczy, na które chciałbym się odnieść, odpowiedź Mike'a nie, pomyślałam, że udzielę mój wkład tutaj również. Tam też umieściłem kopię tej odpowiedzi.

Zmniejszenie pliku dziennika powinno być naprawdę zarezerwowane dla scenariuszy, w których wystąpił nieoczekiwany wzrost, którego nie spodziewasz się ponownie. Jeśli plik dziennika ponownie wzrośnie do tego samego rozmiaru, nie zostanie wiele osiągnięte przez jego tymczasowe zmniejszenie. Teraz, w zależności od celów odzyskiwania bazy danych, są to działania, które powinieneś podjąć.

Najpierw zrób pełną kopię zapasową

Nigdy nie wprowadzaj żadnych zmian w bazie danych bez upewnienia się, że możesz ją przywrócić, jeśli coś pójdzie nie tak.

Jeśli zależy Ci na odzyskaniu punktu w czasie

(I przez odzyskiwanie punktu w czasie, mam na myśli, że zależy ci na możliwości przywrócenia do czegoś innego niż pełna lub różnicowa kopia zapasowa.)

Prawdopodobnie twoja baza danych jest w FULLtrybie odzyskiwania. Jeśli nie, upewnij się, że:

ALTER DATABASE yourdb SET RECOVERY FULL;

Nawet jeśli regularnie wykonujesz pełne kopie zapasowe, plik dziennika będzie się powiększał aż do momentu utworzenia kopii zapasowej dziennika - służy to ochronie, aby nie niepotrzebnie pożerać miejsca na dysku. Powinieneś wykonywać te kopie zapasowe dziennika dość często, zgodnie z celami odzyskiwania. Na przykład, jeśli masz regułę biznesową, która mówi, że możesz pozwolić sobie na utratę nie mniej niż 15 minut danych w przypadku awarii, powinieneś mieć zadanie, które tworzy kopię zapasową dziennika co 15 minut. Oto skrypt, który wygeneruje nazwy plików ze znacznikami czasu na podstawie bieżącego czasu (ale możesz to również zrobić z planami konserwacji itp., Po prostu nie wybieraj żadnych opcji zmniejszania w planach konserwacji, są one okropne).

DECLARE @path NVARCHAR(255) = N'\\backup_share\log\yourdb_' 
  + CONVERT(CHAR(8), GETDATE(), 112) + '_'
  + REPLACE(CONVERT(CHAR(8), GETDATE(), 108),':','')
  + '.trn';

BACKUP LOG foo TO DISK = @path WITH INIT, COMPRESSION;

Należy pamiętać, że \\backup_share\powinien znajdować się na innym komputerze, który reprezentuje inne podstawowe urządzenie pamięci masowej. Tworzenie kopii zapasowych na tym samym komputerze (lub na innym komputerze, który używa tych samych dysków bazowych lub innej maszyny wirtualnej, która znajduje się na tym samym hoście fizycznym) tak naprawdę nie pomaga, ponieważ jeśli komputer się wysadzi, stracisz bazę danych i jego kopie zapasowe. W zależności od infrastruktury sieci bardziej sensowne może być tworzenie kopii zapasowych lokalnie, a następnie przenoszenie ich do innej lokalizacji za kulisami; w obu przypadkach chcesz je jak najszybciej usunąć z podstawowej maszyny bazy danych.

Teraz, gdy masz już regularne kopie zapasowe dzienników, rozsądne jest zmniejszenie pliku dziennika do czegoś bardziej sensownego niż to, co jest wysadzane do tej pory. Ten sposób nie oznacza, uruchomiony SHRINKFILEw kółko, aż plik dziennika jest 1 MB - nawet jeśli kopii zapasowej dziennika często, to nadal musi pomieścić sumę wszelkich współbieżnych transakcji, które mogą wystąpić. Zdarzenia autogrow pliku dziennika są kosztowne, ponieważ SQL Server musi wyzerować pliki (w przeciwieństwie do plików danych, gdy włączona jest natychmiastowa inicjalizacja pliku), a transakcje użytkownika muszą czekać, aż to nastąpi. Chcesz, aby procedura ta była jak najmniejsza, a na pewno nie chcesz, aby użytkownicy płacili za nią.

Pamiętaj, że może być konieczne dwukrotne utworzenie kopii zapasowej dziennika, zanim możliwe będzie zmniejszenie (dzięki Robert).

Musisz wymyślić praktyczny rozmiar pliku dziennika. Nikt tutaj nie może ci powiedzieć, co to jest, nie wiedząc dużo więcej o swoim systemie, ale jeśli często zmniejszałeś plik dziennika i ponownie rośnie, dobry znak wodny jest prawdopodobnie o 10-50% wyższy niż największy, jaki był . Powiedzmy, że dochodzi do 200 MB, a chcesz, aby wszelkie kolejne zdarzenia automatycznego wzrostu wynosiły 50 MB, a następnie możesz dostosować rozmiar pliku dziennika w ten sposób:

USE [master];
GO
ALTER DATABASE Test1 
  MODIFY FILE
  (NAME = yourdb_log, SIZE = 200MB, FILEGROWTH = 50MB);
GO

Pamiętaj, że jeśli plik dziennika ma obecnie> 200 MB, może być konieczne uruchomienie go w pierwszej kolejności:

USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);
GO

Jeśli nie zależy ci na odzyskaniu punktu w czasie

Jeśli jest to testowa baza danych i nie obchodzi Cię odzyskiwanie w określonym momencie, upewnij się, że baza danych znajduje się w SIMPLEtrybie odzyskiwania.

ALTER DATABASE yourdb SET RECOVERY SIMPLE;

Przełączenie bazy danych w SIMPLEtryb odzyskiwania sprawi, że SQL Server ponownie użyje części pliku dziennika (zasadniczo wycofując nieaktywne transakcje) zamiast rosnąć, aby prowadzić rejestr wszystkich transakcji (podobnie jak FULLodzyskiwanie do momentu utworzenia kopii zapasowej dziennika). CHECKPOINTzdarzenia pomogą kontrolować dziennik i upewnią się, że nie musi on rosnąć, chyba że wygenerujesz dużo aktywności t-log między CHECKPOINTs.

Następnie należy bezwzględnie upewnić się, że ten wzrost dziennika był naprawdę spowodowany nienormalnym zdarzeniem (powiedzmy, corocznym wiosennym czyszczeniem lub odbudową największych indeksów), a nie normalnym, codziennym użyciem. Jeśli zmniejszysz plik dziennika do absurdalnie małego rozmiaru, a program SQL Server po prostu go powiększy, aby dostosować się do normalnej aktywności, co zyskałeś? Czy byłeś w stanie wykorzystać to miejsce na dysku, które zwolniłeś tylko tymczasowo? Jeśli potrzebujesz natychmiastowej poprawki, możesz uruchomić następujące czynności:

USE yourdb;
GO
CHECKPOINT;
GO
CHECKPOINT; -- run twice to ensure file wrap-around
GO
-- 200 MB
DBCC SHRINKFILE(yourdb_log, 200);
GO

W przeciwnym razie ustaw odpowiedni rozmiar i tempo wzrostu. Zgodnie z przykładem w przypadku odzyskiwania w określonym momencie można użyć tego samego kodu i logiki, aby określić odpowiedni rozmiar pliku i ustawić rozsądne parametry autogrowth.

Niektórych rzeczy nie chcesz robić

• Utwórz kopię zapasową dziennika z TRUNCATE_ONLYopcją, a następnieSHRINKFILE . Po pierwsze, ta TRUNCATE_ONLYopcja jest przestarzała i nie jest już dostępna w bieżących wersjach SQL Server. Po drugie, jeśli jesteś w FULLmodelu odzyskiwania, spowoduje to zniszczenie łańcucha dzienników i będzie wymagać nowej, pełnej kopii zapasowej.

• Odłącz bazę danych, usuń plik dziennika i podłącz ponownie . Nie mogę podkreślić, jak niebezpieczne to może być. Twoja baza danych może nie zostać ponownie uruchomiona, może pojawić się jako podejrzana, konieczne może być przywrócenie kopii zapasowej (jeśli taka istnieje) itp. Itp.

• Użyj opcji „zmniejsz bazę danych” . DBCC SHRINKDATABASEa opcja planu konserwacji, aby zrobić to samo, to złe pomysły, szczególnie jeśli naprawdę potrzebujesz tylko rozwiązać problem z logiem. Wybierz plik, który chcesz dostosować, i dostosuj go niezależnie, używając DBCC SHRINKFILElub ALTER DATABASE ... MODIFY FILE(przykłady powyżej).

• Zmniejsz plik dziennika do 1 MB . Wygląda to kusząco, ponieważ, hej, SQL Server pozwoli mi to zrobić w określonych scenariuszach i spojrzeć na całą wolną przestrzeń! O ile twoja baza danych nie jest tylko do odczytu (i tak, powinieneś oznaczyć ją jako taką za pomocą ALTER DATABASE), absolutnie doprowadzi to do wielu niepotrzebnych zdarzeń wzrostu, ponieważ dziennik musi uwzględniać bieżące transakcje niezależnie od modelu odzyskiwania. Po co tymczasowo zwalniać to miejsce, aby SQL Server mógł je powoli i boleśnie przywrócić?

• Utwórz drugi plik dziennika . Zapewni to tymczasową ulgę dla dysku, który zapełnił twój dysk, ale to jest jak próba naprawienia nakłutego płuca opaską. Powinieneś poradzić sobie z problematycznym plikiem dziennika zamiast dodawać kolejny potencjalny problem. Poza przekierowaniem niektórych działań dziennika transakcji na inny dysk, drugi plik dziennika naprawdę nic dla ciebie nie robi (w przeciwieństwie do drugiego pliku danych), ponieważ tylko jeden z plików może być używany jednocześnie. Paul Randal wyjaśnia również, dlaczego wiele plików dziennika może cię później ugryźć .

Bądź proaktywny

Zamiast zmniejszać plik dziennika do niewielkiej ilości i pozwalać mu na ciągłe automatyczne rozwijanie się w niewielkim tempie, ustaw go na odpowiednio duży rozmiar (taki, który pomieści sumę największego zestawu równoczesnych transakcji) i ustaw rozsądny autogrow ustawienie awaryjne, aby nie musiało rosnąć wiele razy, aby zaspokoić pojedyncze transakcje, i aby stosunkowo rzadko rosło podczas normalnych operacji biznesowych.

Najgorsze możliwe ustawienia to wzrost o 1 MB lub wzrost o 10%. Zabawne, że są to ustawienia domyślne dla SQL Server (na co narzekałem i prosiłem o bezskuteczne zmiany ) - 1 MB na pliki danych i 10% na pliki dziennika. Ten pierwszy jest o wiele za mały w dzisiejszych czasach, a drugi za każdym razem prowadzi do coraz dłuższych zdarzeń (powiedzmy, plik dziennika to 500 MB, pierwszy wzrost to 50 MB, następny wzrost to 55 MB, następny wzrost to 60,5 MB itd. itd. - a przy wolnym we / wy, uwierz mi, naprawdę zauważysz tę krzywą).

Dalsza lektura

Proszę, nie zatrzymuj się tutaj; podczas gdy wiele porad dotyczących zmniejszania plików dziennika jest z natury złe, a nawet potencjalnie katastrofalne, istnieją osoby, którym bardziej zależy na integralności danych niż na zwolnieniu miejsca na dysku.

• Wpis na blogu, który napisałem w 2009 r., Kiedy zobaczyłem kilka postów „tutaj, jak zmniejszyć plik dziennika” .

• Post na blogu, który Brent Ozar napisał cztery lata temu, wskazując na wiele zasobów, w odpowiedzi na artykuł w magazynie SQL Server Magazine, który nie powinien zostać opublikowany .

• Wpis na blogu autorstwa Paula Randala wyjaśniający, dlaczego utrzymanie t-log jest ważne i dlaczego nie powinieneś zmniejszać plików danych .

• Mike Walsh ma świetną odpowiedź powyżej, obejmującą również niektóre z tych aspektów, w tym powody, dla których możesz nie być w stanie natychmiast zmniejszyć pliku dziennika .

Możesz także zobaczyć zawartość swojego pliku dziennika. Aby to zrobić, możesz użyć nieudokumentowanego fn_dbloglub czytnika dziennika transakcji, takiego jak ApexSQL Log .

Nie pokazuje reorganizacji indeksu, ale pokazuje wszystko DML i DDL różne imprezy: ALTER, CREATE, DROP, spust włącz / wyłącz, grant / cofnąć uprawnienia, obiekt zmienić.

Zastrzeżenie: Pracuję dla ApexSQL jako inżynier wsparcia

Jest to najczęściej spotykany problem w prawie wszystkich bazach danych, w których dzienniki rosną i wypełniają dysk.

• Z jakich powodów dziennik transakcji staje się tak duży?

1. Długa aktywna transakcja
2. Wysokie transakcje rejestrowania, takie jak odbudowywanie indeksu, reorganizacja, wstawianie zbiorcze, usuwanie itp.
3. Każda konfiguracja wysokiej dostępności, taka jak replikacja, kopia lustrzana, która przechowuje dziennik i nie pozwala na zwolnienie przestrzeni dziennika

• Dlaczego mój plik dziennika jest tak duży?

Sprawdź log_reuse_wait_deskolumnę c w sys.databasestabeli, aby dowiedzieć się, co powstrzymuje dzienniki przed obcięciem:

select name, log_reuse_wait_desc 
from sys.databases

• Jakie są sposoby zapobiegania występowaniu tego problemu?

Kopie zapasowe dzienników pomogą Ci kontrolować wzrost dzienników, chyba że istnieje coś, co powstrzymuje dzienniki przed ponownym użyciem.

• Co mam zrobić, gdy zaczynam śledzić podstawową przyczynę i chcę przywrócić prawidłowy rozmiar pliku dziennika transakcji?

Jeśli zidentyfikowałeś, co go faktycznie powoduje, postaraj się to naprawić zgodnie z opisem na poniższej stronie.

https://www.brentozar.com/archive/2016/03/my-favorite-system-column-log_reuse_wait_desc/

Właściwe zaplanowanie tworzenia kopii zapasowych dzienników jest najlepszym sposobem radzenia sobie z powiększaniem dzienników, chyba że w nietypowej sytuacji.