it-swarm.com.de

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

Ich habe drei Wartungspläne eingerichtet, die auf einer SQL Server 2005-Instanz ausgeführt werden sollen:

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

Die stündlichen Protokollsicherungen liegen normalerweise zwischen einigen hundert Kb und 10 MB), abhängig von der Aktivitätsstufe. Die täglichen Unterschiede steigen normalerweise 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 dazu führen, dass die nächste Transaktionsprotokollsicherung auf mehr als das Zweifache der Größe der vollständigen Sicherung, in diesem Fall 8 GB, ansteigt, bevor sie zur Normalität zurückkehrt.

Außer BACKUP LOG <DatabaseName> WITH TRUNCATE_ONLY, gibt es eine 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, die ihnen vorausgeht?

38
Dave

Einige interessante Vorschläge, die alle Missverständnisse darüber zeigen, wie Protokollsicherungen funktionieren. 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 erstellt 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. indem Sie zum SIMPLE-Wiederherstellungsmodell wechseln, von einem Datenbank-Snapshot zurückkehren und das Protokoll mithilfe von BACKUP LOG WITH NO_LOG/TRUNCATE_ONLY abschneiden). In diesem Fall die erste Protokollsicherung enthält das gesamte Transaktionsprotokoll seit der letzten vollständigen Sicherung - wodurch die Protokollsicherungskette neu gestartet wird. oder wenn die Protokollsicherungskette 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 auf das SIMPLE-Wiederherstellungsmodell zuzugreifen, 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 von Ihnen durchgeführten Wartungsarbeiten veröffentlichen können, kann ich Ihnen bei der Optimierung helfen. Führen Sie zufällig Index-Neuerstellungen durch, gefolgt von einer verkleinerten Datenbank, um den von den Index-Neuerstellungen verwendeten Speicherplatz zurückzugewinnen?

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
  • erstellen Sie eine endgültige Protokollsicherung (dies ermöglicht Ihnen die Wiederherstellung bis zum Beginn der Wartung)
    • wechseln Sie zum SIMPLE-Wiederherstellungsmodell
    • 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 weitere Infos.

Vielen Dank

