Transaktionen in T-SQL

Es gibt in der IT kaum ein Konzept, das so viel Vertrauen erfordert und gleichzeitig so viel Misstrauen erzeugt wie die Transaktion. Sie ist der Versuch, Ordnung in das Chaos zu bringen – ein Vertrag zwischen Mensch und Maschine, zwischen Absicht und Umsetzung. Ein „Wenn es schon schiefgeht, dann bitte konsequent!“-Versprechen.

Wer mit Datenbanken arbeitet, weiß: Wir alle jagen der Kontrolle hinterher. Wir wollen, dass unsere INSERTs sicher, unsere UPDATEs zuverlässig und unsere DELETEs rückgängig zu machen sind. Wir träumen von atomaren, konsistenten, isolierten und dauerhaften Zuständen – kurz: ACID. (Atomicity, Consistency, Isolation und Durability). Doch hinter diesem Ideal lauert die Erkenntnis, dass absolute Kontrolle eine Illusion ist.

Dieser Artikel beschreibt explizite Transaktionen. Das Gegenstück sind implizite Transaktionen, die das für sorgen, dass jede Anweisung entweder vollständig oder gar nicht ausgeführt wird. Also kein „halbes DELETE“ weil bei 50 Prozent etwas Unvorhergesehenes passiert und so nur die Hälfte gelöscht werden konnte.

BEGIN TRAN – der erste Vertrauensvorschuss

Es beginnt, wie so viele Beziehungen, mit einem großen Versprechen. BEGIN TRAN – die Zauberformel, mit der der SQL Server und wir Entwickler uns gegenseitig ewige Verlässlichkeit schwören. Ein Satz, kaum getippt, und schon glauben wir, die Welt der Daten unter Kontrolle zu haben. Jedes BEGIN TRAN-Kommando erhöht den Transactions Level um 1 – das wird später für COMMIT und ROLLBACK wichtig.

Doch wer jemals mit Transaktionen gearbeitet hat, weiß: Kontrolle ist ein zartes Pflänzchen. Zwischen Absicht und Realität liegt ein ganzer Ozean aus Sperren, Abhängigkeiten und unerklärlichen Time-outs. Eine Transaktion ist kein Befehl, sondern ein Bekenntnis: Ich verspreche, mich zu kümmern. Alles, was jetzt folgt, soll gemeinsam geschehen oder gar nicht.

Der SQL Server nickt, zieht sich metaphorisch seine Richterrobe über und sagt: „Na schön. Aber ab jetzt beobachte ich dich genau.“ Jede Änderung, jedes Update, jedes DELETE wird notiert – im Transaktionsprotokoll (Transaction Log), dem Tagebuch der Wahrheit. Dort steht später minutiös, was du alles versucht hast – ob du es am Ende durchziehst oder doch kneifst.

Viele Entwickler fühlen sich in diesem Moment mächtig: „Ich entscheide, wann committet wird!“ Aber genau hier beginnt die Illusion. Denn in Wahrheit entscheidet der SQL Server, ob du committest. Und manchmal entscheidet das System auch ganz ohne dich. Ein Netzwerkabbruch, ein Deadlock, ein Stromausfall – und deine schöne Transaktion liegt da wie ein unerledigtes Versprechen: halb gesagt, halb fertig, halb verloren.

COMMIT – der Moment der Wahrheit

Dann kommt der große Augenblick. COMMIT – der Satz, der alles besiegelt. Was vorher nur im Protokoll schlummerte, wird jetzt Realität. Es ist wie das Unterschreiben eines Vertrags, nachdem man das Kleingedruckte zu spät gelesen hat. Allerdings sorgt dieser Befehl nur dafür, dass der Transactions Level um 1 reduziert wird. Und erst wenn dieser anschließend gleich 0 ist, treten alle Modifikationen ein.

Wenn der SQL Server das COMMIT akzeptiert, ist das wie ein stilles „Amen“. Alles ist gespeichert, alles ist gültig. Manchmal fühlt sich das an wie der Moment, in dem man auf „Senden“ bei einer E-Mail klickt – und in dem Sekundenbruchteil merkt, dass der Anhang fehlt. Nur dass man hier keinen „Recall“ hat. 

Der Commit ist endgültig. Das ist seine Stärke – und seine Gefahr. Er ist das „Ja, ich will“ in der Welt der Datenbanken. Kein Zurück, keine zweite Chance. Die einzige Option, die danach bleibt, ist der Versuch, mit einem neuen BEGIN TRAN die Vergangenheit zu überschreiben. Doch wer Beziehungen auf dieser Basis führt, weiß: Das endet selten gut.

Interessant ist, wie viele Entwickler glauben, ein COMMIT sei ein Moment der Kontrolle. In Wahrheit ist er der Moment, in dem man sie verliert. Denn bis zum Commit kann man noch entscheiden, ob man zurückrudert. Danach ist der SQL Server frei, die Änderungen zu schreiben, zu „flushen“, zu optimieren – und du kannst nur hoffen, dass du dich nicht vertippt hast.

ROLLBACK – das Datenbank-Wiedergutmachungsprogramm

Es gibt Tage, da läuft alles schief. Man wollte nur eine kleine Korrektur machen, ein winziges Update – und plötzlich sind 1,2 Millionen Datensätze betroffen. Da steht man dann, in kaltem Schweiß, und murmelt: ROLLBACK – wie ein verzweifeltes Storno an der Supermarktkasse, kurz bevor der Kassenzettel gedruckt wird. Der Rollback ist das Versprechen, dass alles ungeschehen gemacht werden kann. Ein Zurück zum Ausgangspunkt. 

