Wie reduziere ich die Größe der Transaktionsprotokollsicherung nach einer vollständigen Sicherung?

38

Ich habe drei Wartungspläne für die Ausführung auf einer SQL Server 2005-Instanz eingerichtet:

  • Wöchentliche Datenbankoptimierungen, gefolgt von einer vollständigen Sicherung
  • Tägliche differenzielle Sicherung
  • Stündliche Transaktionsprotokollsicherungen

Die stündlichen Protokollsicherungen liegen in der Regel zwischen einigen Hundert KB und 10 MB, je nach Aktivitätsgrad. Die täglichen Differenzen steigen bis zum Ende der Woche auf etwa 250 MB, und die wöchentliche Sicherung beträgt etwa 3,5 GB.

Das Problem, das ich habe, ist, dass die Optimierungen vor der vollständigen Sicherung zu verursachen scheinen, dass die nächste Transaktionsprotokollsicherung auf über das Zweifache der Größe der vollständigen Sicherung, in diesem Fall 8 GB, anwächst, bevor sie zur normalen Größe zurückkehrt.

Gibt BACKUP LOG <DatabaseName> WITH TRUNCATE_ONLYes eine andere Möglichkeit, die Größe dieser Protokollsicherung zu verringern oder zu verhindern, dass die Optimierungen überhaupt im Transaktionsprotokoll aufgezeichnet werden, da sie sicherlich in der vollständigen Sicherung berücksichtigt werden, der sie vorangehen?

sql-server sql-server-2005 Dave
quelle
1
+1 Dies wurde aufgrund des durch diese Frage hervorgerufenen Gedankenaustauschs positiv bewertet.
MarlonRibunal

Antworten:

35

Einige interessante Vorschläge, die alle ein Missverständnis hinsichtlich der Funktionsweise von Protokollsicherungen aufzeigen. Eine Protokollsicherung enthält ALLE Transaktionsprotokolle, die seit der vorherigen Protokollsicherung erstellt wurden, unabhängig davon, welche vollständigen oder differenziellen Sicherungen in der Zwischenzeit durchgeführt wurden. Das Stoppen von Protokollsicherungen oder das Wechseln zu täglichen vollständigen Sicherungen hat keine Auswirkungen auf die Größe der Protokollsicherungen. Das einzige, was sich auf das Transaktionsprotokoll auswirkt, ist eine Protokollsicherung, sobald die Protokollsicherungskette gestartet wurde.

Die einzige Ausnahme von dieser Regel besteht darin, dass die Protokollsicherungskette unterbrochen wurde (z. B. durch Aufrufen des SIMPLE-Wiederherstellungsmodells, Zurücksetzen von einem Datenbank-Snapshot, Abschneiden des Protokolls mit BACKUP LOG WITH NO_LOG / TRUNCATE_ONLY). In diesem Fall erfolgt die erste Protokollsicherung Enthält das gesamte Transaktionsprotokoll seit der letzten vollständigen Sicherung, wodurch die Protokollsicherungskette neu gestartet wird. oder wenn die Protokollsicherungskette noch nicht gestartet wurde - wenn Sie zum ersten Mal auf FULL umschalten, arbeiten Sie in einer Art Pseudo-SIMPLE-Wiederherstellungsmodell, bis die erste vollständige Sicherung durchgeführt wird.

Um Ihre ursprüngliche Frage zu beantworten, müssen Sie, ohne in das SIMPLE-Wiederherstellungsmodell einzusteigen, das gesamte Transaktionsprotokoll sichern. Abhängig von den von Ihnen ausgeführten Aktionen können Sie häufigere Protokollsicherungen durchführen, um deren Größe zu verringern, oder eine gezieltere Datenbank erstellen.

Wenn Sie Informationen zu den Wartungsoperationen veröffentlichen können, die Sie ausführen, kann ich Sie bei der Optimierung unterstützen. Führen Sie zufällig Indexwiederherstellungen durch, gefolgt von einer verkleinerten Datenbank, um den von den Indexwiederherstellungen verwendeten Speicherplatz wiederzugewinnen?

