Oracle Datenbank & PL/SQL – Entwicklung, Migration und Performance-Tuning

Positionierung

Oracle ist für viele Unternehmen die Kerndatenbank für unternehmenskritische Anwendungen. Gleichzeitig ist Oracle eine der komplexesten Datenbankplattformen am Markt: Das Instanzmodell mit SGA, PGA und Hintergrundprozessen, die PL/SQL-Sprache mit ihren eigenen Konventionen, die Feinheiten des Optimizer-Verhaltens und die besondere Komplexität von Migrationsprojekten machen Oracle-Expertise zu einem spezialisierten Gebiet. Ich arbeite mit Oracle-Datenbanken seit den frühen 2000ern – von Oracle 8i über 10g, 11g, 12c und 18c bis zur aktuellen Generation 19c. Diese Bandbreite erlaubt mir, sowohl ältere Systeme zu verstehen als auch moderne Oracle-Features gezielt einzusetzen.

Was meine Arbeit mit Oracle auszeichnet, ist die Kombination aus PL/SQL-Entwicklungstiefe und dem breiten Erfahrungsschatz aus Migrationsprojekten. Viele Auftraggeber kommen zu mir, wenn ein Oracle-Altsystem abgelöst werden soll: Java-Anwendungen mit Oracle-Backend, die auf .NET und SQL Server migriert werden müssen, oder Oracle-ETL-Prozesse, die durch moderne SSIS-Strecken ersetzt werden sollen. Ich kenne beide Seiten – das Oracle-Quellsystem und die SQL-Server-Zielplattform – und kann daher Migrationsprojekte ohne den üblichen Wissenstransfer zwischen zwei Spezialisten durchführen.

Hinzu kommt meine Erfahrung im Bereich Oracle-Performance. Ein schlecht optimiertes PL/SQL-Paket oder eine Abfrage ohne passenden Index kann eine Oracle-Datenbank empfindlich belasten. Explain Plan-Analysen, der Einsatz von Optimizer-Hints, die korrekte Verwendung von Bind-Variablen und das Index-Design sind Werkzeuge, mit denen ich Performance-Probleme systematisch angehe und nachhaltig behebe. Diese Kombination aus Entwicklungs-, Migrations- und Performance-Kompetenz ist der Mehrwert, den ich in Oracle-Projekte einbringe.

Oracle von 8i bis 19c

Oracle-Datenbanken haben sich über mehrere Jahrzehnte zu einem komplexen Ökosystem entwickelt. Version 8i brachte Internet-Integration, 9i verbesserte Real Application Clusters, 10g einführte Grid Computing und automatisches Speichermanagement (ASSM), 11g stärkte die Data Guard- und RAC-Fähigkeiten, 12c einführte die Multitenant-Architektur mit CDB und PDB, und 18c sowie 19c festigten die Langzeitversion der modernen Oracle-Generation. Jede Version brachte neue PL/SQL-Features, neue Optimizer-Technologien und neue Administrationswerkzeuge. Diese Versionsbreite ist in Legacy-Umgebungen von erheblicher praktischer Bedeutung: Viele Installationen laufen noch auf Oracle 11g oder 12c, und Code, der dort funktioniert, setzt andere Verhaltensweisen voraus als aktueller 19c-Code.

Oracle-Editionen und Lizenzkostenrelevanz

Oracle ist in verschiedenen Editionen erhältlich: Oracle Database Express Edition (XE) für kleine Umgebungen und Entwicklung, Standard Edition 2 (SE2) für kleinere Produktionsumgebungen und Enterprise Edition (EE) für den vollen Funktionsumfang. Die Lizenzierungslogik von Oracle – insbesondere die Prozessor-basierte Lizenzierung der Enterprise Edition – ist ein wesentlicher Treiber für Migrationsprojekte. Wenn ein Unternehmen Oracle EE durch SQL Server Standard oder Enterprise ersetzt, können Lizenzkosten erheblich reduziert werden. Diesen Lizenzaspekt berücksichtige ich bei Migrationsentscheidungen immer explizit, denn er ist oft der entscheidende Grund, warum ein Projekt überhaupt angestossen wird.

Typische Oracle-Workloads

Im Projektalltag begegne ich Oracle-Datenbanken in drei typischen Rollen: als Backend für Java-Anwendungen mit JDBC-Zugriff, als ETL-Quelldatenbank (oft zusammen mit ODI, Informatica oder eigenem PL/SQL) und als Kerndatenbank für Abrechnungs- und Versicherungssysteme mit umfangreicher Stored-Procedure-Logik. Diese Rollen erfordern unterschiedliche Schwerpunkte: JDBC-lastige Anwendungen leiden typischerweise unter fehlenden Bind-Variablen und Parse-Overhead; ETL-Umgebungen profitieren am meisten von Bulk-Collect-Optimierungen; Abrechnungssysteme erfordern robuste Exception-Behandlung und transaktionssichere PL/SQL-Packages.

• Oracle 8i bis 19c: Versionsbandbreite aus Praxisprojekten
• Multitenant-Architektur: CDB und PDB seit Oracle 12c
• Editionen: XE, SE2, EE – Lizenzaspekte bei Migrationen
• Real Application Clusters (RAC): Grundverständnis und Abgrenzung
• Oracle-Features: Partitionierung, Materialized Views, Advanced Queuing
• PL/SQL-Entwicklung: Packages, Prozeduren, Funktionen, Trigger
• Tooling: SQL*Plus (Skripte und Automatisierung), SQL Developer, TOAD
• Performance: Optimizer, Explain Plan, Hints, Indizes
• Migration: SSMA, Datentyp-Mapping, PL/SQL zu T-SQL

Datenbankarchitektur und Instanzmodell

Das Oracle-Instanzmodell ist fundamental verschieden von SQL Server. Eine Oracle-Instanz besteht aus dem Speicherbereich (SGA – System Global Area) und einer Reihe von Hintergrundprozessen; die Datenbankdateien liegen separat. Diese Trennung von Instanz und Datenbank hat weitreichende Konsequenzen: Es ist möglich, eine Instanz zu starten, ohne eine Datenbank zu mounten; es ist möglich, eine Datenbank an eine andere Instanz zu hängen. Dieses Modell bildet die Grundlage für Oracle RAC, Data Guard und Multitenant. Wer Oracle administriert oder migriert, muss dieses Modell verinnerlicht haben.

Schematische Darstellung der Oracle-Instanz: Die SGA hält geteilte Speicherstrukturen für alle Sessions; Hintergrundprozesse koordinieren Schreib-, Log- und Wiederherstellungsoperationen; Datendateien, Redo Logs und Controlfiles bilden die persistente Speicherschicht.

SGA: Shared Pool, Buffer Cache und Redo Log Buffer

