Oracle SQL-Skripte, die von Large-Language-Model (LLM)-Agenten erstellt werden, können auf dem Papier fehlerfrei aussehen und dennoch in der Produktion explodieren. In einer 2,3 Millionen Zeilen umfassenden Legacy-Codebase schleuste ein KI-gesteuerter Agent routinemäßig Identifikatoren ein, die nicht existierten – zum Beispiel die Verwendung von POLICY_STATUS anstelle der tatsächlichen Spalte STATUS_CD oder der Bezug auf eine nicht existierende Tabelle CUSTOMERS anstatt CUSTOMER.

Das Ausführen des Skripts, um den Tippfehler zu finden, ist bei UPDATE- oder DELETE-Anweisungen keine Option. Die Ausführung auf einem produktionsnahen Datensatz führt zu Sperren (Locks), verbraucht Sequenznummern und kann kaskadierende Nebeneffekte auslösen. Entwickler benötigen eine Möglichkeit, Namen und Syntax zu validieren, ohne Daten zu berühren. Die Antwort ist überraschend einfach: der Oracle-Befehl EXPLAIN PLAN – umfunktioniert als Linting-Schritt.

Wie EXPLAIN PLAN als schneller Validator fungiert

Wenn Oracle eine Anweisung erhält, wird sie zuerst geparst. Das Parsen prüft, ob jede referenzierte Tabelle, Spalte und Berechtigung existiert, erstellt dann einen Ausführungsplan und schreibt diesen Plan in eine Systemtabelle. Der Befehl führt die Anweisung niemals aus: Es werden keine Zeilen geändert, keine Trigger ausgelöst und keine Sperren gesetzt. Wenn der Parser auf ein unbekanntes Objekt stößt, wirft er innerhalb weniger Millisekunden einen Fehler aus.

Dieses Verhalten macht EXPLAIN PLAN zu einem perfekten Pre-Flight-Check für KI-generiertes SQL. Eine fehlende Tabelle oder Spalte wird sofort gemeldet, sodass die Generierungsschleife den Fehler korrigieren kann, noch bevor ein Mensch das Skript überhaupt sieht.

Der Workflow, den ich in meine CI-Pipeline integriert habe

  1. Aufteilen des eingehenden Skripts in einzelne Anweisungen.
  2. Ausführen von EXPLAIN PLAN FOR <statement> gegen ein Entwicklerschema.
  3. Sammeln aller vom Oracle-Parser zurückgegebenen Parsing-Fehler.
  4. Zurückgeben der Fehler an das LLM für einen erneuten Versuch (Retry).

In der Praxis bereinigt ein einziger Retry die Mehrheit der Namensfehler. Die KI lernt das korrekte Schema und passt ihre Ausgabe automatisch an. Ich habe den Agenten zudem in den Read-Only-Modus versetzt: Er darf SELECTs und EXPLAIN PLAN-Aufrufe tätigen, aber DDL, DML und COMMIT werden blockiert. Diese Sandbox garantiert, dass die Datenbank unberührt bleibt, während die KI ihre Struktur sondiert.

Über die Namensprüfung hinaus offenbart der generierte Plan offensichtliche Performance-Warnsignale. Wenn eine Anweisung einen Full-Table-Scan auf einer massiven Tabelle auslösen würde, zeigt der Plan dies an, bevor eine einzige Zeile angefasst wird. Dies gibt Entwicklern die Chance, Indizes vorzuschlagen oder das Prädikat umzuschreiben.

Grenzen des Ansatzes

  • Logische Korrektheit wird nicht überprüft. Eine Anweisung, die die richtigen Spalten referenziert, aber den falschen Filter anwendet, besteht den Lint-Check trotzdem.
  • PL/SQL-Blöcke sind nicht abgedeckt. Der Parser verarbeitet nur einzelne SQL-Anweisungen; prozeduraler Code benötigt einen separaten Validierungspfad.
  • Validierung auf Datenebene fehlt. Der Lint kann nicht sagen, ob ein Literaler mit dem Wertebereich einer Spalte übereinstimmt oder ob eine Fremdschlüsselreferenz tatsächlich existiert.
  • Nur Entwicklerschema. Fehler, die nur in der Produktion auftreten – zum Beispiel eine Tabelle, die in der Entwicklung existiert, aber in der Produktion umbenannt wurde – bleiben bis später unsichtbar.

Diese Lücken schmälern den Nutzen der Methode nicht; sie definieren lediglich ihren Umfang. Bei den meisten LLM-generierten DML-Skripten ist der häufigste Fehler ein Tippfehler oder ein falscher Objektname, und genau das fängt EXPLAIN PLAN ab.

Portabilität auf andere Datenbank-Engines

Dasselbe Prinzip gilt über Oracle hinaus. Der PREPARE-Befehl von PostgreSQL oder EXPLAIN kann eine Abfrage ohne Ausführung parsen. SQL Server bietet SET PARSEONLY ON, was die Engine dazu zwingt, Syntax und Objektnamen zu validieren, während die eigentliche Verarbeitung übersprungen wird. Jedes RDBMS, das das Parsen von der Ausführung trennt, kann als leichtgewichtiger Linting-Gate fungieren.

Fazit

Das Ausführen von EXPLAIN PLAN (oder seines Äquivalents) bei jeder KI-generierten SQL-Anweisung verwandelt einen Datenbank-Parser in ein kostengünstiges, risikofreies Linting-Gate. Es fängt die häufigsten Namens- und Syntaxfehler ab, bevor Daten bewegt werden, wodurch Legacy-Systeme stabil bleiben, während Entwickler den Produktivitätsvorteil der LLM-gestützten Programmierung nutzen können.