2
MSSQL Recovery mit nur einem Transaktionslog
Hallo MSSQl Admins und Spezialisten,
ich habe ein Problem mit einer MSSQL DB. Wir haben ein Datafile gelöscht. Backup ist von Samstag vorhanden. Ein aktuelles Transactionslog ist auch vorhanden. Auf dem Testsystem klappte ein Recovery wie es in dem Artikel beschrieben ist. Nun meine Frage Warum braucht man ein Backup des aktuellen Transactionslogs um ein Recovery durchzuführen? Es ist doch akuell auf dem System vorhanden.
Warum funktioniert dieser Weg nicht?
1. Ausgangssytuation Datafile gelöscht und DB in Modell Full.
2. Restore von Samstag (Fullbackup) aber without recovery.
3. Restore des aktuellen Transactionslogs welches vorher auf eine weitere Partition verschoben wurde.
Und genau am Punkt 3 tretten die Probleme auf. Man muss als erstes, sozusagen vor dem Punkt 2 ein Backup des aktuellen Transactionslogs machen und kann dann mit dem Punkt 2 beginnen. Dann klappt das Recovery.
Vielleicht gibt es jemanden der das Geheimniss lüftet warum das so ist.
www.dbarecovery.com/lostprimaryfull.html+i+have+transaction+log+datafile+deleted&hl=de&ct=clnk&cd=1&gl=de
ich habe ein Problem mit einer MSSQL DB. Wir haben ein Datafile gelöscht. Backup ist von Samstag vorhanden. Ein aktuelles Transactionslog ist auch vorhanden. Auf dem Testsystem klappte ein Recovery wie es in dem Artikel beschrieben ist. Nun meine Frage Warum braucht man ein Backup des aktuellen Transactionslogs um ein Recovery durchzuführen? Es ist doch akuell auf dem System vorhanden.
Warum funktioniert dieser Weg nicht?
1. Ausgangssytuation Datafile gelöscht und DB in Modell Full.
2. Restore von Samstag (Fullbackup) aber without recovery.
3. Restore des aktuellen Transactionslogs welches vorher auf eine weitere Partition verschoben wurde.
Und genau am Punkt 3 tretten die Probleme auf. Man muss als erstes, sozusagen vor dem Punkt 2 ein Backup des aktuellen Transactionslogs machen und kann dann mit dem Punkt 2 beginnen. Dann klappt das Recovery.
Vielleicht gibt es jemanden der das Geheimniss lüftet warum das so ist.
www.dbarecovery.com/lostprimaryfull.html+i+have+transaction+log+datafile+deleted&hl=de&ct=clnk&cd=1&gl=de
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 98775
Url: https://administrator.de/contentid/98775
Printed on: April 24, 2024 at 14:04 o'clock
2 Comments
Latest comment
Rein vom Datenformat sind aktiven Datenfiles / Logfiles (*.mdf,*.ldf) und das Format der Backupdateien (*.bak) schonmal unterschiedlich, z.B. kann eine BAK mehrere Backups aufnehmen und enthält auch nur benutzte Datenblöcke etc.
Das RESTORE-Kommando versteht sich nur auf BAKs, kann mit einem .ldf also schonmal nix anfangen.
Das Recovery nach einem Absturz aus *.mdf und *.ldf macht die Datenbank-Engine alleine, da wird kein RESTORE-Kommando intern irgendwo ausgeführt, sondern beim Startup anhand der Transaction-IDs die Differenz zwischen Log und Daten erkannt und bereinigt.
Warum man keine LDFs als Ersatz für Backups nehmen kann wird vermutlich irgendwas mit den Transactions-IDs oder Konsistenz zu tun haben.
Was ein interessantes Experiment wäre: 2. machen, dann SQL stoppen, das wegkopierte LDF dem Server unterschieben und gucken ob er beim Startup aus dem "gefüllten" LDF ein Recovery versucht oder nicht ...
Das RESTORE-Kommando versteht sich nur auf BAKs, kann mit einem .ldf also schonmal nix anfangen.
Das Recovery nach einem Absturz aus *.mdf und *.ldf macht die Datenbank-Engine alleine, da wird kein RESTORE-Kommando intern irgendwo ausgeführt, sondern beim Startup anhand der Transaction-IDs die Differenz zwischen Log und Daten erkannt und bereinigt.
Warum man keine LDFs als Ersatz für Backups nehmen kann wird vermutlich irgendwas mit den Transactions-IDs oder Konsistenz zu tun haben.
Was ein interessantes Experiment wäre: 2. machen, dann SQL stoppen, das wegkopierte LDF dem Server unterschieben und gucken ob er beim Startup aus dem "gefüllten" LDF ein Recovery versucht oder nicht ...
experiment schon vorher durchgeführt: Ergebnis negativ. Beim hochfahren meint MSSQL das LDF file wäre nicht das welches zur der Datenbank gehört. Schade!!! Die Idee hatte ich auch schon gehabt 
gruß RObudus
gruß RObudus