Der Shared Pool speichert geparste SQL-Anweisungen und PL/SQL-Kompilate in der Library Cache sowie Datenbankmetadaten in der Data Dictionary Cache. Schlecht optimierter Code mit literalen Werten statt Bind-Variablen zwingt Oracle, dieselbe Abfrage immer wieder neu zu parsen – ein klassisches Performance-Problem, das den Shared Pool unter Druck setzt und Hard-Parse-Overhead erzeugt. Der Buffer Cache hält Datenblöcke im Speicher, um Lesezugriffe aus den Datendateien zu minimieren. Das Trefferverhältnis des Buffer Cache (Buffer Cache Hit Ratio) ist ein erster Hinweis auf Speicherknappheit, wenn er unter typische Schwellwerte fällt. Der Redo Log Buffer puffert Änderungsaufzeichnungen, bevor der LGWR-Prozess sie in die Redo-Log-Dateien schreibt.

Hintergrundprozesse: DBWn, LGWR, CKPT, SMON, PMON

Die Hintergrundprozesse sind das Rückgrat der Oracle-Instanz. DBWn (Database Writer) schreibt geänderte Datenblöcke aus dem Buffer Cache in die Datendateien – asynchron und nach eigenem Rhythm, nicht unmittelbar nach jedem COMMIT. LGWR (Log Writer) schreibt den Redo Log Buffer bei jedem COMMIT in die Redo-Log-Dateien und sichert damit die Transaktionsbeständigkeit. CKPT (Checkpoint) signalisiert, bis zu welchem SCN alle Änderungen auf Platte geschrieben sind – ein Checkpoint minimiert Recovery-Zeit. SMON (System Monitor) führt Crash Recovery durch und bereinigt temporäre Segmente. PMON (Process Monitor) bereinigt nach abgestürzen Verbindungen. Dieses Zusammenspiel zu verstehen, ist entscheidend für die Diagnose von Performance-Problemen und für das Verständnis, wie Oracle Transaktionen intern verarbeitet.

Multitenant: CDB und PDB seit Oracle 12c

Oracle 12c einführte die Multitenant-Architektur: eine Container-Datenbank (CDB) kann mehrere Pluggable Databases (PDB) beherbergen. Jede PDB hat ihre eigene Datenmenge, ihr eigenes Schema und ihre eigene Konfiguration, teilt aber die Instanz-Ressourcen (SGA, Hintergrundprozesse) mit anderen PDBs. Diese Architektur ist das Oracle-Pendant zur SQL-Server-Instanz-mit-mehreren-Datenbanken, allerdings mit eigenen Besonderheiten bei Verbindungsstrings, Berechtigungskonzepten und dem Umgang mit Common Users. Bei Migrationen aus 12c/19c-Umgebungen ist es wichtig zu wissen, ob der Code auf CDB- oder PDB-Ebene ausgeführt wird.

PL/SQL: Packages, Prozeduren, Cursor

PL/SQL ist Oracles prozedurale Erweiterung von SQL. Anders als T-SQL, das direkt im SQL-Server-Kontext ausgeführt wird, hat PL/SQL eine eigene Compilerinfrastruktur, eigene Speicherkonzepte und eine eigene Semantik für Transaktionen und Sperrmechanismen. Das mächtigste Konstrukt in PL/SQL ist das Package: eine Einheit, die Typdefinitionen, Variablen, Prozeduren und Funktionen zusammenfasst und eine klare Trennung zwischen öffentlicher Schnittstelle (Specification) und Implementierung (Body) bietet. Packages können Status über eine gesamte Session halten – eine Fähigkeit, die es in SQL Server so nicht gibt und die bei Migrationen besondere Aufmerksamkeit erfordert.

Strukturdiagramm eines PL/SQL-Pakets: Die Specification definiert die öffentliche Schnittstelle mit Prozedur-Signaturen, Typen und REF-CURSOR-Definitionen. Der Body implementiert die Logik mit Cursorn, Bulk-Collect-Schritten und strukturierter Exception-Behandlung.

Package Specification und Body

Die Specification eines PL/SQL-Packages entspricht einem Header in C oder einem Interface in Java: Sie deklariert, was nach aussen sichtbar ist. Dazu gehören Prozedur- und Funktionssignaturen, Typdefinitionen (TYPE ... IS TABLE OF, TYPE ... IS RECORD), Konstanten und öffentliche Variablen. Der Body enthält die eigentliche Implementierung aller in der Specification deklarierten Elemente sowie private Hilfsprozeduren, die von aussen nicht zugreifbar sind. Diese Modularisierung ist für größere Systeme unverzichtbar: Sie erlaubt es, die Schnittstelle stabil zu halten, während der Body unabhängig weiterentwickelt wird. Ich setze Packages konsequent ein, weil sie den Code testbarer, wartbarer und besser dokumentierbar machen.

Explizite Cursor und Ref Cursor

Ein expliziter Cursor gibt dem Entwickler vollständige Kontrolle über den Abfrageprozess: OPEN, FETCH (Zeile für Zeile oder in Bulk) und CLOSE. Diese Kontrolle ist notwendig, wenn die Verarbeitung zeilenweise erfolgen muss oder wenn der Cursor an mehreren Stellen im Code verwendet wird. Der Ref Cursor (REF CURSOR oder SYS_REFCURSOR) ist ein Zeiger auf ein Cursor-Ergebnis, der als Parameter übergeben oder zurückgegeben werden kann. Ref Cursor sind das Standard-Muster für Prozeduren, die Ergebismengen an aufrufende Schichten zurückliefern – vergleichbar mit einem Recordset in ADO oder einem DataReader in ADO.NET. Bei der Migration nach SQL Server werden Ref-Cursor-Prozeduren typischerweise zu Stored Procedures konvertiert, die ein SELECT-Resultset zurückgeben.

-- Package-Deklaration: oeffentliche Schnittstelle
CREATE OR REPLACE PACKAGE pkg_auftraege AS
    -- Oeffentlicher Typ fuer Bulk-Collect-Operationen
    TYPE t_auftraege_tab IS TABLE OF auftraege%ROWTYPE;

    -- Ref-Cursor-Typ fuer die Rueckgabe von Ergebnismengen
    TYPE t_ref_cursor IS REF CURSOR;

    -- Prozedur: verarbeitet Auftraege eines Kunden
    PROCEDURE verarbeite_auftraege(
        p_kunden_id   IN  auftraege.kunden_id%TYPE,
        p_status      IN  VARCHAR2 DEFAULT 'OFFEN',
        p_ergebnis    OUT t_ref_cursor,
        p_anzahl      OUT NUMBER
    );

    -- Funktion: Gesamtsumme eines Kunden
    FUNCTION get_gesamtsumme(
        p_kunden_id IN auftraege.kunden_id%TYPE
    ) RETURN NUMBER;
END pkg_auftraege;
/

