DISCLAIMER: przeczytaj uważnie poniższe komentarze i zakładam, że przeczytałeś już zaakceptowaną odpowiedź. Jak mówiłem prawie 5 lat temu:

Jeśli ktoś ma jakieś uwagi do dodania w sytuacjach, gdy nie jest to odpowiednie lub optymalne rozwiązanie, prosimy o komentarz poniżej

• Kliknij prawym przyciskiem myszy nazwę bazy danych.

• Wybierz Zadania → Zmniejsz → Baza Danych

• Następnie kliknij OK !

I zazwyczaj otwieram katalog Eksploratora Windows zawierający pliki bazy danych, więc od razu widzę efekt.

byłem zaskoczony, że to działa! Zwykle używałem DBCC wcześniej, ale po prostu próbowałem i nic nie kurczyło, więc próbowałem GUI (2005) i działało świetnie - uwolnienie 17 GB w 10 sekund

W trybie pełnego odzyskiwania może to nie działać, więc najpierw musisz wykonać kopię zapasową dziennika lub zmienić na proste odzyskiwanie, a następnie zmniejszyć plik. [thanks @onupdatecascade for this]

--

PS: doceniam to, co niektórzy skomentowali na temat niebezpieczeństw z tym związanych, ale w moim środowisku nie miałem żadnych problemów robiąc to sam, zwłaszcza, że zawsze robię pełną kopię zapasową najpierw. Zanim przejdziesz dalej, weź pod uwagę środowisko i wpływ na strategię tworzenia kopii zapasowych i bezpieczeństwo pracy. Wszystko, co robiłem, to wskazywanie ludziom funkcji dostarczonej przez Microsoft!

