Gdy baza danych SQL Server jest w trybie SIMPLE, nie musisz przejmować się bakcupami dziennika transakcji. Ale w trybie PROSTYM dziennik transakcji wydaje się powiększać, podobnie jak w trybie PEŁNYM. Czy w pewnym momencie jest obcinany automatycznie? Czy też muszę go obcinać / zmniejszać ręcznie?
Odpowiedzi:
Zostanie obcięty automatycznie, ale różni się znacznie od kurczenia. Obcinanie odzyskuje przestrzeń dziennika do ponownego użycia, zmniejszając fizycznie zmniejsza rozmiar pliku, aby zwolnić miejsce z powrotem do systemu operacyjnego. Jeśli Twój dziennik urósł do obecnego rozmiaru, prawdopodobnie wzrośnie on ponownie, jeśli go zmniejszysz.
Sugeruję zapoznanie się z typowym i maksymalnym wykorzystaniem dzienników dla twojego systemu. Poniższe zapytanie (nie moje, wzmocnione skryptami Glen Berrys DMV) można uruchomić ręcznie lub przechwycić dane wyjściowe do tabeli za pomocą zadania agenta. Jeśli zalogujesz się do stołu przez około tydzień, otrzymasz obraz typowego użycia i, co ważniejsze, gdy proces powoduje, że dziennik rośnie ponad to, czego oczekujesz.
SELECT
db.[name] AS [Database Name]
, db.recovery_model_desc AS [Recovery Model]
, db.log_reuse_wait_desc AS [Log Reuse Wait Description]
, ls.cntr_value AS [Log Size (KB)]
, lu.cntr_value AS [Log Used (KB)]
, CAST(
CAST(lu.cntr_value AS FLOAT) / CAST(ls.cntr_value AS FLOAT)
AS DECIMAL(18,2)
) * 100 AS [Log Used %]
, db.[compatibility_level] AS [DB Compatibility Level]
, db.page_verify_option_desc AS [Page Verify Option]
, db.is_auto_create_stats_on, db.is_auto_update_stats_on
, db.is_auto_update_stats_async_on, db.is_parameterization_forced
, db.snapshot_isolation_state_desc, db.is_read_committed_snapshot_on
FROM sys.databases AS db
INNER JOIN sys.dm_os_performance_counters AS lu
ON db.name = lu.instance_name
INNER JOIN sys.dm_os_performance_counters AS ls
ON db.name = ls.instance_name
WHERE lu.counter_name LIKE N'Log File(s) Used Size (KB)%'
AND ls.counter_name LIKE N'Log File(s) Size (KB)%'
AND ls.cntr_value > 0
OPTION (RECOMPILE);
Transaction Log Truncation opisuje zarówno kiedy, jak i dlaczego występuje obcinanie dziennika.
Jeśli rekordy dziennika nigdy nie zostaną usunięte z dziennika transakcji, ostatecznie zapełni całe miejsce na dysku dostępne dla fizycznych plików dziennika. Obcinanie dziennika automatycznie zwalnia miejsce w dzienniku logicznym do ponownego wykorzystania przez dziennik transakcji.
Czynniki, które mogą opóźnić Obcinanie dziennika jest przydatnym źródłem informacji, które pozwala zrozumieć, dlaczego dziennik może nie zostać obcięty, a zatem może być większy niż oczekiwano.
Jak wspomniano wcześniej, nie, nie automatycznie się skurczy. Oczyści jednak trochę śmieci.
Powodem jest to, że w modelu pełnego odzyskiwania mówisz SQLowi, że chcesz wykonywać kopie zapasowe tlogu w celu odzyskania punktu w czasie, dzięki czemu rejestruje wszystkie transakcje wykonane na bazie danych.
Ponieważ mówisz, że chcesz odzyskać w czasie, musisz wykonać pełne kopie zapasowe i kopie zapasowe tlog. Po zakończeniu tworzenia kopii zapasowych tlog opróżni zawartość loga (oprócz końca) i zacznie od nowa.
Może to pomóc, jeśli uważasz te pliki za kontenery.
Moja sugestia jest taka, że jeśli blogi stały się duże i niemożliwe do zarządzania, wytnij pełną kopię zapasową. Przejdź do modelu odzyskiwania SIMPLE i SHRINK plik tlog. Wróć do pełnego modelu odzyskiwania i przeprowadź konserwację fragmentacji *. Jak napisali inni, nie jest to najlepsza praktyka i doprowadzi do wysokiego stopnia rozdrobnienia.
Następnie zaplanuj i rozpocznij system tworzenia kopii zapasowych.
* Indeks odbudowuje / reorganizuje operacje i defragmentację na poziomie dysku . Nie jest to część konserwacji dzienników: Utrzymujesz swoje dzienniki T, wykonując ich kopię zapasową. Są to pojemniki, które rosną, gdy zbliżają się do pojemności. Przebudowa / reorganizacja może pomóc w odzyskaniu danych po niewłaściwym zarządzaniu dziennikiem, co prowadzi do dużego zużycia dysku.