Ich bin kein SQL-Experte und werde jedes Mal daran erinnert, wenn ich etwas tun muss, das über die Grundlagen hinausgeht. Ich habe eine Testdatenbank, die nicht groß ist, aber das Transaktionsprotokoll ist es definitiv. Wie lösche ich das Transaktionsprotokoll?

Das Verkleinern einer Protokolldatei sollte wirklich für Szenarien reserviert werden, in denen unerwartetes Wachstum aufgetreten ist, von dem Sie nicht erwarten, dass es erneut auftritt. Wenn die Protokolldatei wieder auf die gleiche Größe anwächst, wird durch vorübergehendes Verkleinern nicht viel erreicht. Abhängig von den Wiederherstellungszielen Ihrer Datenbank sollten Sie diese Maßnahmen ergreifen.

Erstellen Sie zunächst eine vollständige Sicherung

Nehmen Sie niemals Änderungen an Ihrer Datenbank vor, ohne sicherzustellen, dass Sie sie wiederherstellen können, falls etwas schief geht.

Wenn Sie sich für die Wiederherstellung zu einem bestimmten Zeitpunkt interessieren

(Und mit der Wiederherstellung zu einem bestimmten Zeitpunkt ist es Ihnen wichtig, dass Sie alles andere als eine vollständige oder differenzielle Sicherung wiederherstellen können.)

Vermutlich befindet sich Ihre Datenbank im FULLWiederherstellungsmodus. Wenn nicht, stellen Sie sicher, dass es sich um Folgendes handelt:

ALTER DATABASE testdb SET RECOVERY FULL;

Selbst wenn Sie regelmäßig vollständige Sicherungen durchführen, wächst und wächst die Protokolldatei, bis Sie eine Protokollsicherung durchführen. Dies dient Ihrem Schutz, um nicht unnötig Speicherplatz zu verbrauchen. Sie sollten diese Protokollsicherungen entsprechend Ihren Wiederherstellungszielen ziemlich häufig durchführen. Wenn Sie beispielsweise eine Geschäftsregel haben, die besagt, dass Sie es sich leisten können, im Katastrophenfall nicht mehr als 15 Minuten Daten zu verlieren, sollten Sie einen Job haben, der das Protokoll alle 15 Minuten sichert. Hier ist ein Skript, das Dateinamen mit Zeitstempel basierend auf der aktuellen Zeit generiert (aber Sie können dies auch mit Wartungsplänen usw. tun, wählen Sie einfach keine der Verkleinerungsoptionen in Wartungsplänen aus, sie sind schrecklich).

DECLARE @path NVARCHAR(255) = N'\\backup_share\log\testdb_' 
  + CONVERT(CHAR(8), GETDATE(), 112) + '_'
  + REPLACE(CONVERT(CHAR(8), GETDATE(), 108),':','')
  + '.trn';

BACKUP LOG foo TO DISK = @path WITH INIT, COMPRESSION;

Beachten Sie, dass \\backup_share\sich dieser Computer auf einem anderen Computer befinden sollte, der ein anderes zugrunde liegendes Speichergerät darstellt. Das Sichern dieser Daten auf demselben Computer (oder auf einem anderen Computer, der dieselben zugrunde liegenden Festplatten verwendet, oder auf einer anderen VM, die sich auf demselben physischen Host befindet) hilft Ihnen nicht wirklich, da Sie Ihre Datenbank verloren haben, wenn der Computer in die Luft sprengt und seine Backups. Abhängig von Ihrer Netzwerkinfrastruktur ist es möglicherweise sinnvoller, lokal zu sichern und diese dann hinter den Kulissen an einen anderen Ort zu übertragen. In beiden Fällen möchten Sie sie so schnell wie möglich vom primären Datenbankcomputer entfernen.

