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 .
