Stellen Sie sich vor, es ist Freitagnachmittag um 16:30 Uhr. Ein Entwickler hat gerade den Befehl Create A Table In Oracle für das neue Abrechnungssystem ausgeführt. Alles sieht sauber aus, die Spaltennamen sind logisch, die Anwendung läuft in der Testumgebung ohne Probleme. Sechs Monate später, mitten im Weihnachtsgeschäft, bricht das System zusammen. Die Datenbank-Administratoren stellen fest, dass einfache Abfragen, die früher Millisekunden dauerten, plötzlich Minuten brauchen. Der Grund liegt nicht an fehlenden Indizes oder zu wenig Arbeitsspeicher. Er liegt in der Definition der Tabellenstruktur vom ersten Tag an. Ich habe das bei einem großen deutschen Logistikdienstleister miterlebt, wo eine falsch gewählte Spaltendefinition für eine Tracking-Nummer dazu führte, dass die täglichen Batch-Läufe statt vier Stunden plötzlich vierzehn Stunden dauerten. Das kostete das Unternehmen schätzungsweise 12.000 Euro pro Tag an Überstunden und verzögerten Liefergarantien, nur weil beim Erstellen der Tabelle jemand dachte, dass "Standardwerte schon passen werden".
Die Falle der variablen Längen und der Zeilenwanderung
Ein extrem verbreiteter Fehler beim Prozess, eine neue Struktur anzulegen, ist der exzessive Einsatz von VARCHAR2 mit völlig überdimensionierten Längenangaben. Viele denken sich: "Ich nehme einfach 4000 Byte, dann passt alles rein." In der Theorie kostet das keinen Platz, da Oracle nur den tatsächlich genutzten Speicher belegt. In der Praxis ist das ein technisches Desaster.
Wenn eine Zeile ursprünglich nur 10 Byte in einer 4000-Byte-Spalte speichert und später auf 1000 Byte aktualisiert wird, passt sie oft nicht mehr in den ursprünglichen Datenblock. Oracle muss die Zeile verschieben, lässt aber einen Zeiger zurück. Das nennt man Row Chaining oder Row Migration. Wenn Sie nun eine Million Zeilen lesen, muss der Lesekopf der Festplatte oder der Speichercontroller doppelt so oft zugreifen, weil er den Zeigern folgen muss. Die Performance bricht um 50 % oder mehr ein.
Wählen Sie die Länge so knapp wie möglich und so groß wie nötig. Schauen Sie sich die echten Daten an. Wenn eine Kundennummer in Deutschland laut Norm maximal 12 Stellen hat, dann definieren Sie VARCHAR2(15) und nicht VARCHAR2(255). Das schützt die Integrität Ihrer Datenblöcke.
Create A Table In Oracle und das Missverständnis der Default-Werte
In vielen Skripten sehe ich, dass Entwickler Default-Werte für Spalten definieren, ohne über die Konsequenzen für den Speicherplatz nachzudenken. Das passiert besonders oft bei Zeitstempeln oder Status-Flags.
Das Problem mit NULL-Werten am Ende der Zeile
Oracle speichert Daten in einer Zeile effizienter, wenn die Spalten am Ende der Tabellendefinition leer (NULL) sind. Oracle muss für diese Spalten dann gar keinen Platz reservieren. Wenn Sie aber eine Tabelle bauen und eine Spalte mit einem Default-Wert wie 'N' oder 0 mitten in die Definition setzen, erzwingen Sie, dass Oracle für jede Zeile Metadaten für diese Spalte speichert, auch wenn sie nie manuell geändert wird.
Ein konkretes Beispiel aus meiner Praxis: Ein Finanzdienstleister hatte eine Tabelle mit 200 Millionen Datensätzen. Durch das einfache Umstellen der Spaltenreihenfolge — die am häufigsten gefüllten Spalten nach vorne, die optionalen nach hinten — konnten wir die Größe der Tabelle auf der Festplatte um 15 % reduzieren. Das bedeutet weniger I/O-Last, schnellere Backups und weniger Kosten für teuren Flash-Speicher im SAN.
Datentypen sind keine Empfehlungen sondern Gesetze
Einer der teuersten Fehler, den ich immer wieder sehe, ist das Speichern von Zahlen oder Daten als Strings. Man glaubt, man sei flexibel, falls "mal ein Buchstabe dazu kommt". Das ist der sicherste Weg, um die Optimierung der Datenbank komplett auszuhebeln.
Ein Projekt bei einem mittelständischen Fertiger verdeutlicht das. Sie speicherten das Datum der Produktion als VARCHAR2(10) im Format 'DD.MM.YYYY'. Als die Geschäftsführung einen Bericht über die Produktion der letzten drei Jahre wollte, musste die Datenbank jede einzelne Zeile von einem String in ein Datum umwandeln, um den Filter anzuwenden. Die Abfrage dauerte 45 Minuten. Nachdem wir die Spalte auf den korrekten DATE-Typ umgestellt hatten, sank die Zeit auf 12 Sekunden. Der Optimierer konnte nun Statistiken über die Verteilung der Daten führen und wusste genau, welche Datenblöcke er überspringen konnte.
Zudem verhindern falsche Datentypen die Verwendung von Indizes. Ein Index auf einer String-Spalte hilft nicht, wenn Sie eine mathematische Operation oder einen Datumsvergleich durchführen wollen, ohne explizite und teure Konvertierungen.
Das Märchen vom automatischen Index
Es herrscht oft der Glaube vor, dass man sich beim ersten Schritt, wenn man Create A Table In Oracle nutzt, noch keine Gedanken über den Zugriff machen muss. Das sei Aufgabe der Administratoren im späteren Verlauf. Das ist falsch.
Ein Primary Key erzeugt zwar automatisch einen Unique Index, aber das reicht selten aus. Was oft vergessen wird, sind die Foreign Key Spalten. Oracle indiziert diese nicht automatisch. Das führt bei Löschvorgängen oder Updates in der Elterntabelle oft zu massiven Sperrproblemen (Table-Level Locks) in der Kindtabelle. Ich habe Systeme gesehen, die komplett eingefroren sind, nur weil jemand einen Datensatz in einer Stammdatentabelle gelöscht hat und Oracle die gesamte Bewegungstabelle sperren musste, um die referenzielle Integrität zu prüfen. Jede Spalte, die Teil eines Foreign Keys ist, sollte in 99 % der Fälle einen manuell angelegten Index erhalten.
Der Vorher-Nachher-Vergleich in der Realität
Schauen wir uns an, wie ein typischer, naiver Ansatz im Vergleich zu einer professionellen Umsetzung aussieht.
Stellen wir uns eine Tabelle für Bestellungen vor. Der unerfahrene Entwickler schreibt ein Skript, das einfach alle Felder nacheinander auflistet. Er verwendet VARCHAR2(255) für fast alles, nutzt keine expliziten Tablespaces und verlässt sich auf die Standardeinstellungen der Datenbank. Die Spaltenreihenfolge ist zufällig, oft so, wie sie ihm gerade eingefallen sind: Bestellnummer, Kunde, Datum, Status, Kommentar, Betrag. Der Kommentar ist oft leer, steht aber in der Mitte der Zeilenstruktur.
Nach sechs Monaten wiegt diese Tabelle 500 GB, obwohl die reinen Nutzdaten nur 100 GB betragen würden. Der Platz wird durch "leere" Platzhalter und fragmentierte Datenblöcke verschwendet. Jede Volltextsuche liest Unmengen an unnötigem Ballast mit.
Der Profi hingegen analysiert zuerst die Datenverteilung. Er setzt die Bestellnummer und das Datum nach vorne. Er nutzt den Typ NUMBER mit festen Präzisionen für den Betrag, was Berechnungsfehler durch Rundungen verhindert, die bei Gleitkommazahlen auftreten können. Den Kommentar setzt er ganz ans Ende der Tabelle. Er definiert explizit einen Tablespace mit einer passenden Blockgröße und aktiviert vielleicht sogar die Kompression (Advanced Row Compression), wenn er weiß, dass die Daten oft gelesen, aber selten geändert werden.
Das Ergebnis: Die Tabelle des Profis ist nur 80 GB groß. Sie passt fast vollständig in den Buffer Cache der Datenbank. Abfragen, die beim naiven Ansatz die Festplatte zum Glühen brachten, laufen hier komplett im Arbeitsspeicher ab. Die Antwortzeiten sind um den Faktor 50 schneller, ohne dass teurere Hardware gekauft werden musste.
Das Logging-Dilemma bei Massenimporten
Wenn Sie eine Tabelle initial befüllen, ist das Standardverhalten von Oracle, jede einzelne Änderung im Redo-Log mitzuschreiben. Das ist wichtig für die Ausfallsicherheit, aber bei der Erstellung von Milliarden von Testdaten oder bei Migrationen ist es eine Bremse.
Ich habe erlebt, wie ein Importprozess 20 Stunden dauerte, weil die Redo-Logs auf langsamen Platten lagen. Durch das Setzen der Tabelle auf NOLOGGING während der Erstellungs- und Ladephase konnten wir dieselbe Datenmenge in unter zwei Stunden importieren. Man muss nur wissen, dass man danach sofort ein Backup machen muss, da die Daten im Falle eines Absturzes nicht wiederherstellbar sind. Viele trauen sich das nicht oder wissen nicht, wie sie das Risiko managen sollen. In der Praxis ist es oft der einzige Weg, um enge Zeitfenster bei Wochenend-Migrationen einzuhalten.
Speicherparameter und die unterschätzte PCTFREE-Einstellung
Oracle lässt standardmäßig 10 % Platz in jedem Datenblock für zukünftige Updates (PCTFREE). Wenn Sie eine Tabelle haben, die nach dem Einfügen nie wieder geändert wird — zum Beispiel ein Log-Archiv — verschwenden Sie damit 10 % Ihres gesamten Speichers. Bei einer 1-Terabyte-Tabelle sind das 100 GB für absolut nichts.
Umgekehrt: Wenn Sie eine Tabelle haben, in der Zeilen ständig wachsen, sind 10 % viel zu wenig. Die Zeilen werden sofort migriert, was die Performance ruiniert. Ich habe bei einem Telekommunikationsanbieter die PCTFREE auf 30 % gesetzt für eine Tabelle, die Profileinstellungen speichert. Die Fragmentierung sank massiv, und die CPU-Last der Datenbank ging um 15 % zurück, weil der Overhead für das Management der verschobenen Zeilen wegfiel.
Realitätscheck
Erfolgreich mit Oracle zu arbeiten bedeutet, die Arroganz abzulegen, dass die Hardware schon alles richten wird. Oracle ist ein extrem mächtiges Werkzeug, aber es verzeiht keine Faulheit beim Design. Wenn Sie denken, Sie können "einfach mal schnell" eine Tabelle hinklatschen und die Performance später durch Tuning-Experten lösen lassen, liegen Sie falsch. Schlechtes physisches Design lässt sich im Nachhinein nur durch extrem aufwendige Migrationen korrigieren, die oft Downtime bedeuten.
Es gibt keine magische Einstellung, die eine schlecht strukturierte Tabelle rettet. Sie müssen verstehen, wie die Daten auf die Festplatte geschrieben werden. Sie müssen wissen, welche Datentypen welche mathematischen Eigenschaften haben. Und Sie müssen den Mut haben, Entwicklern zu widersprechen, die alles in "flexiblen" Universalspalten speichern wollen. Oracle belohnt Präzision und bestraft Vagheiheit mit hohen Lizenzkosten für zusätzliche Prozessoren, die nur dazu da sind, ineffizienten Code und schlechte Strukturen zu kompensieren. Wer es richtig macht, spart am Ende nicht nur Zeit, sondern echtes Geld bei der Infrastruktur.
