Der beste Weg, um Transaktionsprotokolle nach einem Zeitplan zu sichern und abzuschneiden

Ich bin kein DBA, aber da die Dinge so sind, wie sie sind, muss ich den DBA-Hut tragen und Wartungspläne für meine SQL Server-Instanz einrichten.

Daher habe ich für eine Weile meinen SSIS-Prozess über Nacht eine SQL-Task ausführen ausführen lassen, um die Sicherungen durchzuführen - im Grunde genommen, master.dbo.xp_create_subdirum sicherzustellen, dass die Zielordner vorhanden sind, und dann BACKUP DATABASE [DbName] TO DISK = 'G:\Backups\DbName\DbName.bak' WITH INIT.

Wenn diese Aufgabe fehlschlug, wurde der Rest des Prozesses abgebrochen und ich erhielt eine Benachrichtigung und kam am nächsten Morgen, um festzustellen, dass das Laufwerk für Transaktionsprotokolle voll war. Daher habe ich sie manuell abgeschnitten und bin weitergegangen. .. bis sich die Story wiederholte und die Transaktionsprotokolle wieder über den verfügbaren Speicherplatz hinauswuchsen.

Das Skript "Manuelles Abschneiden" sieht folgendermaßen aus:

use Staging;
alter database Staging set recovery simple
alter database Staging set recovery full
dbcc shrinkfile ('Staging_log', 0, truncateonly);
go

Ich werde es leid und habe beschlossen, stattdessen zu versuchen, die Dinge richtig zu machen. Befolgen Sie die Schritte hier und erstellen Sie einen tatsächlichen Wartungsplan :

Ich habe das noch nie gemacht, also habe ich ein paar Fragen:

• Wird das Sichern der Transaktionsprotokolle wie diese automatisch abgeschnitten, oder muss ich noch etwas tun?
• Ist es in Ordnung, Daten- und Transaktionsprotokollsicherungen gleichzeitig auszuführen? Wenn nicht, wie geht das dann richtig?
• Die Sicherungsdateien werden über Nacht von einem anderen Prozess abgerufen, der alle Dateien auf dem Server erfasst und an anderer Stelle speichert. Wäre es eine gute Idee, den Sicherungssatz nach 2 Tagen abzulaufen? Muss ich sie überhaupt ablaufen lassen?
• Bereinigungsaufgaben entfernen jeweils "alte" .bak- und .trn-Dateien unter den Unterordnern von G:\Backups. Ist das sinnvoll?
• Wäre es besser, dies in SSIS zu tun, damit ich meine ETL fehlschlagen kann, wenn die Sicherungen fehlschlagen? Oder sollte es meinen ETL-Prozess überhaupt interessieren?

Es tut mir leid, wenn dies zu viele Fragen für einen Beitrag sind. Bei Bedarf werde ich stattdessen mehrere Fragen bearbeiten und stellen. Ich denke, sie sind alle eng miteinander verbunden.

Nur über Nacht schreibt SSIS, tagsüber wird nur gelesen - ich brauche nur eine tägliche Wiederherstellung.

Sie sollten Ihr Wiederherstellungsmodell basierend auf Ihren Geschäftsanforderungen auswählen:

• Wie viel Datengeschäft kann verlieren und gleichzeitig überleben?

Basierend auf der obigen Antwort sollten Sie Ihr Datenbankwiederherstellungsmodell sorgfältig auswählen .

In einfachen Worten (ohne das massenprotokollierte Wiederherstellungsmodell zu diskutieren) ,

• Ein vollständiges Wiederherstellungsmodell ermöglicht Protokollsicherungen, die eine Wiederherstellung zu einem bestimmten Zeitpunkt ermöglichen.
  • Das Abschneiden von Protokollen kann auftreten, wenn Sie Transaktionsprotokollsicherungen durchführen, dh der Speicherplatz der Protokolldatei wird nach jeder Protokollsicherung wiederverwendet und bläht nicht auf!