USE AdventureWorks2008R2;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE AdventureWorks2008R2
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (AdventureWorks2008R2_Log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE AdventureWorks2008R2
SET RECOVERY FULL;
GO

Od: DBCC SHRINKFILE (Transact-SQL)

Możesz najpierw wykonać kopię zapasową.

Poniżej znajduje się skrypt do zmniejszania dziennika transakcji, ale zdecydowanie polecam utworzenie kopii zapasowej dziennika transakcji przed zmniejszeniem go.

Jeśli zmniejszysz plik, stracisz mnóstwo danych, które mogą uratować życie w przypadku katastrofy. Dziennik transakcji zawiera wiele przydatnych danych, które można odczytać za pomocą zewnętrznego czytnika dziennika transakcji (można je odczytać ręcznie, ale przy dużym wysiłku).

Dziennik transakcji jest również koniecznością, jeśli chodzi o punkt w czasie odzyskiwania, więc nie tylko wyrzucić go, ale upewnij się, że kopię zapasową go wcześniej.

Oto kilka postów, w których ludzie używali danych przechowywanych w dzienniku transakcji do odzyskiwania:

• Jak wyświetlić logi transakcji w SQL Server 2008

• odczyt pliku dziennika (*.LDF) w SQL Server 2008

USE DATABASE_NAME;
GO

ALTER DATABASE DATABASE_NAME
SET RECOVERY SIMPLE;
GO
--First parameter is log file name and second is size in MB
DBCC SHRINKFILE (DATABASE_NAME_Log, 1);

ALTER DATABASE DATABASE_NAME
SET RECOVERY FULL;
GO

Możesz uzyskać błąd, który wygląda tak, gdy wykonujesz polecenia powyżej

"nie można zmniejszyć pliku dziennika (nazwy pliku dziennika), ponieważ logiczne plik dziennika znajdujący się na końcu pliku jest w użyciu "

Oznacza to, że TLOG jest w użyciu. W takim przypadku spróbuj wykonać to kilka razy pod rząd lub znajdź sposób na zmniejszenie aktywności w bazie danych.

Jeśli nie używasz logów transakcji do przywracania (tzn. robisz tylko pełne kopie zapasowe), możesz ustawić tryb odzyskiwania na "prosty", a dziennik transakcji wkrótce się zmniejszy i nigdy więcej się nie wypełni.

Jeśli używasz SQL 7 lub 2000, możesz włączyć "obcinaj log na checkpoincie" w zakładce Opcje bazy danych. To ma ten sam efekt.

Nie jest to oczywiście zalecane w środowiskach produkcyjnych, ponieważ nie będzie można przywrócić do pewnego punktu w czasie.

Oto prosty i bardzo nieelegancki & potencjalnie niebezpieczny sposób.

1. Backup DB
2. Detach DB
3. Zmień nazwę pliku dziennika
4. Dołącz DB
5. zostanie odtworzony nowy plik dziennika
6. Usuń przemianowany plik dziennika.

Zgaduję, że nie robisz kopii zapasowych logów. (Które obcinają dziennik). Moja rada to zmiana modelu odzyskiwania z pełnego na prostego . Zapobiegnie to wzdęciom kłody.

Jak dotąd większość odpowiedzi zakłada, że nie potrzebujesz pliku dziennika transakcji, jednak jeśli twoja baza danych korzysta z modelu odzyskiwania FULL i chcesz zachować kopie zapasowe na wypadek konieczności przywrócenia bazy danych, to nie należy okracać lub usuwać pliku dziennika w sposób sugerowany przez wiele z tych odpowiedzi.

Usunięcie pliku dziennika (poprzez jego obcinanie, odrzucanie, kasowanie itp.) spowoduje przerwanie łańcucha kopii zapasowej i uniemożliwi przywrócenie do dowolnego punktu w czas od ostatniej pełnej, różnicowej lub transakcji kopii zapasowej dziennika, aż do następnej pełnej lub różnicowej kopii zapasowej.

Z artykułu Microsoft naBACKUP

Zalecamy, aby nigdy nie używać NO_LOG ani TRUNCATE_ONLY do ręcznego obcinanie dziennika transakcji, ponieważ powoduje to przerwanie łańcucha dziennika. Do następny pełny lub różnicowy backup bazy danych, Baza Danych nie jest zabezpieczony przed awarią mediów. Używaj ręcznego obcinania logów tylko w bardzo specjalne okoliczności i natychmiast tworzyć kopie zapasowe danych.

Aby tego uniknąć, wykonaj kopię zapasową pliku dziennika na dysk przed zmniejszeniem go. Składnia wyglądałaby mniej więcej tak:

BACKUP LOG MyDatabaseName 
TO DISK='C:\DatabaseBackups\MyDatabaseName_backup_2013_01_31_095212_8797154.trn'

DBCC SHRINKFILE (N'MyDatabaseName_Log', 200)

Dziennik transakcji SQL Server musi być odpowiednio utrzymywany, aby zapobiec jego niepożądanemu wzrostowi. Oznacza to uruchamianie kopii zapasowych dziennika transakcji wystarczająco często. Nie robiąc tego, ryzykujesz, że dziennik transakcji stanie się pełny i zacznie rosnąć.

Oprócz odpowiedzi na to pytanie polecam lekturę i zrozumienie dziennika transakcji common mitów. Odczyty te mogą pomóc zrozumieć dziennik transakcji i zdecydować, jakich technik użyć, aby go" wyczyścić": {]}

Od 10 najważniejsze mity dziennika transakcji SQL Server:

Mit: mój serwer SQL jest zbyt zajęty. Nie chcę tworzyć kopii zapasowych dziennika transakcji SQL Server

Jedną z największych intensywnych operacji w SQL Server jest Zdarzenie auto-grow pliku dziennika transakcji online. Nie wykonując wystarczająco często kopii zapasowych dzienników transakcji, dziennik transakcji online stanie się pełny i będzie musiał się rozrastać. Domyślny rozmiar wzrostu to 10%. Im bardziej ruchliwa jest baza danych, im szybciej dziennik transakcji online będzie rosnąć, jeśli nie zostaną utworzone kopie zapasowe dziennika transakcji Tworzenie kopii zapasowej dziennika transakcji SQL Server nie blokuje dziennika transakcji online, ale ma miejsce zdarzenie automatycznego wzrostu. Może zablokować całą aktywność w dzienniku transakcji online

Od mity z dziennika transakcji:

Mit: regularne kurczenie się logów to dobra praktyka konserwacji

FALSE. Wzrost logów jest bardzo drogi, ponieważ nowy kawałek musi zostać wyzerowany. Cała aktywność zapisu zatrzymuje się w tej bazie danych, dopóki zerowanie nie zostanie zakończone, a jeśli zapis na dysku jest powolny lub rozmiar automatycznego wzrostu jest duży, ta pauza może być ogromna i użytkownicy zauważą. To jeden z powodów, dla których chcesz uniknąć wzrostu. Jeśli zmniejszysz dziennik, będzie on ponownie rosnąć i po prostu marnujesz działanie dysku na niepotrzebną grę shrink-and-grow-again

