Für ein UPDATE anhand einer anderen Tabelle waren in Oracle häufig korrelierte Unterabfragen, Inline-Views oder MERGE-Statements nötig. Oracle AI Database 26ai unterstützt Direct Joins für UPDATE und DELETE: Eine FROM-Klausel kann die Quelltabelle oder Filtertabelle direkt angeben. Das macht die Absicht des DML-Statements sichtbarer – erhöht aber auch die Verantwortung, Join-Eindeutigkeit und betroffene Zeilen vor dem Commit zu prüfen.
1. UPDATE mit Quelltabelle
Die FROM-Klausel kann Werte für die Zielspalte liefern. Ein typischer Fall ist die Übernahme eines berechneten oder gepflegten Werts aus einer Referenztabelle:
UPDATE employees e
SET e.salary = j.max_salary
FROM jobs j
WHERE j.job_id = e.job_id;Die Zielspalte links vom Gleichheitszeichen muss aus der Zielrelation stammen. Die Quelltabelle liefert den neuen Wert oder schränkt die zu ändernden Zeilen ein. Trigger auf der Zieltabelle werden weiterhin normal ausgelöst.
2. ORA-30926 früh verhindern
Das UPDATE darf jede Zielzeile höchstens einmal ändern. Liefert die Join-Bedingung für eine Zielzeile mehrere Quellzeilen, schlägt das Statement mit ORA-30926 fehl. Das ist ein wichtiger Schutz: Oracle wählt nicht einfach beliebig einen Quellwert aus.
Vor dem UPDATE sollte deshalb ein Prüf-SELECT laufen, der doppelte Treffer sichtbar macht:
SELECT e.employee_id, COUNT(*) AS matches
FROM employees e
JOIN jobs j ON j.job_id = e.job_id
GROUP BY e.employee_id
HAVING COUNT(*) > 1;Wenn Mehrfachtreffer fachlich möglich sind, muss der Quellbestand zuerst über eine eindeutige Regel reduziert werden – etwa mit einer geprüften Aggregation oder einer fachlich begründeten Auswahl. Ein zufälliges ROWNUM = 1 versteckt dagegen einen Datenfehler.
3. DELETE mit klarer Zielrelation
Auch DELETE kann eine FROM-Klausel nutzen. Die Tabelle nach DELETE FROM ist das Ziel; die Tabellen in FROM liefern die Join-Bedingung:
DELETE FROM orders o
FROM customers c
WHERE c.customer_id = o.customer_id
AND c.status = 'CLOSED';Wenn eine Zielzeile durch mehrere passende Quellzeilen gefunden wird, wird sie nicht mehrfach gelöscht. Trotzdem sollte die Join-Logik eindeutig und fachlich verständlich bleiben. Vor einem produktiven DELETE gehören ein SELECT mit identischer FROM-/WHERE-Logik, eine Trefferzählung und – je nach Kritikalität – ein gesicherter Wiederherstellungsweg ins Runbook.
4. Syntaxgrenzen und Betriebsfolgen
Die DML-Zielrelation wird weiterhin separat angegeben; ANSI-Join-Syntax darf nicht beliebig mit der Zielklausel vermischt werden. In der FROM-Klausel sind Joins möglich, rechte und vollständige Outer Joins sind jedoch nicht erlaubt. Für komplexe Datenbewegungen kann MERGE weiterhin die passendere Wahl sein, besonders wenn INSERT und UPDATE gemeinsam fachlich geregelt werden müssen.
Direct Joins ändern außerdem nichts an Locking, Undo, Triggern oder Commit-Verhalten. Große UPDATEs und DELETEs sollten mit realistischen Datenmengen, passenden Indizes und einem gemessenen Undo-/Redo-Bedarf getestet werden. Ein lesbareres Statement ist nicht automatisch ein günstigerer Ausführungsplan.
5. Sicheres DML-Runbook
- Identische Join- und Filterlogik zunächst als SELECT ausführen.
- Trefferanzahl, Nullwerte und Mehrfachtreffer vor dem DML prüfen.
- Bei UPDATE die Eindeutigkeit pro Zielzeile nachweisen.
- Bei DELETE Zielrelation, Backup-/Recovery-Weg und Transaktionsgrenze festlegen.
- Ausführungsplan, Locks, Undo, Trigger und Fehlerlogging in Test und Produktion beobachten.
- Erst nach fachlicher Freigabe committen und das Ergebnis verifizieren.
Fazit
Direct Joins für UPDATE und DELETE in Oracle AI Database 26ai machen relationale DML-Logik kompakter und verständlicher. Der produktive Einsatz steht und fällt mit eindeutigen Join-Schlüsseln, dem Schutz vor Mehrfachtreffern und einem SELECT-first-Runbook. So bleibt die neue Syntax ein kontrollierter Vorteil statt eine schwer nachvollziehbare Massenänderung.
Weiterführend: Oracles UPDATE-Referenz mit Direct Join, die DELETE-Referenz und die SQL-Neuerungen in 26ai.