-- Package-Body: Implementierung
CREATE OR REPLACE PACKAGE BODY pkg_auftraege AS

    -- Private Hilfsprozedur (nur intern sichtbar)
    PROCEDURE log_fehler(p_code IN NUMBER, p_meldung IN VARCHAR2) IS
        PRAGMA AUTONOMOUS_TRANSACTION;  -- unabhaengige Transaktion fuer Logging
    BEGIN
        INSERT INTO fehler_log (fehler_code, fehler_meldung, erstellt_am)
        VALUES (p_code, p_meldung, SYSDATE);
        COMMIT;  -- Commit nur fuer autonome Transaktion
    END log_fehler;

    -- Hauptprozedur mit explizitem Cursor und Bulk Collect
    PROCEDURE verarbeite_auftraege(
        p_kunden_id   IN  auftraege.kunden_id%TYPE,
        p_status      IN  VARCHAR2 DEFAULT 'OFFEN',
        p_ergebnis    OUT t_ref_cursor,
        p_anzahl      OUT NUMBER
    ) IS
        -- Lokale Collection fuer Bulk-Verarbeitung
        v_auftraege   t_auftraege_tab;

        -- Expliziter Cursor: Datenselektion
        CURSOR c_auftraege IS
            SELECT * FROM auftraege
            WHERE  kunden_id = p_kunden_id
            AND    status    = p_status
            ORDER BY erstellt_am;
    BEGIN
        -- Bulk Collect: gesamte Ergebnismenge in eine Collection laden
        OPEN c_auftraege;
        FETCH c_auftraege BULK COLLECT INTO v_auftraege LIMIT 1000;
        CLOSE c_auftraege;

        p_anzahl := v_auftraege.COUNT;

        -- Zeilenweise Verarbeitung der Collection
        FOR i IN 1 .. v_auftraege.COUNT LOOP
            UPDATE auftraege
            SET    bearbeitet_am = SYSDATE,
                   bearbeitet_von = USER
            WHERE  auftrags_id = v_auftraege(i).auftrags_id;
        END LOOP;

        -- Ref-Cursor-Ergebnis fuer den Aufrufer oeffnen
        OPEN p_ergebnis FOR
            SELECT * FROM auftraege
            WHERE  kunden_id = p_kunden_id
            AND    status    = p_status
            ORDER BY erstellt_am;

    EXCEPTION
        WHEN NO_DATA_FOUND THEN
            p_anzahl := 0;
            -- Keinen Fehler weitergeben, leeren Cursor zurueckgeben
            OPEN p_ergebnis FOR SELECT * FROM auftraege WHERE 1=0;
        WHEN OTHERS THEN
            -- Alle unbehandelten Fehler protokollieren
            log_fehler(SQLCODE, SQLERRM);
            RAISE;  -- Fehler an den Aufrufer weitergeben
    END verarbeite_auftraege;

    FUNCTION get_gesamtsumme(
        p_kunden_id IN auftraege.kunden_id%TYPE
    ) RETURN NUMBER IS
        v_summe NUMBER := 0;
    BEGIN
        SELECT NVL(SUM(betrag), 0)
        INTO   v_summe
        FROM   auftraege
        WHERE  kunden_id = p_kunden_id;
        RETURN v_summe;
    EXCEPTION
        WHEN OTHERS THEN
            log_fehler(SQLCODE, SQLERRM);
            RETURN NULL;
    END get_gesamtsumme;

END pkg_auftraege;
/

Dieses Package zeigt das vollständige Muster: Specification mit öffentlichen Typen und Signaturen, Body mit privater Hilfsprozedur, explizitem Cursor, Bulk Collect, autonomer Transaktion für das Fehler-Log und Ref-Cursor-Rückgabe. Kommentare bewusst auf Deutsch, ASCII-konform.

Bulk Collect, Bulk Bind und Pipelined Functions

Eine der häufigsten Performance-Fallen in PL/SQL ist der Row-by-Row-Ansatz: Eine Schleife öffnet einen Cursor, liest eine Zeile, verarbeitet sie, schreibt ein UPDATE – und wiederholt das für Tausende oder Millionen von Zeilen. Jeder Wechsel zwischen PL/SQL-Engine und SQL-Engine kostet Zeit; bei vielen Iterationen addiert sich dieser Context-Switch-Overhead erheblich. Bulk Collect und Bulk Bind lösen dieses Problem, indem sie mehrere Zeilen in einem einzigen SQL-Engine-Aufruf lesen oder schreiben.

BULK COLLECT INTO mit LIMIT

FETCH ... BULK COLLECT INTO lädt mehrere Zeilen auf einmal in eine PL/SQL-Collection (VARRAY, Nested Table oder Assoziatives Array). Das optionale LIMIT begrenzt die Größe jeder Ladung und verhindert, dass der gesamte Cursor-Inhalt unkontrolliert in den PGA-Speicher geladen wird. Für grosse Datenmengen ist LIMIT mit einer Größe von 500 bis 2000 Zeilen typischerweise optimal: gross genug, um den Context-Switch-Overhead zu minimieren, klein genug, um PGA-Überlauf zu vermeiden.

FORALL: Bulk DML

Das FORALL-Statement ist das Gegenstück zu BULK COLLECT auf der DML-Seite: Es führt ein INSERT, UPDATE oder DELETE für alle Elemente einer Collection in einem einzigen SQL-Engine-Aufruf aus. Im Unterschied zu einer FOR-Schleife mit DML reduziert FORALL den Context-Switch-Overhead drastisch und verbessert den Durchsatz bei Massenoperationen oft um eine Größenordnung. Das SAVE EXCEPTIONS-Klausel erlaubt es, DML-Fehler (z.B. Constraint-Verletzungen) zu sammeln und nach dem Batch-Lauf auszuwerten, anstatt beim ersten Fehler abzubrechen.

Pipelined Table Functions

Pipelined Table Functions erzeugen Ergebniszeilen iterativ und liefern sie direkt an den Aufrufer, während die Funktion noch läuft. Das ermöglicht Abfragen wie SELECT * FROM TABLE(meine_funktion()), bei denen die Verarbeitung in einer Funktion stattfindet, das Ergebnis aber direkt mit SQL weiterverarbeitet werden kann. Pipelined Functions sind nützlich für komplexe Transformationslogik, die sich nicht sauber in reines SQL ausdrücken lässt, aber dennoch in einer FROM-Klausel verwendet werden soll. Bei der Migration nach SQL Server gibt es kein direktes Äquivalent; typischerweise werden Pipelined Functions durch Table-Valued Functions (TVF) mit RETURN TABLE AS ... SELECT-Logik abgebildet.

DECLARE
    -- Collection-Typ fuer Bulk-Operationen
    TYPE t_id_tab   IS TABLE OF auftraege.auftrags_id%TYPE;
    TYPE t_sum_tab  IS TABLE OF auftraege.betrag%TYPE;

    v_ids    t_id_tab;
    v_summen t_sum_tab;

    -- Cursor: selektiert alle offenen Auftraege
    CURSOR c_offen IS
        SELECT auftrags_id, betrag
        FROM   auftraege
        WHERE  status = 'OFFEN'
        ORDER BY erstellt_am;

    -- Fehler-Collection fuer SAVE EXCEPTIONS
    v_errors  NUMBER;
    ex_dml    EXCEPTION;
    PRAGMA EXCEPTION_INIT(ex_dml, -24381);  -- Fehlercode fuer SAVE EXCEPTIONS
