it-swarm.com.de

Wie wirkt sich das Verkleinern einer SQL Server-Protokolldatei auf die Leistung aus?

Ich habe eine SQL Server 2008-Datenbank mit einer Datendatei von etwa 2 GB, aber die Protokolldatei ist größer als 8 GB. Bei Datenbanken vor 2008 konnte ich das 'Sicherungsprotokoll' und das TRUNCATE_ONLY Option, aber diese ist bei Datenbanken ab 2008 nicht mehr verfügbar.

Ich habe ein Skript, das die Protokolldatei abschneidet:

USE [MyDatabase]
GO
ALTER DATABASE [MyDatabase] SET RECOVERY SIMPLE WITH NO_WAIT
DBCC shrinkfile('MyDatabase_log', 1)
ALTER DATABASE [MyDatabase] SET RECOVERY FULL WITH NO_WAIT
GO

Dadurch wird die Protokolldatei vollständig abgeschnitten, aber meine Frage lautet: Beeinträchtigt dies die Leistung?

Ich führe täglich zwei vollständige Sicherungen durch, sodass das Protokoll für den Daten-Roll-Forward nicht unbedingt erforderlich sein sollte.

19
MartinHT

Ich empfehle wirklich, Wichtigkeit einer ordnungsgemäßen Verwaltung der Transaktionsprotokollgröße von Paul S. Randal zu lesen.

Die Quintessenz ist, dass es nur zwei wirklich gute Möglichkeiten gibt, Transaktionsprotokoll zu behandeln :

  1. Entweder gehen Sie mit regulären LOG-Dateisicherungen und die LOG-Datei verwendet ihren Speicherplatz nach jeder LOG-Sicherung wieder und wächst nicht auf unbestimmte Zeit, oder

  2. Verwenden Sie das SIMPLE-Wiederherstellungsmodell, und Sie müssen sich nicht um die Größe Ihrer LOG-Datei kümmern, da Sie regelmäßig vollständige Sicherungen durchführen.

Was das Abschneiden und die Leistung von LOG-Dateien betrifft, ist, dass Sie immer einen Leistungseinbruch erhalten, wenn die LOG-Datei erhöht werden soll (ein Zitat aus dem obigen). verlinkter Blog-Beitrag):

Wenn Sie das Protokoll verkleinern, wird es erneut wachsen - was möglicherweise zu einer Fragmentierung von VLF] führt und definitiv dazu, dass Ihre Arbeitslast angehalten wird, während das Protokoll wächst, da das Protokoll keine sofortige Initialisierung verwenden kann [. ..]

Update: Verwechseln Sie das Abschneiden von LOG-Dateien nicht mit dem Verkleinern von DATA-Dateien. Das Verkleinern von DATENDateien ist wirklich schlecht. Siehe Warum Sie Ihre Datendateien nicht verkleinern sollten für Details.

26
MicSim

OK zuerst ja, das Protokoll ist auch bei den täglichen vollständigen Sicherungen erforderlich, wenn Sie im Falle eines Problems eine Wiederherstellung durchführen möchten. Wir sichern unser Transaktionsprotokoll alle 15 Minuten. Das Problem ist, dass Sie Ihr Transaktionsprotokoll nicht sichern und das Protokoll deshalb so unverschämt wächst. Sie sollten ein Transaktionsprotokoll fast nie verkleinern müssen, wenn Sie korrekte Transaktionsprotokollsicherungen durchführen.

Sie müssen die Datenbank sichern, bevor Sie das Protokoll abschneiden. Ich empfehle, dies außerhalb der Geschäftszeiten zu tun, damit keine neuen Daten zwischen dem Backup und dem Abschneiden eingefügt werden. Richten Sie dann die richtigen Transaktionsprotokollsicherungen ein, damit Sie dieses Problem nie wieder haben.

In Bezug auf die Beeinträchtigung der Leistung ist dies schwer zu sagen, ohne die Details Ihrer Systemhardware und -nutzung zu kennen.

6
HLGEM

Wie schnell wächst das Transaktionsprotokoll? Wenn es ziemlich schnell ist, beeinträchtigen Sie die Leistung, indem Sie es auf nahezu nichts verkleinern, da es Zeit damit verbringen muss, es wieder aufzubauen. Dies bedeutet nicht, dass Sie es nicht von Zeit zu Zeit verkleinern sollten, aber Sie müssen über das Größenproblem nachdenken, anstatt nur auf ein Minimum zu verkleinern. Ist der Perf-Hit riesig? Wahrscheinlich nicht, aber es hängt von der Auslastung des Servers ab (Anzahl der Transaktionen usw.).

Eine Sache, die ich problematisch finde, ist: "Ich führe täglich 2 vollständige Sicherungen durch, sodass das Protokoll für die Datenweiterleitung nicht unbedingt erforderlich sein sollte." Das Protokoll ist äußerst wichtig für Punkte zwischen Ihren vollständigen Sicherungen. Selbst zweimal am Tag wird die Notwendigkeit einer Protokolldatei für die Notfallwiederherstellung nicht beseitigt, es sei denn, es handelt sich um eine schreibgeschützte Datenbank (wenn dies der Fall wäre, würden Sie jedoch keinen enormen Anstieg der Protokolldatei feststellen).

4