7
MSSQL - Datensatz wiederherstellen
Welche Möglichkeiten gibt es bei einem Microsoft SQL Server 2005,
einen bestimmten gelöschten Datensatz wiederherzustellen?
Hallo an alle,
ich nutze einen Microsoft SQL Server 2005 auf dem mehrer Datenbanken laufen.
Leider kommt es immer wieder vor das jemand über eine Anwendung versehentlich
einen Datensatz löscht. Die Datenbank wird täglich Abends gesichert.
Um den Datensatz wiederherzustellen gehe ich momentan immer einen
sehr Umständlichen und lang andauernden Weg, da ich es auch nicht besser weiß.
Die Letzte Sicherung als Temporäre Datenbank zurückspielen.
Anhand der Logs den gelöschten Datensatz raussuchen und in die Livedatenbank
überspielen.
Gibt es hier nicht eine einfachere Methode dies durchzuführen?
Ich habe im Netz schon über Transaktionprotokoll und Snapshots gelesen.
Soweit ich das aber verstehe kann man damit nur zu einem bestimmten Zeitpunkt
zurückkehren, nicht aber einen bestimmten Datensatz zurückholen.
Eine richtige Alternative zu meinem Vorgehen konnte ich noch nicht wirklich finden oder
ich gehe die Sache irgendwie falsch an.
Ich bin für jede Anregung, jeden Link und Lektüre zu diesem Problem dankbar.
einen bestimmten gelöschten Datensatz wiederherzustellen?
Hallo an alle,
ich nutze einen Microsoft SQL Server 2005 auf dem mehrer Datenbanken laufen.
Leider kommt es immer wieder vor das jemand über eine Anwendung versehentlich
einen Datensatz löscht. Die Datenbank wird täglich Abends gesichert.
Um den Datensatz wiederherzustellen gehe ich momentan immer einen
sehr Umständlichen und lang andauernden Weg, da ich es auch nicht besser weiß.
Die Letzte Sicherung als Temporäre Datenbank zurückspielen.
Anhand der Logs den gelöschten Datensatz raussuchen und in die Livedatenbank
überspielen.
Gibt es hier nicht eine einfachere Methode dies durchzuführen?
Ich habe im Netz schon über Transaktionprotokoll und Snapshots gelesen.
Soweit ich das aber verstehe kann man damit nur zu einem bestimmten Zeitpunkt
zurückkehren, nicht aber einen bestimmten Datensatz zurückholen.
Eine richtige Alternative zu meinem Vorgehen konnte ich noch nicht wirklich finden oder
ich gehe die Sache irgendwie falsch an.
Ich bin für jede Anregung, jeden Link und Lektüre zu diesem Problem dankbar.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 152637
Url: https://administrator.de/forum/mssql-datensatz-wiederherstellen-152637.html
Ausgedruckt am: 15.04.2025 um 13:04 Uhr
7 Kommentare
Neuester Kommentar
Moin,
eine Möglichkeit wäre es einen Trigger ON DELETE anzulegen, der den Datensatz in eine andere Tabelle wegkopiert, bevor er gelöscht wird. Das erfordert allerdings schon ein bischgen Ahnung von T-SQL und vorallem von der Anwendung.
Transaktionslogs bringen, wie du schon selbst festgestellt hast, nichts da man nicht gezielt einzelne Datensätze zurückholen kann.
Ansonsten: Den Anwendern anständig auf die Finger klopfen (lassen) - wie kann man mehrmals (!) aus versehen einen Datensatz löschen? *kopfschüttel*
lg,
Slainte
eine Möglichkeit wäre es einen Trigger ON DELETE anzulegen, der den Datensatz in eine andere Tabelle wegkopiert, bevor er gelöscht wird. Das erfordert allerdings schon ein bischgen Ahnung von T-SQL und vorallem von der Anwendung.
Transaktionslogs bringen, wie du schon selbst festgestellt hast, nichts da man nicht gezielt einzelne Datensätze zurückholen kann.
Ansonsten: Den Anwendern anständig auf die Finger klopfen (lassen) - wie kann man mehrmals (!) aus versehen einen Datensatz löschen? *kopfschüttel*
lg,
Slainte
Moin,
das Transaktions-Log bringt nichts. Es ist ja lediglich dafür da das eine unterbrochene Aktion rückgängig gemacht werden kann... Dein Löschen wurde aber ja vermutlich dann erfolgreich abgeschlossen ;)
Habt ihr selbst die Anwendung erstellt? In dem Fall würde ich das so machen das man einfach die Anwendung abändert. Ein "Deleted-Flag" einbauen, das auf 1 setzen wenn es gelöscht wurde und gut ist... Das kann sogar der Anwender selbst machen wenn man das entsprechend in die Anwendung einbaut
das Transaktions-Log bringt nichts. Es ist ja lediglich dafür da das eine unterbrochene Aktion rückgängig gemacht werden kann... Dein Löschen wurde aber ja vermutlich dann erfolgreich abgeschlossen ;)
Habt ihr selbst die Anwendung erstellt? In dem Fall würde ich das so machen das man einfach die Anwendung abändert. Ein "Deleted-Flag" einbauen, das auf 1 setzen wenn es gelöscht wurde und gut ist... Das kann sogar der Anwender selbst machen wenn man das entsprechend in die Anwendung einbaut
Moin vschmidt,
ich würde dir ein noch radikaleres Vorgehen als meine beiden geschätzten Vorposter empfehlen.
Wenn denn so ein Aus-Versehen-Löscher um die Ecke biegt mit "Ich habe gestern, als ich angeregt mit meiner Frau telefoniert habe, den Datensatz XY weggebratzt.."
-> "Kein Problem" , sagst du dann, "ich stelle eben eben mal kurz den Datenbankzustand von vorgestern 02:30h wieder her, da war das letzte Full Backup. Und da war der Satz doch bestimmt noch vorhanden, oder?"
Und die anderen 157.000 Anwender, die daraufhin die Dateneingaben von heute und gestern nacharbeiten müssen, denen gibst du seine Telefonnummer.
Nochmal etwas abstrakter:
a) es gibt keine vorgesehene Möglichkeit, einzelne/bestimmte Datensätze wiederherzustellen
b) und zwar ist es nicht implementiert weil die Datenbank insgesamt konsistent sein muss. Was ist denn, wenn du die Rechnung eines Kunden "wiederherstellst", aber dieser Kunde inzwischen aus dem Kundenstamm entfernt wurde? Oder zwischenzeitlich die Außenstände dieses Kunden in die Quartalberichtserstellung eingeflossen sind?
c) und außerdem: für die Änderung der Dateninhalte hat der oben erwähnte DAU die Rechte und die Verantwortung. Nicht du. Du darfst es gar nicht manipulieren.
Und lass dich nicht von irgendwelchen Flurbekanntschaften zu so etwas überreden. Du manipulierst produktive Daten (weil du zufällig DBA bist).
Das ist weder revisionssicher noch professionell.
Grüße
Biber
ich würde dir ein noch radikaleres Vorgehen als meine beiden geschätzten Vorposter empfehlen.
Wenn denn so ein Aus-Versehen-Löscher um die Ecke biegt mit "Ich habe gestern, als ich angeregt mit meiner Frau telefoniert habe, den Datensatz XY weggebratzt.."
-> "Kein Problem" , sagst du dann, "ich stelle eben eben mal kurz den Datenbankzustand von vorgestern 02:30h wieder her, da war das letzte Full Backup. Und da war der Satz doch bestimmt noch vorhanden, oder?"
Und die anderen 157.000 Anwender, die daraufhin die Dateneingaben von heute und gestern nacharbeiten müssen, denen gibst du seine Telefonnummer.
Nochmal etwas abstrakter:
a) es gibt keine vorgesehene Möglichkeit, einzelne/bestimmte Datensätze wiederherzustellen
b) und zwar ist es nicht implementiert weil die Datenbank insgesamt konsistent sein muss. Was ist denn, wenn du die Rechnung eines Kunden "wiederherstellst", aber dieser Kunde inzwischen aus dem Kundenstamm entfernt wurde? Oder zwischenzeitlich die Außenstände dieses Kunden in die Quartalberichtserstellung eingeflossen sind?
c) und außerdem: für die Änderung der Dateninhalte hat der oben erwähnte DAU die Rechte und die Verantwortung. Nicht du. Du darfst es gar nicht manipulieren.
Und lass dich nicht von irgendwelchen Flurbekanntschaften zu so etwas überreden. Du manipulierst produktive Daten (weil du zufällig DBA bist).
Das ist weder revisionssicher noch professionell.
Grüße
Biber
Am besten ist dabei wenn du vom Löscher einen Antrag hast der beinhaltet das du den Datensatz xyz wiederherstellen sollst.
Das auch mit Unterschrfiten versehen ist vom Vorgesetzten ect...
So gibt es immer nen Nachweis wer was wann gelöscht hat und wiso die Datenbank "manipuliert" wurde.
Bei uns gabs wegen sowas schonmal etwas Ärger da ein Datensatz "abhanden" gekommen ist der offene Überweisungen enthielt.
Und einige Leute waren dann später etwas sauer da die kein Geld bekommen haben...
Das auch mit Unterschrfiten versehen ist vom Vorgesetzten ect...
So gibt es immer nen Nachweis wer was wann gelöscht hat und wiso die Datenbank "manipuliert" wurde.
Bei uns gabs wegen sowas schonmal etwas Ärger da ein Datensatz "abhanden" gekommen ist der offene Überweisungen enthielt.
Und einige Leute waren dann später etwas sauer da die kein Geld bekommen haben...
Ich muss auch sagen dein Problem darf es eigentlich nicht geben.
Du musst da wirklich unterscheiden
Manchne Daten darf einfach keiner löschen können.
Andere dürfen nicht alle löschen können.
Und wenn wiklich jemand was löscht muss er sie einfach wieder selbst eintippen.
Auf Datenbank Ebene eine Anwendung zu manipulieren ist wirklich keine gute Idee.
Du musst da wirklich unterscheiden
Manchne Daten darf einfach keiner löschen können.
Andere dürfen nicht alle löschen können.
Und wenn wiklich jemand was löscht muss er sie einfach wieder selbst eintippen.
Auf Datenbank Ebene eine Anwendung zu manipulieren ist wirklich keine gute Idee.
Vielen Dank für eure Antworten und Anregungen.
Eure Antworten bestätigen meine Vermutung, das die Rücksicherung in der Art nicht vorgesehen ist.
Die Anwendung ist nicht von uns, somit können wir hier von der Anwendung aus nicht vorbeugend eingreifen.
Was die Datenbankstruktur angeht, würde ich behaupten dass wir uns hier gut auskennen.
Was die Löschrechte angeht, grenzen wir diese soweit es geht ein, somit haben meist nur zwei Personen
die Möglichkeiten dazu. Und leider schaft es auch der kleine Personenkreis es immer wieder was zu löschen.
Wobei in einigen Fällen, verleiht die die Anwendung vielleicht auch ein wenig zur Fehlbedienung, was den Benutzer natürlich
nicht von seiner Verantwortung entbindet.
Ich bin bei euch, dass meine momentane Vorgehensweise nicht unbedingt der Richtlinie zur Einhaltung der Datenbaknkonsistenz
bzw. der Revisionssicherheit entspricht.
In den bisherigen Fällen, handelte es sich um nicht so kritische Daten, die in eine Verechnung oder so fallen.
Die Frage ist natürlich wie geht man mit sowas um, wenn der Kunde wirklich darauf besteht die Daten zurück zu bekommen.
"Argumentationen wie dafür haben wir doch die Sicherung will jetzt nicht kommentieren"
Einige Vorschläge sind ja schon gefallen..
- Trigger, wäre eine Überlegung wert, zumindest würde dies Zeit einsparen.
- Kunden in die Verantwortung ziehen, ist vermutlich die beste Lösung
Gibt es hier eventuell Rechtliche Grundlagen (Manipulation verboten) auf die man sich berufen kann?
Eure Antworten bestätigen meine Vermutung, das die Rücksicherung in der Art nicht vorgesehen ist.
Die Anwendung ist nicht von uns, somit können wir hier von der Anwendung aus nicht vorbeugend eingreifen.
Was die Datenbankstruktur angeht, würde ich behaupten dass wir uns hier gut auskennen.
Was die Löschrechte angeht, grenzen wir diese soweit es geht ein, somit haben meist nur zwei Personen
die Möglichkeiten dazu. Und leider schaft es auch der kleine Personenkreis es immer wieder was zu löschen.
Wobei in einigen Fällen, verleiht die die Anwendung vielleicht auch ein wenig zur Fehlbedienung, was den Benutzer natürlich
nicht von seiner Verantwortung entbindet.
Ich bin bei euch, dass meine momentane Vorgehensweise nicht unbedingt der Richtlinie zur Einhaltung der Datenbaknkonsistenz
bzw. der Revisionssicherheit entspricht.
In den bisherigen Fällen, handelte es sich um nicht so kritische Daten, die in eine Verechnung oder so fallen.
Die Frage ist natürlich wie geht man mit sowas um, wenn der Kunde wirklich darauf besteht die Daten zurück zu bekommen.
"Argumentationen wie dafür haben wir doch die Sicherung will jetzt nicht kommentieren"
Einige Vorschläge sind ja schon gefallen..
- Trigger, wäre eine Überlegung wert, zumindest würde dies Zeit einsparen.
- Kunden in die Verantwortung ziehen, ist vermutlich die beste Lösung
Gibt es hier eventuell Rechtliche Grundlagen (Manipulation verboten) auf die man sich berufen kann?
Moin vschmidt
Meiner Meinung nach wird es dafür auch Rechtsverbindliches geben, denn dieses Problem hat mit Sicherheit auch schon bei Anderen zu Konflikten und auch zu Prozessen geführt.
--> Ist aber nur eine sbjektive Überzeugung.
Ansonsten kann ich dir da kein Muster-verhalten empfehlen.
Sagen wir so - wenn du mit deinen Kenntnissen der Tabellenstrukturen und -abhängigkeiten felsenfest davonüberzeugt bist, dass dieser eine anstößige Datendsatz keinerlei Seiteneffekte auf andere Datensätze/Tabellen hat, egal, ob er nun "gelöscht" oder "wiedergestellt" ist und du eine schriftliche Anweisung zu dieser Manipulation seitens des Kundens hast... dann mach es (wenn du willst).
Wenn eines von beiden fehlt, dann lass es auf jeden Fall.
Allerdings... wenn dieser eine Datensatz keine Seiteneffekte auf andere Datensätze hat, egal ob vorhanden oder nicht vorhanden - WTF hat ihn der Aus-Versehen-Löscher nicht einfach wieder neu eingetippselt?
Grüße
Biber
Die Frage ist natürlich wie geht man mit sowas um, wenn der Kunde wirklich darauf besteht die Daten zurück zu bekommen.
Gibt es hier eventuell Rechtliche Grundlagen (Manipulation verboten) auf die man sich berufen kann?
Die zweite Teilfrage kann ich als Nicht-Jurist nicht abschliessend beantworten.Gibt es hier eventuell Rechtliche Grundlagen (Manipulation verboten) auf die man sich berufen kann?
Meiner Meinung nach wird es dafür auch Rechtsverbindliches geben, denn dieses Problem hat mit Sicherheit auch schon bei Anderen zu Konflikten und auch zu Prozessen geführt.
--> Ist aber nur eine sbjektive Überzeugung.
Ansonsten kann ich dir da kein Muster-verhalten empfehlen.
Sagen wir so - wenn du mit deinen Kenntnissen der Tabellenstrukturen und -abhängigkeiten felsenfest davonüberzeugt bist, dass dieser eine anstößige Datendsatz keinerlei Seiteneffekte auf andere Datensätze/Tabellen hat, egal, ob er nun "gelöscht" oder "wiedergestellt" ist und du eine schriftliche Anweisung zu dieser Manipulation seitens des Kundens hast... dann mach es (wenn du willst).
Wenn eines von beiden fehlt, dann lass es auf jeden Fall.
Allerdings... wenn dieser eine Datensatz keine Seiteneffekte auf andere Datensätze hat, egal ob vorhanden oder nicht vorhanden - WTF hat ihn der Aus-Versehen-Löscher nicht einfach wieder neu eingetippselt?
Grüße
Biber