BEGIN
    OPEN c_offen;
    LOOP
        -- Bulk Collect: bis zu 500 Zeilen auf einmal laden
        FETCH c_offen BULK COLLECT INTO v_ids, v_summen LIMIT 500;
        EXIT WHEN v_ids.COUNT = 0;

        BEGIN
            -- Bulk DML: alle geladenen Zeilen auf einmal aktualisieren
            FORALL i IN 1 .. v_ids.COUNT SAVE EXCEPTIONS
                UPDATE auftraege
                SET    status       = 'VERARBEITET',
                       bearbeitet_am = SYSDATE,
                       betrag_final  = v_summen(i) * 1.19  -- Beispiel: Steuer aufschlagen
                WHERE  auftrags_id  = v_ids(i);

        EXCEPTION
            WHEN ex_dml THEN
                -- Einzelne DML-Fehler auswerten (nicht den gesamten Batch abbrechen)
                v_errors := SQL%BULK_EXCEPTIONS.COUNT;
                FOR j IN 1 .. v_errors LOOP
                    -- Fehler-ID und Fehlercode protokollieren
                    INSERT INTO fehler_log (fehler_code, fehler_meldung, erstellt_am)
                    VALUES (
                        SQL%BULK_EXCEPTIONS(j).ERROR_CODE,
                        'Fehler bei Auftrags-ID: ' || v_ids(SQL%BULK_EXCEPTIONS(j).ERROR_INDEX),
                        SYSDATE
                    );
                END LOOP;
        END;

        -- Commit pro Batch, um Redo-Log-Druck zu verteilen
        COMMIT;

    END LOOP;
    CLOSE c_offen;
END;
/

BULK COLLECT LIMIT 500 lädt haappenweise; FORALL SAVE EXCEPTIONS schreibt alle Updates auf einmal und fängt Einzelfehler ab, ohne den gesamten Batch abzubrechen. Commit pro Batch vermeidet überfuellte Undo-Segmente bei Massenoperationen.

Exception-Behandlung und Fehlerprotokollierung

Eine robuste Exception-Behandlung ist in PL/SQL genauso wichtig wie in jeder anderen Sprache – und in Oracle-Umgebungen oft der Unterschied zwischen einem System, das nach Fehlern sauber weiterlaueft, und einem, das Daten in inkonsistenten Zuständen hinterlässt. PL/SQL unterscheidet zwischen vordefinierten Exceptions (z.B. NO_DATA_FOUND, TOO_MANY_ROWS, ZERO_DIVIDE), benannten benutzerspezifischen Exceptions und dem generischen OTHERS-Handler. Die Kombination dieser Mechanismen erlaubt eine feingranulare Fehlerbehandlung, die sowohl erwartete Ausnahmen (z.B. kein Ergebnis) als auch unerwartete Fehler (z.B. Constraint-Verletzungen) korrekt behandelt.

PRAGMA EXCEPTION_INIT und benutzerdefinierte Exceptions

Mit PRAGMA EXCEPTION_INIT können ORA-Fehlercodes einem benannten Exception-Bezeichner zugeordnet werden. Das macht Exception-Handler lesbarer und ermöglicht spezifische Reaktionen auf bestimmte Oracle-Fehler, ohne den generischen OTHERS-Handler zu bemühen. Benutzerdefinierte Exceptions werden mit DECLARE ... my_exception EXCEPTION; deklariert und mit RAISE my_exception; ausgelöst – ein Muster, das zur klaren Kommunikation von Fehlerzuständen zwischen Packageprozeduren dient.

Autonome Transaktionen für Fehler-Logging

Ein klassisches Problem in der Exception-Behandlung ist das Logging: Wenn eine Transaktion fehlschlägt und zurückgerollt wird (ROLLBACK), werden auch alle LOG-Einträge, die in derselben Transaktion vorgenommen wurden, zurückgerollt. Die Lösung ist PRAGMA AUTONOMOUS_TRANSACTION in der Logging-Prozedur: Sie führt ihren eigenen COMMIT aus, unabhängig von der äußeren Transaktion. Dieses Muster ist Standard für Fehler-Log-Tabellen in Oracle-Systemen und stellt sicher, dass Fehlermeldungen auch dann sichtbar bleiben, wenn die verursachende Transaktion vollständig zurückgerollt wurde.

SQLERRM, SQLCODE und DBMS_UTILITY.FORMAT_ERROR_BACKTRACE

SQLCODE und SQLERRM liefern den Oracle-Fehlercode und die Fehlermeldung des zuletzt aufgetretenen Fehlers. DBMS_UTILITY.FORMAT_ERROR_BACKTRACE gibt den vollständigen Stacktrace zurück und ermöglicht so die genaue Lokalisierung des Fehlers in einem Paket mit mehreren Schichten. Diese Kombination – SQLCODE, SQLERRM und FORMAT_ERROR_BACKTRACE – ist die Grundlage eines aussagekräftigen Fehler-Logs, das die Diagnose von Produktionsproblemen erheblich erleichtert.

Performance: Explain Plan, Hints, Indizes

Oracle-Performance-Analyse beginnt mit dem Explain Plan. EXPLAIN PLAN FOR gefolgt von SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY) zeigt, welche Operationen der Optimizer plant: Full Table Scans, Index Range Scans, Hash Joins, Nested Loops, Sort Merge Joins. Das Verständnis, welcher Zugriffsweg wann optimal ist, ist Kern-kompetenz in der Oracle-Performance-Arbeit. Ein Full Table Scan ist nicht automatisch schlecht – für kleine Tabellen oder grosse Treffermengen kann er effizienter sein als ein Index Scan. Ein Nested Loop ist für kleine Outer-Mengen optimal, aber katastrophal für kartesische Produkte.

Bind-Variablen und Hard Parse

Das häufigste, selbst verursachte Performance-Problem in Oracle-Umgebungen ist der excessive Hard Parse durch fehlende Bind-Variablen. Wenn eine Java-Anwendung Abfragen wie SELECT * FROM kunden WHERE id = 12345 mit eingebetteten Literalwerten absendet, muss Oracle jeden Abfragetext einzeln parsen, optimieren und im Shared Pool cachen. Dasselbe Statement mit Bind-Variablen (WHERE id = :p1) wird nach dem ersten Parse im Shared Pool gecacht und wieder verwendet. In stark belasteten Systemen kann die Umstellung auf Bind-Variablen Shared-Pool-Latch-Contention erheblich reduzieren und die Gesamtperformance sichtbar verbessern.

Optimizer-Hints

Hints sind Direktiven an den Oracle Cost-Based Optimizer (CBO), die einen bestimmten Ausführungsplan erzwingen oder bevorzugen. Sie werden als Kommentare unmittelbar nach dem SELECT-, INSERT-, UPDATE- oder DELETE-Schlüssel in der Form /*+ HINT */ eingebettet. Gangige Hints sind INDEX (bevorzuge diesen Index), NO_INDEX (vermeide diesen Index), FULL (erzwinge Full Table Scan), LEADING (bestimme Join-Reihenfolge) und USE_NL / USE_HASH / USE_MERGE (bestimme Join-Methode). Hints sollten mit Bedacht eingesetzt werden: Sie können kurzfristig Performance-Probleme beheben, verhindern aber, dass der Optimizer seine Entscheidungen bei geänderten Statistiken anpassen kann.