Sobald Sie regelmäßige Protokollsicherungen ausgeführt haben, sollte es sinnvoll sein, die Protokolldatei auf einen vernünftigeren Wert zu verkleinern, als dies bisher der Fall war. Dies bedeutet nicht, dass SHRINKFILEdie Protokolldatei immer wieder ausgeführt wird, bis sie 1 MB groß ist. Selbst wenn Sie das Protokoll häufig sichern, muss die Summe aller gleichzeitig auftretenden Transaktionen berücksichtigt werden. Autogrow-Ereignisse für Protokolldateien sind teuer, da SQL Server die Dateien auf Null setzen muss (im Gegensatz zu Datendateien, wenn die sofortige Dateiinitialisierung aktiviert ist) und Benutzertransaktionen warten müssen, während dies geschieht. Sie möchten diese Grow-Shrink-Grow-Shrink-Routine so wenig wie möglich ausführen, und Sie möchten Ihre Benutzer auf keinen Fall dafür bezahlen lassen.

Beachten Sie, dass Sie das Protokoll möglicherweise zweimal sichern müssen, bevor ein Verkleinern möglich ist (danke Robert).

Sie müssen also eine praktische Größe für Ihre Protokolldatei festlegen. Niemand hier kann Ihnen sagen, was das ist, ohne viel mehr über Ihr System zu wissen, aber wenn Sie die Protokolldatei häufig verkleinert haben und sie wieder gewachsen ist, ist ein gutes Wasserzeichen wahrscheinlich 10-50% höher als das größte, das es war . Angenommen, das sind 200 MB, und Sie möchten, dass alle nachfolgenden Autogrowth-Ereignisse 50 MB betragen. Dann können Sie die Größe der Protokolldatei folgendermaßen anpassen:

USE [master];
GO
ALTER DATABASE Test1 
  MODIFY FILE
  (NAME = yourdb_log, SIZE = 200MB, FILEGROWTH = 50MB);
GO

Beachten Sie, dass Sie möglicherweise zuerst Folgendes ausführen müssen, wenn die Protokolldatei derzeit> 200 MB ist:

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

Wenn Sie sich nicht für die Wiederherstellung zu einem bestimmten Zeitpunkt interessieren

Wenn es sich um eine Testdatenbank handelt und Sie sich nicht für die Wiederherstellung zu einem bestimmten Zeitpunkt interessieren, sollten Sie sicherstellen, dass sich Ihre Datenbank im SIMPLEWiederherstellungsmodus befindet.

ALTER DATABASE testdb SET RECOVERY SIMPLE;

Wenn Sie die Datenbank in den SIMPLEWiederherstellungsmodus versetzen, wird sichergestellt, dass SQL Server Teile der Protokolldatei wiederverwendet (im Wesentlichen inaktive Transaktionen auslaufen lässt), anstatt zu wachsen, um alle Transaktionen aufzuzeichnen (wie dies bei der FULLWiederherstellung der Fall ist, bis Sie das Protokoll sichern). CHECKPOINTEreignisse helfen dabei, das Protokoll zu steuern und sicherzustellen, dass es nicht wachsen muss, es sei denn, Sie generieren eine Menge T-Log-Aktivitäten zwischen CHECKPOINTs.

Als nächstes sollten Sie unbedingt sicherstellen, dass dieses Protokollwachstum tatsächlich auf ein abnormales Ereignis (z. B. einen jährlichen Frühjahrsputz oder die Neuerstellung Ihrer größten Indizes) und nicht auf den normalen täglichen Gebrauch zurückzuführen ist. Was haben Sie gewonnen, wenn Sie die Protokolldatei auf eine lächerlich kleine Größe verkleinert haben und SQL Server sie nur erneut vergrößern muss, um Ihrer normalen Aktivität gerecht zu werden? Konnten Sie den Speicherplatz nutzen, den Sie nur vorübergehend freigegeben haben? Wenn Sie eine sofortige Lösung benötigen, können Sie Folgendes ausführen:

USE yourdb;
GO
CHECKPOINT;
GO
CHECKPOINT; -- run twice to ensure file wrap-around
GO
DBCC SHRINKFILE(yourdb_log, 200); -- unit is set in MBs
GO

Andernfalls stellen Sie eine geeignete Größe und Wachstumsrate ein. Gemäß dem Beispiel im Fall der Wiederherstellung zu einem bestimmten Zeitpunkt können Sie denselben Code und dieselbe Logik verwenden, um die geeignete Dateigröße zu bestimmen und angemessene Parameter für das automatische Wachstum festzulegen.

Einige Dinge, die Sie nicht tun möchten

