Antwort.

Hintergrund des Problems
Bei der Verarbeitung von Geschäftslogik müssen häufig Daten in mehreren miteinander verbundenen Tabellen geändert werden. Wenn etwas nicht erfolgreich abgeschlossen wird (z. B. aufgrund einer verletzten Einschränkung), ist es wichtig, nicht nur die letzte Operation, sondern alle Aktionen im Rahmen der Logik zurückzusetzen. Zu diesem Zweck werden Transaktionsmechanismen und Fehlerbehandlung eingesetzt.

Problem
Nicht alle DBMS unterstützen standardmäßig das Rollback bei Fehlern in mehrstufigen Verfahren (insbesondere wenn TRY/CATCH, EXCEPTION-Handler verwendet werden). Eine falsche Implementierung der Transaktionslogik kann zu "stückhaften" Änderungen führen (ein Teil der Daten wurde aktualisiert, ein anderer nicht), was die Geschäftsintegrität gefährdet.

Lösung
Zur korrekten Behandlung werden explizite Transaktionsöffnungen und -abschlüsse (BEGIN TRANSACTION, COMMIT/ROLLBACK) mit Fehlererfassung verwendet. Der Syntax und die Möglichkeiten variieren in verschiedenen DBMS.

Beispiel für MS SQL Server:

CREATE PROCEDURE update_balances(@from INT, @to INT, @amount DECIMAL(10,2))
AS
BEGIN
  BEGIN TRY
    BEGIN TRANSACTION;
      UPDATE accounts SET balance = balance - @amount WHERE id = @from;
      UPDATE accounts SET balance = balance + @amount WHERE id = @to;
    COMMIT TRANSACTION;
  END TRY
  BEGIN CATCH
    ROLLBACK TRANSACTION;
    INSERT INTO error_log(err_message, err_date) VALUES(ERROR_MESSAGE(), GETDATE());
    THROW; -- Wir werfen den Fehler weiter
  END CATCH
END;

Für PostgreSQL:

CREATE OR REPLACE FUNCTION update_balances(from_id INT, to_id INT, amount NUMERIC)
RETURNS void AS $$
BEGIN
  UPDATE accounts SET balance = balance - amount WHERE id = from_id;
  UPDATE accounts SET balance = balance + amount WHERE id = to_id;
  -- Eine Ausnahme wird die Transaktion automatisch zurücksetzen
EXCEPTION WHEN OTHERS THEN
  INSERT INTO error_log(err_message, err_date) VALUES(SQLERRM, NOW());
  RAISE;
END;
$$ LANGUAGE plpgsql;

Wesentliche Merkmale:

• Wir öffnen und schließen die Transaktion explizit.
• Wir behandeln Fehler im Catch/Exception-Block und setzen Änderungen zurück.
• Wir protokollieren Informationen über Fehler zur Überprüfung.

Trickfragen.

Kann ein Fehler innerhalb einer Stored Procedure immer automatisch die Transaktion zurückrollen? Nein! Zum Beispiel, im MS SQL Server ist ein Rollback nicht garantiert — ein explizites ROLLBACK ist erforderlich. In PostgreSQL wird bei jedem Fehler die gesamte Transaktion "beschädigt" und erfordert Abschluss.

Kann man innerhalb einer einzigen Prozedur "teilweise" committen? Schlechte Praxis. Es wird empfohlen, commit/rollback nur einmal am Ende der Geschäftsoperation durchzuführen. Einige Plattformen ermöglichen "savepoints", aber das ist für Spezialaufgaben.

Welche Fehlertypen können nicht über TRY/CATCH/EXCEPTION in SQL erfasst werden? Einige Systemfehler (z. B. Verbindungsabbruch zum Server) gelangen nicht in den Handler und können ein Rollback unmöglich machen.

Typische Fehler und Anti-Pattern

• COMMIT ohne Fehlerbehandlung hinterlassen: Wir protokollieren "beschädigte" oder teilweise geänderte Daten in der Datenbank.
• Mehrere COMMIT/ROLLBACK innerhalb einer Geschäftsoperation.
• Ignorieren der Fehlerprotokollierung.

Beispiel aus dem Leben

Negativer Fall

Die Stored Procedure aktualisierte drei Tabellen und endete mit einem COMMIT ohne Fehlererfassung. Infolgedessen waren bei einem Fehler in der zweiten Tabelle die erste bereits geändert, und es musste stundenlang manuell aus Backups "rückgängig gemacht" werden.

Vorteile:
Einfach und "funktioniert", bis ein Fehler auftritt.

Nachteile:
Risiko der Inkonsistenz; Es ist unmöglich, sich bei Fehlern schnell zu erholen.

Positiver Fall

Wir implementierten explizite Fehlerbehandlung + Rollback von Transaktionen mit Protokollierung aller Fehler in einem separaten Log. Die Rückkehr zu einem konsistenten Zustand der Datenbank dauert Sekunden, Fehler werden analysiert und minimiert.

Vorteile:
Garantie der Unveränderlichkeit der sauberen Daten selbst bei Fehlern; transparente Logik.

Nachteile:
Ein wenig schwieriger für Anfänger, erfordert Disziplin im Code.