Eine Geschäftsaktion kann in einer Microservice-Architektur mehrere Datenbanken oder PDBs berühren. Eine globale ACID-Transaktion über alle Services ist dann oft schwer zu betreiben. Das Saga-Muster zerlegt den Ablauf in lokale Transaktionen. Jeder erfolgreiche Schritt veröffentlicht den nächsten Zustand; bei einem Fehler werden zuvor ausgeführte Schritte durch fachliche Kompensationsaktionen ausgeglichen.
1. Geschäftsprozess in lokale Schritte zerlegen
Startpunkt ist nicht die API, sondern der Geschäftsprozess. Für jeden Schritt sollten Service, lokale Datenbank, Statusübergang, Nachricht und mögliche Kompensation beschrieben werden. Ein Bestellprozess könnte beispielsweise Reservierung, Zahlung und Versand nacheinander auslösen.
Jeder Teilnehmer committet seine eigene Transaktion. Der Saga-Koordinator verwaltet die Reihenfolge und den Zustand. Dadurch bleiben lokale Datenbanktransaktionen überschaubar, während die gesamte Geschäftsaktion eine explizite Zustandsmaschine erhält.
2. Kompensationen als fachliche Operationen
Eine Kompensation muss nicht das exakte Gegenteil einer Aktion sein. Eine Zahlung wird vielleicht erstattet, eine Reservierung freigegeben und ein Versandauftrag storniert. Diese Aktionen können eigene Regeln, Fristen und Fehlerfälle haben.
Planen Sie deshalb Idempotenz und Wiederholbarkeit ein. Wenn eine Nachricht doppelt zugestellt oder ein Teilnehmer nach einem Timeout erneut angesprochen wird, darf nicht zweimal erstattet oder freigegeben werden. Eindeutige Saga- und Schritt-IDs helfen, den Zustand fachlich und technisch zu korrelieren.
3. Oracle Saga Framework und Rollen
Oracle AI Database 26ai stellt Saga-APIs für Microservice-Anwendungen bereit. Für PL/SQL-basierte Teilnehmer bietet DBMS_SAGA entsprechende Schnittstellen; bei Anwendungen mit Middleware können JMS-Erweiterungen genutzt werden. Die passende Variante hängt davon ab, ob die Service-Logik innerhalb der Datenbank oder in einem separaten Service ausgeführt wird.
Auch die Rechte gehören in die Architektur. Teilnehmer benötigen die vorgesehene Saga-Rolle; Administratoren und Anwendungen sollten getrennte Accounts und minimale Privilegien verwenden. Die Datenbank darf nicht allein deshalb weitreichende Rechte erhalten, weil sie als Koordinator oder Teilnehmer dient.
4. Zustand, Timeout und Recovery überwachen
Ein Saga-System braucht mehr als technische Logs. Monitoring sollte offene, abgeschlossene, fehlgeschlagene und kompensierte Sagas mit ihren Teilnehmern und Schrittzuständen anzeigen. Timeouts, nicht bestätigte Nachrichten und wiederholte Kompensationen müssen alarmiert werden.
Für Recovery-Fälle muss klar sein, wer einen hängenden Schritt erneut startet, force-committet oder force-rollbackt. Solche Eingriffe gehören in ein freigegebenes Runbook, da sie unmittelbar fachliche Zustände verändern können. Historische Views wie DBA_HIST_SAGAS unterstützen die Analyse abgeschlossener Abläufe.
5. Praktische DBA- und Architektur-Checkliste
- Geschäftsaktion, Teilnehmer, lokale Transaktionen und Kompensationen modellieren.
- Saga-ID, Schritt-ID, Status, Timeout und Wiederholungsstrategie definieren.
- Idempotenz und doppelte Nachrichten in jedem Teilnehmer testen.
- Rollen, Accounts, Queue- oder Messaging-Zugriff und Datenbankgrenzen minimal vergeben.
- Offene Sagas, Kompensationen, Fehler und Laufzeiten zentral überwachen.
- Force-Commit, Force-Rollback und Recovery nur über dokumentierte Runbooks erlauben.
Fazit
Oracle AI Database 26ai unterstützt mit dem Saga Framework Microservice-Transaktionen, ohne alle Teilnehmer in eine globale ACID-Transaktion zu zwingen. Der Preis ist mehr fachliche Modellierung: Kompensationen, Zustände und Nachrichten müssen bewusst gestaltet werden. Mit klaren Rollen, Idempotenz und einem guten Recovery-Runbook wird das Muster auch im Betrieb beherrschbar.
Weiterführend: Oracles Leitfaden zur Entwicklung mit Sagas, die DBMS_SAGA-Referenz und die Neuerungen in Oracle AI Database 26ai.