• Sichern Sie das Protokoll mit TRUNCATE_ONLYOption und dannSHRINKFILE . Zum einen ist diese TRUNCATE_ONLYOption veraltet und in aktuellen Versionen von SQL Server nicht mehr verfügbar. Zweitens, wenn Sie sich im FULLWiederherstellungsmodell befinden, wird Ihre Protokollkette zerstört und eine neue, vollständige Sicherung erforderlich.

• Trennen Sie die Datenbank, löschen Sie die Protokolldatei und hängen Sie sie erneut an . Ich kann nicht betonen, wie gefährlich das sein kann. Ihre Datenbank wird möglicherweise nicht wiederhergestellt, sie wird möglicherweise als verdächtig angezeigt, Sie müssen möglicherweise auf eine Sicherung zurückgreifen (falls vorhanden) usw. usw.

• Verwenden Sie die Option "Datenbank verkleinern" . DBCC SHRINKDATABASEund die Wartungsplanoption, um dasselbe zu tun, sind schlechte Ideen, insbesondere wenn Sie wirklich nur ein Protokollproblem lösen müssen. Richten Sie die Datei, die Sie anpassen möchten, gezielt aus und passen Sie sie mithilfe von DBCC SHRINKFILEoder ALTER DATABASE ... MODIFY FILE(Beispiele oben) unabhängig an .

• Verkleinern Sie die Protokolldatei auf 1 MB . Das sieht verlockend aus, denn mit SQL Server kann ich es in bestimmten Szenarien tun und mir den gesamten freien Speicherplatz ansehen! Wenn Ihre Datenbank nicht schreibgeschützt ist (und Sie sollten sie als solche markieren ALTER DATABASE), führt dies absolut nur zu vielen unnötigen Wachstumsereignissen, da das Protokoll aktuelle Transaktionen unabhängig vom Wiederherstellungsmodell berücksichtigen muss. Was bringt es, diesen Speicherplatz vorübergehend freizugeben, damit SQL Server ihn langsam und schmerzhaft zurücknehmen kann?

• Erstellen Sie eine zweite Protokolldatei . Dies entlastet vorübergehend das Laufwerk, das Ihre Festplatte gefüllt hat. Dies entspricht jedoch dem Versuch, eine durchstochene Lunge mit einem Pflaster zu reparieren. Sie sollten sich direkt mit der problematischen Protokolldatei befassen, anstatt nur ein weiteres potenzielles Problem hinzuzufügen. Abgesehen davon, dass eine Transaktionsprotokollaktivität auf ein anderes Laufwerk umgeleitet wird, hat eine zweite Protokolldatei (im Gegensatz zu einer zweiten Datendatei) wirklich nichts für Sie zu tun, da immer nur eine der Dateien gleichzeitig verwendet werden kann. Paul Randal erklärt auch, warum mehrere Protokolldateien Sie später beißen können .

Sei proaktiv

Anstatt Ihre Protokolldatei auf eine kleine Menge zu verkleinern und sie ständig mit einer kleinen Geschwindigkeit automatisch wachsen zu lassen, stellen Sie sie auf eine relativ große Größe ein (eine, die die Summe Ihrer größten Anzahl gleichzeitiger Transaktionen berücksichtigt) und legen Sie eine angemessene automatische Zunahme fest Einstellung als Fallback, damit es nicht mehrmals wachsen muss, um einzelne Transaktionen zu erfüllen, und dass es relativ selten vorkommt, dass es während des normalen Geschäftsbetriebs jemals wachsen muss.

