Mar 13, 2017

3225

SQL Server löscht Daten von sich selbst aus ?!

Hallo liebe Administrator-Fachwissenden

,

wir benutzen bei uns im Haus seit Jahren ein Programm, dass Daten auf einem SQL-Server speichert. Mittlerweile liegen diese Daten auf einem SQL Server 2008 R2 mit passendem Management Studio. Auf dem Server ist ebenfalls Windows Server Standard 2008 R2 installiert.

Letzte Woche merkten wir, das in einer einzigen Tabelle Daten fehlten. Daraufhin haben wir das ganze untersucht und haben festgestellt dass 60.000 von 62.000 Datensätzen verschwunden sind. Weder im Ereignisprotokoll des Servers, noch im SQL Reporting oder unser Programminternes Reporting Tool hatte irgendeine auffällige Meldung drin.

Das Ganze beunruhigt mich doch sehr und wollte daher mal fragen, ob ihr Ideen habt, was das ganze verursacht haben oder wo man noch nach Fehlerquellen schauen könnte.

Kann es z.B. sein, dass so etwas in der Art passieren könnte, wenn das Programm abschmiert während es eine Anweisung ausführt? Oder wenn von extern die Leute per VPN zugreifen und das dann abschmiert, das da was passieren kann?

Es ist halt sehr seltsam weil es das erste mal in über 10 Jahren ist, das so etwas passiert. Ich hoffe ihr könnt mir weiterhelfen.

Falls ihr noch Infos braucht oder etwas wissen wollt, fragt ruhig.

Grüße

Kev

Please also mark the comments that contributed to the solution of the article

Content-Key: 332024

Url: https://administrator.de/contentid/332024

Printed on: May 10, 2024 at 12:05 o'clock

20 Comments

Latest comment

Moin,

wenn das Programm korrekt geschrieben ist (also Transactions verwendet), können durch "Abschmieren" keine Records aus den Tabellen verschwinden. Genauere Auskunft erteilt sicher der Hersteller/Programmierer.

Wahrscheinlicher ist allerdings eine versehentliche/vorsätzliche Löschung der Datensätze durch einen User/Admin. Wer hat denn bei euch alles die Möglichkeit direkt SQL-Scripts/Befehle auf der DB auszuführen?

lg,
Slainte

Moin,

ich vermute mal, da ist irgendwo versehentlich ein

 DELETE FROM [TABLE_NAME] (WHERE ... )

ausgeführt worden. Insbesondere, wenn es nur diese eine Tabelle getroffen hat...

Von selbst fängt kein SQL-Server an, irgendwas zu löschen. Das würde das Produkt ja dann direkt vom MArkt weg befördern...
Und auch ein Verbindungsabbruch während ein Statement übertragen wird, lässt sich zu 99,9% ausschließen. Wenn dann wären da nur fragmente angekommen, aber ein Abbruch löst kein Löschen aus (außer die Where-Clause ist nicht vollständig angekommen)

Werden da Daten irgendwo über ein Formular reingeschrieben?
Vllt. ist es ja auch eine SQL-Injection gewesen....

Könnt ihr das denn zeitlich eingrenzen? Also wisst ihr, ab welchem Zeitpunkt genau die Datensätze fehlen (weil z.B. ein Zeitstempel in der Tabelle enthalten ist)? Wenn ja, wäre das Zeitfenster schon mal stark einzugrenzen....

Ansonsten müsste man mehrere Datensicherungen mit dem aktuellen Stand abgleichen, um herauszufinden wann die Daten (also ab welchem Tag) verloren gegangen sind

Gruß
em-pie

Erst mal danke für eure Antworten.

@SlainteMhath:

Wir sind die Programmierer des Programms und ich kann dir versichern, dass da kein einziger Quellcode drin ist der auf einmal 60.000 Datensätze löscht, vor allem queerbeet, wenn dann hätten mehrere Löschbefehle folgen müssen und das hätten wir zu 100% bemerkt.

Auf der DB haben nur 3 Leute aus der IT zugriff sonst niemand. Im Programm allerdings können mehrere Leute Datensätze löschen, allerding immer nur einzelne.

@em-pie:

Deine Beschreibung klingt einleuchtend und zum selben Schlussfolgerung bin ich auch gekommen, nur hilft mir das leider nicht weiter, da das eine absolute Datentechnische Katastrophe für uns ist wenn das öfters vorkommen sollte, daher brauch ich zumindest einen Anhaltspunkt, was es sein könnte.

Wir können die Löschung der Daten wann es passiert ist eingrenzen ja es muss irgendwann am 10.03 passiert sein, ABER wenn ich mir die übrig gebliebenen Daten in der Tabelle anschaue ist kein einziger Filter auszumachen nach dem hätte gelöscht werden können. Datum des Erstellens, Bearbeitens, MA, IDs usw... alles ist querbeet drin, nicht greifbares.

Wir haben auch schon versucht anhand von Select-befehlen in der zurückgespielten Vollständigen Tabelle genau auf die 2000 Datensätze zu kommen, ohne Erfolg bisher leider.

Gruß
Kev

Und wie sieht es mit folgender Theorie aus:
Jemand hat versehentlich das Delete * from ausgelöst und es 1 Sekunde später bemerkt und das Löschen abgebrochen....

Und wenn über die Transaction-Logs nicht zu identifizieren ist, kann/ wird das löschen ggf. nicht via der Transaction-Statements ausgeführt worden sein...
Habt ihr mal in die Transaction-Logs reingeschaut?
http://stackoverflow.com/questions/4507509/how-to-view-transaction-logs ...

Ich habe gerade mal reingesehen und leider finde ich mich da kaum zurecht, weil nicht mal ein Datum vorhanden ist, nach dem ich schauen könnte, woher weiß ich denn welcher befehl wann abgeschickt wurde?

Gruß
Kev

Dann schaue dir einmal diesen Code an

DECLARE @TableName sysname
SET @TableName = 'dbo.Table_1'  

SELECT
    u.[name] AS UserName
    , l.[Begin Time] AS TransactionStartTime
FROM
    fn_dblog(NULL, NULL) l
INNER JOIN
    (
    SELECT
        [Transaction ID]
    FROM 
        fn_dblog(NULL, NULL) 
    WHERE
        AllocUnitName LIKE @TableName + '%'  
    AND
        Operation = 'LOP_DELETE_ROWS'  
    ) deletes
ON  deletes.[Transaction ID] = l.[Transaction ID]
INNER JOIN
    sysusers u
ON  u.[sid] = l.[Transaction SID]

Quelle: http://dba.stackexchange.com/questions/4269/how-to-find-out-who-deleted ...

Das müsste dir auch helfen

Ohne genaues Verständnis der Daten und der Vorgänge in der DB läßt sich von Außen leider nicht viel sagen. Ich würde aber blind Wetten, das der Server nicht "ausversehen" oder unabsichtlich Daten verloren hat. Auch würde ich einen Hardware-Fehler ausschließen.

Auch sehe ich es als warscheinlich an, das die Daten eine oder (wenige) mehrere Gemeinsamkeiten haben oder hatten. Mehrere einzelne Löschvorgänge auf zufällige Daten wären aufwendig, Zufälliges Löschen ist auch nicht so einfach und müsste mutwillig so geschrieben worden sein. Bleiben also nur drei Möglichkeiten:
- Mutwillig
- Gemeinsamkeit(en) vorhanden
- Abgebrochene Transaktion wie es em-pie beschrieben hat

Der Zeitpunkt der Löschnung der Datensätze wird immer dann eine Rolle spielen, wenn der Vorgang aus dem Inneren kommt. Wenn irgendwer irgendwas ausgeführt hat oder verändert hat. Wenn jemand Code getestet hat oder grade gefeuert wurde. Ist das ganze Bestandteil einer Aktion von Außen (Angriff auf ein Webinterface) ist der Zeitpunkt vermutlich purer Zufall.

Für zukünftige Datenverluste kannst du auf jeden Fall einen Trigger auf die Tabelle setzen und kannst den Datum, Zeit, User und / oder die Daten mit loggen.

@em-pie:

kann es sein, dass der Befehl nur Transactions vom heutigen Tag anzeigt?

oder das der Transaction Log regelmäßig gelöscht wird?

@ukulele-7:

Das Problem an dem ganzen ist die willkürlichkeit des Phenomens, wenn jemand von außen oder innen mutwillig das Ganze getan hätte, wieso nur diese eine Tabelle? wieso nicht alle Datensaätze?

