none
bis wohin sichert Transactionlog RRS feed

  • Frage

  • Hallo Allerseits,

    mir ist an einer Stelle nicht klar bis wohin das Transactionlog sichert und habe auch im Netz nichts Passendes gefunden - da hoffe ich hier auf euch ;o)

    Ich mache um 22.00 eine Vollsicherung der Datenbank und dann alle 15 Minuten das Transactionlog. Die Transactionsicherung sichert alle Log-Daten bis zur letzten Log-Sicherung - soweit klar.

    Nach dem Prinzip sicher ich dann um 08:00 das Transactionlog und im Normalfalle würde dann die Sicherung um 8:15 bis 8:00 zurückgehen. Was passiert aber, wenn ich um 8:05 ein Vollsicherung starte?  wird dann trotzdem bei der logsicherung bis 08:00 zurückgegangen oder dann nur bis 8:05???

    Hintergrund der Frage:

    Ich sichere die log-Sicherungen per Tool permanent weg sowie nächtlich die Vollsicherung - sollte ich aber tagsüber ein Backup starten (z. B. vor wichtigen Eingriffen in die DB) wird dies nicht direkt weggesichert. Wenn mir aber just an dem Tag der Server abraucht - kann ich dann noch die Daten wiederherstellen oder schlägt es fehl da laut oigen Beispiel eine Log-Datei nicht vollständig ist?

    Hoffe ich konnte mich halbwegs verständlich ausdrücken ;o)Gruß

    Bernd

    Mittwoch, 16. Dezember 2015 09:06

Antworten

  • ...

    ) eine Log Sicherung bezieht sich immer auf die letzte Vollsicherung. Wenn Du um 8:05 Uhr eine Vollsicherung machst, dann bezieht sich die nächste Log Sicherung um 8:15 auf diese und beinhaltet somit den Zeitraum 8:05-8:15.

    2) Wenn Du zur Sicherheit vor einer großen Aktion noch eine Sicherung machen willst, kannst Du auch die Option "COPY_ONLY" nutzen, dann bleibt die vorherige Voll/Log Backup Kette unverändert erhalten und Du hast sozusagen ein "Standalone-Backup", siehe BACKUP (Transact-SQL) => COPY_ONLY


    ...

    Das ist leider beides falsch (1) und (2)

    1) Transaktionsprotokoll-Backups setzen immer am letzten Transaktionsprotokoll-Backup an. Das kann man an den Log-Sequence-Nummern erkennen.

    Vermutlich ist der Umstand, dass man eine Wiederherstellung/ein Restore immer mit einem vollständigen Backup starten muss, der Grund für das Missverständnis.

    2) Da ein Full/Vollständiges-Backup keinerlei Auswirkungen auf die Log-Kette hat, hat auch ein mit "COPY_ONLY" erzeugtes Full-Backup keinerlei Effekt in diesem Szenario.

    Full-Backups mit Copy_Only benötigt man nur, wenn man mit differentiellen Backups arbeitet, da sie die Differential Bitmaps NICHT zurücksetzen.

    LSNs im Transaktionsprotokoll (Log Sequence Numbers) bleiben davon völlig unbeeindruckt. Das Backup selber wird lediglich EBENFALLS protokolliert. Wäre das anders, würde ja jedes Full Backup die Log-Kette unterbrechen und damit alle Log-Backups davor nutzlos machen, sprich bei einem Problem mit dem letzten Backup würde man automatisch Daten verlieren.


    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform, MCM, MVP
    www.SarpedonQualityLab.com | www.SQL-Server-Master-Class.com


    Mittwoch, 16. Dezember 2015 20:48

