Das Verkleinern einer Protokolldatei sollte wirklich Szenarien vorbehalten sein, in denen ein 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 nun folgende Maßnahmen ergreifen.
Erstellen Sie zuerst 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 Ihnen die Wiederherstellung zu einem bestimmten Zeitpunkt wichtig ist
(Und mit Point-in-Time-Wiederherstellung meine ich, dass es Ihnen wichtig ist, etwas anderes als eine vollständige oder differenzielle Sicherung wiederherstellen zu können.)
Vermutlich ist Ihre Datenbank FULL Wiederherstellungsmodus. Wenn nicht, stellen Sie sicher, dass es:
ALTER DATABASE testdb SET RECOVERY FULL;
Selbst wenn Sie regelmäßig vollständige Sicherungen erstellen, wird die Protokolldatei größer und größer, bis Sie eine Protokollierung durchführen Backup - dies dient zu Ihrem Schutz, um Ihren Speicherplatz nicht unnötig zu verschlingen. Entsprechend Ihren Wiederherstellungszielen sollten Sie diese Protokollsicherungen recht 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, sie sind schrecklich). P>
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\ sollte sich auf einem anderen Computer befinden, der ein anderes zugrunde liegendes Speichergerät darstellt. Diese auf derselben Maschine (oder auf einer anderen Maschine, die dieselben zugrunde liegenden Festplatten verwendet, oder einer anderen VM, die sich auf demselben physischen Host befindet) zu sichern, hilft Ihnen nicht wirklich, denn wenn die Maschine explodiert, haben Sie Ihre Datenbank verloren und seine Backups. Abhängig von Ihrer Netzwerkinfrastruktur kann es sinnvoller sein, lokal zu sichern und sie dann hinter den Kulissen an einen anderen Ort zu übertragen. in jedem Fall möchten Sie sie so schnell wie möglich von der primären Datenbankmaschine entfernen.
Nun, sobald Sie regelmäßige Protokollsicherungen ausgeführt haben, sollte es vernünftig sein, die Protokolldatei auf etwas Vernünftigeres zu verkleinern als auf das, was sie jetzt in die Luft gesprengt hat. Dies nicht bedeutet, dass SHRINKFILE ausgeführt wird immer wieder, bis die Protokolldatei 1 MB groß ist - selbst wenn Sie das Protokoll häufig sichern, muss es dennoch die Summe aller gleichzeitig auftretenden Transaktionen aufnehmen können. Protokolldatei-Autogrowth-Ereignisse 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 Wachsen-Schrumpfen-Wachsen-Schrumpfen-Routine so wenig wie möglich durchführen, und Sie möchten sicherlich nicht, dass Ihre Benutzer dafür bezahlen.
Beachten Sie, dass Sie das Protokoll möglicherweise zweimal sichern müssen, bevor eine Verkleinerung möglich ist (danke Robert).
Sie müssen sich also eine praktische Größe für Ihre Protokolldatei einfallen lassen. 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 wächst, ist ein gutes Wasserzeichen wahrscheinlich 10-50% höher als das größte, das es war . Nehmen wir an, das sind 200 MB, und Sie möchten, dass alle nachfolgenden Autogrowth-Ereignisse 50 MB groß sind, 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 Folgendes möglicherweise zuerst ausführen müssen, wenn die Protokolldatei derzeit> 200 MB ist:
USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);
GO
Wenn Ihnen die Wiederherstellung zu einem bestimmten Zeitpunkt egal ist
Wenn es sich um eine Testdatenbank handelt und Ihnen die zeitpunktbezogene Wiederherstellung egal ist, sollten Sie sicherstellen, dass sich Ihre Datenbank im SIMPLE-Modus befindet Wiederherstellungsmodus.
ALTER DATABASE testdb SET RECOVERY SIMPLE;
Setzen der Datenbank in SIMPLE Der Wiederherstellungsmodus stellt sicher, dass SQL Server Teile der Protokolldatei wiederverwendet (im Wesentlichen inaktive Transaktionen auslaufen lässt), anstatt zu wachsen, um alle aufzuzeichnen Transaktionen (wie FULL Wiederherstellung funktioniert, bis Sie das Protokoll sichern). CHECKPOINT Ereignisse helfen bei der Kontrolle des Protokolls und stellen sicher, dass es nicht wachsen muss, es sei denn, Sie generieren eine Menge T-Protokoll-Aktivität zwischen CHECKPOINT s.
Als nächstes sollten Sie unbedingt sicherstellen, dass dieses Log-Wachstum wirklich auf ein ungewöhnliches Ereignis zurückzuführen ist (z. B. ein jährlicher Frühjahrsputz oder die Wiederherstellung Ihrer größten Indizes) und nicht auf eine normale, alltägliche Nutzung. Was haben Sie gewonnen, wenn Sie die Protokolldatei auf eine lächerlich kleine Größe verkleinern und SQL Server sie nur wieder vergrößern muss, um Ihre normalen Aktivitäten zu ermöglichen? Konnten Sie den freigegebenen Speicherplatz nur vorübergehend nutzen? 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
Stellen Sie andernfalls eine angemessene Größe und Wachstumsrate ein. Wie im Beispiel im Fall der Point-in-Time-Wiederherstellung können Sie denselben Code und dieselbe Logik verwenden, um zu bestimmen, welche Dateigröße angemessen ist, und angemessene Parameter für die automatische Vergrößerung festlegen.
Einige Dinge, die Sie nicht tun möchten
-
Sichern Sie das Protokoll mit
TRUNCATE_ONLYOption und dannSHRINKFILE. Zum einen diesesTRUNCATE_ONLYDie Option ist veraltet und in aktuellen Versionen von SQL Server nicht mehr verfügbar. Zweitens, wenn Sie inFULLsind Wiederherstellungsmodell, wird dies Ihre Protokollkette zerstören und eine neue, vollständige Sicherung erfordern. -
Trennen Sie die Datenbank, löschen Sie die Protokolldatei und verbinden Sie sie erneut . Ich kann nicht betonen, wie gefährlich das sein kann. Ihre Datenbank wird möglicherweise nicht wiederhergestellt, sie wird möglicherweise als verdächtig eingestuft, Sie müssen möglicherweise zu einer Sicherungskopie zurückkehren (falls vorhanden) usw. usw.
-
Verwenden Sie die Option "Datenbank verkleinern" .
DBCC SHRINKDATABASEund die Wartungsplanoption, dasselbe zu tun, sind schlechte Ideen, insbesondere wenn Sie wirklich nur ein Protokollproblem lösen müssen. Wählen Sie die Datei aus, die Sie anpassen möchten, und passen Sie sie mithilfe vonDBCC SHRINKFILEunabhängig an oderALTER DATABASE ... MODIFY FILE(Beispiele oben). -
Verkleinern Sie die Protokolldatei auf 1 MB . Das sieht verlockend aus, denn, hey, SQL Server lässt mich das in bestimmten Szenarien tun und schaue mir den ganzen Speicherplatz an, den es freigibt! Sofern Ihre Datenbank nicht schreibgeschützt ist (und das ist sie, sollten Sie sie mit
ALTER DATABASEals solche markieren ), führt dies absolut nur zu vielen unnötigen Wachstumsereignissen, da das Protokoll unabhängig vom Wiederherstellungsmodell aktuelle Transaktionen aufnehmen muss. Was bringt es, diesen Speicherplatz vorübergehend freizugeben, nur damit SQL Server ihn langsam und schmerzhaft zurückerobern kann? -
Erstellen Sie eine zweite Protokolldatei . Dies wird das Laufwerk, das Ihre Festplatte gefüllt hat, vorübergehend entlasten, aber das ist wie der 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 einige Transaktionsprotokollaktivitäten auf ein anderes Laufwerk umgeleitet werden, tut eine zweite Protokolldatei wirklich nichts für Sie (im Gegensatz zu einer zweiten Datendatei), 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.
Seien Sie proaktiv
Anstatt Ihre Protokolldatei auf einen kleinen Betrag zu verkleinern und sie ständig mit einer kleinen Rate automatisch wachsen zu lassen, setzen Sie sie auf eine einigermaßen große Größe (eine, die die Summe Ihrer größten Menge gleichzeitiger Transaktionen aufnehmen kann) und legen Sie eine angemessene automatische Vergrößerung fest Einstellung als Fallback, damit es nicht mehrmals wachsen muss, um einzelne Transaktionen zu erfüllen, und damit es relativ selten sein wird, dass es während des normalen Geschäftsbetriebs jemals wachsen muss.
Die schlechtesten möglichen Einstellungen sind hier 1 MB Wachstum oder 10 % Wachstum. Komischerweise sind dies die Standardwerte 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 (sagen wir, 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 , etc. etc. - und bei langsamer E/A, glauben Sie mir, werden Sie diese Kurve wirklich bemerken).
Weiterführende Literatur
Bitte hören Sie hier nicht auf; Während viele der Ratschläge, die Sie 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 das Freigeben von Speicherplatz.
Ein Blogbeitrag, den ich 2009 geschrieben habe, als ich sah, dass einige „So verkleinern Sie die Protokolldatei“-Beiträge auftauchten.
Ein Blogbeitrag, den Brent Ozar vor vier Jahren schrieb und auf mehrere Ressourcen hinwies, als Antwort auf einen Artikel im SQL Server Magazine, der nicht sollte wurden veröffentlicht.
Ein Blogbeitrag von Paul Randal, der erklärt, 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.
