Log bazy sello ma 12 GB

[Lukasz team 9]

Witam,

 

Posiadam bazę SQL o wielkości 6850 mb. Przed aktualizacją do 1.27 log zajmował 50-100 MB, po aktualizacji zajmuje 11725 mb.

Co mogę zrobić by pozbyć się tak dużego logu ? 

Czy wersja 1.27 posiada jakiś błąd który to spowodował?

 

 

[Bartosz Rosa 1 774]

Log transakcyjny rośnie w momencie wykonywania operacji na bazie. Jeśli były usuwane jakieś dane, to każda usunięta dana ląduje w logu - jest to mechanizm serwera SQL zapobiegający uszkodzeniu danych, możliwości ich odtworzenia itd. Zazwyczaj po wykonaniu backupu jest on zmniejszany, gdyż dane te nie są już potrzebne z okazji wykonania backupu danych.

Proszę wykonać kopię zapasową (archiwizację), jeśli to nie pomoże, to w programie serwisowym można użyć opcji Kompaktowania bazy, która robi w zasadzie polecenie:

DBCC SHRINKDATABASE('nazwa_bazy_danych')

 

[Lukasz team 9]

Backupy mamy wykonywane automatycznie 2 x dziennie przez SQLMS :

BACKUP DATABASE [sello_s] TO  DISK = @FileName  WITH FORMAT, INIT,  NAME = @BackupName, SKIP, NOREWIND, NOUNLOAD, STATS = 10
GO

 

Wykonałem archiwizację przez Sello, następnie shrink przez SQLMS - po tych zabiegach log wzrósł do 12908 MB.

[Bartosz Rosa 1 774]

W Management Studio proszę sprawdzić pod prawym klawiszem > Tasks > Shrink > Files i tam zobaczyć ile serwer pokazuje miejsca do zwolnienia w przypadku logu. Można również w razie potrzeby wykonać shrinka z tego miejsca.

[Lukasz team 9]

Shrinka wykonałem z Managemen Studio 

1 godzinę temu, Lukasz team napisał:

Wykonałem archiwizację przez Sello, następnie shrink przez SQLMS - po tych zabiegach log wzrósł do 12908 MB.

 

Obecnie Management Studio pokazuje dla File type: Log

 

Currently allocated space: 12908,00 MB

Avaitable free space 1095,05 MB (8%)

 

 

Mogę zmigrować log do innego pliku, ale to nie rozwiąże problemu tworzenia się loga o gigantycznej objętości.  

Log "rozrósł się" w momencie podniesienia wersji bazy danych z 1.26.0 na 1.27.0 

[Bartosz Rosa 1 774]

Tutaj znalazłem kilka podpowiedzi odnośnie problemu ze zmniejszaniem logu: https://stackoverflow.com/questions/779153/why-cant-i-shrink-a-transaction-log-file-even-after-backup

Pomóc z tłumaczeniem?

[Lukasz team 9]

Dziękuje - wskazówki ze wskazanego w linku forum pomogły

 

Wykonałem backup LOGu, póżniej shrink logu po tym okazało się że Avaitable free space wzrosło do 79 %, powtórzyłem backup LOGu , jeszcze raz shrink - i tak 4 krotnie - końcowo LOG zajmuje 4 MB.

 

 

[Lukasz team 9]

Odświeżę temat - problem narasta, nie potrafię znależć przyczyny. Zmieniłem kilka komponentów w serwerze - między innymi dysk na 1 TB NVME (liczyłem na chociaż drobny przyrost wydajności - dalej jest mocno licho). Od 72 dni nie był robiony backup przez sello - jedynie przez polecenie MSSQL - plik LOGu ma 450 GB . Shrink logu powiększa go - każdorazowa operacja shrink to poprzednia zajętość logu + rozmiar bazy danych . Pomaga jedynie backup logu ( który przy logu trwającym 450 GB i bardzo szybkich dyskach i tak trwa wieczność). Chciałbym wyeliminować na stałe przyczynę . Wygląda to tak, że przy każdorazowym backupie bazy ( FULL) całość bazy trafia do pliku logu i nigdy z tamtąd nie znika.

[Bartosz Rosa 1 774]

Na wielkość pliku log ma wpływ między innymi ustawienie RECOVERY  MODEL.

Najczęściej stosowane są typy Simple oraz Full. Tryb Simple przechowuje w logu tylko bieżące transakcje bazodanowe (zmiany w bazie), tryb full przechowuje całą historię od ostatniego backupu. W takim wypadku należy pamiętać, aby wykonywać backup danych łącznie z logiem. Wykonanie jednak takiego backupu nie powoduje automatycznego zmniejszenia pliku log. Ilość wolnego miejsca w pliku log można sprawdzić np tym poleceniem:

SELECT (total_log_size_in_bytes - used_log_space_in_bytes)*1.0/1024/1024 AS [ilosc wolnego miejsca w pliku log MB]  
FROM sys.dm_db_log_space_usage;  

Jego zmniejszenie powinno w takiej sytuacji spowodować użycie funkcji shrink.

W bazach zakładanych przez nasze oprogramowanie na serwerach w wersji Express jest włączony tryb Simple - co oznacza, że w zasadzie przy uszkodzeniu pliku bazy jedyna możliwość odzyskania danych to przywrócenie bazy z backupu. Na serwerach pełnych, bazy zakładają się w trybie Full - można spróbować zmienić na Simple (najpierw wykonując backup).

[Lukasz team 9]

Używam serwera na linuxie w wersji Standard - nawet nie zauważyłem, że prawdopodobnie przy którymś z przywracań kopii przestawiłem tryb Recovery Model na Full. Zmieniłem na Simple - shrink loga zmniejszył go do 4 MB. Pozostawiam Recovery Model na Simple - przy automatycznym backupie 3x na dobę i serwerze z backupem bare-metal i zewnętrzną kopią zapasową raczej zachowam możliwie wysoki poziom bezpieczeństwa danych.