Datenbanknahe Verarbeitung präzise entwickeln und untersuchen

Mengenorientiert formulieren und mit tatsächlichen Plänen untersuchen

SQL beschreibt das gewünschte Ergebnis. Der Optimizer entscheidet anhand von Datenverteilung, Statistiken, Parametern und Datenbankkonfiguration, wie dieses Ergebnis erzeugt wird.

Wir untersuchen insbesondere:

• tatsächliche Ausführungspläne
• geschätzte und tatsächlich verarbeitete Zeilen
• Tabellen- und Indexzugriffe
• Join-Reihenfolge und Join-Verfahren
• Filterung und Datenreduktion
• Sortier- und Hash-Operationen
• Partition Pruning
• Parallelverarbeitung
• Bind Variables
• implizite Typumwandlungen
• wiederholte Einzelabfragen
• SQL innerhalb von Schleifen
• Anzahl der Ausführungen
• Buffer Gets, I/O, CPU und Laufzeit
• Auswirkungen konkurrierender Verarbeitung

Ein kostengünstig geschätzter Plan ist noch kein Nachweis für eine schnelle Verarbeitung. Entscheidend sind die tatsächlichen Datenmengen, Bind-Werte und Ausführungsstatistiken unter einer repräsentativen Arbeitslast.

Wir bevorzugen mengenorientierte Verarbeitung, wenn sie die fachliche Regel eindeutig und nachvollziehbar abbildet. Zeilenweise Verarbeitung bleibt dort möglich, wo der Geschäftsprozess oder eine kontrollierte Fehlerbehandlung sie erfordert.

Geschäftslogik kapseln und Verantwortungsgrenzen sichtbar halten

PL/SQL-Packages bündeln Datenbanklogik hinter definierten Schnittstellen. Package Specification und Package Body trennen den von außen sichtbaren Vertrag von seiner internen Umsetzung.

Wir strukturieren:

• öffentliche und interne Prozeduren und Funktionen
• Eingabe-, Ausgabe- und Rückgabewerte
• fachliche Vorbedingungen
• Validierungen
• Zustandsänderungen
• Transaktionsverantwortung
• Fehlercodes und Fehlermeldungen
• Abhängigkeiten zu Tabellen, Views und anderen Packages
• Berechtigungen und Ausführungskontext
• Protokollierung und Messpunkte
• Versionierung und Deployment

Eigene Anwendungen sollen nicht unkontrolliert in die Tabellen eines Standardprodukts schreiben. Wo Hersteller-APIs oder definierte Erweiterungspunkte bestehen, werden sie gegenüber direkten Eingriffen bevorzugt.

Bei Oracle Applications und vergleichbaren ERP-Systemen bleibt dadurch erkennbar:

• welche Logik zum Produktstandard gehört
• welche Funktion konfiguriert wurde
• welche kundeneigenen Packages existieren
• welche Hersteller-APIs verwendet werden
• welche Abhängigkeiten bei Upgrade oder Migration zu prüfen sind
• wer die fachliche und technische Verantwortung trägt

Direkte Änderungen an Produktdaten oder Produktcode bleiben begründungspflichtige Ausnahmen mit ausdrücklich bewerteten Auswirkungen.

Konsistente Zustandsänderungen unter konkurrierender Last führen

Eine Transaktion muss einen fachlich konsistenten Zustandsübergang abbilden. Commit und Rollback dürfen nicht zufällig durch technische Schleifen, Zwischenstände oder einzelne Hilfsfunktionen bestimmt werden.

Wir untersuchen:

• fachliche Transaktionsgrenzen
• Commit- und Rollback-Verantwortung
• Sperrreihenfolge
• konkurrierende Änderungen
• verlorene Aktualisierungen
• wiederholte Verarbeitung
• Idempotenz
• Savepoints
• Undo- und Redo-Verhalten
• lange offene Transaktionen
• Deadlock-Risiken
• Fehler nach teilweiser Verarbeitung
• Wiederaufnahme nach Abbruch

Oracle stellt lesenden Transaktionen über SCN und Undo einen konsistenten Datenstand bereit. Die Anwendung muss dennoch festlegen, welche fachlichen Zustände gemeinsam verändert werden und welche Zwischenstände für andere Prozesse sichtbar sein dürfen.

Bei hoher Parallelität betrachten wir nicht nur die Laufzeit einer einzelnen Verarbeitung. Entscheidend ist, wie viele gleichzeitige Vorgänge möglich sind, ohne dass Sperren, Redo, Undo oder gemeinsame Ressourcen den Gesamtdurchsatz begrenzen.

Große Datenmengen kontrolliert und wiederanlauffähig verarbeiten

PL/SQL und SQL besitzen unterschiedliche Ausführungsbereiche. Häufige Wechsel zwischen PL/SQL und SQL erhöhen den Verarbeitungsaufwand. BULK COLLECT und FORALL können die Zahl dieser Wechsel reduzieren, wenn Mengen, Speicherbedarf und Fehlerbehandlung dazu passen.

Wir bewerten:

• setorientiertes SQL
• BULK COLLECT
• FORALL
• geeignete Batch-Größen
• Speicherbedarf der PGA
• Fehlerbehandlung einzelner Datensätze
• SAVE EXCEPTIONS
• Parallelverarbeitung
• Chunking großer Datenbestände
• Fortschritts- und Statusführung
• kontrollierte Commit-Punkte
• Jobketten und Abhängigkeiten
• Wiederanlauf nach Teilfehlern
• Vermeidung doppelter Verarbeitung

Ein Batch gilt nicht allein deshalb als beherrschbar, weil er im fehlerfreien Fall schnell durchläuft. Er muss erkennen lassen, welche Daten verarbeitet wurden, welche fehlgeschlagen sind und wie ohne widersprüchliche Doppelverarbeitung fortgesetzt werden kann.

Fehlerursache, betroffene Daten und Verarbeitungskontext erhalten

Eine Fehlerbehandlung, die jede Exception in eine allgemeine Meldung übersetzt, erschwert Analyse und Wiederanlauf. Ebenso problematisch ist das unkontrollierte Ignorieren einzelner Fehler, während der Gesamtprozess formal erfolgreich endet.

Wir unterscheiden:

• fachliche Ablehnung
• erwartete technische Ausnahme
• Dateninkonsistenz
• Ressourcen- oder Kapazitätsproblem
• temporären Schnittstellenfehler
• nicht behandelten Programmfehler

Für relevante Fehler halten wir fest:

• Verarbeitungsschritt
• fachlicher Vorgang
• betroffene Identität
• Zeitpunkt und Status
• Oracle-Fehlercode und Fehlertext
• Aufrufkette
• bereits erfolgte Änderungen
• Wiederholbarkeit
• benötigte Korrektur oder Entscheidung

Protokollierung wird so gestaltet, dass sie die Verarbeitung erklärbar macht, ohne selbst zum Performance- oder Speicherproblem zu werden.