-- Schritt 1: Explain Plan fuer eine Abfrage generieren
EXPLAIN PLAN FOR
    SELECT /*+ INDEX(a idx_auftraege_kunden) LEADING(a k) USE_NL(k) */
           a.auftrags_id,
           a.betrag,
           k.name        AS kundenname
    FROM   auftraege a
    JOIN   kunden    k ON k.kunden_id = a.kunden_id
    WHERE  a.kunden_id = :p_kunden_id   -- Bind-Variable statt Literal
    AND    a.status    = 'OFFEN'
    AND    a.erstellt_am >= TRUNC(SYSDATE) - 30;

-- Schritt 2: Plan anzeigen (TYPICAL-Format mit Kostenschaetzungen)
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY(
    format => 'TYPICAL +ROWS +BYTES +COST +PEEKED_BINDS'
));

-- Schritt 3: Laufzeit-Statistiken fuer eine bereits ausgefuehrte Abfrage
-- (aus dem Cursor Cache, identifiziert ueber SQL_ID)
SELECT s.sql_id,
       s.executions,
       s.elapsed_time / NULLIF(s.executions, 0) / 1e6  AS avg_sec,
       s.buffer_gets  / NULLIF(s.executions, 0)        AS avg_bufgets,
       s.rows_processed / NULLIF(s.executions, 0)      AS avg_rows,
       s.sql_text
FROM   v$sql s
WHERE  s.sql_text LIKE '%auftraege%'
AND    s.executions > 0
ORDER BY avg_sec DESC
FETCH FIRST 10 ROWS ONLY;

-- Schritt 4: Fehlende Indizes identifizieren (vom Optimizer vorgeschlagen)
SELECT d.operation,
       d.options,
       d.object_name,
       d.object_alias,
       d.cost,
       d.cardinality
FROM   plan_table d
WHERE  d.operation = 'TABLE ACCESS'
AND    d.options   = 'FULL'
ORDER BY d.cost DESC;

Explain Plan mit Hints steuert den Optimizer; Bind-Variablen verhindern Hard Parse; v$sql liefert reale Laufzeitstatistiken aus dem Cursor Cache für nachträgliche Analyse.

Index-Strategien in Oracle

Oracle unterstützt B-Tree-Indizes (Standard), Bitmap-Indizes, Function-Based Indizes und Composite Indizes. B-Tree-Indizes sind für selektive Abfragen mit wenigen Treffern optimal; Bitmap-Indizes eignen sich für Spalten mit geringer Kardinalität (z.B. Status-Spalten) in Data-Warehouse-Umgebungen. Function-Based Indizes indexieren den Wert eines Ausdrucks (z.B. UPPER(name)) und ermöglichen damit indizierte Suchen auf transformierte Werte. Ein häufiger Fehler ist die Verwendung von Funktionen auf indizierten Spalten in der WHERE-Klausel – das macht den Index unnutzbar. Oracle Index Monitoring (ALTER INDEX ... MONITORING USAGE) hilft, ungenutzte Indizes zu identifizieren und zu entfernen.

Oracle-zu-SQL-Server-Migration

Die Migration von Oracle auf SQL Server ist ein vielschichtiges Projekt, das weit über das reine Überspielen von Daten hinausgeht. Schema-Mapping, Datentyp-Konvertierung, die Umstellung von Sequences auf IDENTITY- oder Sequence-Objekte, die Umschreibung von PL/SQL-Logik in T-SQL und die Sicherstellung der Applikationskonsistenz sind alle separate, anspruchsvolle Aufgaben. Ich habe solche Migrationen aus mehreren Projekten kennen: bei einem Chemie-/Industrieunternehmen, wo eine Java/Oracle-Landschaft auf .NET/SQL Server umgestellt wurde, und bei einer Sparkasse, wo Oracle-ETL-Prozesse durch SSIS abgelöst wurden.

Das Vorgehensmodell gliedert sich in Analyse (Schema-Inventar, PL/SQL-Umfang, Datentyp-Mapping), Konvertierung (SSMA, PL/SQL-zu-T-SQL, Sequences zu IDENTITY), Datenmigration (ETL/SSIS, Validierung) und Abnahme (Output-Vergleich, Performance-Tests, Parallelbetrieb).

Datentyp-Mapping Oracle zu SQL Server

Das Datentyp-Mapping ist eine der ersten und wichtigsten Aufgaben in einem Oracle-zu-SQL-Server-Migrationsprojekt. Viele Oracle-Datentypen haben keine direkte Entsprechung in SQL Server; andere haben zwar eine Entsprechung, verhalten sich aber subtil anders. NUMBER ist Oracles generischer numerischer Typ und kann je nach Precision und Scale zu INT, BIGINT, DECIMAL oder FLOAT in SQL Server abgebildet werden. VARCHAR2 entspricht in den meisten Fällen VARCHAR(n) in SQL Server. DATE in Oracle speichert Datum und Uhrzeit; das SQL-Server-Pendant DATETIME2 ist genauer, aber DATE in SQL Server speichert nur das Datum – ein häufiger Quell von Fehlern. CLOB und BLOB werden zu VARCHAR(MAX) bzw. VARBINARY(MAX). RAW wird zu VARBINARY.

-- ============================================================
-- ORACLE-SEITE: Beispieltabelle mit typischen Oracle-Datentypen
-- ============================================================
CREATE TABLE auftraege_oracle (
    auftrags_id   NUMBER(10)        NOT NULL,   -- INTEGER / BIGINT in SQL Server
    kunden_id     NUMBER(10)        NOT NULL,
    betrag        NUMBER(15, 2)     NOT NULL,   -- DECIMAL(15,2) in SQL Server
    beschreibung  VARCHAR2(500),               -- VARCHAR(500) in SQL Server
    notizen       CLOB,                         -- VARCHAR(MAX) in SQL Server
    bild          BLOB,                         -- VARBINARY(MAX) in SQL Server
    erstellt_am   DATE,                         -- DATETIME2(0) in SQL Server (enthalt Zeit!)
    aktiv         CHAR(1) DEFAULT 'J',          -- BIT oder CHAR(1) in SQL Server
    rohdaten      RAW(100),                     -- VARBINARY(100) in SQL Server
    CONSTRAINT pk_auftraege PRIMARY KEY (auftrags_id)
);

-- Sequence als Primaerschluessel-Generator (Oracle)
CREATE SEQUENCE seq_auftraege START WITH 1 INCREMENT BY 1 NOCACHE;

