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

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?

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/]

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.

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.

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.

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.

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.

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.