Nur dass der SQL Server auch hier sehr genau ist: Er führt keine Zeitreise durch, sondern rekonstruiert akribisch aus dem Transaktionsprotokoll, was rückgängig gemacht werden muss. Das ist kein Zauber – das ist Buchhaltung. Und wie in jeder guten Buchhaltung kostet jede Korrektur Zeit und Ressourcen. Auch wird dabei der Transactions Level auf 0 heruntergesetzt.

Ein ROLLBACK kann in großen Systemen Minuten dauern – und währenddessen sind Tabellen blockiert, Sessions hängen, Benutzer fluchen. Manche Entwickler sehen im Rollback ein Eingeständnis von Schwäche. Tatsächlich ist er ein Zeichen von Reife. Denn wer nie zurückrollt, lernt nie, was alles schiefgehen kann.

Isolation Levels – Vertrauen, aber bitte getrennt

Jetzt kommen wir zum wahren Kern der Beziehung zwischen Transaktionen: Vertrauen. Isolation Levels sind die Beziehungsregeln im Mehrbenutzerbetrieb. Sie definieren, wie sehr man den anderen traut – oder eben nicht.

• Read Uncommitted ist die offene Beziehung: Jeder darf alles sehen, auch wenn es noch gar nicht feststeht. „Dirty Reads“ nennt man das – romantisch ausgedrückt: Man teilt Gefühle, bevor man sich sicher ist. Schnell, aufregend, aber gefährlich.
• Read Committed ist die klassische monogame Beziehung: Man sieht nur, was offiziell bestätigt ist. Kein Blick auf halb fertige Daten, keine Gerüchteküche. Solide, wenn auch etwas konservativ. Dies ist beim SQL Server Standard.
• Repeatable Read geht einen Schritt weiter: Hier will man Sicherheit. Einmal gelesen bleibt gelesen. Niemand darf dazwischenfunken. Das ist schön – bis jemand merkt, dass dadurch alle blockiert sind.
• Und dann kommt Serializable: der Isolation Level für Kontrollfreaks. Hier wird alles nacheinander abgewickelt, kein Parallelismus, keine Überraschungen. Das System ist sicher, aber langsam. Manchmal fühlt es sich an wie ein Single-Threaded-Dinner mit 200 Gästen.
• SQL Server bietet auch Snapshot Isolation – ein moderner Ansatz. Man lebt in seiner eigenen Kopie der Realität, liest aus Versionsspeichern und glaubt, alles sei stabil. Bis man merkt, dass die Welt sich trotzdem weitergedreht hat.

Isolation Levels sind damit weniger technische Einstellungen als Charakterfragen. Wer zu viel Vertrauen gibt, riskiert Chaos. Wer zu wenig gibt, erstickt am Overhead.

Deadlocks, Sperren und andere Beziehungskrisen

Keine Abhandlung über Transaktionen ist vollständig ohne das Wort „Deadlock“. Das ist der Moment, in dem zwei Transaktionen sich gegenseitig so sehr lieben, dass sie sich nie wieder loslassen.

Transaktion A will Datensatz X, den Transaktion B hält, und Transaktion B will Datensatz Y, den A schon gesperrt hat. Beide warten, beide hoffen, keiner bewegt sich – eine klassische Beziehungskrise. SQL Server greift dann als Paartherapeut ein: „Einer von euch muss loslassen.“ Und zack, eine Transaktion wird abgebrochen. „Deadlock victim“ – das klingt tragisch, ist aber manchmal die beste Lösung.

Sperren (Locks) sind ohnehin ein sensibles Thema. Sie sind wie Nähe: Zu viel davon, und keiner kann mehr atmen; zu wenig, und das Chaos regiert. SQL Server unterscheidet fein zwischen Shared Locks (lesen), Exclusive Locks (schreiben), Update Locks (vorsichtiges Schreiben) und Intent Locks (symbolische Vorwarnungen).

Jede Aktion löst eine Reaktion aus. Und in komplexen Systemen tanzen diese Sperren wie ein Ballett aus Eifersucht und Misstrauen. Deadlocks sind nur das sichtbare Symptom. Darunter liegt das viel größere Thema: Vertrauen in parallele Prozesse. Denn nichts ist so gefährlich wie ein Entwickler, der glaubt, Transaktionen liefen „schon irgendwie durch“.

Fazit

Transaktionen sind wie Beziehungen: Sie beginnen mit Hoffnung, verlaufen chaotisch und enden entweder glücklich oder mit einem Rollback. Sie sind der Versuch, Ordnung in ein chaotisches Universum zu bringen – die Illusion, man könne alle Änderungen kontrollieren. 

Doch wer lange genug mit SQL Server gearbeitet hat, weiß: Kontrolle ist immer nur geliehen. Isolation Levels lehren uns, dass Vertrauen Grenzen braucht. Sperren zeigen, dass Nähe Konsequenzen hat. Und Deadlocks erinnern uns daran, dass zwei gleichzeitige Wahrheiten manchmal nicht koexistieren können. Am Ende geht es bei Transaktionen nicht um Technik, sondern um Verantwortung.

Wer eine Transaktion beginnt, übernimmt die Pflicht, sie zu Ende zu bringen – mit Bedacht, mit Verständnis und im Bewusstsein, dass nichts so gefährlich ist wie ein unbedachtes COMMIT.

SQL Server vergisst nichts. Er vergibt vielleicht, aber er vergisst nicht. Und so bleibt die Transaktion, bei aller Rationalität, das romantischste Konzept der gesamten Datenbankwelt: der Versuch, Vertrauen in Nullen und Einsen zu gießen – in der Hoffnung, dass alles am Ende zusammenpasst.