-- ============================================================
-- SQL-SERVER-SEITE: Aequivalente Tabelle nach SSMA-Migration
-- ============================================================
CREATE TABLE auftraege_sqlserver (
    auftrags_id   INT              NOT NULL IDENTITY(1,1),  -- IDENTITY ersetzt Sequence
    kunden_id     INT              NOT NULL,
    betrag        DECIMAL(15, 2)   NOT NULL,
    beschreibung  NVARCHAR(500)    NULL,        -- NVARCHAR fuer Unicode-Sicherheit
    notizen       NVARCHAR(MAX)    NULL,        -- CLOB -> NVARCHAR(MAX)
    bild          VARBINARY(MAX)   NULL,        -- BLOB -> VARBINARY(MAX)
    erstellt_am   DATETIME2(0)     NULL,        -- DATE(Oracle) hat Zeit -> DATETIME2
    aktiv         BIT              NOT NULL DEFAULT 1,  -- CHAR(1) -> BIT
    rohdaten      VARBINARY(100)   NULL,        -- RAW -> VARBINARY
    CONSTRAINT pk_auftraege_ss PRIMARY KEY (auftrags_id)
);

-- MERGE-Aequivalent: Oracle MERGE vs. SQL Server MERGE
-- Oracle:
MERGE INTO auftraege_oracle t
USING (SELECT 1001 AS id, 'VERARBEITET' AS status FROM DUAL) s
ON (t.auftrags_id = s.id)
WHEN MATCHED     THEN UPDATE SET t.aktiv = 'N'
WHEN NOT MATCHED THEN INSERT (auftrags_id, kunden_id, betrag, aktiv)
                      VALUES (seq_auftraege.NEXTVAL, 0, 0, 'N');

-- SQL Server (nach SSMA-Migration):
MERGE INTO auftraege_sqlserver AS t
USING (VALUES (1001, 'VERARBEITET')) AS s (id, status)
ON (t.auftrags_id = s.id)
WHEN MATCHED     THEN UPDATE SET t.aktiv = 0
WHEN NOT MATCHED THEN INSERT (kunden_id, betrag, aktiv) VALUES (0, 0, 0);

Das Mapping zeigt die wichtigsten Typkonvertierungen: NUMBER zu INT/DECIMAL, VARCHAR2 zu NVARCHAR, CLOB zu NVARCHAR(MAX), DATE-Semantik-Unterschied, Sequence zu IDENTITY und MERGE-Syntax-Varianten.

SQL Server Migration Assistant (SSMA)

SSMA für Oracle ist Microsofts kostenloses Migrations-Tool, das automatisch Schema und einfachen PL/SQL-Code konvertiert. SSMA analysiert das Oracle-Schema, erstellt einen Migrationsbericht mit Problemen und Warnungen und generiert T-SQL-DDL-Skripte. Für einfachen Code – Tabellen, Views, einfache Prozeduren – ist SSMA sehr effektiv. Für komplexe PL/SQL-Packages mit Cursor-Logik, PRAGMA AUTONOMOUS_TRANSACTION, Package-State oder Oracle-spezifischen Built-ins liefert SSMA Stubs mit TODO-Kommentaren, die manuell abgeschlossen werden müssen. SSMA ist ein guter Ausgangspunkt, kein vollautomatisches Migrations-Tool. Das manuelle Nacharbeiten erfordert tiefes Wissen sowohl über Oracle als auch über SQL Server – genau die Kombination, die ich mitbringe.

PL/SQL-zu-T-SQL-Konvertierung

Die Konvertierung von PL/SQL nach T-SQL ist die technisch anspruchsvollste Aufgabe in einem Oracle-zu-SQL-Server-Migrationsprojekt. Beide Sprachen sind prozedurale SQL-Erweiterungen, aber sie unterscheiden sich in Syntax, Semantik und verfügbaren Konstrukten so stark, dass eine mechanische Übersetzung fast nie funktioniert. Ich gehe systematisch vor: Zürst eine Inventarisierung aller PL/SQL-Objekte mit ihren Abhängigkeiten, dann eine Klassifizierung nach Konvertierungsaufwand, dann die Konvertierung in priorisierten Batches mit Regressionstests nach jedem Batch.

Wichtigste Unterschiede: Variablen, Cursors, Ausnahmen

In T-SQL werden Variablen mit DECLARE @var TYPE deklariert und mit SET @var = ... oder SELECT @var = ... gesetzt. PL/SQL kennt diesen Unterschied zwischen SET und SELECT nicht. Cursors existieren in T-SQL (DECLARE CURSOR, OPEN, FETCH, CLOSE, DEALLOCATE), sind aber wegen Performance-Problemen in der Praxis selten eingesetzt – set-basierte Alternativen sind fast immer vorzuziehen. Exceptions heissen in T-SQL TRY/CATCH mit THROW, ERROR_NUMBER(), ERROR_MESSAGE(). Das Konzept von PRAGMA EXCEPTION_INIT gibt es nicht; ERROR_NUMBER() liefert den SQL-Server-Fehlercode, aber eine direkte 1:1-Abbildung von Oracle-ORA-Fehlern auf SQL-Server-Fehlercodes gibt es nicht.

Oracle-Konstrukte ohne direktes T-SQL-Äquivalent

Einige Oracle-Konstrukte erfordern kreativere Lösungsansätze in T-SQL: DUAL (Oracles einzeilige Tabelle für SELECT 1 FROM DUAL) wird in T-SQL einfach zu SELECT 1 ohne FROM-Klausel. ROWNUM für Top-N-Abfragen wird zu TOP n oder ROW_NUMBER() OVER (...). CONNECT BY PRIOR für hierarchische Abfragen wird zu einem rekursiven CTE mit WITH ... AS (... UNION ALL ...). DECODE() entspricht CASE WHEN. NVL() entspricht ISNULL() oder COALESCE(). TO_DATE(), TO_CHAR(), TRUNC() haben jeweils T-SQL-Entsprechungen (CONVERT, FORMAT, CAST, DATETRUNC). Package-State – Variablen, die ihre Werte zwischen Aufrufen innerhalb einer Session halten – hat in SQL Server keine direkte Entsprechung; es braucht entweder Context-Tabellen, temporäre Tabellen oder Anwendungs-Session-Kontexte.

-- ============================================================
-- ORIGINAL: Oracle PL/SQL-Prozedur mit Cursor und Exception
-- ============================================================
CREATE OR REPLACE PROCEDURE oracle_rechnungen_verarbeiten(
    p_faellig_bis DATE,
    p_verarbeitet OUT NUMBER
) IS
    CURSOR c_faellig IS
        SELECT r.rechnungs_id, r.betrag, k.email
        FROM   rechnungen r
        JOIN   kunden      k ON k.kunden_id = r.kunden_id
        WHERE  r.faellig_am <= p_faellig_bis
        AND    r.status = 'OFFEN';
    v_row  c_faellig%ROWTYPE;
    v_zaehler NUMBER := 0;
