4
Änderungen in Tabelle bzw. Datenbank nachvollziehen SQL Server 2008
Hallo zusammen,
von einen auf den anderen Tag verlor eine bestimmte Tabelle in einer Datenbank ihren kompletten Inhalt. Die Daten konnten
alle wiederhergestellt werden, soweit auch wieder alles OK. Doch aus diversen Gründen wäre es nun interessant, den
Hintergrund zu erfahren was in dieser Tabelle passierte.
Der User hat natürlich keinen direkten Zugriff auf die Datenbank und müsste in der Software bei ca. 400 Artikeln je den einen Datensatz löschen...
Der einzige User der Zugang hat bin ich - bin aber in letzter Zeit nicht annähernd an dieser Datenbank gewesen.
Gibt es dazu eine Möglichkeit die Sache ohne riesen Aufwand nachzuvollziehen?
Gruß
Anti108
von einen auf den anderen Tag verlor eine bestimmte Tabelle in einer Datenbank ihren kompletten Inhalt. Die Daten konnten
alle wiederhergestellt werden, soweit auch wieder alles OK. Doch aus diversen Gründen wäre es nun interessant, den
Hintergrund zu erfahren was in dieser Tabelle passierte.
Der User hat natürlich keinen direkten Zugriff auf die Datenbank und müsste in der Software bei ca. 400 Artikeln je den einen Datensatz löschen...
Der einzige User der Zugang hat bin ich - bin aber in letzter Zeit nicht annähernd an dieser Datenbank gewesen.
Gibt es dazu eine Möglichkeit die Sache ohne riesen Aufwand nachzuvollziehen?
Gruß
Anti108
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: 272308
Url: https://administrator.de/contentid/272308
Printed on: April 26, 2024 at 15:04 o'clock
4 Comments
Latest comment
Im Nachhinein nicht.
Im Vorfeld könnte man einen Trigger schreiben der Änderungen an Tabelleninhalten loggt oder sogar unterbindet, wenn sie nicht gewisse Kriterien erfüllen, sagen wir immer nur ein Datensatz pro Update / Delete Anweisung ist betroffen.
Wenn du den Zeitpunkt kennst, an dem das "Problem" auftritt aber nicht den Verursacher ließe es sich noch mit einem Tool wie AnyLab SQL Profiler "mitschnieden", das ist aber sehr viel Information in sehr kurzer Zeit. Das geht wirklich nur zum punktuellen Debugging.
Im Vorfeld könnte man einen Trigger schreiben der Änderungen an Tabelleninhalten loggt oder sogar unterbindet, wenn sie nicht gewisse Kriterien erfüllen, sagen wir immer nur ein Datensatz pro Update / Delete Anweisung ist betroffen.
Wenn du den Zeitpunkt kennst, an dem das "Problem" auftritt aber nicht den Verursacher ließe es sich noch mit einem Tool wie AnyLab SQL Profiler "mitschnieden", das ist aber sehr viel Information in sehr kurzer Zeit. Das geht wirklich nur zum punktuellen Debugging.
Leider wird dieser Vorfall einmalig gewesen sein...
Das interessante für uns wäre eben zu erfahren ob unser SQL Server bzw. ein Fehler unsererseits passiert ist, oder
ob es die Software selbst verursacht hat.
Ein Backup der DB vor und nach dem Vorfall bringt uns hier auch nicht weiter?
Das interessante für uns wäre eben zu erfahren ob unser SQL Server bzw. ein Fehler unsererseits passiert ist, oder
ob es die Software selbst verursacht hat.
Ein Backup der DB vor und nach dem Vorfall bringt uns hier auch nicht weiter?
Nein. Der Server hat in dem gesicherten Zustand die Daten, die habt ihr ja auch schon zurück geholt. In deinem neuen Zustand ist die Tabelle leer. Die DB hat kein Interesse daran sich zu merken wer was wann getan hat und was der Zustand vorher war (solange man ihr das nicht sagt), das würde alles Ressourcen in Form von Performance und Speicherplatz kosten und wäre in 99,9% der Fälle einfach nur Overhead.
OK. Klare Aussage und auch verständlich. Danke!