[Bearbeiten: Nach all der Diskussion darüber, ob eine vollständige Sicherung die Größe einer nachfolgenden Protokollsicherung ändern kann (es kann nicht), habe ich einen umfassenden Blog-Beitrag mit Hintergrundmaterial und einem Skript zusammengestellt, das dies beweist. Überprüfen Sie es unter https://www.sqlskills.com/blogs/paul/misconceptions-around-the-log-and-log-backups-how-to-convince-yourself/]

35
Paul Randal

Sie könnten sie verkleinern, aber sie wachsen einfach wieder und verursachen schließlich eine Festplattenfragmentierung. Indexwiederherstellungen und -defrags erstellen sehr große Transaktionsprotokolle. 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 vermute, Sie verwenden einen Wartungsplan für die Optimierungen. Sie können ihn ändern, um ein Skript zu verwenden, das Indexdefrags nur dann ausfü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 Differenzen zugunsten täglicher vollständiger Backups überspringen.

5
SqlACID

Ihre letzte Frage lautete: "Abgesehen von BACKUP LOG WITH TRUNCATE_ONLY gibt es eine Möglichkeit, die Größe dieser Protokollsicherung zu verringern oder zu verhindern, dass die Optimierungen überhaupt im Transaktionsprotokoll aufgezeichnet werden, da sie mit Sicherheit berücksichtigt werden denn in der vollständigen Sicherung gehen sie voran? "

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. Bei einigen meiner Server am Samstagabend sehen die Jobpläne beispielsweise folgendermaßen aus:

  • 9:30 PM - Transaktionsprotokollsicherung wird ausgeführt.
  • 9:45 PM - Die Transaktionsprotokollsicherung wird zum letzten Mal ausgeführt. Der Zeitplan endet um 9:59 Uhr.
  • 10:00 PM - Der Indexwartungsjob startet und verfügt über integrierte Stopps, die vor 11:30 Uhr beendet werden müssen.
  • 11:30 PM - Der vollständige Sicherungsjob beginnt und endet in weniger als 30 Minuten.
  • 00:00 Uhr - Die Transaktionsprotokollsicherungen werden alle 15 Minuten erneut gestartet.

Das bedeutet, dass ich zwischen 21.45 Uhr und 23.30 Uhr keine Wiederherstellung zu einem bestimmten Zeitpunkt habe, aber die Auszahlung ist eine schnellere Leistung.

3
Brent Ozar

Einfache Antwort: Ändern Sie Ihren wöchentlichen Optimierungsjob so, dass er jede Nacht ausgewogener ausgeführt wird. d.h. die Tabellen a-e am Sonntagabend neu indizieren, f - l am Montagabend usw. Wenn Sie ein gutes Gleichgewicht finden, wird Ihr Protokoll im Durchschnitt ungefähr 1/6 der Größe haben. Dies funktioniert natürlich am besten, wenn Sie den integrierten ssis-Indexwartungsjob nicht verwenden.

Der Nachteil davon und es ist bedeutend, abhängig von der Last, die Ihre Datenbank erfährt, dass es Chaos mit dem Optimierer und der Wiederverwendung von Abfrageplänen verursacht.

Wenn Sie sich jedoch nur um die wöchentliche Größe Ihres T-Logs 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.

3
Jeremy Lowell

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

2
Steve Jones

Können Sie Ihr Transaktionsprotokoll während Ihrer Datenbankoptimierung an verschiedenen Stellen speziell sichern? Die Gesamtgröße der T-Logs wäre gleich, aber jedes wäre kleiner, was Ihnen möglicherweise irgendwie helfen würde.

Können Sie eine gezieltere Datenbankoptimierung durchführen, damit weniger Transaktionen erstellt werden (jemand hat dies erwähnt, aber ich bin nicht sicher, ob die Auswirkungen dargelegt wurden). B. eine gewisse Fragmentierung tolerieren oder Platz für eine Weile verschwenden. Wenn 40% Ihrer Tabellen nur zu 5% fragmentiert sind, kann das Nichtberühren eine Menge Aktivität sparen.

2
ErikE

Es kann wahrscheinlich davon ausgegangen werden, dass Ihre "Optimierungen" Indexwiederherstellungen umfassen. In einer Datenbank, in der nicht viele Aktualisierungen und Einfügungen vorgenommen werden, ist es möglicherweise akzeptabel, diese Aufgaben nur wöchentlich auszuführen. Wenn Ihre Daten jedoch sehr flüssig sind, möchten Sie möglicherweise einige Dinge tun:

  1. Erstellen oder reorganisieren Sie Ihre Indizes jede Nacht, wenn Ihr Zeitplan dies zulässt und die Auswirkungen akzeptabel sind. Wenn Sie diese nächtlichen Indexwartungsaufgaben ausführen, zielen Sie nur auf die Indizes ab, die für Neuerstellungen über 30% und für Neuorganisierungen im Bereich von 15 bis 30% fragmentiert sind.

  2. Bei diesen Aufgaben handelt es sich um protokollierte Transaktionen. Wenn Sie also Bedenken hinsichtlich des Protokollwachstums haben, würde ich befürworten, was Paul empfohlen hat. Die endgültige Transaktionsprotokollsicherung vor der Indexwartung, 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 gehe meine Protokolldateien zenartig an: Sie haben die Größe, die sie haben möchten. Solange sie aufgrund schlechter Sicherungspraktiken im Vergleich zu Datenbankaktivitäten, nach denen ich lebe, kein starkes Wachstum ertragen haben.

Was Skripte betrifft, die die diskretionäre Indexpflege durchführen, schauen Sie online: Es gibt eine Menge da draußen. 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 Magazine (glaube ich, Juli 2009) enthält auch einen vollständigen Artikel zu diesem Thema. Es geht darum, eine zu finden, die für Sie gut funktioniert, und sie mit minimalen Anpassungen zu Ihrer eigenen zu machen.

2
Tim Ford