BEGIN
    OPEN c_faellig;
    LOOP
        FETCH c_faellig INTO v_row;
        EXIT WHEN c_faellig%NOTFOUND;
        UPDATE rechnungen
        SET status = 'GEMAHNT', gemahnt_am = SYSDATE
        WHERE rechnungs_id = v_row.rechnungs_id;
        v_zaehler := v_zaehler + 1;
    END LOOP;
    CLOSE c_faellig;
    COMMIT;
    p_verarbeitet := v_zaehler;
EXCEPTION
    WHEN OTHERS THEN
        ROLLBACK;
        RAISE;
END;
/

-- ============================================================
-- KONVERTIERUNG: SQL Server T-SQL Stored Procedure
-- Kein Cursor noetig: SET-basierter UPDATE mit OUTPUT-Klausel
-- ============================================================
CREATE OR ALTER PROCEDURE dbo.rechnungen_verarbeiten
    @faellig_bis  DATE,
    @verarbeitet  INT OUTPUT
AS
BEGIN
    SET NOCOUNT ON;

    -- Deklaration: Tabellenvariable fuer OUTPUT-Ergebnisse
    DECLARE @aktualisiert TABLE (rechnungs_id INT);

    BEGIN TRY
        BEGIN TRANSACTION;

        -- SET-basierter UPDATE: ersetzt den Oracle-Cursor vollstaendig
        -- OUTPUT-Klausel erfasst die aktualisierten IDs
        UPDATE r
        SET    r.status    = 'GEMAHNT',
               r.gemahnt_am = GETDATE()
        OUTPUT inserted.rechnungs_id INTO @aktualisiert (rechnungs_id)
        FROM   dbo.rechnungen r
        WHERE  r.faellig_am <= @faellig_bis
        AND    r.status     = 'OFFEN';

        -- Anzahl der verarbeiteten Zeilen zurueckgeben
        SET @verarbeitet = @@ROWCOUNT;

        COMMIT TRANSACTION;
    END TRY
    BEGIN CATCH
        IF @@TRANCOUNT > 0 ROLLBACK TRANSACTION;
        -- Fehler an den Aufrufer weitergeben (entspricht RAISE in PL/SQL)
        THROW;
    END CATCH;
END;
GO

Die Oracle-Cursor-Schleife wird in T-SQL durch einen set-basierten UPDATE mit OUTPUT-Klausel ersetzt – einfacher, schneller und idiomatisches T-SQL. TRY/CATCH mit THROW entspricht dem Oracle EXCEPTION WHEN OTHERS THEN RAISE.

Sequences zu IDENTITY und SQL-Server-Sequences

Oracle-Sequences (CREATE SEQUENCE ... NEXTVAL) werden in SQL Server auf zwei Arten abgebildet: IDENTITY-Spalten für einfache Auto-Increment-Primärschlüssel und SQL-Server-Sequences (CREATE SEQUENCE, NEXT VALUE FOR ...) für Fälle, in denen der Wert vor dem INSERT benötigt wird. SSMA konvertiert Oracle-Sequences standardmäßig zu IDENTITY, was für die meisten Fälle korrekt ist. Wenn Sequences in PL/SQL-Code ausserhalb von INSERT-Statements verwendet werden (z.B. um Batches zu nummerieren oder Schlüssel in mehreren Tabellen gleichzeitig zu erzeugen), ist SQL-Server-Sequence die geeignetere Abbildung.

Tooling: SQL*Plus, SQL Developer, TOAD

Das Tooling für Oracle-Datenbankarbeit hat sich über die Jahre stark entwickelt. SQL*Plus, das Kommandozeilen-Tool, das Oracle seit den frühen Tagen mitliefert, ist nach wie vor das Werkzeug der Wahl für Skriptautomatisierung, Batch-Verarbeitung und schnelle Ad-hoc-Abfragen in Serverumgebungen ohne grafische Oberfläche. SQL Developer ist Oracles kostenloser grafischer Client mit IDE-Fähigkeiten: PL/SQL-Debugger, Data Modeler, Migrationsassistent und Data Pump-Integration. TOAD von Quest ist der Industriestandard für professionelle Oracle-Entwicklung und DBA-Arbeit: umfangreiche Code-Analyse, Schema-Vergleich, Performance-Diagnostik und Team-Coding-Features. Ich habe alle drei Werkzeuge intensiv eingesetzt und setze sie je nach Aufgabe und Umgebung situationsgerecht ein.

SQL*Plus für Automatisierung

SQL*Plus lässt sich vollständig über Skripte steuern: CONNECT, START, SPOOL, SET SERVEROUTPUT ON und die EXECUTE-Syntax ermöglichen die Ausführung kompletter PL/SQL-Workflows aus der Kommandozeile. In Unix/Linux-Umgebungen – wo viele grosse Oracle-Installationen laufen – ist SQL*Plus das natürliche Werkzeug für Shell-Skripte, die Datenbankoperationen orchestrieren. In Migrationsprojekten habe ich SQL*Plus eingesetzt, um Schema-Dumps, Datenexporte und Validierungsabfragen zu automatisieren.

TOAD: Performance-Diagnostik und Code-Analyse

TOAD bietet Features, die über einfache Abfrageverarbeitung hinausgehen: Schema Compare ermöglicht den Vergleich von Datenbankobjekten zwischen Umgebungen; Code Analysis prüft PL/SQL-Code auf Qualitäts- und Performance-Antipattern; der SQL Optimizer bietet grafische Explain-Plan-Darstellung und Ausführungsplan-Vergleich; Team Coding unterstützt versionierten Code-Austausch. In Projekten, wo Lizenz-Budget vorhanden war, ist TOAD das effizienteste Werkzeug für intensive PL/SQL-Entwicklung und Performance-Analyse.

Data Pump, SQL*Loader und externe Werkzeuge

Für Datenmigration und -transfer sind Data Pump (expdp/impdp), SQL*Loader und externe ETL-Werkzeuge die wesentlichen Instrumente. Data Pump erzeugt logische Exporte in Oracles eigenem Format (dump files) und ist die empfohlene Methode für Schema-Migration zwischen Oracle-Instanzen. SQL*Loader lädt externe Datendateien (CSV, festes Format) effizient in Oracle-Tabellen und ist besonders in Anfangsladezyklen von Migrationsprojekten nützlich. Für den Transfer von Oracle nach SQL Server kommen entweder SSIS mit OLE DB- oder ODBC-Oracle-Connector, Azure Data Factory mit Oracle-Connector oder dedizierte Migrations-Tools wie SSMA zum Einsatz.

ANSI-SQL für plattformübergreifende Reports

In Umgebungen, in denen Reports oder Abfragen gegen verschiedene Datenbanksysteme laufen müssen – Oracle, SQL Server, Teradata, MySQL – ist ANSI-SQL-konformer Code ein erheblicher Wartungsvorteil. Crystal Reports, SSRS und andere Reporting-Werkzeuge können direkt gegen Oracle-Datasources abfragen; wenn diese Abfragen ANSI-konform sind, läuft derselbe Code auch gegen SQL-Server- oder Teradata-Quellen. Ich schreibe Reporting-SQL bewusst ANSI-konform, wo es möglich ist: Standard-Joins statt Oracle-Join-Syntax (+), CASE statt DECODE, COALESCE statt NVL, EXTRACT statt TO_CHAR für Datumskomponenten, CAST statt proprietäre Konvertierungsfunktionen.

