Eine einzelne vergessene Transaktion kann wichtige Updates lange auf einem Row Lock warten lassen. In Oracle AI Database 26ai können Anwendungen Transaktionen mit einer Priorität versehen. Wenn eine höher priorisierte Transaktion blockiert wird, darf die Datenbank eine niedrigere blockierende Transaktion automatisch zurückrollen – abhängig von den konfigurierten Wartezeiten.
1. Priorität als fachliche Entscheidung
Transaktionen können auf Session-Ebene als HIGH, MEDIUM oder LOW eingestuft werden. HIGH ist der Standard und wird von dieser Funktion nicht zurückgerollt. MEDIUM kann für HIGH freigegeben werden, LOW kann für HIGH oder MEDIUM weichen, wenn die jeweilige Wartezeit überschritten ist.
Die Anwendung muss diese Einstufung fachlich begründen. Ein Benutzerinterface-Update, ein Finanzabschluss und ein optionaler Hintergrundabgleich haben nicht zwingend dieselbe Priorität. Eine pauschale HIGH-Einstufung nimmt der Funktion den Nutzen und kann weiterhin zu langen Wartezeiten führen.
2. Wait Targets vorsichtig kalibrieren
Die Parameter PRIORITY_TXNS_HIGH_WAIT_TARGET und PRIORITY_TXNS_MEDIUM_WAIT_TARGET definieren, wie lange eine höher priorisierte Transaktion auf den Lock warten darf. Wird der Wert zu niedrig gesetzt, kann eine legitime längere Transaktion zu früh zurückgerollt werden. Bei einem zu hohen Wert bleibt der Schutz vor Blockierung praktisch wirkungslos.
Oracle empfiehlt deshalb, vor dem produktiven Rollback den TRACK-Modus zu verwenden. In diesem Modus werden Statistiken gesammelt, die zeigen, welche Transaktionen zurückgerollt worden wären. So lässt sich das Ziel anhand realer Lock-Wartezeiten statt anhand eines Bauchgefühls bestimmen.
3. TRACK vor ROLLBACK
Der TRACK-Modus ist eine sichere Einführungsstufe: Die Datenbank beobachtet die Situation, führt aber noch keinen automatischen Rollback aus. Nach einem repräsentativen Zeitraum werden Wartezeiten, betroffene Services, Transaktionsdauer und mögliche Fehlalarme ausgewertet.
Erst wenn die Zielwerte plausibel sind, wird in den ROLLBACK-Modus gewechselt. Das sollte als Change mit klarer Rücknahmeoption erfolgen. Für RAC müssen die relevanten Einstellungen konsistent über die Instanzen hinweg betrieben werden.
4. Automatischen Rollback in der Anwendung behandeln
Wenn Oracle eine blockierende Transaktion zurückrollt, bleibt die Session aktiv. Die Anwendung muss den Rollback erkennen und mit einem SQL-ROLLBACK bestätigen. Ohne diese Behandlung können Anwendungen einen unerwarteten Zustand melden oder denselben Vorgang unkontrolliert wiederholen.
Retry-Logik braucht deshalb Backoff, eine maximale Anzahl von Versuchen und eine fachliche Idempotenz. Besonders bei Zahlungs-, Bestands- oder Statusänderungen muss verhindert werden, dass ein erneuter Versuch eine bereits teilweise ausgeführte Aktion doppelt verarbeitet.
5. Praktische DBA-Checkliste
- Row-Lock-Wartezeiten, Blocker und betroffene Services zunächst messen.
- Transaktionsprioritäten gemeinsam mit den Anwendungsteams festlegen.
- TRACK-Modus und Wait Targets in einer realistischen Lastphase beobachten.
- Rollback-Erkennung, Bestätigung und Retry-Logik im Client testen.
- RAC-, Batch-, XA- und Sonderfälle im Betriebsmodell berücksichtigen.
- Rollback-Statistiken, Fehlerraten, Lock-Wartezeiten und Service-Level überwachen.
Fazit
Priority Transactions in Oracle AI Database 26ai geben DBAs und Anwendungen ein neues Werkzeug gegen lang laufende Row-Lock-Blockaden. Der sichere Einsatz beginnt mit TRACK, realen Wartezeitdaten und fachlich begründeten Prioritäten. Erst danach sollten automatische Rollbacks und die zugehörige Retry-Logik produktiv geschaltet werden.
Weiterführend: Oracles Leitfaden zur Verwaltung von Transaktionen, die TXN_PRIORITY-Referenz und die Referenz zu PRIORITY_TXNS_MODE.