Ręcznie ustaw rozmiar pliku dziennika po zmniejszeniu SQL Server 2008 R2

Staję się w pewnym momencie mimowolnym DBA w pracy i naprawdę potrzebuję pomocy w czymś.

Mamy 40 GB bazy danych w trybie pełnego odzyskiwania, nie skonfigurowano kopii zapasowej dziennika i ogromny plik dziennika o wielkości 84 GB. Do tej pory planowałem uratować tę sytuację, aby uruchomić pełną kopię zapasową dziennika w bazie danych, zmniejszyć plik dziennika i zainicjować plan konserwacji, aby co noc uruchamiać tworzenie kopii zapasowej dziennika z kopią zapasową bazy danych, aby pomóc zachować kontrolę.

Mój problem polega na tym, że nie chcę, aby plik dziennika zmniejszał się do zera i spędziłem pierwszy poranek w poniedziałek stale rosnąc. Mam przybliżoną ocenę tego, jaki powinien być plik (około 20% bazy danych) i chciałbym ustawić to od samego początku, aby zapewnić jak najwięcej ciągłej przestrzeni. Czy to tylko przypadek zmiany „Rozmiar początkowy” w Właściwości bazy danych -> Pliki? Zgaduję również, że baza danych musiałaby być offline, aby tak się stało?

Z góry dziękuję

Po prostu zmniejsz się do optymalnego rozmiaru. Nie używaj interfejsu użytkownika, po prostu zrób to - powiedzmy, że 200 MB to Twój optymalny rozmiar:

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

Jeśli chcesz wykonać kopię zapasową dziennika tylko raz dziennie i nie jesteś zainteresowany odzyskiwaniem w określonym momencie, powinieneś przejść na prosty model odzyskiwania. Oznacza to, że kopie zapasowe dziennika są niepotrzebne (w rzeczywistości niemożliwe), ale zawartość dziennika będzie zarządzać samodzielnie.

Jeśli chcesz, aby kopie zapasowe dziennika były znaczące, nie planuj wykonywania pełnej kopii zapasowej w nocy, a następnie pojedynczej kopii zapasowej dziennika zaraz po. Utrzymuje to pełny model odzyskiwania, sprawia, że ​​dziennik działa naprawdę ciężko i niczego nie kupuje. Jeśli chcesz odzyskać dane w określonym momencie, częściej wykonuj kopie zapasowe dziennika z szybkością, która spełnia wymagania dotyczące tolerancji utraty danych. Jeśli nigdy nie chcesz stracić więcej niż 15 minut danych, uruchom kopię zapasową dziennika co 15 minut.

Twoje zarządzanie plikami może być operacją całkowicie online. Istnieją dwie ścieżki, w zależności od potrzeby zachowania informacji dziennika w celu odzyskania:

Odzyskiwanie punktu w czasie nie jest konieczne

1. Konwertuj bazę danych do SIMPLEodzyskiwania. Wykonaj punkt kontrolny, aby zapisać transakcje na dysku.
2. Spłaszcz dziennik.
3. Zmień rozmiar dziennika do odpowiedniego rozmiaru.

Polecam również ustawienie stałej kwoty wzrostu i nieograniczonego wzrostu (aby lepiej zarządzać logiem). Uwaga: ustalona kwota wzrostu jest bardzo zależna od kwoty, zalecam początkowo korzystanie z 1–2 GB, w zależności od tego, jaki wzrost może się spodziewać w dzienniku. Idealnie byłoby, gdyby Twój dziennik nie urósł zbytnio, więc nie powinno to mieć większego wpływu. Jeśli Twój dziennik regularnie rośnie, może być konieczne ponowne sprawdzenie rozmiaru.

Zrealizowane przy użyciu:

ALTER DATABASE [foo] 
SET RECOVERY SIMPLE;

CHECKPOINT;

DBCC SHRINKFILE (foo_log,0);

ALTER DATABASE [foo]
MODIFY FILE (NAME=foo_log,SIZE=8000MB,MAXSIZE=UNLIMITED,FILEGROWTH=1000MB);

--Optional if you want the database in full recovery mode 
--for point in time recovery going forward
ALTER DATABASE [foo] 
SET RECOVERY FULL;

Potrzebne jest odzyskanie punktu w czasie

Największe zawieszenie polega na tym, że nie można zmniejszyć pliku dziennika poza aktualnie aktywny segment VLF. Aby to zobaczyć, możesz użyć DBCC LOGINFOw kontekście bazy danych. Każdy segment o statusie = 2 jest aktywny. Aby wyczyścić aktywne segmenty, konieczne będzie uruchomienie kopii zapasowej dziennika transakcji, gdy żadne transakcje nie są aktualnie aktywne w tym segmencie. Twoje kroki to:

1. Uruchom kopię zapasową dziennika transakcji.
2. Zmniejsz swój plik. (Najlepiej spłaszczyć, ale jeśli baza danych jest aktywna, będzie to trudne).
3. Powtarzaj kroki 1 i 2, aż dziennik osiągnie odpowiedni rozmiar, najlepiej możliwie jak najmniejszy.
4. Zmień rozmiar dziennika do odpowiedniego rozmiaru.

Zrealizowane przy użyciu:

BACKUP LOG [foo] TO DISK='<Location of t-log backup>';

DBCC SHRINKFILE (foo_log,0);

--Repeat the above until your log file is small "enough"

ALTER DATABASE [foo]
MODIFY FILE (NAME=foo_log,SIZE=8000MB,MAXSIZE=UNLIMITED,FILEGROWTH=1000MB);

Kilka dodatkowych zasobów, aby zrozumieć, co się tutaj dzieje:

• Modele odzyskiwania programu SQL Server

• Zalecenia t-log Kimberly Tripp

• Punkty kontrolne bazy danych

Właściwie nie, baza danych nie musi być offline, aby zmniejszyć dziennik. Powiem, że jest to prawdopodobnie jeden z niewielu przypadków, w których zmniejszanie kłody jest dobrym pomysłem. Możesz ustawić początkowy rozmiar, ale łatwiej byłoby zmniejszyć i powiedzieć, aby zmniejszył się do określonego rozmiaru.

USE [DBName]
GO
DBCC SHRINKFILE (N'LogName' , SizeInMg)
GO

Możesz to również zrobić za pomocą GUI i drugiego przycisku opcji i pola wyboru, które mówi, jak duży ma być koniec dziennika. Możesz przejść do GUI, klikając prawym przyciskiem myszy bazę danych w eksploratorze obiektów w SSMS, wybierając zadania, zmniejsz, pliki.

W uzupełnieniu odpowiedzi Aarona na temat trybu prostego można zaplanować 2 (lub więcej) różnicowych kopii zapasowych dziennie, zmniejszając w ten sposób okno utraty danych operacji bazy danych, zachowując tryb PROSTY.