Wenn Sie während der Wartung keine andere Aktivität in der Datenbank haben, können Sie Folgendes tun:

  • Stellen Sie sicher, dass die Benutzeraktivität gestoppt ist
  • Führen Sie eine letzte Protokollsicherung durch (damit können Sie bis zum Beginn der Wartung eine Wiederherstellung durchführen).
    • Wechseln Sie zum Wiederherstellungsmodell SIMPLE
    • Wartung durchführen - das Protokoll wird an jedem Prüfpunkt abgeschnitten
    • Wechseln Sie zum vollständigen Wiederherstellungsmodell und erstellen Sie eine vollständige Sicherung
    • weiter wie gewohnt

Hoffe das hilft - freue mich auf mehr Infos.

Vielen Dank

[Bearbeiten: Nach all den Diskussionen darüber, ob ein vollständiges Backup die Größe eines nachfolgenden Log-Backups verändern kann (kann es nicht), habe ich einen umfassenden Blog-Beitrag mit Hintergrundmaterial und einem Skript zusammengestellt, das dies beweist. Schau es dir an unter https://www.sqlskills.com/blogs/paul/misconceptions-around-the-log-and-log-backups-show-to-convince-yourself/]

Paul Randal
quelle
4
Paul - überhaupt nicht einverstanden. Führen Sie während der Indexpflege nur keine Protokollsicherungen durch. Das Protokoll wird größer und die nächste vollständige Sicherung wird größer, aber Sie werden nicht die Leistungseinbußen von T-Log-Sicherungen zur gleichen Zeit wie Ihre Indexwartungsjobs verzeichnen. Kannst du den Vorteil davon sehen? Sie würden sicherlich zustimmen, dass gleichzeitige T-Log-Sicherungen und Indexpflege zu Leistungseinbußen führen würden.
Brent Ozar
6
Nein - ich würde immer noch nicht zustimmen. Ich möchte lieber häufiger Log-Backups durchführen, damit sie kleiner sind als ein Monster, nachdem die Wartung abgeschlossen ist. Das Vorhandensein von überproportional großen Protokollsicherungen kann zu Problemen beim Kopieren über das Netzwerk führen (z. B. bei Offsite-Sicherungen oder beim Protokollversand). Wenn keine Benutzeraktivität ist und keine andere Notwendigkeit , dass die Log - Sicherungen, dann vielleicht , aber wenn das System abstürzt und Sie tun müssen , Backup einen Schwanz-of-the-Protokoll, das viel Zeit , dass der Teil Ihrer Ausfallzeiten dauern wird , . Ich sollte einen Blogeintrag darüber machen.
Paul Randal
Und selbst das hilft der ursprünglichen Frage des OP nicht, wie die Größe der Protokollsicherung nach der Indexwartung verringert werden kann. Je nachdem, welche Vorgänge ausgeführt werden, wird sie möglicherweise größer.
Paul Randal
5

Sie könnten sie verkleinern, aber sie werden einfach wieder größer und verursachen schließlich eine Fragmentierung der Festplatte. Durch Neuerstellungen und Defragmentierungen von Indizes werden sehr große Transaktionsprotokolle erstellt. Wenn Sie keine Wiederherstellung zu einem bestimmten Zeitpunkt benötigen, können Sie in den einfachen Wiederherstellungsmodus wechseln und die Transaktionsprotokollsicherungen vollständig entfernen.

Ich nehme an, Sie verwenden einen Wartungsplan für die Optimierungen. Sie könnten ihn ändern, um ein Skript zu verwenden, das nur dann Indexdefragmentierungen durchführt, wenn eine bestimmte Fragmentierungsstufe erreicht ist und Sie wahrscheinlich keinen Leistungseinbruch erleiden würden. Dies würde viel kleinere Protokolle erzeugen.

Ich würde tägliche Differentiale zugunsten von täglichen vollständigen Backups BTW überspringen.

SqlACID
quelle
Ich nehme an, ich könnte am Ende des vollständigen Backups einfach ein TRUNCATE-LOG erstellen, aber das scheint nicht unbedingt die beste Methode zu sein. Ich habe mir Alternativen erhofft ... Was wären die Vorteile eines täglichen vollständigen Backups? als diffs? Das scheint nur mehr Platz für relativ wenig Nutzen zu verbrauchen. Ich kann auch nicht auf einfache Wiederherstellung umstellen, da ich die Granularität der stündlichen Protokollsicherungen benötige. Schließlich bin ich mir nicht sicher, wie das Verschieben der Optimierungen in ein Skript helfen würde. Sicherlich hätte ich immer noch das gleiche Problem, nur seltener.
Dave
Ich habe dies wegen des Vorschlags, Unterschiede zu überspringen und zu den täglichen Ergebnissen zu wechseln, abgelehnt. Warum? Volle 3,5 GB, während Unterschiede nur 250 MB sind. Die Backup-Strategie sieht für mich absolut gut aus. Das Entfernen von Diffs bedeutet, dass viele GB mehr Speicherplatz für eine winzige Beschleunigung der Wiederherstellungszeit zur Verfügung stehen.
Paul Randal
2
Die Situation eines jeden ist anders, an Unterschieden ist nichts auszusetzen, aber wenn der Platz nicht knapp ist und Sie sich schnell erholen müssen, ist es besser, einen Schritt als zwei zu haben.
SqlACID
1
@ Dave Sehen Sie sich Jeremys Antwort an, erstellen Sie eine gespeicherte Prozedur, um bestimmte Dateien zu defragmentieren, und teilen Sie sie in kleinere Teile auf.
SqlACID
3

Ihre letzte Frage lautete: "Mit Ausnahme von BACKUP LOG WITH TRUNCATE_ONLY gibt es keine Möglichkeit, die Größe dieser Protokollsicherung zu verringern oder zu verhindern, dass die Optimierungen überhaupt im Transaktionsprotokoll aufgezeichnet werden, da sie mit Sicherheit vollständig berücksichtigt werden Backup, dem sie vorausgehen? "

Nein, aber hier ist eine Problemumgehung. Wenn Sie wissen, dass die einzigen Aktivitäten in dieser Datenbank zu diesem Zeitpunkt die Indexwartungsjobs sind, können Sie die Transaktionsprotokollsicherungen stoppen, bevor die Indexwartung beginnt. Beispielsweise sehen einige meiner Server an Samstagnächten folgendermaßen aus:

  • 21:30 Uhr - Transaktionsprotokollsicherung wird ausgeführt.
  • 21:45 Uhr - Die Sicherung des Transaktionsprotokolls wird zum letzten Mal ausgeführt. Der Zeitplan endet um 9:59 Uhr.
  • 22:00 Uhr - Der Indexwartungsjob beginnt und wird vor 11:30 Uhr beendet.
  • 23:30 - Der vollständige Sicherungsjob beginnt und endet in weniger als 30 Minuten.
  • 12:00 Uhr - Transaktionsprotokollsicherungen werden alle 15 Minuten neu gestartet.

Das bedeutet, dass ich zwischen 21:45 und 23:30 Uhr keine Wiederherstellungszeit habe, aber die Auszahlung ist eine schnellere Leistung.

Brent Ozar
quelle
Und Sie müssen kurz vor 22 Uhr auf SIMPLE umsteigen, oder? Andernfalls enthält die 12-AM-Protokollsicherung das gesamte Protokoll, das zwischen 22:00 Uhr und 12:00 Uhr erstellt wurde.
Paul Randal
Hoppla, ich habe das auch abgelehnt, weil du nicht erwähnt hast, dass du bei SIMPLE bist. Wenn Sie in BULK_LOGGED bleiben, wird auch die Größe der nächsten Protokollsicherung nicht geändert, da alle Datenbereiche erfasst werden, die durch minimal protokollierte Vorgänge geändert wurden. Wow - hat bisher jede Antwort auf diese Frage abgelehnt.
Paul Randal
NEIN , auf keinen Fall auf einfach umstellen. Er fragte nach der Größe seiner Transaktionsprotokollsicherungen, nicht nach der Größe seiner vollständigen Sicherungen oder seiner Transaktionsprotokolldatei.
Brent Ozar
Wie reduziert das, was Sie tun, die Größe von Transaktionsprotokollsicherungen? Sie enthalten alles seit der vorherigen Protokollsicherung, es sei denn, Sie unterbrechen die Protokollsicherungskette und starten sie anschließend mit der vollständigen Sicherung neu.
Paul Randal
Es sei denn, Ihre Indexpflege macht nichts ...
Paul Randal
3

Einfache Antwort: Ändern Sie Ihren wöchentlichen Optimierungsjob so, dass er nachts ausgewogener ausgeführt wird. Das heißt, die Tabellen werden am Sonntagabend neu indiziert, wenn am Montagabend ein gutes Gleichgewicht gefunden wird, wird Ihr Protokoll im Durchschnitt etwa 1/6 der Größe betragen. Dies funktioniert natürlich am besten, wenn Sie den integrierten SSIS-Index-Wartungsjob nicht verwenden.

Dies hat den Nachteil, dass es je nach Belastung Ihrer Datenbank zu Problemen mit dem Optimierer und der Wiederverwendung von Abfrageplänen kommt.

Wenn Sie sich jedoch nur um die Größe Ihres T-Logs auf wöchentlicher Basis kümmern, teilen Sie es von Tag zu Tag oder von Stunde zu Stunde auf und führen Sie die T-Log-Sicherungen dazwischen durch.


quelle
2

Sie können sich auch ein Drittanbieter-Tool (Litespeed von Quest, SQL Backup von Red Gate, Hyperbac) ansehen, um die Größe der Sicherungen und Protokolle zu verringern. Sie können sich schnell in Bandeinsparungen amortisieren.

Steve Jones
quelle
2

Es ist wahrscheinlich anzunehmen, dass Ihre "Optimierungen" Index-Neuerstellungen beinhalten. Nur die wöchentliche Ausführung dieser Aufgaben kann in einer Datenbank akzeptabel sein, in der es nicht viele Aktualisierungen und Einfügungen gibt. Wenn Ihre Daten jedoch sehr flüssig sind, möchten Sie möglicherweise einige Dinge tun:

  1. Erstellen Sie Ihre Indizes jede Nacht neu oder organisieren Sie sie neu, wenn Ihr Zeitplan dies zulässt und die Auswirkungen akzeptabel sind. Bei der Ausführung dieser nächtlichen Indexwartungsaufgaben werden nur die Indizes berücksichtigt, die für Neuerstellungen über 30% und für Neuerstellungen im Bereich von 15 bis 30% fragmentiert sind.

  2. Bei diesen Aufgaben handelt es sich um protokollierte Transaktionen. Wenn Sie sich also Gedanken über das Wachstum von Protokollen machen, würde ich das befürworten, was Paul empfohlen hat. Die endgültige Sicherung des Transaktionsprotokolls vor der Indexwartung muss durchgeführt werden. Wechseln Sie zu Einfache Wiederherstellung, gefolgt vom Wartungsprozess, und wechseln Sie dann zurück zu Vollständige Wiederherstellung, gefolgt von einer vollständigen Datensicherung.

Ich verfolge einen Zen-ähnlichen Ansatz für meine Protokolldateien: Sie haben die Größe, die sie haben möchten. Solange sie kein übermäßiges Wachstum durch schlechte Sicherungspraktiken im Vergleich zu Datenbankaktivitäten ertragen, ist dies das Mantra, nach dem ich lebe.

Bei Skripten, die die diskretionäre Indexpflege durchführen, wird online gesucht: Es gibt eine Menge davon. Andrew Kelly hat vor etwa einem Jahr einen anständigen Artikel im SQL Magazine veröffentlicht. SQLServerPedia enthält einige Skripte von Michelle Ufford, und die neueste Ausgabe des SQL-Magazins (Juli 2009, glaube ich) enthält auch einen vollständigen Artikel zu diesem Thema. Es geht darum, eine zu finden, die gut zu Ihnen passt, und sie mit minimalen Anpassungen zu Ihrer eigenen zu machen.

Tim Ford
quelle
2

Können Sie Ihr Transaktionslog an verschiedenen Stellen während Ihrer Datenbankoptimierung speziell sichern? Die Gesamtgröße der T-Logs wäre die gleiche, aber jedes würde kleiner sein, was Ihnen möglicherweise in irgendeiner Weise helfen könnte.

Können Sie eine gezieltere Datenbankoptimierung durchführen, sodass weniger Transaktionen erstellt werden (jemand hat dies erwähnt, aber ich bin nicht sicher, ob die Auswirkungen genau beschrieben wurden)? Zum Beispiel eine gewisse Fragmentierung oder Platzverschwendung für eine Weile tolerieren. Wenn 40% Ihrer Tabellen nur zu 5% fragmentiert sind, können Sie viel Zeit sparen, wenn Sie sie nicht berühren.

ErikE
quelle