Alle Antworten

  • Hallo Bernd,

    eine Log Sicherung bezieht sich immer auf die letzte Vollsicherung. Wenn Du um 8:05 Uhr eine Vollsicherung machst, dann bezieht sich die nächste Log Sicherung um 8:15 auf diese und beinhaltet somit den Zeitraum 8:05-8:15.

    Wenn Du zur Sicherheit vor einer großen Aktion noch eine Sicherung machen willst, kannst Du auch die Option "COPY_ONLY" nutzen, dann bleibt die vorherige Voll/Log Backup Kette unverändert erhalten und Du hast sozusagen ein "Standalone-Backup", siehe BACKUP (Transact-SQL) => COPY_ONLY


    Olaf Helper

    [ Blog] [ Xing] [ MVP]


    Mittwoch, 16. Dezember 2015 09:39
  • Hallo Bernd,

    ergänzend zu Olafs Antwort, schau Dir mal an:

    Anwenden von Transaktionsprotokollsicherungen (SQL Server)

    Gruß Elmar

    Mittwoch, 16. Dezember 2015 11:21
  • Hallo,

    Die Transaktionlog Sicherung um 8:15 beinhaltet auch die Logs zwischen 8:00 und 8:05. Wenn es anders wäre würde man keine Point-in-Time Rücksicherung für die Daten dieser 5 Minuten machen können. 

    Es stimmt aber dass alle Transaktionen ab 8:05 auf der neuen Vollsicherung basieren.

    Man kann es ganz leicht prüfen wenn man eine Sicherung vom Stand 8:03 wiederherstellen will, hierfür braucht man auch die LOG Sicherung von 8:15.

    Gruß Benjamin 


    Benjamin Hoch
    MCSE: Data Platform,
    MCSA: Windows Server 2012,




    Mittwoch, 16. Dezember 2015 11:46
  • Hier mal ein kurzes Beispielskript

    /*
    Anlegen einer Testdatenbank und einer Tabelle
    */
    CREATE DATABASE [logdemo]
    ALTER DATABASE [logdemo] SET RECOVERY FULL 
    GO
    USE [logdemo]
    GO
    
    
    create table demo (
    id int identity ,
    c1 char(1000) default 'a')
    
    BACKUP DATABASE [logdemo] TO  DISK = N'C:\Temp\01_logdemo.bak' WITH NOFORMAT, NOINIT,  NAME = N'logdemo-Vollständig Datenbank Sichern', SKIP, NOREWIND, NOUNLOAD,  STATS = 10
    GO
    
    --Einfügen von Datensätzen um Einträge im Logfile zu erzeugen zum Vergleich
    -- Log File Sicherung ca. 4,5 MB Groß
    
    insert into demo values 
    (default);
    go 1000
    BACKUP LOG [logdemo] TO  DISK = N'C:\temp\02_logdemo.trn' WITH NOFORMAT, NOINIT,  NAME = N'logdemo-Log Datenbank Sichern', SKIP, NOREWIND, NOUNLOAD,  STATS = 10
    GO
    -- Log File Sicherung ca. 4,5 MB Groß 
    -- Ende Vorbereitung
    
    insert into demo values 
    (default);
    go 1000
    
    -- Durchführung einer Vollsicherung nach dem Insert
    BACKUP DATABASE [logdemo] TO  DISK = N'C:\Temp\03_logdemo.bak' WITH NOFORMAT, NOINIT,  NAME = N'logdemo-Vollständig Datenbank Sichern', SKIP, NOREWIND, NOUNLOAD,  STATS = 10
    GO
    -- jetzt müsste das Log leer sein da nach der Vollsicherung keine neuen Daten hinzugefügt wurden
    BACKUP LOG [logdemo] TO  DISK = N'C:\temp\04_logdemo.trn' WITH NOFORMAT, NOINIT,  NAME = N'logdemo-Log Datenbank Sichern', SKIP, NOREWIND, NOUNLOAD,  STATS = 10
    GO
    /*
    Tatsächlich hat die Vollsicherung keine auswirkungen auf den Inhalt des LOGs. 
    Erst durch die LOG Sicherung werden die Insert Daten von vor dem Fullbackup aus dem LOG gesichert.


    Benjamin Hoch
    MCSE: Data Platform,
    MCSA: Windows Server 2012,

    Mittwoch, 16. Dezember 2015 19:44
  • ...

    ) eine Log Sicherung bezieht sich immer auf die letzte Vollsicherung. Wenn Du um 8:05 Uhr eine Vollsicherung machst, dann bezieht sich die nächste Log Sicherung um 8:15 auf diese und beinhaltet somit den Zeitraum 8:05-8:15.

    2) Wenn Du zur Sicherheit vor einer großen Aktion noch eine Sicherung machen willst, kannst Du auch die Option "COPY_ONLY" nutzen, dann bleibt die vorherige Voll/Log Backup Kette unverändert erhalten und Du hast sozusagen ein "Standalone-Backup", siehe BACKUP (Transact-SQL) => COPY_ONLY


    ...

    Das ist leider beides falsch (1) und (2)

    1) Transaktionsprotokoll-Backups setzen immer am letzten Transaktionsprotokoll-Backup an. Das kann man an den Log-Sequence-Nummern erkennen.

    Vermutlich ist der Umstand, dass man eine Wiederherstellung/ein Restore immer mit einem vollständigen Backup starten muss, der Grund für das Missverständnis.

    2) Da ein Full/Vollständiges-Backup keinerlei Auswirkungen auf die Log-Kette hat, hat auch ein mit "COPY_ONLY" erzeugtes Full-Backup keinerlei Effekt in diesem Szenario.

    Full-Backups mit Copy_Only benötigt man nur, wenn man mit differentiellen Backups arbeitet, da sie die Differential Bitmaps NICHT zurücksetzen.

    LSNs im Transaktionsprotokoll (Log Sequence Numbers) bleiben davon völlig unbeeindruckt. Das Backup selber wird lediglich EBENFALLS protokolliert. Wäre das anders, würde ja jedes Full Backup die Log-Kette unterbrechen und damit alle Log-Backups davor nutzlos machen, sprich bei einem Problem mit dem letzten Backup würde man automatisch Daten verlieren.


    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform, MCM, MVP
    www.SarpedonQualityLab.com | www.SQL-Server-Master-Class.com


    Mittwoch, 16. Dezember 2015 20:48
  • Hi,

    Danke erstmal für die  ganzen Antworten - hatte auch schon selbst bei MSDN gesucht, aber genau den Artikel mit dem Zeitplan (siehe Elmar) nicht gefunden oder übersehen.

    Der zeigt ja auch das Andreas Recht hat und hat für mich den Vorteil, daß ich mit solch "Zwischenbackups" nichts kaputt machen kann ;o)

    Differntielle Backups sind für mich aussen vor - habe bis heute nicht wirklich den Sinn verstanden diese zu benutzen und ich beschäftige mich nicht mit Dingen die für mich Quatsch sind ;o))

    Gruß

    Bernd


    Bernd Winnemöller

    Montag, 4. Januar 2016 13:49
  • Hallo Bernd,
    noch ein kurzes Wort zu den differentiellen Backups.
    Beispiel:
    Datenbank mit 1 TB
    Änderung am Tag 10 GB

    Vollsicherung wäre 1 TB
    Differentielle Sicherung am Tag 1 10 GB bis hin zu Tag 6 60 GB (Aber nur, wenn andere Pages geändert wurden, als an den Vortagen. Also ist eher ein Volumen < 60 GB am Tag 6 zu erwarten.)
    Tag 7 ist wieder Vollsicherung, obwohl es durchaus Sinn machen könnte, bis zum Tag 100 (oder länger) zu warten.

    Ich denke, der Sinn wird dann schon klar, oder? Sowohl die Dauer/Last, als auch das Volumen (auf Platte) oder die Menge, die durchs Netzwerk geht ist deutlich kleiner.
     Einen schönen Tag noch,
    Christoph
    --
    Data Platform MVP - http://www.insidesql.org/blogs/cmu

    Mittwoch, 6. Januar 2016 07:38
    Beantworter
  • Moin Christoph,

    nicht wirklich klar ;o))

    Bei deinem Beispiel habe ich in der Woche insgesamt 210 GB zu sichern an differentiellen Sicherungen. Wenn ich stattdessen die Transactionlogs sichere habe ich 60GB zu sichern und am Ende das gleiche Ergebnis.

    Einzig mir bekannte Argument ist, daß ich halt alle Transactionlogs benötige zur Widerherstellung. Dies zählt für mich aber eigentlich nur bei Bandsicherungen....

    Gruß

    Bernd


    Bernd Winnemöller

    Donnerstag, 4. Februar 2016 10:06
  • Hallo Bernd

    Die Differenz Sicherungen werden um beim Beispiel von Christoph zu bleiben in den seltensten Fällen so groß werden. Es ist deutlich schneller beim Restore das letzte Vollbackup, dann das letzte Diff Backup und von da an alle Logs wiederherzustellen. 

    Durch das DIFF Backup spart man sich die Wiederherstellung aller LOG Dateien (und damit aller Operationen im LOG) von dem Zeitpunkt des Voll Backup bis zum letzten Diff Backup. 

    Theoretisch kann man nach jedem DIFF Backup alle vorhergehenden DIFF Backup Dateien verwerfen da sie für den Restore nicht mehr nötig sind. (Würde ich aber nicht machen)

    Das Differenz Backup macht gerade bei sehr großen Datenbank mit vielen Änderungen Sinn.

    Gruß Benjamin


    Benjamin Hoch
    MCSE: Data Platform,
    MCSA: Windows Server 2012,

    Donnerstag, 4. Februar 2016 10:24
  • ...

    Bei deinem Beispiel habe ich in der Woche insgesamt 210 GB zu sichern an differentiellen Sicherungen. Wenn ich stattdessen die Transactionlogs sichere habe ich 60GB zu sichern und am Ende das gleiche Ergebnis.

    Einzig mir bekannte Argument ist, daß ich halt alle Transactionlogs benötige zur Widerherstellung. Dies zählt für mich aber eigentlich nur bei Bandsicherungen....

    ...

    Das ist schon nicht ganz falsch.
    Aber: Wer wenn man, um eine RPO von max 15 Minuten zu erreichen jeweils 15-minütige Log-backups macht, hat man nach 6 Tagen über 250 Logfiles. Allein die Datei-Validierung dauert ja auch. Insofern ist es dann idR performanter lediglich eine 60GB-Datei + eine Handvoll Logs wiederherzustellen anstelle 288 Log-Files - auch bei 15.000 RPM Backup-Disks.

    Damit man also auch seine RTO der SLA erreicht, kann das sinnvoll sein ;-)


    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform, MCM, MVP
    www.SarpedonQualityLab.com | www.SQL-Server-Master-Class.com

    Donnerstag, 4. Februar 2016 10:25
  • OK - bei extrem großen Datenbanken mache ich mir nochmal Gedanken darüber - bisher liege ich noch bei allen Kunden unter 1TB was sich aber bald ändern könnte ;o)

    Bernd Winnemöller

    Donnerstag, 18. Februar 2016 11:00
  • Hallo Bernd,

    vielleicht noch eine kleine Bemerkung am Rande. Nicht die reine Größe einer Datenbank ist der entscheidende Punkt bei der Verwendung von Diff Backups. Hier ist der entscheidende Faktor die Anzahl der Transaktionen für die ein Rollforward und dann ein Rollback während der LOG Rücksicherung durchgeführt werden muss.

    Zwar kann man durchaus annehmen dass eine Große Datenbank auch mehr Transaktionen hat aber dies trifft nicht grundsätzlich zu. Nehmen wir eine Datenbank (z.B. 20 GB) in der sehr, sehr viele Insert, Update und Delete Operationen laufen plus Index Rebuild und Reorg, ohne an der Menge der Daten viel zu ändern. Hier brauche man im schlechtesten Fall (kurz vor der wöchentlichen Vollsicherung) bestimmt mehrere Stunden für dem Restore. Mit dem Diff schafft man es in unter einer Stunde.


    Benjamin Hoch
    MCSE: Data Platform,
    MCSA: Windows Server 2012,

    Donnerstag, 18. Februar 2016 12:13
  • Und um noch eines draufzusetzen:

    wenn man eine RTO von 15 Minuten garantieren möchte, MUSS man entsprechend viele Log-Backups einplanen.

    Und dann dauert es beim Wiederherstellen auch, wenn sie praktisch leer sind.

    Da hilft dann auch ein Differentielles Backup. - In dem Fall mag aber auch ein Full Backup alternativ funktionieren, wenn die Datenbank wirklich so klein ist.


    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
    MCM SQL Server 2008
    MVP Data Platform
    www.SarpedonQualityLab.com | www.SQL-Server-Master-Class.com

    Donnerstag, 18. Februar 2016 13:24