Die schlechtesten Einstellungen sind hier 1 MB Wachstum oder 10% Wachstum. Komischerweise sind dies die Standardeinstellungen für SQL Server (über die ich mich beschwert und vergeblich um Änderungen gebeten habe ) - 1 MB für Datendateien und 10% für Protokolldateien. Ersteres ist heutzutage viel zu klein, und letzteres führt jedes Mal zu immer längeren Ereignissen (z. B. Ihre Protokolldatei ist 500 MB groß, das erste Wachstum beträgt 50 MB, das nächste Wachstum beträgt 55 MB, das nächste Wachstum beträgt 60,5 MB usw. usw. - und bei langsamer E / A, glauben Sie mir, Sie werden diese Kurve wirklich bemerken.

Weiterführende Literatur

Bitte hör hier nicht auf; Während viele der Ratschläge, die Sie dort draußen zum Verkleinern von Protokolldateien sehen, von Natur aus schlecht und sogar potenziell katastrophal sind, gibt es einige Leute, denen die Datenintegrität wichtiger ist als die Freigabe von Speicherplatz.

Ein Blog-Beitrag, den ich 2009 geschrieben habe, als ich einige Beiträge zum Thema "So verkleinern Sie die Protokolldatei" gesehen habe .

Ein Blog-Beitrag, den Brent Ozar vor vier Jahren schrieb und auf mehrere Ressourcen hinwies, als Antwort auf einen Artikel im SQL Server Magazine, der nicht hätte veröffentlicht werden dürfen .

Ein Blog-Beitrag von Paul Randal, in dem erklärt wird, warum die Wartung von T-Logs wichtig ist und warum Sie Ihre Datendateien auch nicht verkleinern sollten .

Mike Walsh hat eine großartige Antwort, die auch einige dieser Aspekte abdeckt, einschließlich der Gründe, warum Sie Ihre Protokolldatei möglicherweise nicht sofort verkleinern können .

-- DON'T FORGET TO BACKUP THE DB :D (Check [here][1]) 


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

Von: DBCC SHRINKFILE (Transact-SQL)

Möglicherweise möchten Sie zuerst eine Sicherungskopie erstellen.

HAFTUNGSAUSSCHLUSS: Bitte lesen Sie die folgenden Kommentare sorgfältig durch, und ich gehe davon aus, dass Sie die akzeptierte Antwort bereits gelesen haben. Wie ich vor fast 5 Jahren sagte:

Wenn jemand Kommentare für Situationen hat, in denen dies KEINE angemessene oder optimale Lösung ist, kommentieren Sie diese bitte unten

• Klicken Sie mit der rechten Maustaste auf den Datenbanknamen.

• Wählen Sie Aufgaben → Verkleinern → Datenbank

• Dann klicken Sie OK!

Normalerweise öffne ich das Windows Explorer-Verzeichnis mit den Datenbankdateien, damit ich den Effekt sofort sehen kann.

Ich war eigentlich ziemlich überrascht, dass das funktioniert hat! Normalerweise habe ich DBCC schon einmal verwendet, aber ich habe es nur versucht und es hat nichts geschrumpft, also habe ich die GUI (2005) ausprobiert und es hat großartig funktioniert - 17 GB in 10 Sekunden freizugeben

Im vollständigen Wiederherstellungsmodus funktioniert dies möglicherweise nicht. Sie müssen entweder zuerst das Protokoll sichern oder zu Einfache Wiederherstellung wechseln und dann die Datei verkleinern. [danke @onupdatecascade dafür]

- -

PS: Ich weiß zu schätzen, was einige zu den Gefahren gesagt haben, aber in meiner Umgebung hatte ich selbst keine Probleme damit, zumal ich immer zuerst ein vollständiges Backup mache. Berücksichtigen Sie daher bitte Ihre Umgebung und wie sich dies auf Ihre Sicherungsstrategie und die Arbeitsplatzsicherheit auswirkt, bevor Sie fortfahren. Ich habe nur auf eine Funktion von Microsoft hingewiesen!

Unten finden Sie ein Skript zum Verkleinern des Transaktionsprotokolls. Ich würde jedoch auf jeden Fall empfehlen, das Transaktionsprotokoll vor dem Verkleinern zu sichern.

Wenn Sie die Datei nur verkleinern, verlieren Sie eine Menge Daten, die im Katastrophenfall lebensrettend sein können. Das Transaktionsprotokoll enthält viele nützliche Daten, die mit einem Transaktionsprotokollleser eines Drittanbieters gelesen werden können (es kann manuell gelesen werden, jedoch mit extremem Aufwand).

Das Transaktionsprotokoll ist auch ein Muss, wenn es um die Wiederherstellung zu einem bestimmten Zeitpunkt geht. Werfen Sie es also nicht einfach weg, sondern sichern Sie es vorher.

Hier sind einige Beiträge, in denen Personen Daten verwendet haben, die im Transaktionsprotokoll gespeichert sind, um die Wiederherstellung durchzuführen:

• Anzeigen von Transaktionsprotokollen in SQL Server 2008

• Lesen Sie die Protokolldatei (* .LDF) in 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

Möglicherweise wird ein Fehler angezeigt, der so aussieht, wenn die obigen Befehle ausgeführt werden

"Protokolldatei (Name der Protokolldatei) kann nicht verkleinert werden, da die logische Protokolldatei am Ende der Datei verwendet wird."

Dies bedeutet, dass TLOG verwendet wird. Versuchen Sie in diesem Fall, dies mehrmals hintereinander auszuführen, oder suchen Sie nach einer Möglichkeit, die Datenbankaktivitäten zu reduzieren.

Hier ist ein einfacher und sehr uneleganter und potenziell gefährlicher Weg.

1. Sicherungsdatenbank
2. DB abnehmen
3. Protokolldatei umbenennen
4. DB anhängen
5. Neue Protokolldatei wird neu erstellt
6. Umbenannte Protokolldatei löschen.

Ich vermute, dass Sie keine Protokollsicherungen durchführen. (Welche das Protokoll abschneiden). Mein Rat ist, das Wiederherstellungsmodell von vollständig auf einfach zu ändern . Dies verhindert das Aufblähen des Protokolls.

Wenn Sie die Transaktionsprotokolle nicht für Wiederherstellungen verwenden (dh Sie führen immer nur vollständige Sicherungen durch), können Sie den Wiederherstellungsmodus auf "Einfach" setzen. Das Transaktionsprotokoll wird in Kürze verkleinert und nie wieder gefüllt.

Wenn Sie SQL 7 oder 2000 verwenden, können Sie auf der Registerkarte "Datenbankoptionen" die Option "Anmeldepunkt abschneiden" aktivieren. Dies hat den gleichen Effekt.

Dies wird in Produktionsumgebungen offensichtlich nicht empfohlen, da Sie zu einem bestimmten Zeitpunkt keine Wiederherstellung durchführen können.

Diese von John empfohlene Technik wird nicht empfohlen, da nicht garantiert werden kann, dass die Datenbank ohne die Protokolldatei angehängt wird. Ändern Sie die Datenbank von "voll" in "einfach", erzwingen Sie einen Prüfpunkt und warten Sie einige Minuten. Der SQL Server löscht das Protokoll, das Sie dann mit DBCC SHRINKFILE verkleinern können.

Bei den meisten Antworten wird bisher davon ausgegangen, dass Sie die Transaktionsprotokolldatei nicht benötigen. Wenn Ihre Datenbank jedoch das FULLWiederherstellungsmodell verwendet und Sie Ihre Sicherungen aufbewahren möchten, falls Sie die Datenbank wiederherstellen müssen, kürzen oder löschen Sie die Datei nicht Protokolldatei, wie viele dieser Antworten vermuten lassen.

Wenn Sie die Protokolldatei entfernen (durch Abschneiden, Verwerfen, Löschen usw.), wird Ihre Sicherungskette unterbrochen und Sie können zu keinem Zeitpunkt seit Ihrer letzten vollständigen, differenziellen oder Transaktionsprotokollsicherung bis zur nächsten vollständigen Sicherung wiederherstellen oder es wird eine differenzielle Sicherung durchgeführt.

Ab dem Microsoft-Artikel weiterBACKUP

Wir empfehlen, niemals NO_LOG oder TRUNCATE_ONLY zu verwenden, um das Transaktionsprotokoll manuell abzuschneiden, da dies die Protokollkette unterbricht. Bis zur nächsten vollständigen oder differenziellen Datenbanksicherung ist die Datenbank nicht vor Medienfehlern geschützt. Verwenden Sie die manuelle Protokollkürzung nur unter ganz besonderen Umständen und erstellen Sie sofort Sicherungen der Daten.

Um dies zu vermeiden, sichern Sie Ihre Protokolldatei auf der Festplatte, bevor Sie sie verkleinern. Die Syntax würde ungefähr so ​​aussehen:

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

DBCC SHRINKFILE (N'MyDatabaseName_Log', 200)

Das SQL Server-Transaktionsprotokoll muss ordnungsgemäß verwaltet werden, um unerwünschtes Wachstum zu verhindern. Dies bedeutet, dass Transaktionsprotokollsicherungen häufig genug ausgeführt werden. Wenn Sie dies nicht tun, riskieren Sie, dass das Transaktionsprotokoll voll wird und wächst.

Neben den Antworten auf diese Frage empfehle ich, die gängigen Mythen des Transaktionsprotokolls zu lesen und zu verstehen. Diese Messwerte können dazu beitragen, das Transaktionsprotokoll zu verstehen und zu entscheiden, mit welchen Techniken es "gelöscht" werden soll:

Aus den 10 wichtigsten Mythen des SQL Server-Transaktionsprotokolls :

Mythos: Mein SQL Server ist zu beschäftigt. Ich möchte keine SQL Server-Transaktionsprotokollsicherungen durchführen

Eine der größten leistungsintensiven Vorgänge in SQL Server ist ein automatisch wachsendes Ereignis der Online-Transaktionsprotokolldatei. Wenn Transaktionsprotokollsicherungen nicht oft genug durchgeführt werden, wird das Online-Transaktionsprotokoll voll und muss erweitert werden. Die Standardwachstumsgröße beträgt 10%. Je geschäftiger die Datenbank ist, desto schneller wächst das Online-Transaktionsprotokoll, wenn keine Transaktionsprotokollsicherungen erstellt werden. Durch das Erstellen einer SQL Server-Transaktionsprotokollsicherung wird das Online-Transaktionsprotokoll nicht blockiert, ein Ereignis mit automatischem Wachstum jedoch. Es kann alle Aktivitäten im Online-Transaktionsprotokoll blockieren

Aus Transaktionsprotokoll-Mythen :

Mythos: Regelmäßiges Schrumpfen von Holz ist eine gute Wartungspraxis

FALSCH. Das Holzwachstum ist sehr teuer, da der neue Block auf Null gesetzt werden muss. Alle Schreibaktivitäten in dieser Datenbank werden gestoppt, bis die Nullstellung abgeschlossen ist. Wenn das Schreiben auf der Festplatte langsam ist oder die Größe des automatischen Wachstums groß ist, kann diese Pause sehr groß sein und die Benutzer werden es bemerken. Das ist ein Grund, warum Sie Wachstum vermeiden wollen. Wenn Sie das Protokoll verkleinern, wächst es erneut und Sie verschwenden nur den Festplattenbetrieb für unnötige Spiele zum Verkleinern und erneuten Vergrößern

Überprüfen Sie zuerst das Datenbankwiederherstellungsmodell. Standardmäßig erstellt SQL Server Express Edition eine Datenbank für das einfache Wiederherstellungsmodell (wenn ich mich nicht irre).

Sicherungsprotokoll DatabaseName With Truncate_Only:

DBCC ShrinkFile(yourLogical_LogFileName, 50)

SP_helpfile gibt Ihnen den Namen der logischen Protokolldatei.

Beziehen auf:

Wiederherstellung aus einem vollständigen Transaktionsprotokoll in einer SQL Server-Datenbank

Wenn sich Ihre Datenbank im vollständigen Wiederherstellungsmodell befindet und Sie keine TL-Sicherung durchführen, ändern Sie sie in EINFACH.

Verwenden Sie den DBCC ShrinkFile ({logicalLogName}, TRUNCATEONLY)Befehl. Wenn dies eine Testdatenbank ist und Sie versuchen, Speicherplatz zu sparen / zurückzugewinnen, hilft dies.

Denken Sie jedoch daran, dass TX-Protokolle eine Art Mindest- / Steady-State-Größe haben, bis zu der sie wachsen werden. Abhängig von Ihrem Wiederherstellungsmodell können Sie das Protokoll möglicherweise nicht verkleinern. Wenn das Protokoll in FULL ist und Sie keine TX-Protokollsicherungen ausgeben, kann es nicht verkleinert werden. Es wächst für immer. Wenn Sie keine TX-Protokollsicherungen benötigen, wechseln Sie Ihr Wiederherstellungsmodell zu Einfach .

Und denken Sie daran, niemals die Protokolldatei (LDF) zu löschen! Sie werden so ziemlich sofort eine Datenbankbeschädigung haben. Gekocht! Erledigt! Verlorene Daten! Wenn die MDF-Hauptdatei nicht repariert wird, kann sie dauerhaft beschädigt werden.

Löschen Sie niemals das Transaktionsprotokoll - Sie verlieren Daten! Ein Teil Ihrer Daten befindet sich im TX-Protokoll (unabhängig vom Wiederherstellungsmodell) ... wenn Sie die TX-Protokolldatei, die effektiv gelöscht wird, trennen und "umbenennen" Teil Ihrer Datenbank .

Für diejenigen, die das TX-Protokoll gelöscht haben, möchten Sie möglicherweise einige checkdb-Befehle ausführen und die Beschädigung beheben, bevor Sie weitere Daten verlieren.

Schauen Sie sich Paul Randals Blog-Beiträge zu diesem Thema an, schlechte Ratschläge .

Verwenden Sie im Allgemeinen auch keine Schrumpfdatei für die MDF-Dateien, da dies Ihre Daten stark fragmentieren kann. Weitere Informationen finden Sie in seinem Abschnitt "Bad Advice" ("Warum Sie Ihre Datendateien nicht verkleinern sollten").

Schauen Sie sich Pauls Website an - er behandelt genau diese Fragen. Letzten Monat ging er in seiner Myth A Day- Reihe viele dieser Themen durch .

So schneiden Sie die Protokolldatei ab:

• Sichern Sie die Datenbank
• Trennen Sie die Datenbank entweder mithilfe von Enterprise Manager oder indem Sie Folgendes ausführen: Sp_DetachDB [DBName]
• Löschen Sie die Transaktionsprotokolldatei. (oder benennen Sie die Datei um, nur für den Fall)
• Hängen Sie die Datenbank erneut an: Sp_AttachDB [DBName]
• Wenn die Datenbank angehängt ist, wird eine neue Transaktionsprotokolldatei erstellt.

So verkleinern Sie die Protokolldatei:

• Sicherungsprotokoll [DBName] mit No_Log

• Verkleinern Sie die Datenbank um Folgendes:

  Verwenden von Enterprise Manager: - Klicken Sie mit der rechten Maustaste auf die Datenbank, Alle Aufgaben, Datenbank verkleinern, Dateien, Protokolldatei auswählen, OK.

  Verwenden von T-SQL: - Dbcc Shrinkfile ([Log_Logical_Name])

Sie finden den logischen Namen der Protokolldatei, indem Sie sp_helpdb ausführen oder die Eigenschaften der Datenbank in Enterprise Manager überprüfen.

Nach meiner Erfahrung gibt es auf den meisten SQL Servern keine Sicherung des Transaktionsprotokolls. Vollständige Sicherungen oder differenzielle Sicherungen sind gängige Praxis, aber Transaktionsprotokollsicherungen sind wirklich selten. Die Transaktionsprotokolldatei wächst also für immer (bis die Festplatte voll ist). In diesem Fall sollte das Wiederherstellungsmodell auf " einfach" gesetzt werden " gesetzt werden. Vergessen Sie nicht, auch die Systemdatenbanken "model" und "tempdb" zu ändern.

Eine Sicherung der Datenbank "tempdb" macht keinen Sinn, daher sollte das Wiederherstellungsmodell dieser Datenbank immer "einfach" sein.

1. Erstellen Sie eine Sicherungskopie der MDB-Datei.
2. Beenden Sie SQL-Dienste
3. Benennen Sie die Protokolldatei um
4. Starten Sie den Dienst

(Das System erstellt eine neue Protokolldatei.)

Löschen oder verschieben Sie die umbenannte Protokolldatei.

Es passierte bei mir, wo die Datenbankprotokolldatei 28 GB groß war.

Was können Sie tun, um dies zu reduzieren? Tatsächlich sind Protokolldateien diejenigen Dateidaten, die der SQL Server behält, wenn eine Transaktion stattgefunden hat. Damit eine Transaktion SQL Server verarbeitet, werden Seiten für dieselbe Transaktion zugewiesen. Nach Abschluss der Transaktion werden diese jedoch nicht plötzlich freigegeben, in der Hoffnung, dass eine Transaktion wie die gleiche zustande kommt. Dies hält den Raum.

Schritt 1: Führen Sie diesen Befehl zuerst im Prüfpunkt für die Datenbankabfrage aus

Schritt 2: Klicken Sie mit der rechten Maustaste auf die Datenbank. Aufgabe> Sichern Wählen Sie den Sicherungstyp als Transaktionsprotokoll aus. Fügen Sie eine Zieladresse und einen Dateinamen hinzu, um die Sicherungsdaten (.bak) beizubehalten.

Wiederholen Sie diesen Schritt erneut und geben Sie zu diesem Zeitpunkt einen anderen Dateinamen an

Schritt 3: Gehen Sie nun zur Datenbank. Klicken Sie mit der rechten Maustaste auf die Datenbank

Aufgaben> Verkleinern> Dateien Wählen Sie Dateityp als Aktion zum Verkleinern von Protokollen, um nicht verwendeten Speicherplatz freizugeben

Schritt 4:

Überprüfen Sie Ihre Protokolldatei normalerweise in SQL 2014 unter

C: \ Programme \ Microsoft SQL Server \ MSSQL12.MSSQL2014EXPRESS \ MSSQL \ DATA

In meinem Fall ist es von 28 GB auf 1 MB reduziert

Versuche dies:

USE DatabaseName

GO

DBCC SHRINKFILE( TransactionLogName, 1)

BACKUP LOG DatabaseName WITH TRUNCATE_ONLY

DBCC SHRINKFILE( TransactionLogName, 1)

GO 

Datenbank → Rechtsklick Eigenschaften → Datei → Fügen Sie eine weitere Protokolldatei mit einem anderen Namen hinzu und legen Sie den Pfad wie in der alten Protokolldatei mit einem anderen Dateinamen fest.

Die Datenbank nimmt die neu erstellte Protokolldatei automatisch auf.

1. Sicherungsdatenbank
2. DB abnehmen
3. Protokolldatei umbenennen
4. DB anhängen (beim Anhängen entfernen umbenannte .ldf (Protokolldatei) .Wählen Sie sie aus und entfernen Sie sie, indem Sie auf die Schaltfläche Entfernen klicken.)
5. Neue Protokolldatei wird neu erstellt
6. Umbenannte Protokolldatei löschen.

Dies funktioniert, es wird jedoch empfohlen, zuerst eine Sicherungskopie Ihrer Datenbank zu erstellen.

Einige der anderen Antworten funktionierten bei mir nicht: Es war nicht möglich, den Prüfpunkt zu erstellen, während die Datenbank online war, da das Transaktionsprotokoll voll war (wie ironisch). Nachdem ich die Datenbank in den Notfallmodus versetzt hatte, konnte ich die Protokolldatei verkleinern:

alter database <database_name> set emergency;
use <database_name>;
checkpoint;
checkpoint;
alter database <database_name> set online;
dbcc shrinkfile(<database_name>_log, 200);

Beispiel:

DBCC SQLPERF(LOGSPACE)

BACKUP LOG Comapny WITH TRUNCATE_ONLY

DBCC SHRINKFILE (Company_log, 500)

DBCC SQLPERF(LOGSPACE)

Leicht aktualisierte Antwort für MSSQL 2017 und Verwendung des SQL Server Management Studio. Ich ging meistens von diesen Anweisungen aus https://www.sqlshack.com/sql-server-transaction-log-backup-truncate-and-shrink-operations/

Ich hatte kürzlich eine Datenbank-Sicherung, also habe ich das Transaktionsprotokoll gesichert. Dann habe ich es für ein gutes Maß wieder gesichert. Schließlich habe ich die Protokolldatei verkleinert und bin von 20 GB auf 7 MB gestiegen, viel mehr entsprechend der Größe meiner Daten. Ich glaube nicht, dass die Transaktionsprotokolle jemals gesichert wurden, seit dies vor 2 Jahren installiert wurde. Stellen Sie diese Aufgabe also in den Reinigungskalender.

DB-Transaktionsprotokoll Auf Mindestgröße verkleinern :

1. Sicherung: Transaktionsprotokoll
2. Dateien verkleinern: Transaktionsprotokoll
3. Sicherung: Transaktionsprotokoll
4. Dateien verkleinern: Transaktionsprotokoll

Ich habe mehrere DBs getestet: Diese Sequenz funktioniert .

Es schrumpft normalerweise auf 2 MB .

ODER durch ein Skript:

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