Darüberhinaus kann ein normaler User keine DS löschen zumindest keine 60.000, da bräuchte er schon fast den ganzen Tag.

Gruß

Kev

oder das der Transaction Log regelmäßig gelöscht wird?

Normalerweise wirds das Log nachdem es gesichert wurde ge-truncated

Also zufällig löschen ist, wie du auch selbst festgestellt hast, ungewöhnlich und aufwendig, daher gehe ich davon aus das es irgendeinen Zusammenhang geben wird oder es wirklich mutwillig war. Du siehst keinen Zusammenhang, das macht es schwer, aber er könnte dennoch da sein. Der Zusammenhang könnte sehr viel Aufschluss darüber geben warum es passiert ist, daher würde ich an deiner Stelle Zeit in die Suche investieren.

Also ich werde nochmal nachschauen, aber für mich sieht das im ersten Augenblick willkürlich aus.

Weder Ersteller, noch Erstelldatum, IDs oder sonst was ist in irgendeinem Schema erkennbar...

Vielleicht ist das Löschen auch über ein JOIN erfolgt und das Schema welches es zu finden gilt, basiert auf einer anderen Tabelle!?

Auch eine Idee, werde ich mir mal näher anschauen.

Aber auf den ersten Blick scheint selbst das nicht zu stimmen, denn wir haben einige IDs drinne stehen, die sind auch willkürlich durcheinander und n:m Tabellen haben wir keine zu der betroffenen Tabelle.

Hmm..

naja, je nachdem, wir eure Tabellen aufgebaut sind, wäre es ja u.U. so möglich:
Deine lückenhafte Tabelle nennt sich Tbl_A, die gejointe Tabelle wäre Tbl_B, dann könnte es wie folgt aussehen

delete from Tbl_A
INNER JOIN Tbl_B on Tbl_A.Field1 = Tbl_B.Field1
where Tbl_B.Field3 <'2017-03-01 12:25:00.000'  

Ob das denkbar ist, weiss ich nicht, da wir ja eure Tabellen- und Beziehungsstruktur nachvollziehbarerweise nicht kennen (kein Vorwurf, nur eine Anmerkung).

ich habs gefunden, mit Mühe und not, es scheint das alle Datensätze rausgelöscht worden zu sein wo keine Teilprojekt ID drin steht

Jetzt muss ich nur noch herausfinden wo das herkommt, bzw. wer das ausgelöst hat...

Danke für eure Hilfe

Das kann auch ein zunächst total abwegig erscheinender Zusammenhang sein, z.B. eine von 3 Spalten ist NULL während es die anderen 2 nicht sein dürfen. Aber auch eben nur ein frei gewähltes Beispiel.

Es ist eigentlich unmöglich auszuschließen, das es einen Zusammenhang gibt. Der Zusammenhang kann aber Aufschluss darüber geben warum die Daten vielleicht versehentlich gelöscht wurden.

Wie anonym sind denn die Daten, könnte man einen Auszug von sagen wir den ersten 100 Zeilen bei einem Select ohne Sortierung hier posten?

Okay dann gibt es dort vielleicht irgendeinen Vorgang in der Software der Teilprojekte löscht oder "bereinigt" und ausversehen zu weit gefasst ist weil eine Where-Einschränkung fehlt.

jap, im formular Teilprjekte gibt es ein Befehl "Delete from table where teilproj_id = " + Variable

und in der Variable scheint aus irgendeinem Grund '0' drin gestanden zu haben, warum unsere Log-Funktion das aber nicht erfasst hat und wie es sein kann dass da 0 drin steht ist wieder eine andere Sache

Eigentlich sollte man auch zwischen NULL und 0 differenzieren, hätte hier geholfen

ja gut normalerweise sollte bei diesem Befehl weder 0 noch NULL drin stehen, da man den Löschbefehl nur ausführen kann, wenn man gerade auf einem teilprojekt steht

aber ich habe jetzt vorher trotzdem eine Abfrage rein gebaut und werde wohl mal einen SQL-Trigger testen um zukünftige Delete befehle loggen zu können

German Question Windows Server Microsoft

Hotly discussed

Wireguard with systemd and nftablesLinuxero - 9 Comments