Ta technika, którą zaleca John, nie jest zalecana, ponieważ nie ma gwarancji, że baza danych zostanie dołączona bez pliku dziennika. ZMIEŃ bazę danych z pełnej na prostą, Wymuś punkt kontrolny i odczekaj kilka minut. Serwer SQL wyczyści dziennik, który można następnie zmniejszyć za pomocą pliku DBCC SHRINKFILE.

Najpierw sprawdź model odzyskiwania bazy danych. Domyślnie SQL Server Express Edition tworzy bazę danych do prostego odzyskiwania model (o ile się nie mylę).

Backup Log DatabaseName With Truncate_Only:

DBCC ShrinkFile(yourLogical_LogFileName, 50)

SP_helpfile wyświetli nazwę pliku logu.

Zobacz:

odzyskiwanie z pełnego dziennika transakcji w bazie danych SQL Server

Jeśli twoja baza danych jest w pełnym modelu odzyskiwania i jeśli nie wykonujesz kopii zapasowej TL, to zmień to na proste.

Użyj polecenia DBCC ShrinkFile ({logicalLogName}, TRUNCATEONLY). Jeśli jest to testowa baza danych i próbujesz zaoszczędzić / odzyskać miejsce, pomoże to.

Pamiętaj jednak, że dzienniki TX mają rodzaj minimalnego / ustalonego rozmiaru, do którego dorosną. W zależności od modelu odzyskiwania możesz nie być w stanie zmniejszyć dziennika - jeśli w całości i nie wystawiasz kopii zapasowych dziennika TX dziennik nie może być zmniejszony - będzie rosnąć na zawsze. Jeśli nie potrzebujesz kopii zapasowych dzienników TX, Zmień model odzyskiwania na Simple .

Oraz pamiętaj, nigdy pod żadnym pozorem nie usuwaj pliku dziennika (LDF)! Będziesz miał prawie natychmiastowe uszkodzenie bazy danych. Gotowane! Zrobione! Utracone dane! Jeśli pozostawiony "nienaprawiony" główny plik MDF może zostać trwale uszkodzony.

Nigdy nie usuwaj dziennika transakcji-stracisz dane! Część danych znajduje się w Dzienniku TX (niezależnie od modelu odzyskiwania)... jeśli odłączysz i" zmienisz nazwę " pliku dziennika TX, który skutecznie usunie część bazy danych.

Dla tych, którzy mają usunięto Dziennik TX możesz chcieć uruchomić kilka poleceń checkdb i naprawić uszkodzenie, zanim stracisz więcej danych.

Sprawdź posty na blogu Paula Randala na ten temat, złe rady.

Również ogólnie nie używaj shrinkfile na plikach MDF, ponieważ może poważnie fragmentować dane. Sprawdź jego sekcję złe Porady, aby uzyskać więcej informacji ("dlaczego nie powinieneś zmniejszać plików danych")

Aby obciąć plik dziennika:

• Kopia zapasowa bazy danych
• odłącz bazę danych, używając Enterprise Manager lub wykonując : Sp_DetachDB [DBName]
• Usuń plik dziennika transakcji. (lub zmień nazwę pliku, na wszelki wypadek)
• ponownie załącz bazę danych używając: Sp_AttachDB [DBName]
• Po dołączeniu bazy danych tworzony jest nowy plik dziennika transakcji.

Aby zmniejszyć dziennik plik:

• Backup log [DBName] with No_Log

• Zmniejsz bazę danych o:

  Korzystanie z Enterprise manager :- Kliknij prawym przyciskiem myszy na bazie danych, wszystkie zadania, zmniejsz bazę danych, pliki, wybierz plik dziennika, OK.

  Używanie T-SQL :- Dbcc Shrinkfile ([Log_Logical_Name])

Logiczną nazwę pliku dziennika można znaleźć, uruchamiając sp_helpdb lub przeglądając właściwości bazy danych w Enterprise Manager.

Z mojego doświadczenia na większości serwerów SQL nie ma kopii zapasowej dziennika transakcji. Pełne kopie zapasowe lub kopie różnicowe są powszechną praktyką, ale kopie zapasowe dziennika transakcji są naprawdę rzadkie. Tak więc plik dziennika transakcji rośnie w nieskończoność(do momentu zapełnienia dysku). W tym przypadku model odzyskiwania powinien być ustawiony na " simple ". Nie zapomnij też zmodyfikować systemowych baz danych "model" i "tempdb".

