Missing in Action – Was würde Chuck Norris tun, um ein Datenleck zu finden?
Missing in Action (MIA – Militärjargon für einen im Einsatz „verloren“ gegangenen Soldaten) waren in unserem Falle Daten, die sich spontan und ohne ersichtlichen Grund verändert haben.
In einem System, das zur Verwaltung von Wertkarten dient, wird in einer Datenbank gespeichert, wie viel Geld ein Benutzer auf seine Wertkarte gebucht hat.
Um zu verhindern, dass der Benutzer „aus Versehen“ sein gesamtes Gehalt auf den Kopf haut, gibt es ein monatliches Limit mit Betrag X. Bei jeder Aufwertung der Karte wird der monatliche Gesamtbetrag in der Datenbank geprüft und nach erfolgreicher Aufwertung gespeichert.
Das System wird von mehreren Tausend Anwendern ohne Probleme verwendet. Doch bei einigen sehr wenigen Benutzern trat ein Fehler auf. Aus dem Nichts heraus wurde der monatliche Gesamtbetrag spontan in der Datenbank auf 0 € zurückgesetzt. Aber wie passierte dieser Fehler?
Was <em>wir</em> getan haben:
Auf der Suche nach dem Datenleck haben wir zunächst eine Codeanalyse vorgenommen und fanden dabei:
NICHTS….
Uns blieb als nächstes die Analyse der in der Datenbank ankommenden Daten. Wir wollten protokollieren, wer die betroffenen Tabellen mit welchen Werten beschreibt. Die erste Lösung erschien also ganz einfach. Ein Systemtrigger, der auslösen musste wenn neue Daten geinserted oder geupdated wurden, sollte eine Protokolltabelle mit Herkunft der Daten und deren Inhalt füllen. Klasse… Das muss uns dem Problem näher bringen…
FALSCH!
Der Systemtrigger würde zwar problemlos alle relevanten Daten protokollieren, braucht dazu aber SA Rechte um den Auslöser der Datenänderung zu identifizieren. Was also in den ersten Tests gut aussah, zeigte sich schnell als Show-Stopper für die reale Welt, denn ohne die entsprechenden Rechte bekommt man Fehler und ein Transaktions-Rollback. Somit kommen zwar keine falschen Daten mehr in der Datenbank an, aber auch keine richtigen….
Nicht gut…
1. Versuch mit dem SQL Server Profiler
Eine alternative Lösung musste her.
Der SQL Server Profiler war das Mittel der Wahl. Auch dieser braucht SA Rechte, wird aber gezielt vom Datenbankadministrator eingesetzt und hat somit nicht die Probleme, dass er für jede Transaktion eigene SA Rechte benötigt.
Eine Vorlage für eine Analyse des Profilers war schnell zusammengebaut und für den Kunden einsatzbereit. Um sicher zu gehen, dass wir den Schuldigen erwischen, haben wir die Vorlage großzügig mit allen relevanten Tabellen und Feldern ausgestattet und nahezu alle relevanten Events des SQL Servers gebucht. In unseren Testläufen bekamen wir problemlos alle Informationen die wir benötigten, um den Fehler zu identifizieren. Eine Schätzung der Serverauslastung ergab, dass nur minimale Reaktionszeitveränderungen im SQL Server zu erwarten waren. Dem Kunden wurde also die Vorlage mit der Bitte zugeschickt, diese auf dem Server 1-2 Wochen laufen zu lassen, um den Fehler sicher zu identifizieren.
Soweit die Theorie. Die Praxis war, dass wir einen extrem kraftvollen Datengenerator geschaffen hatten, denn nach ca. 12 Stunden meldete sich der Kunde bei uns, dass sein Server Performanceeinbußen zeigte und er das Monitoring daher lieber ausschalten wolle. In diesen 12 Stunden hatte der Profiler bereits 2 GB Daten mitgeschrieben, die sich auf insgesamt 2 Mio. Zeilen Protokoll verteilten.
Ideal für eine schnelle Analyse.
Somit war aber klar, dass unser Testsystem einfach doch nicht so genau an die Realität herankommt, wie wir uns das wünschten.
2. Versuch – mit Erfolg
Die Vorlage wurde so überarbeitet, dass sie nur noch exakt die Tabelle beobachtet, die wirklich relevant war. Außerdem wurden die Events des SQL Servers drastisch reduziert und erweiterte Filter eingebaut.
Das Monitoring in gekürzter Version wurde an den Kunden geliefert und in Betrieb genommen. Und siehe da, nach ca. 2 Wochen hatten wir schlanke 50 MB Logfile mit wenigen tausend Zeilen. Und auch den Fehler haben wir damit finden können…
Fazit:
Das Monitoring mit dem SQL Server Profiler ist sehr gut, aber in den Defaulteinstellungen stark überdimensioniert. Man sollte sich genau überlegen, welche Tabellen, Spalten, Statements und Felder des Profilers relevant sein können und auch nur genau diese beobachten. Dann hat man ein schlankes Ergebnis, was auch eine einfache Fehlersuche ermöglicht. Ansonsten, wenn man mal schnell eine große Datei braucht, kann man den Profiler auch super als Datengenerator in einer großen Produktivdatenbank verwenden.
PS: Für alle, die es interessiert, hier der Fehlergrund. Der Fehler lag in einem externen Tool, das sich in einem seltenen Fall einer Netzwerkstörung (das Netzwerk war in genau dem „richtigen“ Moment für eine Zehntelsekunde weg) „verschluckte“, dann mit einem Wert von 0 weiterarbeitete und diesen auch in die Tabelle schrieb.
