Dysk z logiem pełny. Logi pełne. Pliki loga posadowione już na dwóch dyskach. Trzeba zwolnić trochę miejsca
Zaczynasz od
select name, log_reuse_wait_desc from sys.databasesDruga kolumna zwraca informację o tym, co powoduje przepełnienie loga. W moim przypadku było dość standardowo LOG_BACKUP. Oznacza to, że w pierwszej kolejności należy zwolnić miejsce przez wykonanie bakupu loga. Jest to konieczne, gdy baza pracuje w recovery modelu full, a na systemach produkcyjnych tak jest najczęściej.
Po backupie loga, widać już, że w logu jest sporo wolnego miejsca:
USE db_name dbcc SQLperf(logspace) No to można shrinkować plik loga: USE db_nameGO
DBCC SHRINKFILE (N’LogFileName’ , 10240)
GO
A tu niespodzianke. Log się nie skurczył a jeszcze pojawia się komunikat:
Cannot shrink log file <…> because the logical log file located at the end of the file is in use.Porady na forach zazwyczaj zalecają przełączenie bazy w recovery model simple, co wyrzuci z loga niebackupowane transakcje i zupełnie przebuduje jego strukturę, a potem powrót do modelu full. Ale to raczej nie tędy droga. System jest produkcyjny i nie należy przełączać modelu na simple, a na dodatek w moim przypadku… baza pracowała w mirroringu.
Wczytaj się w komunikat. Shrinkować nie można, bo aktywna część loga jest na końcu pliku… Więc może przesuniemy ten „logical log file”. To proste. Wygeneruj po prostu kilka pustych „dummy” transakcji:
create table tabtodelete(id int identity primary key,
x char(10))
GO –100-krotny insert
insert tabtodelete values(’x’)
GO 100 drop table tabtodelete
I gotowe! Teraz shrink zadziałał od razu!