• Mit einem einfachen Wiederherstellungsmodell können Sie nur vollständige Sicherungen erstellen. Eine Wiederherstellung zu einem bestimmten Zeitpunkt ist nicht möglich.
  • Das Abschneiden von Protokollen kann nur erfolgen, wenn ein Prüfpunkt auftritt (manuell oder automatisch). Wenn Sie also regelmäßig vollständige Sicherungen durchführen, müssen Sie sich keine Gedanken über das Transaktionsprotokoll machen, da CHECKPOINT sich um die Wiederverwendung des inaktiven Teils der Protokolldatei kümmert.

Denken Sie daran, dass das Abschneiden von Protokollen KEINE physische Reduzierung der Größe der Transaktionsprotokolldatei darstellt. Dies bedeutet, dass der inaktive Teil der Transaktionsprotokolldatei als wiederverwendbar markiert ist .

Daher sollten Sie Ihre Transaktionsprotokolldatei (und Datendateien) richtig dimensionieren. Wenn Sie die Protokolldatei vergrößern, werden Autogrowth-Ereignisse ausgelöst (wenn Ihre Datenbank als letztes Mittel auf Autogrow eingestellt ist). Überprüfen Sie meine Antwort - Autogrowth - Prozentuale Nutzung?

Ich würde Ihnen dringend empfehlen, Wartungspläne aufzugeben und [eine intelligente Wartungslösung - die einfach, flexibel ist und den Best Practices folgt] - 5 zu implementieren . - Olas Backup-Lösung (und auch die Index-Wartungslösung ).

Lassen Sie uns Ihre Fragen beantworten:

Wird das Sichern der Transaktionsprotokolle wie diese automatisch abgeschnitten, oder muss ich noch etwas tun?

Bitte hängen Sie keine Backups an und setzen Sie sie nicht auf Ablauf. Sie schaffen ein großes Durcheinander. Verwenden INITund erstellen Sie separate Protokollsicherungen mit Datum / Uhrzeit-Stempel. Leicht zu pflegen. Verwenden Sie dazu die Backup-Lösung von Ola. Die Lösung ist flexibel, um auch alte Backups zu löschen.

Ist es in Ordnung, Daten- und Transaktionsprotokollsicherungen gleichzeitig auszuführen? Wenn nicht, wie geht das dann richtig?

Eine vollständige Sicherung hat keine Auswirkungen auf eine T-Log-Sicherung. Eine vollständige Sicherung enthält nur genügend Transaktionsprotokoll, damit die Datenbank im Falle einer Wiederherstellung transaktionskonsistent zu dem Zeitpunkt sein kann, zu dem der Datenleseteil der vollständigen Sicherung abgeschlossen ist. Überprüfen Sie, wie viel Transaktionsprotokoll eine vollständige Sicherung enthält.

Bei einer Protokollsicherung während einer vollständigen Sicherung wird das Transaktionsprotokoll nicht abgeschnitten. Eine (einige) Protokollsicherung (en) nach Abschluss der vollständigen Sicherung schneidet das Protokoll ab.

Die Sicherungsdateien werden über Nacht von einem anderen Prozess abgerufen, der alle Dateien auf dem Server erfasst und an anderer Stelle speichert. Wäre es eine gute Idee, den Sicherungssatz nach 2 Tagen abzulaufen? Muss ich sie überhaupt ablaufen lassen?

Bereinigungsaufgaben entfernen jeweils "alte" .bak- und .trn-Dateien unter den Unterordnern von G: \ Backups. Ist das sinnvoll? Wäre es besser, dies in SSIS zu tun, damit ich meine ETL fehlschlagen kann, wenn die Sicherungen fehlschlagen? Oder sollte es meinen ETL-Prozess überhaupt interessieren?

Verwenden Sie für beide oben die Backup-Wartungslösung von Ola. Es wird sich um das Löschen alter Dateien kümmern.