Kopia zapasowa bazy danych "tempdb" nie ma sensu, więc model odzyskiwania ten db powinien być zawsze "prosty".

1. Zrób kopię zapasową pliku MDB.
2. Stop SQL services
3. Zmień nazwę pliku dziennika
4. Uruchom serwis

(system utworzy nowy plik dziennika.)

Usuń lub przenieś zmieniony plik dziennika.

Spróbuj tego:

USE DatabaseName

GO

DBCC SHRINKFILE( TransactionLogName, 1)

BACKUP LOG DatabaseName WITH TRUNCATE_ONLY

DBCC SHRINKFILE( TransactionLogName, 1)

GO 

Baza danych → kliknij prawym przyciskiem myszy Właściwości → Plik → Dodaj inny plik dziennika o innej nazwie i ustaw ścieżkę tak samo jak stary plik dziennika o innej nazwie.

Baza danych automatycznie pobiera nowo utworzony plik dziennika.

1. Backup DB
2. Detach DB
3. Zmień nazwę pliku dziennika
4. Załącz DB (podczas załączenia Usuń nazwę .ldf (plik dziennika).Wybierz go i usuń, naciskając przycisk Usuń)
5. zostanie odtworzony nowy plik dziennika
6. Usuń przemianowany plik dziennika.

To zadziała, ale zaleca się najpierw wykonanie kopii zapasowej bazy danych.

Przykład:

DBCC SQLPERF(LOGSPACE)

BACKUP LOG Comapny WITH TRUNCATE_ONLY

DBCC SHRINKFILE (Company_log, 500)

DBCC SQLPERF(LOGSPACE)

Zdarzyło się to u mnie, Gdzie plik dziennika bazy danych miał 28 GBs.

Co można zrobić, aby to zmniejszyć? W rzeczywistości pliki dziennika to te dane plików, które serwer SQL Przechowuje, gdy miała miejsce transakcja. Dla transakcji do przetworzenia SQL server przydziela strony dla tego samego. Ale po zakończeniu transakcji, nie są one zwolnione nagle nadzieję, że nie może być transakcja zbliża się jak ta sama. To trzyma przestrzeń.

Krok 1: Najpierw uruchom to polecenie w zapytaniu bazy danych checkpoint

Krok 2: Kliknij prawym przyciskiem myszy na bazie danych Zadanie> Back up Wybierz typ kopii zapasowej jako dziennik transakcji Dodaj adres docelowy i nazwę pliku, aby zachować dane kopii zapasowej (.bak)

Powtórz ten krok jeszcze raz i w tym czasie nadaj inną nazwę pliku

Krok 3: Teraz przejdź do bazy danych Kliknij prawym przyciskiem myszy na bazie danych

Tasks> Shrinks> Files Wybierz typ pliku jako dziennik Shrink action as release unused spacja

Krok 4:

Sprawdź swój plik dziennika zwykle w SQL 2014 można to znaleźć w

C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQL2014EXPRESS\MSSQL \ DATA

W moim przypadku jego zmniejszenie z 28 GB do 1 MB

DB Transaction Log Shrink to min size :

1. Kopia zapasowa: dziennik transakcji
2. Shrink files: Transaction log
3. Kopia zapasowa: dziennik transakcji
4. Shrink files: Transaction log

Wykonałem testy na kilku liczbach DBs: ta sekwencja działa .

Zwykle kurczy się do 2MB .

Lub skryptem:

DECLARE @DB_Name nvarchar(255);
DECLARE @DB_LogFileName nvarchar(255);
SET @DB_Name = '<Database Name>';               --Input Variable
SET @DB_LogFileName = '<LogFileEntryName>';         --Input Variable
EXEC 
(
'USE ['+@DB_Name+']; '+
'BACKUP LOG ['+@DB_Name+'] WITH TRUNCATE_ONLY ' +
'DBCC SHRINKFILE( '''+@DB_LogFileName+''', 2) ' +
'BACKUP LOG ['+@DB_Name+'] WITH TRUNCATE_ONLY ' +
'DBCC SHRINKFILE( '''+@DB_LogFileName+''', 2)'
)
GO