Oracles eigene Syntaxerweiterungen und ihre ANSI-Äquivalente

Oracle hat historisch viele eigene Syntaxerweiterungen eingeführt, die in älterem Code noch häufig anzutreffen sind: Der alte Outer-Join-Operator (+) statt LEFT/RIGHT/FULL OUTER JOIN; DECODE statt CASE WHEN; NVL statt COALESCE; ROWNUM für Top-N statt ROW_NUMBER() OVER (...); START WITH ... CONNECT BY PRIOR für hierarchische Abfragen statt rekursivem CTE. Dieser ältere Code funktioniert in Oracle, läuft aber nirgendwo anders. Wenn Report-SQL plattformunabhängig sein soll, muss er auf ANSI-Syntax umgestellt werden.

Praktischer Ansatz für plattformübergreifende Abfragen

Mein Ansatz für plattformübergreifende Reporting-Abfragen: ANSI-Standard-Joins, CASE WHEN, COALESCE, ISO-Datumsfunktionen (EXTRACT, CURRENT_DATE, CURRENT_TIMESTAMP), Standard-Aggregationsfunktionen und ROW_NUMBER()/RANK()/DENSE_RANK() für analytische Abfragen. Was platform-spezifisch bleiben muss (z.B. ROWID, Partitionierungs-Hints, Oracle-spezifische Funktionen wie LISTAGG oder REGEXP_SUBSTR), wird in plattform-spezifischen SQL-Views oder Parametern isoliert. Reporting-Tools wie Crystal Reports lassen sich so mit minimalem Anpassungsaufwand auf ein anderes Backend umstellen.

Vorgehen in der Zusammenarbeit

Jedes Oracle-Projekt beginnt mit einer sorgfältigen Bestandsaufnahme. Bevor Empfehlungen ausgesprochen oder Code geschrieben wird, verschaffe ich mir einen vollständigen Überblick: Welche Oracle-Version läuft im Einsatz? Welche PL/SQL-Packages gibt es, und wie sind ihre Abhängigkeiten? Welche Performance-Probleme sind bekannt? Wenn eine Migration geplant ist: Was ist der Zeitplan, welche Anwendungen hängen am Oracle-System, welche ETL-Prozesse müssen abgelöst werden? Diese Fragen müssen beantwortet sein, bevor technische Lösungen diskutiert werden.

• Bestandsaufnahme: Oracle-Version, Schema-Inventar, PL/SQL-Abhängigkeiten, Performance-Probleme
• Priorisierung: Performance-Kritisches, Migrationspfad, Legacy-Risiken
• Entwicklung/Tuning: Schrittweise Umsetzung mit Review-Schleifen und Regressionstests
• Migration: SSMA-Analyse, Konvertierung, Datenmigration, Parallelbetrieb, Abnahme
• Dokumentation: PL/SQL-Kommentierung, Migrationsleitfaden, Betriebsdokumentation
• Wissenstransfer: Schulung des internen Teams, Übergabe von Skripten und Abläufen

Ich arbeite remote, hybrid und vor Ort. Für PL/SQL-Entwicklung, Performance-Analyse und SSMA-Konvertierung ist Remote ausreichend und effizient. Für initiale Schema-Workshops, sensible Datenmigrations-Cutover und die Inbetriebnahme der Zielplattform ist persönliche Präsenz oft wertvoller. Die Sprache der Zusammenarbeit ist Deutsch, Englisch oder Portugiesisch – alle drei fliessend, auch für technische Diskussionen.

Was Oracle-Projekte von anderen Datenbankprojekten unterscheidet, ist die Tiefe der Legacy-Abhängigkeiten. Oracle-Systeme laufen oft seit Jahren oder Jahrzehnten; der PL/SQL-Code ist gewachsen, die Autoren sind längst weg, die Dokumentation ist sparsam. In solchen Umgebungen ist die Fähigkeit, fremden Code schnell zu verstehen und sicher zu ändern oder zu migrieren, wichtiger als das Schreiben von neuem Code nach Spezifikation. Diese Fähigkeit habe ich in mehreren Legacy-Migrations-Projekten eingesetzt und weiterentwickelt.

Typische Leistungen im Oracle-Umfeld

Das Spektrum meiner Oracle-Leistungen deckt Entwicklung, Performance-Optimierung, Migration und Datenmigration ab. Je nach Projektanforderung übernehme ich einzelne Bereiche oder das vollständige Spektrum von der Analyse bis zur produktiven Inbetriebnahme.

• PL/SQL-Entwicklung: Packages, Prozeduren, Funktionen, Cursor, Bulk Collect, Exceptions
• Performance-Tuning: Explain Plan-Analyse, Optimizer-Hints, Index-Optimierung, Bind-Variablen
• Oracle-zu-SQL-Server-Migration: Schema-Analyse, SSMA-Einsatz, Datentyp-Mapping
• PL/SQL-zu-T-SQL-Konvertierung: Cursor, Exceptions, Package-State, Sequences zu IDENTITY
• Datenmigration: ETL mit SSIS, Oracle-JDBC-Connector, Validierung, Parallelbetrieb
• Tooling: SQL*Plus-Skriptautomatisierung, SQL Developer, TOAD Performance-Diagnostik
• ANSI-SQL-Refactoring für plattformübergreifende Reports (Crystal Reports, SSRS)
• ODI (Oracle Data Integrator): Grundlagen, Interfaces, Knowledge Module-Konzepte
• Oracle-ETL-Ablösung durch SSIS: Java+Oracle-Prozesse auf SSIS-Strecken umstellen
• Dokumentation und Wissenstransfer: PL/SQL-Kommentierung, Migrations-Leitfäden

Einen besonderen Schwerpunkt bilden Migrationsprojekte, bei denen Java/Oracle-Altsysteme auf .NET/SQL Server umgestellt werden. In solchen Projekten kombiniere ich Oracle-Quellkenntnisse (PL/SQL, Datenmodell, Business-Logik im Code) mit SQL-Server-Zielkenntnisse (T-SQL, SSIS, SSMS-Administration) und .NET-Erfahrung (T4-Templates für Code-Generierung, tSQLt-Tests für die migrierte Logik). Diese Kombination verringert den Koordinationsaufwand zwischen Oracle-Spezialisten, SQL-Server-Entwicklern und .NET-Entwicklern erheblich.

Im Versicherungsbereich habe ich mit ODI (Oracle Data Integrator) gearbeitet: Interfaces, Knowledge Modules (KM) für verschiedene Ladestrate- und technologien und die Orchestrierung von Datenmigrationsprozessen. Auch dort war das Ziel typischerweise die Ablösung der proprietären Oracle-ETL-Infrastruktur durch standardisierte SSIS-Strecken auf SQL Server.

Ausgewählte anonymisierte Referenzprojekte

Häufige Fragen zu Oracle und PL/SQL