Zmniejszenie pliku dziennika powinno być zarezerwowane dla scenariuszy, w których napotkał nieoczekiwany wzrost, którego nie można się spodziewać ponownie. Jeśli plik dziennika ponownie powiększy się do tego samego rozmiaru, niewiele można osiągnąć przez tymczasowe jego zmniejszenie. Teraz, w zależności od celów odzyskiwania bazy danych, oto działania, które powinieneś podjąć.
Najpierw wykonaj 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
(A przez odzyskiwanie do określonego momentu, mam na myśli, że zależy Ci na możliwości przywrócenia do czegokolwiek innego niż pełna lub różnicowa kopia zapasowa).
Przypuszczalnie Twoja baza danych jest w FULL Tryb odzyskiwania. Jeśli nie, upewnij się, że:
ALTER DATABASE testdb SET RECOVERY FULL;
Nawet jeśli regularnie wykonujesz pełne kopie zapasowe, plik dziennika będzie rósł i powiększał się, dopóki nie wykonasz dziennika kopia zapasowa - jest to dla Twojej ochrony, a nie po to, aby niepotrzebnie zajmować miejsce na dysku. Te kopie zapasowe dzienników należy wykonywać dość często, zgodnie z celami odzyskiwania. Na przykład, jeśli masz regułę biznesową, która mówi, że możesz sobie pozwolić na utratę nie więcej 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 aktualnego czasu (ale możesz to również zrobić z planami konserwacji itp., po prostu nie wybieraj żadnej z opcji zmniejszania w planach konserwacji, są okropne).
DECLARE @path NVARCHAR(255) = N'\\backup_share\log\testdb_'
+ CONVERT(CHAR(8), GETDATE(), 112) + '_'
+ REPLACE(CONVERT(CHAR(8), GETDATE(), 108),':','')
+ '.trn';
BACKUP LOG foo TO DISK = @path WITH INIT, COMPRESSION;
Zwróć uwagę, że \\backup_share\ powinien znajdować się na innym komputerze, który reprezentuje inne podstawowe urządzenie magazynujące. Tworzenie kopii zapasowych na tej samej maszynie (lub na innej maszynie, która korzysta z tych samych podstawowych dysków lub innej maszyny wirtualnej, która znajduje się na tym samym fizycznym hoście) tak naprawdę nie pomaga, ponieważ jeśli maszyna wybuchnie, utracisz 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 przesyłanie ich w inne miejsce za kulisami; w obu przypadkach chcesz jak najszybciej usunąć je z podstawowej maszyny bazy danych.
Teraz, gdy masz już uruchomione regularne kopie zapasowe dziennika, rozsądne powinno być zmniejszenie pliku dziennika do czegoś bardziej rozsądnego niż to, co do tej pory zostało przesunięte. To nie oznacza uruchomienie SHRINKFILE w kółko, aż plik dziennika będzie miał rozmiar 1 MB — nawet jeśli często tworzysz kopię zapasową dziennika, nadal musi on uwzględniać sumę wszystkich współbieżnych transakcji, które mogą wystąpić. Zdarzenia automatycznego powiększania pliku dziennika są kosztowne, ponieważ SQL Server musi wyzerować pliki (w przeciwieństwie do plików danych, gdy włączone jest natychmiastowe inicjowanie plików), a transakcje użytkownika muszą czekać, aż to się stanie. Chcesz wykonywać tę procedurę wzrostu-skurczu-wzrostu-kurczenia tak mało, jak to tylko możliwe, i na pewno nie chcesz, aby Twoi użytkownicy za to płacili.
Pamiętaj, że może być konieczne dwukrotne wykonanie kopii zapasowej dziennika, zanim będzie możliwe zmniejszenie (dzięki Robert).
Musisz więc 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 zmniejszasz plik dziennika i ponownie rośnie, dobry znak wodny jest prawdopodobnie o 10-50% wyższy niż największy, jaki był . Załóżmy, że dochodzi do 200 MB i chcesz, aby każde kolejne zdarzenie autowzrostu miało 50 MB, wtedy 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
Zwróć uwagę, że jeśli plik dziennika ma obecnie> 200 MB, może być konieczne uprzednie uruchomienie tego:
USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);
GO
Jeśli nie zależy Ci na odzyskiwaniu do określonego momentu
Jeśli jest to testowa baza danych i nie zależy Ci na odzyskiwaniu do określonego momentu, powinieneś upewnić się, że Twoja baza danych jest w SIMPLE tryb odzyskiwania.
ALTER DATABASE testdb SET RECOVERY SIMPLE;
Umieszczanie bazy danych w SIMPLE tryb odzyskiwania zapewni, że SQL Server ponownie użyje części pliku dziennika (zasadniczo wycofując nieaktywne transakcje), zamiast rozwijać się w celu zapisania wszystkich transakcje (takie jak FULL odzyskiwanie, dopóki nie utworzysz kopii zapasowej dziennika). CHECKPOINT zdarzenia pomogą kontrolować dziennik i upewnić się, że nie musi on rosnąć, chyba że wygenerujesz dużą aktywność t-log między CHECKPOINT s.
Następnie powinieneś upewnić się, że ten wzrost kłody rzeczywiście był spowodowany nienormalnym wydarzeniem (powiedzmy coroczne wiosenne porządki lub odbudowanie twoich największych indeksów), a nie normalnym, codziennym użytkowaniem. Co zyskasz, jeśli zmniejszysz plik dziennika do absurdalnie małego rozmiaru, a SQL Server po prostu musi go ponownie powiększyć, aby dostosować go do normalnej aktywności? Czy udało Ci się wykorzystać zwolnione miejsce na dysku tylko tymczasowo? Jeśli potrzebujesz natychmiastowej naprawy, możesz uruchomić następujące polecenie:
USE yourdb;
GO
CHECKPOINT;
GO
CHECKPOINT; -- run twice to ensure file wrap-around
GO
DBCC SHRINKFILE(yourdb_log, 200); -- unit is set in MBs
GO
W przeciwnym razie ustaw odpowiedni rozmiar i tempo wzrostu. Jak na przykładzie w przypadku odzyskiwania do określonego momentu, możesz użyć tego samego kodu i logiki, aby określić, jaki rozmiar pliku jest odpowiedni i ustawić rozsądne parametry autowzrostu.
Niektóre rzeczy, których nie chcesz robić
-
Utwórz kopię zapasową dziennika za pomocą
TRUNCATE_ONLYopcję, a następnieSHRINKFILE. Po pierwsze, toTRUNCATE_ONLYopcja została uznana za przestarzałą i nie jest już dostępna w bieżących wersjach programu SQL Server. Po drugie, jeśli jesteś wFULLmodel odzyskiwania, spowoduje to zniszczenie łańcucha dzienników i wymaga nowej, pełnej kopii zapasowej. -
Odłącz bazę danych, usuń plik dziennika i dołącz ponownie . Nie mogę podkreślić, jak niebezpieczne może to być. Twoja baza danych może nie zostać przywrócona, może pojawić się jako podejrzana, być może będziesz musiał wrócić do kopii zapasowej (jeśli ją masz) itp. itp.
-
Użyj opcji „zmniejszenie bazy danych” .
DBCC SHRINKDATABASEa opcja planu konserwacji, aby zrobić to samo, to złe pomysły, zwłaszcza jeśli naprawdę potrzebujesz tylko rozwiązać problem z dziennikiem. Wyceluj plik, który chcesz dostosować i dostosuj go niezależnie, używającDBCC SHRINKFILElubALTER 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 niektórych scenariuszach i przyjrzeć się wolnej przestrzeni! Chyba że twoja baza danych jest tylko do odczytu (a tak jest, powinieneś ją oznaczyć jako taką używając
ALTER DATABASE), doprowadzi to absolutnie do wielu niepotrzebnych zdarzeń wzrostu, ponieważ dziennik musi uwzględniać bieżące transakcje niezależnie od modelu odzyskiwania. Jaki jest sens tymczasowego zwalniania tej przestrzeni, aby SQL Server mógł ją odzyskać powoli i boleśnie? -
Utwórz drugi plik dziennika . Zapewni to chwilową ulgę napędowi, który zapełnił dysk, ale jest to jak próba naprawienia przebitego płuca za pomocą plastra. Powinieneś zająć się problematycznym plikiem dziennika bezpośrednio, zamiast dodawać kolejny potencjalny problem. Poza przekierowaniem niektórych działań w dzienniku transakcji na inny dysk, drugi plik dziennika tak naprawdę nic dla ciebie nie robi (w przeciwieństwie do drugiego pliku danych), ponieważ tylko jeden z plików może być używany na raz. 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 jakiejś niewielkiej ilości i pozwalać mu na ciągły automatyczny wzrost w niewielkim tempie, ustaw go na dość duży rozmiar (taki, który pomieści sumę największego zestawu jednoczesnych transakcji) i ustaw rozsądny automatyczny wzrost ustawienie jako rezerwa, aby nie musiała rosnąć wielokrotnie w celu zaspokojenia pojedynczych transakcji i aby stosunkowo rzadko musiał rosnąć podczas normalnych operacji biznesowych.
Najgorsze możliwe ustawienia to wzrost o 1 MB lub wzrost o 10%. Zabawne, że są to wartości domyślne dla SQL Server (na które narzekałem i prosiłem o zmiany bezskutecznie) - 1 MB dla plików danych i 10% dla plików dziennika. Ten pierwszy jest o wiele za mały w dzisiejszych czasach, a drugi prowadzi do coraz dłuższych zdarzeń za każdym razem (powiedzmy, że plik dziennika ma 500 MB, pierwszy wzrost to 50 MB, następny wzrost to 55 MB, następny wzrost to 60,5 MB , itd. itd. - i uwierz mi, przy wolnych I/O, naprawdę zauważysz tę krzywą).
Dalsze czytanie
Proszę, nie zatrzymuj się tutaj; podczas gdy wiele porad dotyczących zmniejszania plików dziennika jest z natury złych, a nawet potencjalnie katastrofalnych, są ludzie, którzy bardziej dbają o integralność danych niż zwalnianie miejsca na dysku.
Wpis na blogu, który napisałem w 2009 roku, kiedy zobaczyłem kilka postów „oto jak zmniejszyć plik dziennika”.
Wpis na blogu, który Brent Ozar napisał cztery lata temu, wskazując na wiele zasobów w odpowiedzi na artykuł w magazynie SQL Server, który nie zostały opublikowane.
Wpis na blogu autorstwa Paula Randala wyjaśniający, dlaczego utrzymanie t-logów jest ważne i dlaczego nie należy również zmniejszać plików danych.
Mike Walsh ma świetną odpowiedź, która obejmuje również niektóre z tych aspektów, w tym powody, dla których możesz nie być w stanie natychmiast zmniejszyć pliku dziennika.
