Oracle DB — wenn ein einzelner Index alles verändert

Letzten Monat kontaktierte uns ein Kunde mit einem Problem, das jeder DBA kennt: Die Anwendung ist langsam. Konkret — die Suche nach Bestellungen in ihrem ERP-System dauerte 45 Sekunden. Vor einem Jahr waren es 2 Sekunden. Datenbank: Oracle 11g R2, Bestellungstabelle: 12 Millionen Zeilen.

Diagnose: EXPLAIN PLAN¶

Erster Instinkt: Wir brauchen mehr RAM oder schnellere Festplatten. Aber bevor man Hardware auf ein Problem wirft, sollte man sich den Execution Plan ansehen. In 90 % der Fälle liegt das Problem im SQL oder fehlenden Indizes. Oracle führte einen FULL TABLE SCAN auf der ORDERS-Tabelle durch, gefolgt von einem NESTED LOOPS Join mit der CUSTOMERS-Tabelle. Kein Index auf der ORDER_DATE-Spalte, nach der gesucht wurde.

Lösung¶

Ein Composite Index auf den Spalten aus der WHERE-Klausel. Nach Erstellung des Index und Aktualisierung der Statistiken änderte sich der Execution Plan dramatisch. Die Kosten fielen von 47.832 auf 234. Die Abfragezeit von 45 Sekunden auf 0,3 Sekunden.

Histogramme — der verborgene Held¶

Die STATUS-Spalte hatte eine stark ungleichmäßige Werteverteilung — 95 % der Zeilen waren ACTIVE. Ohne Histogramm schätzte Oracle eine 50/50-Verteilung, was zu fehlerhaften Execution Plans führte. Lösung: DBMS_STATS.GATHER_TABLE_STATS mit einem Histogramm auf der STATUS-Spalte.

Partitioning¶

Für die Tabelle mit 12 Millionen Zeilen empfahlen wir Range Partitioning nach ORDER_DATE. Monatliche Partitionen = Partition Pruning = weitere Beschleunigung. Bonus: Die Archivierung alter Daten wird trivial.

AWR-Monitoring¶

Wir richteten wöchentliche AWR-Reports mit einem automatischen Alert ein, wenn ein Top-SQL-Statement seinen Execution Plan ändert. Prävention ist besser als Feuerwehr spielen.

Regeln für SQL-Optimierung¶

1. Immer EXPLAIN PLAN — nicht raten, messen. 2. Composite Indizes. 3. Statistiken regelmäßig aktualisieren. 4. Histogramme für ungleichmäßig verteilte Spalten. 5. Partitioning für große Tabellen.